Mangle Table:
-> it is used to mangling packets (change the contents of different packets and that of their headers).
-> table consists of five built in chains.
i.PREROUTING : PREROUTING is used for altering packets just as they enter the firewall and before they hit the routing decision.
ii.POSTROUTING : is used to mangle packets just after all routing decisions has been made.
iii.OUTPUT: used for altering locally generated packets before they enter the routing decision.
iv.INPUT: used to alter packets after they have been routed to the local computer itself, but before the user space application actually sees the data.
v.FORWARD: used to mangle packets after they have hit the first routing decision, but before they actually hit the last routing decision.
-> Targets that are only valid in the mangle table:
i.TOS: *The TOS target is used to set and/or change the Type of Service field in the packet.
*This could be used for setting up policies on the network regarding how a packet should be routed and so on.
ii.TTL: *The TTL target is used to change the TTL.
*We could tell packets to only have a specific TTL and so on.
iii.MARK: *The MARK target is used to set special mark values to the packet.
*These marks could then be recognized by the iproute2 programs to do different routing on the packet depending on what mark they have, or if they don’t have
any. We could also do bandwidth limiting and Class Based Queuing based on these marks.
NAT table:
-> This table should only be used for NAT (Network Address Translation) on different packets
-> it should only be used to translate the packet’s source field or destination field.
-> only first packet in a stream will hit this chain. After this, the rest of the packets will automatically have the same action taken on them as the first packet.
i.PREROUTING: is used to alter packets as soon as they get in to the firewall.
ii.OUTPUT : OUTPUT chain is used for altering locally generated packets (i.e., on the firewall) before they get to the routing decision.
iii.POSTROUTING: is used to alter packets just as they are about to leave the firewall.
-> The actual targets that do these kind of things are:
i.DNAT: *The DNAT target is mainly used to change the destination address of the packet and reroute it to the host.
ii.SNAT: *SNAT is mainly used for changing the source address of packets.
iii.MASQUERADE: *is used in exactly the same way as SNAT, but the MASQUERADE target takes a little bit more overhead to compute.
*The reason for this, is that each time that the MASQUERADE target gets hit by a packet, it automatically checks for the IP address to use,
instead of doing as the SNAT target does – just using the single configured IP address.
*The MASQUERADE target makes it possible to work properly with Dynamic DHCP IP addresses that your ISP might provide for your PPP, PPPoE or SLIP
connections to the Internet
Filter Table:
-> it is mainly used for filtering packets.
-> 3 Chains
i.Forward: FORWARD and is used on all non-locally generated packets that are not destined for our local host.
ii.INPUT: used on all packets that are destined for our local host.
iii.OUTPUT: used for all locally generated packets.
-> We can match packets and filter them in whatever way we want.
-> DROP, LOG, ACCEPT or REJECT packets.
-> This is the place that we actually take action against packets and look at what they contain and DROP or /ACCEPT them, depending on their content.
Raw table:
-> Iptable’s Raw table is for configuration excemptions.
-> Raw table has the following built-in chains.
i.PREROUTING chain
ii.OUTPUT chain
——————————————————————————————————————
State Machine:
-> It is really a connection tracking machine.
-> Connection tracking is done to let the Netfilter framework know the state of a specific connection.
-> Firewalls that implement this are generally called stateful firewalls. A stateful firewall is generally much more secure than non-stateful firewalls since it
allows us to write much tighter rule-sets.
-> packets can be tracked connections in four different so called states.
i.NEW: *the packet may as well not be a SYN packet and still be considered NEW.
ii.ESTABLISHED: *seen traffic in both directions and will then continuously match those packets.
* The NEW state will upon receipt of the reply packet to or through the firewall change to the ESTABLISHED state.
* ICMP error messages and redirects etc can also be considered as ESTABLISHED, if we have generated a packet that in turn generated the ICMP message.
iii.RELATED: * A connection is considered RELATED when it is related to another already ESTABLISHED connection.
*first have a connection that is considered ESTABLISHED. The ESTABLISHED connection will then spawn a connection outside of the main connection.
The newly spawned connection will then be considered RELATED. eg. the FTP-data connections that are considered RELATED to the FTP control port.
iv.INVALID: *means that the packet can not be identified or that it does not have any state.
-> With the –state match we can easily control who or what is allowed to initiate new sessions.
-> All of the connection tracking is done by special framework within the kernel called conntrack.
-> conntrack may be loaded either as a module, or as an internal part of the kernel itself.
-> connection tracking can not work properly without defragmenting packets.
-> All connection tracking is handled in the PREROUTING chain(nat table), except locally generated packets which are handled in the OUTPUT chain (nat table).
* If we send the initial packet in a stream, the state gets set to NEW within the OUTPUT chain, and when we receive a return packet, the state gets changed in the
PREROUTING chain to ESTABLISHED.
* If the first packet is not originated by ourself, the NEW state is set within the PREROUTING chain.
Conntract Entries:
-> /proc/net/ip_conntrack. This gives a list of all the current entries in your conntrack database,If you have the ip_conntrack module loaded.
-> The connection tracking entries may take on a series of different values, all specified in the conntrack headers available in
linux/include/netfilter-ipv4/ip_conntrack*.h files
-> When a connection has seen traffic in both directions, the conntrack entry will replace [UNREPLIED] flag with [ASSURED] flag. Connections marked as [ASSURED]
will not be erased if we reach the maximum possible tracked connections.
-> How many connections that the connection tracking table can hold depends upon a variable that can be set through the ip-sysctl functions in recent kernels.
Also depends on memory (On 128 MB of RAM you will get 8192 possible entries, for 256MB of RAM- 16376 entries. ).
You can read and set your settings through the /proc/sys/net/ipv4/ip_conntrack_max setting.
TCP Connection:
tcp 6 117 SYN_SENT src=192.168.1.5 dst=192.168.1.35 sport=1031 dport=23 [UNREPLIED] src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 use=1
tcp 6 57 SYN_RECV src=192.168.1.5 dst=192.168.1.35 sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 use=1
tcp 6 431999 ESTABLISHED src=192.168.1.5 dst=192.168.1.35 sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 use=1
*After a few more packets, the connection will also become [ASSURED].
tcp 6 431999 ESTABLISHED src=192.168.1.5 dst=192.168.1.35 sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 [ASSURED] use=1
-> When the TCP connection has been closed down, the connection enters the TIME_WAIT state, which is per default set to 2 minutes.
This is used (a kind of buffer time) so that all packets that have gotten out of order can still get through our rule-set,even after the connection has already closed.
-> A connection may also be closed by sending a RST(reset), if the connection were to be refused. In this case, the state is changed to CLOSE.
-> This means that the connection per default have 10 seconds before the whole connection is definitely closed down.
-> RST packets are not acknowledged in any sense, and will break the connection directly.
Internal states:
NONE 30 minutes
ESTABLISHED 5 days
SYN_SENT 2 minutes
SYN_RECV 60 seconds
FIN_WAIT 2 minutes
TIME_WAIT 2 minutes
CLOSE 10 seconds
CLOSE_WAIT 12 hours
LAST_ACK 30 seconds
LISTEN 2 minutes
-> these values are changed via the proc file-system in the /proc/sys/net/ipv4/netfilter/ip_ct_tcp_* variables.
-> These values are set in jiffies (or 1/100th parts of seconds), so 3000 means 30 seconds.
UDP Connection:
-> it is a stateless connections.
-> they don’t contain any connection establishment or connection closing.
udp 17 20 src=192.168.1.2 dst=192.168.1.5 sport=137 dport=1025 [UNREPLIED] src=192.168.1.5 dst=192.168.1.2 sport=1025 dport=137 use=1
*The first is the protocol name,
*and the second is protocol number.
*The third value marks how many seconds this state entry has to live.
*[UNREPLIED] flag tells us that there’s so far been no response to the packet
*The timeout at this point is set to 30 seconds, as per default.
udp 17 170 src=192.168.1.2 dst=192.168.1.5 sport=137 dport=1025 src=192.168.1.5 dst=192.168.1.2 sport=1025 dport=137 use=1
*server has seen a reply to the first packet sent out and the connection is now considered as ESTABLISHED
*The main difference is that the [UNREPLIED] flag has now gone. Moreover, the default timeout has changed to 180 seconds.
udp 17 175 src=192.168.1.5 dst=195.22.79.2 sport=1025 dport=53 src=195.22.79.2 dst=192.168.1.5 sport=53 dport=1025 [ASSURED] use=1
*small amount of traffic over that connection, it became ASSURED.
*If this connection is not used for 180 seconds, it times out.
*This value is reset to 180 sec for each packet that matches the same entry and passes through the firewall, just the same as for all of the internal states.
ICMP connections:
-> ICMP packets are far from a stateful stream.
-> There are four ICMP types that will generate return packets and these have 2 different states NEW and ESTABLISHED states.
*Echo request and reply,
*Timestamp request and reply,
*Information request and reply,
*Address mask request and reply
-> Out of these, the timestamp request and information request are obsolete.
icmp 1 25 src=192.168.1.6 dst=192.168.1.10 type=8 code=0 id=33029 [UNREPLIED] src=192.168.1.10 dst=192.168.1.6 type=0 code=0 id=33029 use=1
*host sends an echo request to the target, which is considered as NEW by the firewall. target then responds with a echo reply which the firewall considers as
state ESTABLISHED.
*have 3 new fields called type(ontains the ICMP type), code( contains the ICMP code) and id (contains the ICMP ID. Each ICMP packet gets an ID set to it when
it is sent, and when the receiver gets the ICMP message, it sets the same ID within the new ICMP message so that the sender will recognize the reply and
will be able to connect it with the correct ICMP request).
*In Reply expectation: for the type and code, these are changed to the correct values for the return packet, so an echo request is changed to echo reply and
so on. The ICMP ID is preserved from the request packet.
-> The reply packet is considered as being ESTABLISHED, after the ICMP reply, there will be absolutely no more legal traffic in the same connection.
So the connection tracking entry is destroyed once the reply has traveled all the way through the Netfilter structure
-> ICMP requests has a default timeout of 30 seconds, which you can change in the /proc/sys/net/ipv4/netfilter/ip_ct_icmp_timeout entry.
-> Another hugely important part of ICMP is the fact that it is used to tell the hosts what happened to specific UDP and TCP connections or connection attempts.
eg: ICMP Host unreachable or ICMP Network unreachable. ICMP replies will very often be recognized as RELATED to original connections or connection attempts.
Meanwhile, the firewall has destroyed the connection tracking entry since it knows this was an error message. Same for both TCP and UDP connection attempts.
Default connections:
-> it happens when it does not know about that protocol.
-> The first packet is considered NEW, and reply traffic and so forth is considered ESTABLISHED.
-> it will use defult time out values set in /proc/sys/net/ipv4/netfilter/ip_ct_generic_timeout variable.
——————————————————————————————
-> iptables package comes with two more tools that are very useful.
iptables-save
iptables-restore
-> they will speed up the loading and saving of larger rule-sets considerably
-> if adding iptables rules with shell script, it will first extract the whole rule-set from the Netfilter kernel space, and after this, it will insert or append
rules, or do whatever change to the rule-set then it will insert the new rule-set from its own memory into kernel space. it takes more time to extract and insert the
rule-set.
-> The iptables-save command is used to save the rule-set into a specially formatted text-file, and the iptables-restore command is used to load this text-file into
kernel again. The best parts of these commands is that they will load and save the rule-set in one single request.
-> iptables-save will grab the whole rule-set from kernel and save it to a file in one single movement. iptables-restore will upload that specific rule-set to kernel
in a single movement for each table.
-> it is useful when huge set of rules that needs to be inserted.
iptables-save:
iptables-save -c > /etc/iptables-save —> saving all rule sets of all tables (Filter, nat, mangle) to a file iptables-save.
iptables-save -c -t fileter > /etc/iptables-save —> saving all rule sets of all table filter to a file iptables-save..
# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:55 2002
*filter
:INPUT DROP [1:229]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -m state –state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth1 -m state –state NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m state –state NEW,RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Wed Apr 24 10:19:55 2002
* -c argument tells iptables-save to keep the values specified in the byte and packet counters.
* -t argument tells the iptables-save command which tables to save.
* The COMMIT keyword tells us that at this point we should commit all rules currently in the pipeline to kernel.
iptables-restore:
-> The iptables-restore command is used to restore the iptables rule-set that was saved with the iptables-save command.
iptables-restore [-c] [-n]
* -c restore counters that was previously saved with iptables-save. or can use like –counters
* -n not overwrite the previously written rules in the table. or can use like –noflush.
cat /etc/iptables-save | iptables-restore -c
*cat the rule-set from /etc/iptables-save file and then pipe it to iptables-restore which takes the rule-set on the standard input and then restores it, including byte and packet counters.
—————————————————————————————————————————
Building iptables:
iptables [-t table] command [match] [target/jump]
-> target instruction may be at any position at rule.
-> iptables uses the filter table by default.
Commands:
-A, –append : This command appends the rule to the end of the chain and hence be checked last.
iptables -A INPUT …
-D, –delete :
-> This command deletes a rule in a chain.
-> iptables -D INPUT –dport 80 -j DROP – by entering the whole rule to match. entry must match the entry in the chain exactly.
-> iptables -D INPUT 1 – must match the number of the rule you want to delete. The rules are numbered from the top of each chain, starting with number 1.
-R, –replace :
-> This command replaces the old entry at the specified line
-> iptables -R INPUT 1 -s 192.168.0.1 -j DROP
-> It works in the same way as the -D but instead of totally deleting the entry, it will replace it with a new entry.
-I, –insert :
-> Insert a rule somewhere in a chain as specified.
-> iptables -I INPUT 1 –dport 80 -j ACCEPT
-> inserted as rule 1 in the INPUT chain, and hence from now on it would be the very first rule in the chain.
-L, –list :
-> This command lists all the entries in the specified chain
-> iptables -L INPUT -nv
-F, –flush :
-> This command flushes all rules from the specified chain and is equivalent to deleting each rule one by one, but is quite a bit faster.
-> iptables -F INPUT
-Z, –zero :
-> to zero all counters in a chain or in all chains.
-> iptables -Z INPUT
-N, –new-chain :
-> to create a new chain of the specified name in the specified table. there must not already be a chain or target of the same name.
-> iptables -N allowed –
-X, –delete-chain:
-> deletes the specified chain from the table. there must be no rules that refer to the chain that is to be deleted.
-> If this command is used without any options, all chains but those built in to the specified table will be deleted.
-> iptables -X allowed.
-P, –policy:
iptables -P INPUT DROP
-> to set a specified default target, or policy, on a chain.
-> All packets that don’t match any rule will then be forced to use the policy of the chain.
-E, –rename-chain:
-> to change the first name of a chain, to the second name.
-> iptables -E allowed disallowed – change the name of the chain from allowed to disallowed.
————————————————————————————————————————————
Protocol:
———
-p, –protocol:
-> iptables -A INPUT -p tcp
-> used to check for certain protocols like TCP, UDP, ICMP or ALL.
-> It may also take a value specified in the /etc/protocols file,
-> The protocl may also be a integer value. ICMP – 1, TCP – 6, UDP – 17, ALL – 0.
-> can give comma delimited list of protocols, such as udp,tcp.
-> if the –protocol match is not used, ‘0’ is the default value.
-> This match can also be inversed with the ! sign. like –protocol ! tcp
-s, –src, –source:
-> iptables -A INPUT -s 192.168.1.1
-> used to match packets, based on their source IP address.
-> we can use like –src 192.168.10.0/24 , –source ! 192.168.0.0/24,
-d, –dst, –destination
-> same like source.
-i, –in-interface
-> iptables -A INPUT -i eth0
-> used for the interface the packet came in on.
-> it is only legal in the INPUT, FORWARD and PREROUTING chains.
————————————————————————————————————————————
iptables -A FORWARD -s 0/0 -i eth0 -d 192.168.1.58 -o eth1 -p TCP –sport 1024:65535 –dport 80 -j ACCEPT
TCP and udp protocol type with multiport :
iptables -A FORWARD -s 0/0 -i eth0 -d 192.168.1.58 -o eth1 -p TCP –sport 1024:65535 -m multiport –dports 80,443 -j ACCEPT
iptables -A FORWARD -d 0/0 -o eth0 -s 192.168.1.58 -i eth1 -p TCP -m state –state ESTABLISHED -j ACCEPT
ICMP protocol type:
iptables -A OUTPUT -p icmp –icmp-type echo-request -j ACCEPT
iptables -A INPUT -p icmp –icmp-type echo-reply -j ACCEPT
SYN type:
iptables -A INPUT -p tcp –syn -m limit –limit 5/s -i eth0 -j ACCEPT
User defined:
iptables -A INPUT -i eth0 -d 206.229.110.2 -j fast-input-queue
iptables -A OUTPUT -o eth0 -s 206.229.110.2 -j fast-output-queue
iptables -A fast-input-queue -p icmp -j icmp-queue-in
iptables -A fast-output-queue -p icmp -j icmp-queue-out
iptables -A icmp-queue-out -p icmp –icmp-type echo-request -m state –state NEW -j ACCEPT
iptables -A icmp-queue-in -p icmp –icmp-type echo-reply -j ACCEPT
————————————————————————————————————————————
vijayababuj 