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? -- 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
