[arch-general] iptables script

Jakub Klinkovský kuba.klinkovsky at gmail.com
Tue Sep 10 14:01:01 EDT 2013


On 10.09.13 at 13:27, F. Gr. wrote:
> I'm newbie about iptables. I use this script
> <http://pastebin.ca/2447430> for my system. It is based on
> <http://wiki.archlinux.org/index.php/Simple_stateful_firewall>. Now I
> want to add an iptables log chain and others. What is the correct
> line to start adding the following?
> 
> <script>
> ## Logging
> $IPT -N LOGDROP
> $IPT -A LOGDROP -m limit --limit 5/m --limit-burst 8 -j LOG --log-prefix "IPTables-Dropped: "
> $IPT -A LOGDROP -j DROP
The position of these lines in script does not matter much, place it anywhere
below line 27.

> 
> # log and drop packets that hit this rule
> $IPT -A INPUT -m conntrack --ctstate INVALID -j LOGDROP
This should replace '$IPT -A INPUT -m conntrack --ctstate INVALID -j DROP' (line
47 in the script)

> </script>
> 
> Supposing I want to add the following lines as well, is there any
> rules that is superfluous? These rules have to place after or before
> the rule "$IPT -A INPUT -m conntrack --ctstate INVALID -j DROP"?
> 
> <script>
> # SSH bruteforce attacks
> $IPT -N IN_SSH
For consistency, place it below the definition on other chains, line 32.

> $IPT -A INPUT -p tcp --dport ssh -m conntrack --ctstate NEW -j IN_SSH
The ssh connections should be handled before it falls into TCP chain, so place
this rule before '$IPT -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP'
(line 50).

> $IPT -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 3 --seconds 10 -j DROP
> $IPT -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 4 --seconds 1800 -j DROP
> $IPT -A IN_SSH -m recent --name sshbf --set -j ACCEPT
Same as the LOGDROP chain (see above), anywhere below line 27.

> $IPT -A INPUT -p tcp --dport ssh -m conntrack --ctstate NEW -j IN_SSH
You don't have to duplicate the rules.

> 
> ## Local Area Network Denial (LAND) attack
> # Block all packets from your own IP
> $IPT -A INPUT -s 192.168.201.2/32 -j DROP
> # Block any packet from local network
> $IPT -A INPUT -s 127.0.0.0/8 -j DROP
> 
> # SYN Flood
> $IPT -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
> 
> # SYN packets
> # Drop any tcp packet that does not start a connection with a syn flag
> $IPT -A INPUT -p tcp ! --syn -m conntrack --ctstate NEW -j DROP
> 
> # NULL packets
> $IPT -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
> 
> # XMAS packets
> $IPT -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
> 
> # Fragments Packet
> $IPT -A INPUT -f -j DROP
> 
> # ping of death
> $IPT -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
> 
> # Furtive port scanner
> $IPT -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT
> </script>
I'm not sure about the rest, I think it should go before any rule in INPUT chain
with target ACCEPT (in the script that is
'$IPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT' on line 43,
icmp echo-request (line 41) does not count - it is already handled). The Simple
Stateful Firewall article on ArchWiki states that "Dropping all traffic and
specifying what is allowed is the best way to make a secure firewall.", so at
least some of these rules might be superfluous.

> 
> 

I don't know how you use the script, but you might consider using the
'iptables-restore' command to switch between multiple iptables configurations.
If you still want to use the iptables.service, you can make the file
/etc/iptables/iptables.rules a symlink and change its target to change the
configuration.
You can run 'iptables-save > foo.rules' to save current iptables configuration,
edit the file to your liking (adding comments etc.), and finally run
'iptables-restore < foo.rules' to load the saved configuration.

Regards,
Jakub Klinkovský (Lahwaacz)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20130910/cfe256c9/attachment.asc>


More information about the arch-general mailing list