Saminnet-Search Article Wiki Forum Piwigo SNS Cloud vtiger Sugar
saminnet info

Articles

Firewall Concepts

With all the possible security threats roaming around the Internet today, a security firewall should be considered a mandatory necessity for any computer systems connected to the Internet. A firewall is a networking device which is used to separate private networks from external access by providing a certain level of security rules and controls.

A simple firewall can be configured to block all access to certain networks, workstations and communication ports. A more complex firewall is capable of inspecting each individual packet that attempts to pass through it and ensures that they are correctly formatted and appropriate to the services provided for (or by) the internal network, this is called a packet filtering firewall.

This chapter will explain some of the concepts forツiptablesツand packet forwarding which can be used to secure your private network. The example configurations provided in each section are only designed to provide an introduction into each of those specific sections, while an example firewall script has been included which will provide simple but effective security for your networked system.

Note !! Many of the newer broadband modems provide built-in firewall features that allow for stateful packet inspection and detailed network address translations, which are capable of providing a high security level for your internal network.

Packet Forwarding

Packet forwarding is a simple concept where the server allows data packets to pass from one network to another. As with the diagram below, packets from the private network are allowed to be forwarded through the server and out to the ISP and vice versa.

ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツツ ツ/-----------------------\
ツツ ツ ツ ツツ /-----------------\ ツツ ツ | ツ Server (Routing) ツツ | ツ ツ ツ/-----------------\
ツツ ツ ツ ツツ | Private Network |------|ツ eth1 : 192.168.1.1 ツ | ツ ツツ | ISP Connection ツ|
ツ ツ ツ ツ ツ | 192.168.1.0/24 ツ| ツ ツツ |-----------------------| ツ ツツ | REMOTE IP ADDR ツ|
ツ ツ ツ ツ ツ \-----------------/ ツ ツツ | eth0 : 123.123.123.2ツ |------| 123.123.123.1 ツ |
ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ\-----------------------/ ツ ツツ \-----------------/

There are a few initial considerations. First, the server must have networks or gateways defined in its routing table so it can make an informed decision where the packet needs to be passed to. Second, the server must have packet forwarding enabled. Thirdly, if the routed packets came from anツRFC1918private subnet, they must be translated into globally routed IP addresses (NAT covered later) before they will be accepted out on the Internet.

Packet forwarding can be enabled either manually as required by the superuser, or automatically when the system starts the networking service. To manually enable or disable packet forwarding, use the respective commands listed below.

[bash]#ツecho 1 > /proc/sys/net/ipv4/ip_forward

[bash]#ツecho 0 > /proc/sys/net/ipv4/ip_forward


To enable automatic packet forwarding for whenever the network service is active, make the following changes in yourツ/etc/sysctl.confツfile.

[bash]#ツvi /etc/sysctl.conf

net.ipv4.ip_forward = 1

Note !! It is common practice for users to have manual control over packet forwarding, and to active or disable the function within their firewall control scripts. However setting packet forwarding to start automatically will be more suitable for a dedicated server.

Packet Filtering

Packet filtering is also a reasonably simple concept (true), however it can be very daunting for new users that don't fully understand how it works, so let's cover the basics first and build it up.

In packet forwarding the kernel is either allowed to move packets between different subnets or is not, and if it is, the decisions are made from the kernel's routing table. In packet filtering an application calledツiptablesツ(www.netfilter.org) stores a list of programmed rules which are individually tested against every packet that either tries to enter, pass through, or exit any of the system's network devices. Each rule is used to test the packet in a sequential order and if the packet matches any of the rules it is either accepted or rejected depending on the global policy and rule definitions.ツiptablesツis your firewall application and is one of the networking frameworks for your Linux kernel.

iptablesツessentially has this name because it stores the rulesets into a group of three tables which each provide different capabilities depending on the rules and the order they are applied. We will only examine theツfilterツandツnatツtables here, theツmangleツtable is used for specialised packet alteration which is beyond our scope. The following table displays theツfilterツiptables and the three built-in chains.

Table Name Chain Name Chain Details
filter INPUT For any packet coming into the system
FORWARD For any packet that is being routed through the system
OUTPUT For any packet that is leaving the system


To list theツfilterツtable and its rules you can use the following command.

[bash]#ツiptables -t filter -nvL


Theツfilterツtable is the default table when working withツiptables, so there is no need to add '-t filter' at the command prompt.

[bash]#ツiptables -nvL

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
ツpkts bytes targetツツツツ prot opt inツツツツ outツツツツ sourceツツツツツツツツツツツツツツ destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
ツpkts bytes targetツツツツ prot opt inツツツツ outツツツツ sourceツツツツツツツツツツツツツツ destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
ツpkts bytes targetツツツツ prot opt inツツツツ outツツツツ sourceツツツツツツツツツツツツツツ destinationツ


