Dropping brute force attacks

Dropping brute force attacks

[Dimitri Yioulos]

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.

Re: Dropping brute force attacks

[Dimitri Yioulos]

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@onpointfc.com> 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@vger.kernel.org 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.

Re: Dropping brute force attacks

[Dimitri Yioulos]

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@onpointfc.com> 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@vger.kernel.org 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.