Iptables

 Iptables options

--append -A chain Append to chain
--check -C chain Check for the existence of a rule
--delete -D chain Delete matching rule from chain
--delete -D chain rulenum Delete rule rulenum (1 = first) from chain
--insert -I chain [rulenum] Insert in chain as rulenum (default 1=first)
--replace -R chain rulenum Replace rule rulenum (1 = first) in chain
--list -L [chain [rulenum]] List the rules in a chain or all chains
--list-rules -S [chain [rulenum]] Print the rules in a chain or all chains
--flush -F [chain] Delete all rules in chain or all chains
--zero -Z [chain [rulenum]] Zero counters in chain or all chains
--new -N chain Create a new user-defined chain
--delete-chain -X [chain] Delete a user-defined chain
--policy -P chain target Change policy on chain to target
--rename-chain -E old-chain new-chain Change chain name, (moving any references)

-----------------------------------------------------------------------------------------------

--table       -t table        table to manipulate (default: 'filter')

--ipv4 -4 Nothing (line is ignored by ip6tables-restore)
--ipv6 -6 Error (line is ignored by iptables-restore)

[!] --proto -p proto protocol: by number or name, eg. `tcp'
[!] --source -s address[/mask][...] source specification
[!] --destination -d address[/mask][...]

--jump -j target target for rule (may load target extension)
--goto -g chain jump to chain with no return

[!] --in-interface -i input name[+] network interface name ([+] for wildcard) (Name of an interface via which a packet was received (only for packets entering the INPUT, FORWARD and PREROUTING chains))

[!] --out-interface -o output name[+] network interface name ([+] for wildcard) (Name of an interface via which a packet is going to be sent (for packets entering the FORWARD, OUTPUT and POSTROUTING chains))

 Iptables built-in tables and chains

Tables are bunch of chains, and chains are bunch of firewall rules.

Filtering point (chains)	Table				Description
	Filter	Nat	Mangle	Raw
INPUT	O		O		for packets destined to local sockets
FORWARD	O		O		for packets being routed through the box
OUTPUT	O	O	O	O	for altering locally-generated packets before routing
PREROUTING		O	O	O	for altering packets as soon as they come in
POSTROUTING		O	O		for altering packets as they are about to go out
	for filtering packets	for NAT	for specialized packet alteration	for configuring exemptions from connection tracking

 Questions about iptables

1. Why should we use iptables-restore instead of iptables command ?
2. What happens if packet reach the end of a user-defined chain?
3. Can an accepted packet in a chain can be dropped somewhere?
4. What happens if a packet reach the RETURN target in built-in chains?
5. What happens if we do not set the default policy and a packet reach the end of a built-in chain?
6. Why should we use the raw table with the NOTRACK target?

 Very nice tutorial forstudying Iptables: https://www.frozentux.net/iptables-tutorial/chunkyhtml/index.html

8.1. Speed considerations

One of the largest reasons for using the iptables-save and iptables-restore commands is that they will speed up the loading and saving of larger rule-sets considerably. The main problem with running a shell script that contains iptables rules is that each invocation of iptables within the script 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 that is needed by this specific command. Finally, it will insert the new rule-set from its own memory into kernel space. Using a shell script, this is done for each and every rule that we want to insert, and for each time we do this, it takes more time to extract and insert the rule-set.

To solve this problem, there is the iptables-save and restore commands. The iptables-save command is used to save the rule-set into a specially formatted text-file, and the iptables-restorecommand 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. In other words, instead of dropping the rule-set out of kernel some 30,000 times, for really large rule-sets, and then upload it to kernel again that many times, we can now save the whole thing into a file in one movement and then upload the whole thing in as little as three movements depending on how many tables you use.

Chapter 11. Iptables targets and jumps

We could then add a jump target to it like this:

iptables -A INPUT -p tcp -j tcp_packets
    

We would then jump from the INPUT chain to the tcp_packets chain and start traversing that chain. When/If we reach the end of that chain, we get dropped back to the INPUT chain and the packet starts traversing from the rule one step below where it jumped to the other chain (tcp_packets in this case). If a packet is ACCEPTed within one of the sub chains, it will be ACCEPT'ed in the superset chain also and it will not traverse any of the superset chains any further. However, do note that the packet will traverse all other chains in the other tables in a normal fashion.

11.1. ACCEPT target

This target needs no further options. As soon as the match specification for a packet has been fully satisfied, and we specify ACCEPT as the target, the rule is accepted and will not continue traversing the current chain or any other ones in the same table. Note however, that a packet that was accepted in one chain might still travel through chains within other tables, and could still be dropped there. There is nothing special about this target whatsoever, and it does not require, nor have the possibility of, adding options to the target. To use this target, we simply specify -j ACCEPT.

11.15. RETURN target

The RETURN target will cause the current packet to stop traveling through the chain where it hit the rule. If it is the subchain of another chain, the packet will continue to travel through the superior chains as if nothing had happened. If the chain is the main chain, for example the INPUT chain, the packet will have the default policy taken on it. The default policy is normally set to ACCEPT, DROP or similar.

For example, let's say a packet enters the INPUT chain and then hits a rule that it matches and that tells it to --jump EXAMPLE_CHAIN. The packet will then start traversing the EXAMPLE_CHAIN, and all of a sudden it matches a specific rule which has the --jump RETURN target set. It will then jump back to the INPUT chain. Another example would be if the packet hit a --jump RETURN rule in the INPUT chain. It would then be dropped to the default policy as previously described, and no more actions would be taken in this chain.

Notes:

• Log and check log:

iptables -t filter -A INPUT -p icmp --icmp-type echo-reply -j LOG --log-prefix="filter INPUT: your comment here."

tail -n 0 -f /var/log/syslog || tail -n 0 -f /var/log/messages

 Related knowlegge

Iptables manpage: https://linux.die.net/man/8/iptables

TCP Flags: PSH and URG http://packetlife.net/blog/2011/mar/2/tcp-flags-psh-and-urg

The PSH flag in the TCP header informs the TCP layer of sending host should send the data immediately and the receiving host should be pushed up the data to the receiving application immediately.

The URG flag is used to inform a receiving station that certain data within a segment is urgent and should be prioritized. If the URG flag is set, the receiving station evaluates the urgent pointer, a 16-bit field in the TCP header. This pointer indicates how much of the data in the segment, counting from the first byte, is urgent. The URG flag isn't employed much by modern protocols.

The concept of default policies within chains raises two fundamental possibilities that we must first consider before we decide how we are going to organize our firewall.

1. We can set a default policy to DROP all packets and then add rules to specifically allow (ACCEPT) packets that may be from trusted IP addresses, or for certain ports on which we have services running such as bittorrent, FTP server, Web Server, Samba file server etc.

or alternatively,

2. We can set a default policy to ACCEPT all packets and then add rules to specifically block (DROP) packets that may be from specific nuisance IP addresses or ranges, or for certain ports on which we have private services or no services running.

Generally, option 1 above is used for the INPUT chain where we want to control what is allowed to access our machine and option 2 would be used for the OUTPUT chain where we generally trust the traffic that is leaving (originating from) our machine.

Default value for default policies is ACCEPT as you can see when typing iptables -L: Chain INPUT (policy ACCEPT). It can be set manually by command: iptables -P chain target

Conntrack and the state machine is rather resource hungry. For this reason, it might sometimes be a good idea to turn off connection tracking and the state machine. http://www.iptables.info/en/connection-state.html#UNTRACKEDCONNS

One example would be if you have a heavily trafficked router that you want to firewall the incoming and outgoing traffic on, but not the routed traffic. You could then set the NOTRACK mark on all packets not destined for the firewall itself by ACCEPT'ing all packets with destination your host in the raw table, and then set the NOTRACK for all other traffic. This would then allow you to have stateful matching on incoming traffic for the router itself, but at the same time save processing power from not handling all the crossing traffic.

Another example when NOTRACK can be used is if you have a highly trafficked webserver and want to do stateful tracking, but don't want to waste processing power on tracking the web traffic. You could then set up a rule that turns of tracking for port 80 on all the locally owned IP addresses, or the ones that are actually serving web traffic. You could then enjoy statefull tracking on all other services, except for webtraffic which might save some processing power on an already overloaded system.

There is however some problems with NOTRACK that you must take into consideration. If a whole connection is set with NOTRACK, then you will not be able to track related connections either, conntrack and nat helpers will simply not work for untracked connections, nor will related ICMP errors do. You will have to open up for these manually in other words. When it comes to complex protocols such as FTP and SCTP et cetera, this can be very hard to manage. As long as you are aware of this, you should be able to handle this however.

To see connection tracking information, we can use command: cat/proc/net/ip_conntrack

If You Enjoyed This, Take 5 Seconds To Share It