Server Security / email and ftp

Discussion in 'General' started by danielborene, Jun 20, 2009.

  1. till

    till Super Moderator Staff Member ISPConfig Developer

    Last edited: Jan 5, 2012
  2. cbj4074

    cbj4074 Member

    I wish I had seen that link earlier ;). Thanks for pointing me in the right direction, Till.

    The cited tutorial contains the correct information regarding the log location (/var/log/syslog), which is good to see.

    However, when I change my fail2ban configuration to match that in the tutorial, I'm never banned in my tests.

    I have not changed the pure-ftpd configuration or logging options, for what that's worth.

    I tried passing the sample log line and regex from the tutorial to fail2ban-regex, and a match is found, so I'm not sure why I'm never banned. I have made sure that my IP address is not white-listed in the fail2ban configuration.

    With fail2ban's loglevel = 3, nothing is logged when I repeatedly fail authentication. The maxretry threshold is set to 3, and I've tried dozens of times -- still nothing.

    If I set fail2ban's loglevel = 4, there is simply too much output for me to sort-out the log entries.

    Is this a question for the fail2ban mailing list?

    Unfortunately, I've introduced another issue while attempting to troubleshoot this one.

    I forced a log rotation for all logs when I meant to force a rotation only for /var/log/auth.log. (I wanted to force a rotation because this file was some 400MB in size, and parsing it with fail2ban-regex was taking too long.) Now, nothing is being written to /var/log/auth.log. If I tail the file, and for example, log-in via SSH, nothing is written to the log. After a day or so, the log is still empty. Why might rotating the log cause this behavior? :confused:

    The files look like this:

    Code:
    -rw-r-----  1 syslog   adm         0 Jan  4 09:49 auth.log
    -rw-r-----  1 syslog   adm      376M Jan  5 08:32 auth.log.1
    
    EDIT: Now that I look at these dates, I realize that the auth.log.1 file is the one being modified, not auth.log.

    I should add that auth.log was never being rotated (which is why it was 376MB in size), so I created the file /etc/logrotate.d/auth and populated it with the following contents:

    Code:
    /var/log/auth.log {
    	weekly
    	rotate 12
    }
    
    I forced the log rotation after creating this file, if I recall correctly.

    The relevant entry in /etc/syslog.conf looks correct:

    Code:
    auth,authpriv.*          -/var/log/auth.log
    
    Any idea why this would cause the .1 log file to become the primary log? Is there a simple way to fix this?
     
    Last edited: Jan 5, 2012
  3. cbj4074

    cbj4074 Member

    Okay, all is well, finally. :cool:

    When I removed the file I had created at /etc/logrotate.d/auth, the system began logging to /var/log/auth.log again.

    Even though the pure-ftpd-mysql jail in fail2ban was not monitoring this file (it was monitoring /var/log/syslog), the fact that /var/log/auth.log was empty seemed to keep fail2ban from banning via the pure-ftpd-mysql jail. This is strange, given that fail2ban continued banning for other jails, such as postfix.

    I don't know why /var/log/auth.log is never rotated on this system, because I have other systems that are nearly identical on which that log is rotated every three days.

    Once I sort that, I'll be a happy camper!
     
  4. enqx

    enqx New Member

    THIS WORKED on ISPCONFIG 3.0.4.3 and Debian Lenny.
     
  5. PermaNoob

    PermaNoob Member

    Thanks a lot--that missing \ in ])?: (.+?@<HOST>) sure caused a lot of trouble, including having Hetzner take my server offline for 6 hours because of the pure-ftpd attacks that weren't being blocked.
     
    Last edited: Feb 1, 2013

Share This Page