LinuxQuestions.org
Latest LQ Deal: Complete CCNA, CCNP & Red Hat Certification Training Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 10-31-2011, 11:33 AM   #1
veeruk101
Member
 
Registered: Mar 2005
Distribution: Ubuntu 12.04 LTS
Posts: 249

Rep: Reputation: 16
Confused about learning iptables recent module


I'm using the iptables recent module to limit too frequent connections to SSH on my machine, but I have some questions about it:

What exactly is the difference between --rcheck and --update? I know update updates the last-seen time and results in a requirement of a 'quiet time' before the next packet can be accepted, but I'm having a hard time understanding this and seeing how it's different from how rcheck behaves. Would anyone who has experience with this module be able to dumb it down and simplify it for me?

My next question is about the following line, which is from the author's website. Why in this case is the update/rcheck rule BEFORE the --set rule? In all other examples I've seen, including the other examples from online I've pasted below it, the --set rule comes first. What difference does this make?

http://snowman.net/projects/ipt_recent/
Code:
iptables -A FORWARD -m recent --update --seconds 60 -j DROP
iptables -A FORWARD -i eth0 -d 127.0.0.0/8 -m recent --set -j DROP
http://blog.zioup.org/2008/iptables_recent/
Code:
iptables -t filter -I BADGUY -m recent --set --name badguys

iptables -A INPUT -i $OUTS -p tcp --syn --dport ssh -m recent --name ssh --set
iptables -A INPUT -i $OUTS -p tcp --syn --dport ssh -m recent --name ssh --rcheck --seconds 300 --hitcount 6 -j BADGUY
iptables -A INPUT -i $OUTS -p tcp --syn --dport ssh -m recent --name ssh --rcheck --seconds  30 --hitcount 2 -j DROP
http://thiemonagel.de/2006/02/preven...cent-matching/
Code:
iptables -A ssh -m recent --update --name blacklist --seconds 600 --hitcount 1 -j DROP

iptables -A ssh -m recent --set --name counting1
iptables -A ssh -m recent --set --name counting2
iptables -A ssh -m recent --set --name counting3
iptables -A ssh -m recent --set --name counting4

iptables -A ssh -m recent --update --name counting1 --seconds 20 --hitcount 3 -j blacklist
iptables -A ssh -m recent --update --name counting2 --seconds 200 --hitcount 15 -j blacklist
iptables -A ssh -m recent --update --name counting3 --seconds 2000 --hitcount 80 -j blacklist
iptables -A ssh -m recent --update --name counting4 --seconds 20000 --hitcount 400 -j blacklist
The above 2 examples both use multiple allowed rates that need to be met before allowing a packet - the first of the 2 allows less than 6 hits in 300 seconds or 2 in 30 seconds, while the second one has 4 different rates. The tutorial for the first one specified that the 300 seconds rule needed to come before the 30 seconds rule otherwise it wouldn't work right, whereas the second one lists the rules in the opposite direction, so I'm not sure why it would work...

Also the second one has created 4 different --name's for its rates (e.g. counting1, counting2...), but the first one uses 'ssh' as its --name for both rates. Which one should I consider when using this module with multiple rates?

I'm COMPLETELY confused by all this, I'd really appreciate it if someone who really understands how this works can explain it in clear terms. I'd like to have a grasp of this for my own learning and so that I can feel more confident when writing my own rules using this module of iptables. Thank you so much.
 
Old 11-01-2011, 11:22 AM   #2
serafean
Member
 
Registered: Mar 2006
Location: Czech Republic
Distribution: Gentoo, Chakra
Posts: 951
Blog Entries: 14

Rep: Reputation: 135Reputation: 135
1) AFAIK --rcheck only checks if the address is in the list, without updating the timestamp. --update also updates the timestamp. That's the only difference. As is written on the page : with rcheck, no matter how much bombarding you get, after the specified delay the address will be removed from the blacklist and a packet will make it through to a rule with -set (or -update). If you use --update, every incoming packet resets the delay.

2) The first line directly blocks (an resets the timeout) the address if it is in the list, not even bothering to check whether the initial conditions for blacklisting are met. IE : "you got on the list, and are still trying to connect to me (no matter through wich device/port)? timeout reset." The second line defines how to get on the list. In this case, I think it would work the same if you switched the lines.
I haven't found any specific reason to have it this way, except for optimization : imagine many (let's say 100+) conditions of how to get on the list, if someone fails to pass the last one, not having a rule like this at the beginning would make iptables match the incoming packet to all preceding rules, to finally discard it. This way, once you're on the list, we don't even bother to check if you're doing something nasty, you're just blocked. If anyone has a better answer, I'm all ears.

3)The 300 second rule checks whether the address is in the ssh list, and if it is, and there are more than 6 packets/300s, it also gets added to the badguy list (specified by --name in the BADGUY target [ -j BADGUY] ). I'd call this scaling up the timeout : you get on the blacklist ( 2hits/30 seconds), you're blocked for 30s, only on the ssh list. You still try to connect, and work up to 6hits/600s, you get on the badguys list, for which there could be different rules. If you put the 2hits/30s before the 6hits/300s, the address could never work its way up to the badguys list.

4) A --name specifies the name of the list to use for blacklisting, here each rule has its own list, and they are not interconnected. This rule lists every packet into all 4 lists.if it matches either of the hits/s, it gets promoted to the "blacklist" which drops all packets (1st line).

To sum up : it depends on what you want to do. The general thing to remember is that the rules are matched one after the other, and that once a packet gets dropped, there the matching stops.
With recent, you can specify more than one list, and can mix and match rules promoting packets from one list to the other, there the order of the rules is extremely important, otherwise the promoting goes wrong.
For high traffic servers, the earlier a packet gets discarded, the better, keep that in mind (might be corrected on this one, just my opinion).
Read the iptables/recent man page. (Print it out, read it at the bus stop/wherever and think about what you want to do (I did that, just thinking about things does wonders)).

I hope I explained at least a bit and that this explanation attempt somewhat clears up your questions

Serafean

Last edited by serafean; 11-01-2011 at 11:23 AM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
iptables recent frater Linux - Security 1 11-25-2010 09:13 AM
learning java input output: tutorials for a confused student sought! titanium_geek Programming 9 12-10-2008 11:27 PM
iptables -m recent conflicting Shwick Linux - Security 2 10-20-2008 08:41 PM
[SOLVED] iptables: dissecting recent module rules anomie Linux - Security 3 03-27-2008 12:32 PM
Fedora Core Test 2; iptables; recent module; missing libipt_recent.so GMcFall Red Hat 3 10-20-2003 03:59 PM


All times are GMT -5. The time now is 11:13 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration