Differences

This shows you the differences between two versions of the page.

--- linux:iptables [2013/08/07 13:16]
5.39.219.26 zplaofpb
+++ linux:iptables [2013/10/25 15:16] (current)
a add Per user traffic accounting (moved from linux:networking)
@@ Line 1: / Line 1: @@
-bmawbuou, http://prospectfunding.com/ Priligy kostar, zsVzYWk.
+====== Linux filtering / firewalling (netfilter/iptables stuff) ======
+==== P2P blocking/limiting ====
+== Links ==
+  * [[http://ipp2p.org/]]
+  * [[http://l7-filter.sourceforge.net/]]
+  * [[http://iptables-tutorial.frozentux.net/iptables-tutorial.html]]
+  * [[linux:iptables:l7patch|Debian ipp2p+l7 patch cookbook]]
+  * [[http://brownian.org.ua/?page_id=17|py-htbstat]] -  //is a tool for collecting HTB kernel statistics, it allows to view graphs and perform basic analysis.//
+  * [[http://dev.inversepath.com/trac/ftester|FTester -- Firewall and IDS Testing tool]]
+==== Netfilter concept / network flow ====
+Click on picture below to see more ..
+{{ linux:24net.png?100 }}
+==== Logging and limiting SSH bruteforce attacks ====
+Logging is easy, just add the same rule but with a ''-j LOG –log-prefix SSHBRUTE'' or whatever you want. eg;
+   iptables -A INPUT -m hashlimit -m tcp -p tcp –dport 22 –hashlimit \
+/min –hashlimit-mode srcip –hashlimit-name ssh -m state \
+             –state NEW -j LOG –log-prefix SSHBRUTE
+As for permantely adding hosts, why? Poluting a firewall ruleset with a rule that isn’t going to be hit frequently is a waste. Which is why the hashlimit rule is perfect for this situation.
+See also [[http://www.ducea.com/2006/06/28/using-iptables-to-block-brute-force-attacks/|this]].
+==== A solution for blocking ssh probers/scanners. ====
+  ### Catch SSH probes
+  iptables -A FORWARD -p tcp --dport 22 -d <local net> -o eth0 -s 0/0 -i ppp0
+         -m state --state NEW
+         -m recent --rcheck --hitcount 3 --seconds 60 --name SSH_PROBERS
+         -j LOG --log-prefix "Adaptive-FW SSH Prober: "
+  iptables -A FORWARD -p tcp --dport 22 -d <local net> -o eth0 -s 0/0 -i ppp0
+         -m state --state NEW
+         -m recent --update --hitcount 3 --seconds 60 --name SSH_PROBERS
+         -j DROP
+  iptables -A FORWARD -p tcp --dport 22 -d <local net> -o eth0 -s 0/0 -i ppp0
+         -m state --state NEW
+         -m recent --set --name SSH_PROBERS
+         -j ACCEPT
+So, in the INPUT chain, you wouldn't use -o, and -d would be the IP on your external link.. in this example, ppp0.
+What it does, is uses the ''ipt_recent'' module, tracking connections from a given IP. 3 incoming connections in 60 seconds will cause the remote host to be blocked. Of course, this affects normal logins too, so for known hosts, it pays to insert a rule beforehand that does a ''-j ACCEPT''.
+===== Per user traffic accounting =====
+Modern times require you to know how much traffic each user on a system is generating. A lightweight and unobtrusive way to do it is:
+<code bash>
+iptables -A PREROUTING -t mangle -j CONNMARK --restore-mark
+for interesting user in /etc/passwd #implementation dependent
+do
+        #mark all user packets with their uid
+        iptables -A OUTPUT -t mangle -m owner --uid-owner $uid -j MARK --set-mark $uid
+        iptables -A OUTPUT -t mangle -m owner --uid-owner $uid -j CONNMARK --save-mark
+        #add rules to count packets
+        iptables -A PREROUTING -t mangle -m mark --mark $uid -m comment --comment "count $user"
+        iptables -A POSTROUTING -t mangle -m mark --mark $uid -m comment --comment "count $user"
+done
+</code>
+Integrating this with existing firewall rules is left as an excercise for the reader.
+Observing counters is as easy as
+<code bash>
+watch "iptables -nvL PREROUTING -t mangle; echo; iptables -nvL POSTROUTING -t mangle"
+</code>
+Or you can parse them periodically and store values somewhere for further processing.
+This method identifies which user caused some traffic only for the traffic that is initiated on the machine. Traffic that originates on a remote system is not caught. I haven't yet found a way to make this work for this case too.
+Tested on rhel6.
+===== Strategy for penalising IPs with too many  simultaneous sessions  =====
+Something like this (eth0 is the user's network):
+   iptables -t mangle -A PREROUTING -p tcp -i eth0 --dport 1024: -m \
+     connlimit --connlimit-above 5 -j SET --add-set p2p src
+   iptables -t mangle -A FORWARD -o eth0 -p tcp -m multiport --sport \
+:65535 -m set --set p2p dst -j MARK --set-mark 60
+   iptables -t mangle -A FORWARD -i eth0 -p tcp -m multiport --dport \
+:65535 -m set --set p2p src -j MARK --set-mark 60
+//You'll have to compile your kernel with **''ipset''** and **''connlimit''** support.//
+===== Conntrack table full  =====
+   > Feb 23 14:26:19 gestor1 kernel: printk: 38 messages suppressed.
+   > Feb 23 14:26:19 gestor1 kernel: ip_conntrack: table full, dropping packet.
+Not necessarily the answer you were looking for, but this is what connlimit was written for. Connlimit will limit the number of parallel
+TCP connections per host. Do something like:
+  iptables -t mangle -A PREROUTING -p tcp -i eth0 --dport 1024: \
+           -m connlimit --connlimit-above 30 -j DROP
+connlimit is not in the vanilla kernel at the minute; you need to patch with pom. You can download pom from
+http://ipset.netfilter.org/install.html, but you may need to patch pom first! See http://lists.netfilter.org/pipermail/netfilter-devel/2006-July/025090.html
+===== Preventing webserver hackers from connecting to IRC servers =====
+Sometimes when a user runs some picture-gallery or forum software, your server gets more or less hacked: a hacker will start under the user with which your webserver runs ('www-run' for example) an ircbot. You can prevent this with this:
+   iptables -I OUTPUT -m owner -p tcp --destination-port 6660:6669 --uid-owner nobody -j REJECT
+//This will not work if the hacker runs his/her irc-server on a different portnumber then the ones blocked.//
+==== Firewall example (the good old TNT firewall) ====
+Download {{linux:firewall.sh|here}}