You should see an output similar to above, if not then stop the iptables service and output the table again. From the listing you can see the three built in chains, and their default policies are all set toツACCEPT, which means the firewall is inactive.

[bash]#ツ/etc/init.d/iptables stop


The output from the top listing does not provide much information, so let's populate the table with some of our own rules. Type the following commands at the prompt then output a listing of the table again.

01- [bash]#ツiptables -P INPUT DROP
02- [bash]#ツiptables -P FORWARD DROP
03- [bash]#ツiptables -P OUTPUT DROP
04- [bash]#ツiptables -A INPUTツ -i lo -j ACCEPT
05- [bash]#ツiptables -A OUTPUT -o lo -j ACCEPT
06- [bash]#ツiptables -A INPUTツ -i ppp0 -p tcp --sport 80 -j ACCEPT
07- [bash]#ツiptables -A OUTPUT -o ppp0 -p tcp --dport 80 -j ACCEPT
08- [bash]#ツiptables -A INPUTツ -i eth1 -s 192.168.1.0/24 -p tcp --dport 3128 -j ACCEPT
09- [bash]#ツiptables -A OUTPUT -o eth1 -d 192.168.1.0/24 -p tcp --sport 3128 -j ACCEPT

[bash]#ツiptables -nvL

01-

04-
06-
08-

02-


03-

05-
07-
09-

Chain INPUT (policy DROP 0 packets, 0 bytes)
ツpkts bytes targetツツツツ prot opt inツツツツ outツツツツ sourceツツツツツツツツツツツツツツ destination
ツツツ 0ツツツツ 0 ACCEPTツツツツ allツ --ツ loツツツツ *ツツツツツツ 0.0.0.0/0ツツツツツツツツツツツ 0.0.0.0/0
ツツツ 0ツツツツ 0 ACCEPTツツツツ tcpツ --ツ ppp0ツツ *ツツツツツツ 0.0.0.0/0ツツツツツツツツツツツ 0.0.0.0/0ツツツツツツツツツツ tcp spt:80
ツツツ 0ツツツツ 0 ACCEPTツツツツ tcpツ --ツ eth1 ツ *ツツツツツツ 192.168.1.0/24ツツツツツツ 0.0.0.0/0ツツツツツツツツツツ tcp dpt:3128

Chain FORWARD (policy DROP 0 packets, 0 bytes)
ツpkts bytes targetツツツツ prot opt inツツツツ outツツツツ sourceツツツツツツツツツツツツツツ destination

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
ツpkts bytes targetツツツツ prot opt inツツツツ outツツツツ sourceツツツツツツツツツツツツツツ destination
ツツツ 0ツツツツ 0 ACCEPTツツツツ allツ --ツ *ツツツツツ loツツツツツ 0.0.0.0/0ツツツツツツツツツツツ 0.0.0.0/0
ツツツ 0ツツツツ 0 ACCEPTツツツツ tcpツ --ツ *ツツツツツ ppp0ツツツ 0.0.0.0/0ツツツツツツツツツツツ 0.0.0.0/0ツツツツツツツツツツ tcp dpt:80
ツツツ 0ツツツツ 0 ACCEPTツツツツ tcpツ --ツ *ツツツツツ eth1 ツツ 0.0.0.0/0ツツツツツツツツツツツ 192.168.1.0/24ツツツツツ tcp spt:3128


The nine commands which you typed above have been numbered along with their output so they can be easily identified in the second table.

Lines 01-03:ツThe first three commands set the default (-P) policy on all the chains toツDROPツeverything, unless suitable rules inside the chain willツACCEPTツthem. This is the most secure method of filtering as any packet that is now to pass through any of the chains, must have a specific rule written for it.

Lines 04-05:ツThese two commands have (-A) appended twoツACCEPTツrules. TheツOUTPUTツrule (05) allows any packet to (-o) leave via the loopback device and theINPUTツrule (04) allows packets to re-enter (-i) via the loopback.

Because the chains are using a defaultツDROPツpolicy, they restrict the server from accessing any of its own services running on the local host, like DNS. A basic rule like this allows the server to access all loopback services without restriction.

Lines 06-07:ツThe next two (-A) appended rules are more specific, lets look at the outbound one first. TheツOUTPUTツrule (07) specifies that any packet going out the (-o) ppp0 interface using (-p) protocolツTCPツisツACCEPTed if its going toツport 80. TheツINPUTツrule (06) specifies that any packet coming in the (-i) ppp0 interface using (-p) protocolツTCPツisツACCEPTed if its coming fromツport 80.

You should be able to pick this up, it says that we are allowed to access external web servers from our own server, but there are no forward rules for the internal network to surf the Internet. We should also allow our internal network the ability to access external web servers too shouldn't we? Let's look at the next rules then.

