Sorry about that,
The lines it should match all the lines in the failregex as a single
event rather than as 3 different events for example in my vncserver.conf
the regex is:
    
failregex = ^.*Connections: disconnected: <HOST>::\d+ \(\[AuthFailure\]
Either the username was not recognised, or the password was incorrect
\).*$
                 ^.*Connections: disconnected: <HOST>::\d+ \(No configured 
security
type is supported by \d+.\d+ VNC Viewer\).*$
                 ^.*Connections: rejecting blacklisted connection: <HOST>.*$    
        

Someone trying to login in with the wrong security type will match the
second line, this counts as a try. If they have made x number of bad
tries over y number of seconds the before this attempt the VNC daemon
will have blacklisted that IP already. The next login attempt will match
lines 2 and 3 and they will be banned because maxretry = 2, but they
made only one login attempt this time. But if I had set up a buffer then
if they matched any or all of the three lines then it counts as 1 login
attempt and the lines don't have to be consecutive in the log. I have a
distro that uses systemd so I only have one log file and there maybe 3
or more lines from other services in between the lines.

On Wed, 2015-09-30 at 09:14 -0700, Gao wrote:

> After another look of the maillog, I see there are also at least another 
> attack like this, instead of AUTH, there are EHLO, RCPT, UNKNOWN, 
> STARTTLS and CONNECT, among these, EHLO is for sure anther attack. The 
> others does not have many attempts in a short period.
> 
> May be I should make it a wildcard in the filter. But I don't want block 
> the normal user by mistake.
> 
> Now, I set findtime=120 and maxretry=5. Also the filter now is like this:
> 
> failregex = ^%(__prefix_line)slost connection after AUTH from (.*)\[<HOST>\]
>              ^%(__prefix_line)slost connection after EHLO from (.*)\[<HOST>\]
>              ^%(__prefix_line)slost connection after UNKNOWN from 
> (.*)\[<HOST>\]
> 
> 
> Gao
> 
> 
> 
> 
> 
> 
> On 15-09-30 04:42 AM, Nick Howitt wrote:
> > I think it can be pretty bad behaviour if you get too many attempts too
> > quickly. I've seen over 1000 in 24h from a single IP. I generally see
> > nothing but every now and then someone has a go and it is a bit
> > irritating.
> >
> > I also had one IP doing about 6 attempts an hour for days until I
> > spotted it and blocked it. I was blocking 10 occurrences in an hour but
> > dropped it to 5 an hour to combat the IP.
> >
> > On 2015-09-30 12:08, Darac Marjal wrote:
> >> On Tue, Sep 29, 2015 at 02:30:47PM -0700, Gao wrote:
> >>> Hello, all
> >>>
> >>> I have the postfix-sasl jail enabled and it works well against attack,
> >>> such as
> >>> "Failed login".
> >>>
> >>> I just notified that my email server's maillog flood with this:
> >>> ...
> >>> Sep 29 14:19:21 szeta postfix/smtpd[19940]: connect from
> >>> ns3366447.ip-37-187-77.eu[37.187.77.147]
> >>> Sep 29 14:19:22 szeta postfix/smtpd[19940]: lost connection after AUTH
> >>> from
> >>> ns3366447.ip-37-187-77.eu[37.187.77.147]
> >>> Sep 29 14:19:22 szeta postfix/smtpd[19940]: disconnect from
> >>> ns3366447.ip-37-187-77.eu[37.187.77.147]
> >> "Lost connection after AUTH" means that postfix sent "AUTH" to the
> >> client, and the client disconnected. In other words, the client
> >> probably
> >> attempted some action which you've configured that only authorized
> >> users
> >> can perform (usually, this is something like sending mail to a
> >> different
> >> serveer (relaying)). Postfix said "authorize yourself in order to
> >> perform this action", and the client just dropped the connection
> >> (rather
> >> than cleanly quitting and waiting for postfix to close the conecction).
> >>
> >> In other words, no authorization was attempted.
> >>
> >> I suspect that fail2ban doesn't block this normally because it's not
> >> really bad behaviour. It's akin to someone connecting to your SSH port
> >> and disconnecting upon finding that it's asking for a password :)
> >>
> >>> ...
> >>>
> >>> And the fail2ban does nothing about this! No new entry about this in
> >>> fail2ban.log. The attack is still going and I am going to manual kill
> >>> it in
> >>> iptables.
> >>>
> >>> What should I do about this in fail2ban? Please help.
> >>>
> >>> Thanks.
> >>>
> >>> Gao
> >>>
> >>> ------------------------------------------------------------------------------
> >>> _______________________________________________
> >>> Fail2ban-users mailing list
> >>> [email protected]
> >>> https://lists.sourceforge.net/lists/listinfo/fail2ban-users
> >>
> >> ------------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> Fail2ban-users mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/fail2ban-users
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > Fail2ban-users mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/fail2ban-users
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Fail2ban-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/fail2ban-users


------------------------------------------------------------------------------
_______________________________________________
Fail2ban-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fail2ban-users

Reply via email to