On Thursday 10 January 2013 6:01:24 pm Dimitri Yioulos wrote: > On Thursday 10 January 2013 5:42:03 pm 叶雨飞 wrote: > > I would suggest look into use hashlimit module, which > > allow you to peek into /proc and have a better > > understanding what ip/block is triggering > > > > On Thu, Jan 10, 2013 at 10:55 AM, Dimitri Yioulos > > > > <dyioulos@xxxxxxxxxxxxx> wrote: > > > Hello, all, and Happy New Year. > > > > > > A few weeks ago I added a post about how to tweak the > > > set up of rules to drop the ip addresses of machines > > > trying to do a brute force login via ipop3d. What > > > I've noticed is that few, if any, addresses are being > > > dropped. Fortunately, I have fail2ban installed on > > > our mail server, so the attacks are being blunted. > > > Still, I'd like to cut these attacks off at the pass, > > > so to speak. With you kind indulgence, allow me to > > > provide information on my set-up again so that > > > perhaps someone can help me get this working > > > properly. > > > > > > Our mail server sits in a DMZ; NAT and Forward rules > > > are in place to make the mail server work (and it > > > does, very well). So, what I did was set the Forward > > > rules to jump to a chain I created called > > > "block_email_brute" (the name sucks, but, hey). Here > > > are the rules: > > > > > > block_email_brute tcp -- anywhere > > > server.mydomain.com tcp dpt:pop3 > > > > > > block_email_brute tcp -- anywhere > > > server.mydomain.com tcp dpt:smtp > > > > > > And here are the rules in the "block_email_brute" > > > chain: > > > > > > tcp -- anywhere > > > server.mydomain.com tcp dpt:pop3 state NEW recent: > > > SET name: DEFAULT side: source > > > > > > LOG tcp -- anywhere > > > server.mydomain.com tcp dpt:pop3 state NEW recent: > > > UPDATE seconds: 60 hit_count: 6 TTL-Match name: > > > DEFAULT25 side: source LOG level info prefix `Anti > > > Email Bruteforce: ' > > > > > > DROP tcp -- anywhere > > > server.mydomain.com tcp dpt:pop3 state NEW recent: > > > UPDATE seconds: 60 hit_count: 6 TTL-Match name: > > > DEFAULT side: source > > > > > > tcp -- anywhere > > > server.mydomain.com tcp dpt:smtp state NEW recent: > > > SET name: DEFAULT25 side: source > > > > > > LOG tcp -- anywhere > > > server.mydomain.com tcp dpt:smtp state NEW recent: > > > UPDATE seconds: 60 hit_count: 6 TTL-Match name: > > > DEFAULT25 side: source LOG level info prefix `Anti > > > Email Bruteforce: ' > > > > > > DROP tcp -- anywhere > > > server.mydomain.com tcp dpt:smtp state NEW recent: > > > UPDATE seconds: 60 hit_count: 6 TTL-Match name: > > > DEFAULT25 side: source > > > > > > ACCEPT tcp -- anywhere anywhere > > > tcp flags:SYN,RST,ACK/SYN > > > > > > ACCEPT tcp -- anywhere anywhere > > > tcp state RELATED,ESTABLISHED > > > > > > I realize that port 110 is the one being attacked, > > > but I added 25 just for good measure. > > > > > > I hope the above information is clear and complete > > > enough. Your help is greatly appreciated. > > > > > > Dimitri > > > > > > -- > > > This message has been scanned for viruses and > > > dangerous content by MailScanner, and is > > > believed to be clean. > > > > > > -- > > > To unsubscribe from this list: send the line > > > "unsubscribe netfilter" in the body of a message to > > > majordomo@xxxxxxxxxxxxxxx More majordomo info at > > > http://vger.kernel.org/majordomo-info.html > > I appreciate the suggestion, and will take a look at > hashlimit. But, why isn't rate-limiting working for me, > as per the above rules? Bump - Can anyone else shed light on this? Many thanks. Dimitri -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