Lines 08-09:ツThe lastツINPUTツrule (08) which has been (-A) appended to the chain allows any packets from the (-s) source network ofツ192.168.1.0/24ツif they enter through the (-i)ツeth1ツdevice and if they are theツTCPツ(-p) protocol and are going to the (--dport) destination port ofツ3128.ツ The matchingツOUTPUTツrule (09) has been (-A) appended to the chain and allows any packets that are going out (-o) theツeth1ツinterface to (-d) destination networkツ192.168.1.0/24ツusing theツTCP(-p) protocol if it came from the (--sport) source port ofツ3128.

These two are fairly detailed rules, they say that anyone on the internal network (192.168.1.0/24) is allowed to send packets to the squid proxy server (3128) through the internal eth1 interface and the results can be returned to the workstation.

If you use a strictツDROPツpolicy like above, its important to note that you may need two rules that complement each other in order for data to flow out and back in again.

A Walk Through

To better understand the above filtering example, its best to walk the configuration through the same way a packet would be subject to the filtering table's definitions, one rule at a time. Remember, every packet of data has certain attributes, source/destination addresses, source/destination ports, the interfaces they are coming in and out and the type of protocol being used, the filtering will reject any packet whose attributes dont match any of the rules in our chains.

A person using the workstation (in the network example below) wishes to access the resources of the web server located on the Internet, can a direct connection be established? No, all the policies are set toツDROPツand there is noツFORWARDツrules defined, so it simply can not occur.

Can the proxy server access the web server on the Internet? Yes, the proxy server has the rights to access anything which is TCP based operating at port 80 out through the ppp0 link, which is to a web server. Can you see theツACCEPTツrules for the packet's attributes in the complementingツINPUTツandツOUTPUTツchains?

ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツツ ツ/-----------------------\
ツツ ツ ツ ツツ /-----------------\ ツツ ツ |ツ Proxy Server (3128)ツ | ツツ ツ /---------------\
ツツ ツ ツ ツツ | ツ Workstation ツ |------| ツeth1 : 192.168.1.1 ツ | ツ ツ ツ|ツ Web Server ツ |
ツ ツ ツ ツ ツ | ツ 192.168.1.10 ツ| ツ ツツ | ツppp0 : 123.123.123.2 |------| (TCP port 80) |
ツ ツ ツ ツ ツ \-----------------/ ツ ツツ | ツ ツlo : 127.0.0.1 ツ ツ | ツ ツ ツ\---------------/
ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ\-----------------------/

The only way now for the workstation to access anything, is via the proxy server application running at port 3128, which in turn can access any web server resources on the Internet and return the requested information to the workstation. Are the required rules in the table?

How does this work without any forwarding rules? Easy, the proxy server is an application that requests resources on behalf of a client, so the request comes into the proxy from the client, and now the request goes out to the web server from the proxy, as though it was requesting the information itself. This happens at the application layer, because its the proxy application which forwards the clients original request, so forwarding at the IP layer is not required here.

Hopefully you have been able to pick up the filtering concepts mentioned above, if you have, well done. The proxy server situation was a little tricky, but was introduced to give you an understanding that particular packets and resources can still be shaped to suit your security requirements by incorporating them into your network design.

Thats a brief introduction to packet filtering, the ability to write and chain together rules that selectively accept or deny any packets that do not meet the security requirements for your network.

What happens to the filter table when you type these following commands? View the table's output after each one and see if you can recognise the effects of the rules, and which direction the packets can pass (i.e., are they going to an internal or external resource). View "man iptables" for further assistance.

[bash]#ツiptables -I INPUTツ 2 -i ppp0 -p tcp --dport ftp -j ACCEPT
[bash]#ツiptables -I OUTPUT 2 -o ppp0 -p tcp --sport ftp -j ACCEPT

[bash]#ツiptables -D INPUTツ -i ppp0 -p tcp --sport 80 -j ACCEPT
[bash]#ツiptables -D OUTPUT -o ppp0 -p tcp --dport 80 -j ACCEPT

[bash]#ツiptables -A INPUTツ -p icmp --icmp-type any -j ACCEPT
[bash]#ツiptables -A OUTPUT -p icmp --icmp-type any -j ACCEPT

[bash]#ツiptables -I INPUTツ -m state --state INVALID -j LOG --log-prefix "INVALID Input: "
[bash]# iptables -I INPUTツ -m state --state INVALID -j DROP

[bash]#ツiptables -F
[bash]#ツ/etc/init.d/iptables restart

Network Address Translation

Network Address Translation (NAT) is the ability to change a data packets destination or source IP address on-the-fly, so the packet looks like it came from (or is going to) a different address than the original (also works on port numbers).

There are many reasons why we should use NAT, here are a few:

  • Frees the requirement to use large amounts of 'real' IP addresses (cheaper),
  • Allows packets from a private (RFC1918) network to be globally routed out to the Internet,
  • Allows packets on the Internet to be routed into a private (RFC1918) network,
  • It masks the true amount of private workstations, as all external traffic appears to come from the one source,
  • It allows inbound traffic to be sent to different internal hosts (bastions) depending on the resources requested, and
  • It does not disclose any security details of the internal private network.

Theツiptablesツpackage also provides support for NAT and has a built-inツnatツtable just for that purpose. Below is a listing of the default chains that are found in theツnatツtable and an explanation of how they are applied.

Table Name Chain Name Chain Details
nat PREROUTING For altering packets as they are entering the system (before filter INPUT)
POSTROUTING For altering packets as they are exiting the system (after filter OUTPUT)
OUTPUT For alteringツ packets before leaving the local system (before the routing table)ツ


As the naming suggests, theツPREROUTINGツandツPOSTROUTINGツchains are applied before or after any kernel routing decisions are made, so the packets can then be routed to match any new changes which have been made to the destination or source addresses.

To list the contents of theツnatツtable, issue the following command at the prompt.

[bash]#ツiptables -t nat -nvL

Source NAT

Source NAT deals with changing the source address of any packets that pass through the NAT device, assuming they meet the criteria of the specified policies and chains. This allows workstations on a private network to send data packets through the NAT device which changes the source address in the packet's header before sending the packet onto the Internet. When the packet reaches its destination and is processed, the distant host returns the packet using the adjusted address as the new destination address, and delivers it back to the NAT device. The NAT device stores a list in memory of all the packets it adjusts, so when they are returned, the packets can be redirected to the real originator of the packets on the internal private network.

Source NAT can be written for inbound and outbound packets, but are more commonly used for outbound.

For a packet to be subject to SNAT, lets consider the following details:

  • The packet has meet at least one rule in all threeツfilterツchains (INPUT, FORWARD, OUTPUT),
  • The packet has been checked against the kernel routing table, and a decision on where to route has been made,
  • As the packet leaves the NAT device, the source address is changed to the NATs external IP address,
  • The NAT device remembers the real owner of the packet.

It all sounds rather confusing, so lets go straight to an example. Type the following rules at the command prompt and then display the contents of theツfilterandツnatツtables with the last command (typed as one line).

01- [bash]#ツiptables -P INPUT ACCEPT
02- [bash]#ツiptables -P FORWARD DROP
03- [bash]#ツiptables -P OUTPUT ACCEPT
04- [bash]#ツiptables -A FORWARD -i eth1 -o ppp0 -s 192.168.1.0/24 -p tcp --dport 80 -j ACCEPT
05- [bash]#ツiptables -A FORWARD -i ppp0 -o eth1 -d 192.168.1.0/24 -p tcp --sport 80 -j ACCEPT
06- [bash]#ツiptables -t nat -A POSTROUTING -o ppp0 -s 192.168.1.0/24 -j SNAT --to-source 123.123.123.2
07- [bash]#ツecho 1 > /proc/sys/net/ipv4/ip_forward

[bash]#ツiptables -nvL ; iptables -t nat -nvL

01-


02-

04-
05-

03-

06-

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
ツpkts bytes targetツツツツ prot opt inツツツツ outツツツツ sourceツツツツツツツツツツツツツツ destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
ツpkts bytes targetツツツツ prot opt inツツツツ outツツツツ sourceツツツツツツツツツツツツツツ destination
ツツツ 0ツツツツ 0 ACCEPTツツツツ tcpツ --ツ eth1 ツ ppp0ツツツ 192.168.1.0/24ツツツツツツ 0.0.0.0/0ツツツツツツツツツツ tcp dpt:80
ツツツ 0ツツツツ 0 ACCEPTツツツツ tcpツ --ツ ppp0ツツ eth1 ツツ 0.0.0.0/0ツツツツツツツツツツツ 192.168.1.0/24ツツツツツ tcp spt:80

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
ツpkts bytes targetツツツツ prot opt inツツツツ outツツツツ sourceツツツツツツツツツツツツツツ destination

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
ツpkts bytes targetツツツツ prot opt inツツツツ outツツツツ sourceツツツツツツツツツツツツツツ destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
ツpkts bytes targetツツツツ prot opt inツツツツ outツツツツ sourceツツツツツツツツツツツツツツ destination
ツツツ 0ツツツツ 0 SNATツツツツツツ allツ --ツ *ツツツツツ ppp0ツツツ 192.168.1.0/24ツツツツツツ 0.0.0.0/0ツツツツツツツツツツ to:123.123.123.2

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
ツpkts bytes targetツツツツ prot opt inツツツツ outツツツツ sourceツツツツツツツツツツツツツツ destination


Lines 01-03:ツThe first three commands have now defined the global policies for the three built-in chains for theツfilterツtable.

To keep the example a little easier to understand, we are going to accept everything that is classed asツINPUTツorツOUTPUT, and for security we are dropping anything trying to pass through (FORWARD) the NAT unless we allow it.

Lines 04-05:ツThe two forward rules are quite specific. Rule 04 says that any packet that comes in (-i) theツeth1ツinterface and goes (-o) out theツppp0ツdevice from the (-s) source network ofツ192.168.1.0/24ツcan beツACCEPTed if its going to (--dport) destination portツ80; a web server. Rule 05 is the matching rule allowing the packet to return back through the NAT.

We don't have anyツINPUTツorツOUTPUTツrestrictions here, so we only need to write and match rules that allow packets to pass through (FORWARD) the NAT. In the diagram below, when a HTTP(80) request comes from the private network, it is allowed to pass through the NAT and continue to the web server out on the Internet. But what are the packet's attributes? Its source address is still 192.168.1.x, so when it reaches its destination, the web server does not know where it came from because its a private non-routableツRFC1918ツIP address, so the server will probably just drop it. No packets will ever be returned.

ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツツ ツ/-----------------------\
ツツ ツ ツ ツツ /-----------------\ ツ ツツ | ツNAT Gateway Device ツ | ツツ ツ /---------------\
ツ ツ ツ ツ ツ | Private Network |------| ツeth1 : 192.168.1.1 ツ | ツ ツツ | ツWeb Server ツ |
ツ ツ ツ ツ ツ | 192.168.1.0/24ツ | ツ ツツ | ツppp0 : 123.123.123.2 |------| (TCP port 80) |
ツ ツ ツ ツ ツ \-----------------/ ツ ツ ツ\-----------------------/ ツ ツ ツ\---------------/

Line 06:ツThis rule is our solution to the above problem. This rule is applied after the routing decisions have been made and the packet is about to depart for the web server out on the Internet. It says, any packet that goes (-o) out theツppp0ツinterface from the (-s)ツ192.168.1.0/24ツnetwork is to have the source address rewritten asツ123.123.123.2.

Now when the packet reaches the Internet web server, it can be processed normally and returned toツ123.123.123.2ツ(the NAT device), where it will automatically be rewritten again and sent back to the original workstation on the internal private network.

Line 07:ツThis command tells the kernel that it is allowed to forward packets between any of its network devices. These packets are still subject to the iptables rulesets.

Some important points about SNAT to remember are:

  • SNAT is used in theツPOSTROUTINGツchain after the kernel routing decisions have been made,
  • Forwarding rules need to be suitable to allow packets in both directions,
  • The "--to-source" address should be the external IP address which will be visible on the packets return, and
  • SNAT should not be used for dynamic links where the IP address is likely to change (see masquerading, next).

IP Masquerading

Put simply, masquerading is a form of SNAT which should be used for all dynamic interfaces where the IP address is likely to be different each time we connect. This is perfect for our dynamic IP broadband accounts, and saves having to rewrite large SNAT rules each time we connect to the Internet. SNAT remembers connection state information (to a degree) if a static connection was to drop, however using masquerading the connection state information is reset each time the interface is (de)activated. Masquerading automates SNAT for dynamic IP connections.

Because masquerading is so easy (true) we are going to use some state tracking attributes in our rules. Type the following rules at the command prompt and display a listing of theツfilterツandツnatツtables.

01- [bash]#ツiptables -P INPUT ACCEPT
02- [bash]#ツiptables -P FORWARD DROP
03- [bash]#ツiptables -P OUTPUT ACCEPT
04- [bash]#ツiptables -A FORWARD -i ppp0 -m state --state ESTABLISHED,RELATED -j ACCEPT
05- [bash]#ツiptables -A FORWARD -i eth1 -o ppp0 -s 192.168.1.0/24 -j ACCEPT
06- [bash]#ツiptables -t nat -A POSTROUTING -o ppp0 -s 192.168.1.0/24 -j MASQUERADE
07- [bash]#ツecho 1 > /proc/sys/net/ipv4/ip_forward

[bash]#ツiptables -nvL ; iptables -t nat -nvL

01-


02-

04-
05-

03-

06-

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
ツpkts bytes targetツツツツ prot opt inツツツツ outツツツツ sourceツツツツツツツツツツツツツツ destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
ツpkts bytes targetツツツツ prot opt inツツツツ outツツツツ sourceツツツツツツツツツツツツツツ destination
ツツツ 0ツツツツ 0 ACCEPTツツツツ allツ --ツ ppp0ツツ *ツツツツツツ 0.0.0.0/0ツツツツツツツツツツツ 0.0.0.0/0ツツツツツツツツツツ state RELATED,ESTABLISHED
ツツツ 0ツツツツ 0 ACCEPTツツツツ tcpツ --ツ eth1 ツ ppp0ツツツ 192.168.1.0/24ツツツツツツ 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
ツpkts bytes targetツツツツ prot opt inツツツツ outツツツツ sourceツツツツツツツツツツツツツツ destination

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
ツpkts bytes targetツツツツ prot opt inツツツツ outツツツツ sourceツツツツツツツツツツツツツツ destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
ツpkts bytes targetツツツツ prot opt inツツツツ outツツツツ sourceツツツツツツツツツツツツツツ destination
ツツツ 0ツツツツ 0 MASQUERADE allツ --ツ *ツツツツツ ppp0ツツツ 192.168.1.0/24ツツツツツツ 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
ツpkts bytes targetツツツツ prot opt inツツツツ outツツツツ sourceツツツツツツツツツツツツツツ destination


Lines 01-03:ツThe first three commands have now defined the global policies for the three built-in chains for theツfilterツtable.

To keep the example a little easier to understand, we are going to accept everything that is classed asツINPUTツorツOUTPUT, and for security we are dropping anything trying to pass through (FORWARD) the NAT unless we explicitly allow it.

Line 04:ツRule 04 deals with the connection state and says, any packet that comes in the (-i)ツppp0ツinterface must (-m)ツmatchツa certainツstate, and theツstateツmust ensure the packet is in response to an alreadyツRELATEDツorツESTABLISHEDツconnection.

Basically only allow packets to be forwarded into the private network if the packet is in response to an alreadyツRELATEDツorツESTABLISHツconnection. This rule will not allow anyツNEWツconnections to be initiated from the external network a connection must already existed, so any packet coming inside will be in response to a current connection that could have only be initiated from the internal network.

Line 05:ツThis is a simple rule that will forward any packets from the (-i)ツeth1ツinterface and out the (-o)ツppp0ツinterface if they are from the (-s)ツ192.168.1.0/24source network.

This is rule does not detail any connection state so it will allow all connection types, but most important is theツNEWツconnection state that it can pass. This rule allows internal workstations to create new connections, and matches rule 4 which allow the packets to return.

Line 06:ツThis rule does the exact same as if it were aツSNATツrule, however being aツMASQUERADEツrule means it will use the IP address that is currently assigned to theツppp0ツinterface when the packet passes through the NAT device.

Any packets that now pass from the internal private network out into the Internet will have its source address rewritten as the external IP address of the NAT device.

Line 07:ツThis command tells the kernel that it is allowed to forward packets between any of its network devices. These packets are still subject to the iptables rulesets.

Remember, masquerading should always be used for dynamic IP connections.

Dangerous Masquerading Rule

Beware of this rule, it is too relaxed and does not specify which direction the packets should be masqueraded. In fact, this rule allows masquerading in BOTH directions. Always specify an (-o) out interface parameter to make the rule work in one direction only.

[bash]#ツiptables -t nat -A POSTROUTING -j MASQUERADE

Warning !! WARNING: The above rule is dangerous, it allows masquerading in both directions.

Destination NAT

Destination NAT deals with changing the destination address of any packets before they are subjected to any routing decisions. This allows specific traffic to be rewritten so it suits a particular rule and can then be redirected depending on the global policies and destinations required.

In its most typical application, DNAT is normally used to change incoming packets that are destined for a particular service or host, and it rewrites the destination addresses so the packets can pass to a different host located inside the private network, normally a DMZ.

When DNAT occurs, the original host (which is located external of the private network) is not aware the packets have been redirected and that the returning data is from a different server. It should be transparent to the originator.

The following commands can be typed at the command prompt, and theツfilterツandツnatツtables displayed using the last command.

01- [bash]#ツiptables -P INPUT ACCEPT
02- [bash]#ツiptables -P FORWARD DROP
03- [bash]#ツiptables -P OUTPUT ACCEPT
04- [bash]#ツiptables -A FORWARD -i eth1 -o ppp0 -s 192.168.1.0/24 -j ACCEPT
05- [bash]#ツiptables -A FORWARD -i ppp0 -o eth1 -p tcp --dport 80 -j ACCEPT
06- [bash]#ツiptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.2:80
07- [bash]#ツecho 1 > /proc/sys/net/ipv4/ip_forward

[bash]#ツiptables -nvL ; iptables -t nat -nvL

01-


02-

04-
05-

03-


06-

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
ツpkts bytes targetツツツツ prot opt inツツツツ outツツツツ sourceツツツツツツツツツツツツツツ destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
ツpkts bytes targetツツツツ prot opt inツツツツ outツツツツ sourceツツツツツツツツツツツツツツ destination
ツツツ 0ツツツツ 0 ACCEPTツツツツ allツ --ツ eth1 ツ ppp0ツツツ 192.168.1.0/24ツツツツツツ 0.0.0.0/0
ツツツ 0ツツツツ 0 ACCEPTツツツツ tcpツ --ツ ppp0ツツ eth1 ツツ 0.0.0.0/0ツツツツツツツツツツツ 192.168.1.0/24ツツツツツ tcp dpt:80

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
ツpkts bytes targetツツツツ prot opt inツツツツ outツツツツ sourceツツツツツツツツツツツツツツ destination

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
ツpkts bytes targetツツツツ prot opt inツツツツ outツツツツ sourceツツツツツツツツツツツツツツ destination
ツツツ 0ツツツツ 0 DNATツツツツツツ tcpツ --ツ ppp0ツツ *ツツツツツツ 0.0.0.0/0ツツツツツツツツツツツ 0.0.0.0/0ツツツツツツツツツツ tcp dpt:80 to:192.168.1.2:80

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
ツpkts bytes targetツツツツ prot opt inツツツツ outツツツツ sourceツツツツツツツツツツツツツツ destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
ツpkts bytes targetツツツツ prot opt inツツツツ outツツツツ sourceツツツツツツツツツツツツツツ destination


Lines 01-03:ツThe first three commands have now defined the global policies for the three built-in chains for theツfilterツtable.

To keep the example a little easier to understand, we are going to accept everything that is classed asツINPUTツorツOUTPUT, and for security we are dropping anything trying to pass through the NAT unless we allow it.

Line 04-05:ツThe firstツFORWARDツrule (04) allows any packets coming in the (-i)ツeth1ツinterface and out the (-o)ツppp0ツinterface if they have come from the internal (-s) sourceツ192.168.1.0/24ツnetwork. The secondツFORWARDツrule (05) allows any packets coming in the (-i)ツppp0ツinterface and out the (-o)ツeth1ツinterface that are using theツTCPツ(-p) protocol if they are going to (--dport) destination portツ80.

These two rules complement each other, the first allows outgoing packets to be forwarded from the internal network and the second rule allows incoming packets to be forwarded into the private network but only if they are going to a web server (port 80).

Is this going to work? Well lets look at the incoming packet's attributes with the following diagram. The remote host that originally sent the data requested a web page URL of "http://www.example.com" which resolved to the IP address of 123.123.123.2 and the packet was sent on its way. When it arrives at the NAT device, the destination address is still 123.123.123.2 so it must be handled by that IP address or rejected. But the web server is inside the network, what do we do?

ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツ ツツ ツ/-----------------------\
ツ ツ ツ /---------------------\ ツ ツ ツ| ツServer (Routing) ツ ツ | ツ ツ ツ/-----------------\
ツ ツ ツ | Internal Web Server |------| ツeth1 : 192.168.1.1 ツ | ツ ツツ | Remote Computer |
ツ ツ ツ | ツ 192.168.1.2(80) ツ | ツ ツ ツ|ツ ppp0 : 123.123.123.2 |------| (Internet Zone) |
ツ ツ ツ \---------------------/ ツ ツ ツ\-----------------------/ ツ ツ ツ\-----------------/

This is where DNAT is able to change the destination address of the incoming packet, and put the new address in its place (192.168.1.2(80)). Because DNAT isツPREROUTING, the packet is now subjected to the kernel routing table which points the new packet to the internal network. Lastly, there must exist a rule in theツFORWARDツchain which will allow the packet to pass through, and there is, rule 05.

Line 06:ツThis is aツPREROUTINGツrule in theツnatツtable, if any packets come in through the (-i)ツppp0ツinterface and are (-p)ツTCPツpackets going to (--dport) destination of portツ80, then they are to be rewritten and sent to the hostツ192.168.1.2:80ツinstead.

Line 07:ツThis command tells the kernel that it is allowed to forward packets between any of its network devices. These packets are still subject to the iptables rulesets.

DNAT declarations are reasonably easy because the destination header can be rewritten before the routing table is queried. Some important points to remember are:

  • DNAT can rewrite packets as they enter the Firewall (before routing),
  • If the new destination host is hacked, the Firewall host is not affected,
  • Do not DNAT a packet to another system that will DNAT it back (routing loops),
  • The "--to-destination" address does not have to be on the internal network, and
  • DNAT can also be used internally to protect vital systems from nasty employees.

Example Firewall Script

The following is an example firewall script which uses all of the concepts covered already in this chapter. It should therefore be relatively easy to understand, implement and maintain.

The firewall script is designed to separate and secure the private network (eth1) from the Internet traffic (ppp0), while providing some flexibility for the internal network which is being masqueraded.

[bash]#ツvi /root/firewall.sh
#!/bin/sh
#
#ツツツツツツ Example Firewall Script

###############################################################
### Define interfaces here
EXT_DEV=ppp0
INT_DEV=eth1
INT_NET=192.168.1.0/24

### Loading firewall modules
modprobe ip_conntrack
modprobe ip_conntrack_ftp

###############################################################
### Enable Packet Forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

### Remove all previous rules, and delete any user defined chains
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X

### Set the default policies to drop
iptables -P INPUTツツ DROP
iptables -P OUTPUTツ DROP
iptables -P FORWARD DROP

### Loopback device OK
iptables -A INPUTツ -i lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT
iptables -A OUTPUT -o lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT

### Allow all ICMP Traffic (optional) - IN, OUT and THROUGH.
iptables -A INPUT ツ -p icmp --icmp-type any -j ACCEPT
iptables -A OUTPUTツ -p icmp --icmp-type any -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type any -j ACCEPT

### Allow all Internal traffic to Server
iptables -A INPUTツ -i $INT_DEV -s $INT_NET -d $INT_NET -j ACCEPT
iptables -A OUTPUT -o $INT_DEV -s $INT_NET -d $INT_NET -j ACCEPT

###############################################################
### OUTBOUND Rule: Allow ALL packets out the external device
iptables -A OUTPUTツ -o $EXT_DEV -j ACCEPT
iptables -A FORWARD -i $INT_DEV -o $EXT_DEV -j ACCEPT

###############################################################
### MASQUERADING: All packets from the internal network will
### appear as if they had originated from the firewall.
iptables -t nat -A POSTROUTING -o $EXT_DEV -s $INT_NET -j MASQUERADE

###############################################################
### INBOUND Rule: Allow ALL EXT packets if a connection already exists (See "NEW" Inbound Rules)
iptables -A INPUTツツ -i $EXT_DEV -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $EXT_DEV -m state --state RELATED,ESTABLISHED -j ACCEPT


#
### INBOUND Rules: Allow ONLY NEW packets on these ports.
#

# New INBOUND Connection: FTP (with TLS)
iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn --dport 20ツツ-j ACCEPT
iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn --dport 21ツ -j ACCEPT

# New INBOUND Connection: Secure Shell
iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn --dport 22ツツ-j ACCEPT

# New INBOUND Connection: SMTP and SMTPS (over TLS/SSL)
iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn --dport 25ツツ-j ACCEPT
iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn --dport 465 -j ACCEPT

# New INBOUND Connection: HTTP (Plain and SSL)
iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn --dport 80ツ -j ACCEPT
iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn --dport 443 -j ACCEPT

# New INBOUND Connection: LDAPS Server (over SSL)
iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn --dport 636ツ-j ACCEPT

# New INBOUND Connection: IMAPS Email Clients (over SSL)
iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn --dport 993 -j ACCEPT

###
# ツ ツSquid Transparent Proxy: Enable rule for transparent proxy redirection
# Redirect all WWW (port 80) OUTBOUNT packets to the Squid Server on portツ3128
#iptables -t nat -A PREROUTING -i $INT_DEV -s $INT_NET -p tcp --dport 80ツ -j REDIRECT --to-port 3128


#
### INBOUND DNAT (redirection) Rules: Allow ONLY NEW packets on these ports and redirect to internal services.
#

### INBOUND Rule: Redirect ALL packets to the INTERNAL workstation - HTTP
#iptables -t nat -A PREROUTING -i $EXT_DEV -p tcp --dport 80 -j DNAT --to-destination wkstn1.example.com:80
#iptables -A FORWARD -i $EXT_DEV -o $INT_DEV -p tcp --dport 80 -j ACCEPT

### INBOUND Rule: Redirect ALL packets to the INTERNAL workstation - HTTPS
#iptables -t nat -A PREROUTING -i $EXT_DEV -p tcp --dport 443 -j DNAT --to-destination wkstn1.example.com:443
#iptables -A FORWARD -i $EXT_DEV -o $INT_DEV -p tcp --dport 443 -j ACCEPT


After the firewall script has been executed and the new firewall rules are active, the iptable settings can be saved so they are automatically implemented when the firewall is next started.

[bash]#ツsh /root/firewall.sh
[bash]#ツ/etc/init.d/iptables save


You should now restart the iptables service and see if the tables and chains are the same.

[bash]#ツ/etc/init.d/iptables restart
[bash]#ツiptables -nvL ; iptables -t nat -nvL


If you intend to use the initscripts to automatically start the iptables service, then any firewall modules that are needed will have to be manually added to the init script.

[bash]#ツvi /etc/init.d/iptables

IPTABLES_MODULES="ip_conntrack ip_conntrack_ftp"


You can check to see if the modules loaded automatically by listing all of modules currently being used by the kernel.

[bash]#ツlsmod

Comments   

 
0 #1 Guest 2019-04-23 23:35
Whats up are using Wordpress for your site platform?
I'm new to the blog world but I'm trying to get started and set up my own.
Do you need any html coding expertise to make your own blog?
Any help would be really appreciated!

Look at my site :: luxury138
Quote
 

TweetTweet Share on LinkedInShare on LinkedIn Share on Google+Google+ Submit to RedditReddit Publish on WordPress WordPress Send emailSend email