As with all the projects available through R-fx Networks, they over time have been designed to meet the everyday administrative needs I have and there-in are released to the public as if they are useful to me they certainly must be useful to someone else.

In recent months the previous version of BFD began to show signs of it age and limitations, not that there was anything inherently wrong with it per say it was just slow over large log sets and had a few quirks that I had never gotten around to addressing as quite simply - it worked.

With some consideration to performance and overall efficiency of the current project and weighting the options, it was decided that rewriting the core functions (not that there is many) and all rule files was the best approach . A couple days later and after testing across a number of system configurations (ensim, interworx, cpanel, plesk, direct admin), I am confident in saying that the next stable release of BFD is completed.

This new version has a rewritten core check function in the main bfd script that is by far more efficient and all rule files have been rewritten to use stream based regexp parsing with sed making for incredibly superior performance:

Test Log Set:
- 1.53 million lines of log data combined from /var/log/messages and /var/log/secure from 200+ Linux Cpanel servers
- processed for a resulting total of 27,193 auth failure events
- executed 4,708 bans post-processing of rules
- time to completion of bfd run on a Pentium D 2.8Ghz system with 1GB of RAM:
BFD 1.2: 21sec average
BFD 0.9: 3 minutes 47 seconds
- Results: BFD 1.2 is roughly 10 times faster than previous versions

With the performance aside, the alerting template for e-mail alerts is now far more manageable, especially on mobile devices. The configuration file has also been reworked with all variables renamed for better consistency and management along with the ordering of variables changed for better usability.

Finally, the execution time of default BFD installs is now 3 minutes and can safely be reduced to once a minute should it be desired by the user with no noticeable performance impacts.

Having said all that, you can download the new BFD 1.2 with the following details:

Home: http://www.rfxn.com/bfd.php
Download: http://www.rfxn.com/downloads/bfd-current.tar.gz
README: http://www.rfxn.com/appdocs/README.bfd
ChangeLog: http://www.rfxn.com/appdocs/CHANGELOG.bfd

If you have a copy of BFD already installed, the new version will overwrite it and you need only open /usr/local/bfd/conf.bfd and reset the e-mail settings and trigger value for bans. Please also be sure to take a quick read of the README file so you can properly configure BFD to meet your needs (especially those performing new BFD installs).

Cool stuff....Guess I'll need to update my servers.

thanks for great stuff. I upgraded bfd to 1.2.
but it detects for normal successful ftp login now.
Here is the log. (I arranged my server`s host name, IP, source IP and so on in here)
The source IP logged in successful, but with multiple user IDs and 2 different domains in the server. Is this why it detected?

-----------------------

The following is a sumeeery event for exceeded login failures on host.mydomain0.com:

SOURCE ADDRESS: 10.20.30.40
TARGET SERVICE: proftpd
FAILED LOGINS: 20
EXECUTED COMeeeND: /etc/apf/apf -d 10.20.30.40 {bfd.proftpd}

SOURCE LOGS FROM SERVICE 'proftpd' (GMT +0900):

Jul 29 10:03:11 secure proftpd[23751]: mydomain1.com (10.20.30.40[10.20.30.40]) - USER ccc@mydomain1.com: Login successful.
Jul 29 10:04:21 secure proftpd[23751]: mydomain2.com (10.20.30.40[10.20.30.40]) - USER bbb@mydomain2.com: Login successful.
Jul 29 10:06:00 secure proftpd[23751]: mydomain1.com (10.20.30.40[10.20.30.40]) - USER ccc@mydomain1.com: Login successful.
Jul 29 10:18:16 secure proftpd[23751]: mydomain1.com (10.20.30.40[10.20.30.40]) - USER ccc@mydomain1.com: Login successful.
Jul 29 10:20:59 secure proftpd[23751]: mydomain2.com (10.20.30.40[10.20.30.40]) - USER ddd@mydomain2.com: Login successful.
Jul 29 10:21:18 secure proftpd[23751]: mydomain2.com (10.20.30.40[10.20.30.40]) - USER eee@mydomain2.com: Login successful.
Jul 29 10:22:05 secure proftpd[23751]: mydomain1.com (10.20.30.40[10.20.30.40]) - USER ccc@mydomain1.com: Login successful.
Jul 29 10:25:00 secure proftpd[23751]: mydomain2.com (10.20.30.40[10.20.30.40]) - USER ggg@mydomain2.com: Login successful.
Jul 29 10:25:28 secure proftpd[23751]: mydomain1.com (10.20.30.40[10.20.30.40]) - USER fff@mydomain1.com: Login successful.
Jul 29 10:26:16 secure proftpd[23751]: mydomain2.com (10.20.30.40[10.20.30.40]) - USER bbb@mydomain2.com: Login successful.
Jul 29 10:27:04 secure proftpd[23751]: mydomain1.com (10.20.30.40[10.20.30.40]) - USER ccc@mydomain1.com: Login successful.
Jul 29 10:28:13 secure proftpd[23751]: mydomain1.com (10.20.30.40[10.20.30.40]) - USER ccc@mydomain1.com: Login successful.
Jul 29 10:29:00 secure proftpd[23751]: mydomain2.com (10.20.30.40[10.20.30.40]) - USER ddd@mydomain2.com: Login successful.
Jul 29 10:29:25 secure proftpd[23751]: mydomain2.com (10.20.30.40[10.20.30.40]) - USER hhh@mydomain2.com: Login successful.
Jul 29 10:31:04 secure proftpd[23751]: mydomain1.com (10.20.30.40[10.20.30.40]) - USER ccc@mydomain1.com: Login successful.
Jul 29 10:34:34 secure proftpd[23751]: mydomain2.com (10.20.30.40[10.20.30.40]) - USER bbb@mydomain2.com: Login successful.
Jul 29 10:35:42 secure proftpd[23751]: mydomain1.com (10.20.30.40[10.20.30.40]) - USER ccc@mydomain1.com: Login successful.
Jul 29 10:40:16 secure proftpd[23751]: mydomain1.com (10.20.30.40[10.20.30.40]) - USER fff@mydomain1.com: Login successful.
Jul 29 10:44:57 secure proftpd[23751]: mydomain1.com (10.20.30.40[10.20.30.40]) - USER fff@mydomain1.com: Login successful.

The issue with proftpd has been corrected, it was a typo in the regexp string which did not show itself on my proftpd test systems. You can either download the bfd-current.tar.gz package and reinstall or download the fixed proftpd rule at http://www.rfxn.com/downloads/proftpd and move the new rule to /usr/local/bfd/rules/. You may also want to run a "rm -f /usr/local/bfd/tmp/*" to clear out all temporary data as a precaution.

I have double checked the validity of all other regexp strings from all rules and am unable to find any similar issues, if you are not running proftpd on your system then there is no need to reinstall.

P.S: what is with the typo's in the generated alerts from your system such as "EXECUTED COMeeeND", is that just something caused when you edited the contents for posing or are the alerts actually coming off like that as i get over 100 alerts a day to my inbox and see no similar typo issues.

About your comment in P.S,.. Sorry, the typo was that I made by mistake when I edited the source IP, hostname and so on.

Anyway, below is another detected log for sendmail.
I don`t want bfd to detect for `Connection rate limit exceeded.`
Is it possible to exclude this from sendmail rule?

--------------

SOURCE ADDRESS: 10.20.30.40
TARGET SERVICE: sendmail
FAILED LOGINS: 92
EXECUTED COMMAND: /etc/apf/apf -d 10.20.30.40 {bfd.sendmail}

SOURCE LOGS FROM SERVICE 'sendmail' (GMT +0900):

Jul 29 01:48:33 secure sm-acceptingconnections[1817]: m6SGmWS7001817: ruleset=check_rcpt, arg1=<myname@mydomain0.com>, relay=host.name.com [10.20.30.40], reject=452 4.3.2 Connection rate limit exceeded.
Jul 29 01:48:33 secure sm-acceptingconnections[1817]: m6SGmWS7001817: from=<root@mydomain0.com>, size=1476, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=host.name.com [10.20.30.40]
Jul 29 01:48:33 secure sm-acceptingconnections[1817]: m6SGmWvo001817: ruleset=check_rcpt, arg1=<myname@mydomain0.com>, relay=host.name.com [10.20.30.40], reject=452 4.3.2 Connection rate limit exceeded.
Jul 29 01:48:33 secure sm-acceptingconnections[1817]: m6SGmWvo001817: from=<root@mydomain0.com>, size=1476, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=host.name.com [10.20.30.40]
Jul 29 01:48:33 secure sm-acceptingconnections[1817]: m6SGmX8W001817: ruleset=check_rcpt, arg1=<myname@mydomain0.com>, relay=host.name.com [10.20.30.40], reject=452 4.3.2 Connection rate limit exceeded.
Jul 29 01:48:33 secure sm-acceptingconnections[1817]: m6SGmX8W001817: from=<root@mydomain0.com>, size=1476, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=host.name.com [10.20.30.40]
Jul 29 01:48:33 secure sm-acceptingconnections[1817]: m6SGmXdq001817: ruleset=check_rcpt, arg1=<myname@mydomain0.com>, relay=host.name.com [10.20.30.40], reject=452 4.3.2 Connection rate limit exceeded.
Jul 29 01:48:33 secure sm-acceptingconnections[1817]: m6SGmXdq001817: from=<root@mydomain0.com>, size=1476, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=host.name.com [10.20.30.40]
Jul 29 01:48:33 secure sm-acceptingconnections[1817]: m6SGmXrE001817: ruleset=check_rcpt, arg1=<myname@mydomain0.com>, relay=host.name.com [10.20.30.40], reject=452 4.3.2 Connection rate limit exceeded.
Jul 29 01:48:33 secure sm-acceptingconnections[1817]: m6SGmXrE001817: from=<root@mydomain0.com>, size=1476, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=host.name.com [10.20.30.40]
Jul 29 01:48:33 secure sm-acceptingconnections[1817]: m6SGmXq6001817: ruleset=check_rcpt, arg1=<myname@mydomain0.com>, relay=host.name.com [10.20.30.40], reject=452 4.3.2 Connection rate limit exceeded.
Jul 29 01:48:33 secure sm-acceptingconnections[1817]: m6SGmXq6001817: from=<root@mydomain0.com>, size=1476, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=host.name.com [10.20.30.40]
Jul 29 01:48:33 secure sm-acceptingconnections[1817]: m6SGmXJc001817: ruleset=check_rcpt, arg1=<myname@mydomain0.com>, relay=host.name.com [10.20.30.40], reject=452 4.3.2 Connection rate limit exceeded.
...
...
--------------

P.S
I use apf+bfd+sim. Thanks for great stuff.
anyway, about apf,
BIND will be patched or updated due to `vulnerable to cache poisoning`
detail: http://www.kb.cert.org/CERT_WEB/services/v...s.nsf/id/800113
then, the source port for BIND will be randomized.
I think I should edit the apf config for dns port .
Can you please give me some advise how I should change the dns part?

sure, just delete /usr/local/bfd/rules/sendmail or move the file to another location such as "mv /usr/local/bfd/rules/sendmail /usr/local/bfd/sendmail.disable". Basically, any file inside the rules folder will get parsed as a rule, so just move it out of that folder or delete it all together.

I still need protection for sendmail. so don`t like to remove whole sendmail rule file.
I want to exclude detection for the sendmail rule `reject=452 4.3.2 Connection rate limit exceeded.`
Is it possible?
BFD 0.9 didn`t detect it, but 1.2 does.

anyway any comment on P.S in my previous post about apf config for DNS Vulnerability ?

Replace the ARG_VAL line in /usr/local/bfd/rules/sendmail with the following:

ARG_VAL=`$TLOG_PATH $LP $TLOG_TF | grep -ivE "IP name lookup|Connection rate limit exceeded" | grep -iE "sendmail|check_rcpt|relaying denied" | sed -e 's/::ffff://' | awk '{print$10}' | tr -d '[],' | grep -E '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' | tail -n $MLOG | sort -n`

APF is an SPI firewall, which means it monitors connection states and as such it will dynamically alter rules on it own to adapt to RELATED or ESTABLISHED connections. I have updated bind on over 200 servers in recent weeks and not a single one required any modification to firewall rules.

Does this new version track already banned IPs differently than the previous? I have a cron.hourly script running that scans /etc/apf/deny_hosts.rules and un-bans IP's after 10 hours using "apf -u". However, when the same IP starts attacking again it is being ignored by BFD 1.2. Do I need to remove the IP from one of BFD's tracking files as well now?

Thanks for your hard work Ryan.

Now about those other projects...

Yes, /usr/local/bfd/tmp/track.attack - in your case just wipe the contents of /usr/local/bfd/tmp/* every 10 hours.

Given the above scenario I will make a change to the release version of BFD (not required update) to clear out the bfd tmp directory daily.

Greetings Ryan:



First off, thank you very much for all of your projects and work.

Is the clear out bfd tmp directory every day a part of BFD 1.2, or will that be a part of the next version?

Thank you.

Greetings Ryan:

Does /usr/local/bfd/ignore.hosts accept comments next to the IP address?
Is CDR supposed to work in ignore.hosts?

If comments are allowed next to the IP entry and CIDR is supposed to work, do you have an area where I can email you the bfd email alert where we have IP addresses being blocked that are in the ignore.hosts file?

Thank you.

Greetings Ryan:

I found the answer to the tmp directory clearing in /etc/cron.daily/bfd

Right now we are facing two outstanding issues: knowing how /usr/local/bfd/ignore.hosts works and any limitations on it; and, we are seeing vpopmail bans where it appears to be a vpopmail log issue with Macintosh computers.

For whatever reason certain computer operating system / software types run, they are logging in, getting their email correctly, are from approved (valid / non hacker) IP's, and the log file shows a failure.

The only way I can think around the issue, but I'm not sure how one would code it is that if you see x successes from an IP, and then a failure here and there from the same IP, not to block it... or to otherwise make use of POP before SMTP to read in a white list file.

Thoughts?

Thank you.

This is what I needed to know. Thank you very much for your great scripts!

just upgrade, thank you

how do i get BFD to stop these types of attacks and ban the ip
i have a centos 5 box with APF and BFD both installed.
thank you

The vpopmail rule has been updated in the release version of BFD to address the rule mismatch of vpopmail, you can run the following quick fix to update your BFD install:

Greetings Ryan:

There's still an issue with the vpopmail BFD rule.

From reviewing the log output on a block, I'm not sure if there's a way around the issue.

But what I'm seeing is that if a valid user logs in successfully from an IP; and some where down the road (road being seconds to minutes) has enough password failures form the same IP (most of the time, it is a different email address, but not always), the system will block the IP even though from a point of view the IP is now proven to be safe (at least for the time being due to the success logins).

Is there a way to expand on the BFD ignore capability?

I'm not sure if it for how H-Sphere implements vpopmail, but in the vpopmail etc directory there is a file called open-smtp which are validated IP addresses which should be ignored by any bfd system.

Of note, this file can contain hundreds to thousands of IP addresses (if that matters) based on the email server utilization.

Thank you.

Ryan,

We're seeing the following in our mail log:



I'd like to create a new vpopmail-smtp rule by copying the current vpopmail rule and change all references of pop3 to smtp. Would that work?

Thanks in advance.

UPDATE:
Tried it out and it seems to be working. Thanks again for APF and BFD!

I had developed these vpopmail rules around a qmail/vpopmail setup on interworx server I personally run so it differs slightly in some log data from hsphere, if you could email ryan@rfxn.com with some log samples numbering a couple hundred lines that would be great. This will allow me to further expand the rules to better handle hsphere while retaining the overall compatibility for interworx also.

Comments are stripped when the file is parsed on a PER LINE BASIS; so put comments one line above or below entries but never on the same line as a valid address entry or that whole line containing the comment will get stripped on parse.

The ignore file uses absolute strings, it does not support any form of masking or similar - the ignore file is applied directly to log data as it is read, so you need to use fully qualified domain names or absolute addresses.

I have added to my todo list to create a simple routine to allow for masking within the ignore file but for the moment this is not yet available.

thanks for the headsup on that. Setting it up shortly, so good to know.

Greetings Ryan:

We recently ran into a problem with BFD blocking "ffff" which in turn blocked all sites on the server rather than the attacker.

Here's the log info (I can understand what happened, but maybe a change in checking can be done to make sure to get the IP after the ffff):

@400000004967cbb6042d05ec 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - FTP session closed.
@400000004967cbb6103a694c 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - FTP session opened.
@400000004967cbb618892e6c 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbb620d80ee4 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbb629271e3c 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbb6316ba25c 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbb639ba86bc 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbb639c03bac 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - Maximum login attempts (5) exceeded, connection refused
@400000004967cbb639c6bbbc 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - FTP session closed.
@400000004967cbb70a520184 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - FTP session opened.
@400000004967cbb71299b9f4 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbb71ae8929c 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbb72355c4cc 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbb72bcc8064 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbb7345f6ad4 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbb734650c3c 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - Maximum login attempts (5) exceeded, connection refused
@400000004967cbb7346bbf14 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - FTP session closed.
@400000004967cbb804f21ef4 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - FTP session opened.
@400000004967cbb80d3cbd94 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbb815909b64 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbb81def622c 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbb8364d9e74 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbb90326fbe4 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbb9032c33d4 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - Maximum login attempts (5) exceeded, connection refused
@400000004967cbb9033311a4 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - FTP session closed.
@400000004967cbb90f5b8e84 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - FTP session opened.
@400000004967cbb9179ca3bc 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbb91fe3c7bc 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbb9284efa34 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbb93093b11c 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbb938ee0efc 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbb938f33b34 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - Maximum login attempts (5) exceeded, connection refused
@400000004967cbb938f98494 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - FTP session closed.
@400000004967cbba09726754 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - FTP session opened.
@400000004967cbba11b3d27c 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbba19fe617c 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbba325cd85c 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbba3ac5a58c 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbbb076da25c 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbbb0773303c 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - Maximum login attempts (5) exceeded, connection refused
@400000004967cbbb0779cf8c 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - FTP session closed.
@400000004967cbbb13906a4c 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - FTP session opened.
@400000004967cbbb1bcc9d84 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbbb2420e0e4 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbbb2c696c44 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbbb34c1a35c 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbbc01886afc 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - USER Administrator: no such user found from ::ffff:195.42.167.200 [::ffff:195.42.167.200] to ::ffff:85.133.53.204:21
@400000004967cbbc0190c3b4 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - Maximum login attempts (5) exceeded, connection refused
@400000004967cbbc019d1024 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - FTP session closed.
@400000004967cbbc0dc7466c 127.0.0.1 (::ffff:195.42.167.200[::ffff:195.42.167.200]) - FTP session opened.


Thank you.

Does anyone have a nice set of plesk rules for BFD? I changed a couple of the rules to work on my plesk install however they don't appear to be processing. For instance, should AUTH_LOG_PATH in the sshd rule be set to /var/log/secure? Thanks...

You should not have to modify the sshd rule for it to parse on plesk systems as it is still basic redhat linux (assuming your using RHEL/CentOS/Fedora. However, yes BFD does need some love towards Plesk as it has been awhile since I last reviewed its compatibility with plesk systems. Any log samples of authentication failures for all major services on plesk systems should be sent to ryan@rfxn.com please.

I installed bfd-current-tar.gz (bfd-1.2) and I noticed that ALERT_USR parameter is missing from conf.bfd that is distributed with BFD. BFD doesnt' work when I tested it, so I added the ALERT_USR="1" to conf.bfd and it still doesn't work. Is ALERT_USR = 1 or 0 still required? Any hints on how to debug the problem are welcome. I've used BFD for awhile and had no issues like this before.

TRIG="3"

# send email alerts for all events [0 = off; 1 = on]
EMAIL_ALERTS="1"

# local user or email address alerts are sent to (separate multiple with comma)
EMAIL_ADDRESS="gvidals@XXXXXXX.net"

# subject of email alerts
EMAIL_SUBJECT="Brute Force Warning for $HOSTNAME"

# executable command to block attacking hosts
BAN_COMMAND="/etc/apf/apf -d $ATTACK_HOST {bfd.$MOD}"

######
# You should not need to edit any options below this line
######

# installation path
INSTALL_PATH="/usr/local/bfd"

# rule files path
RULES_PATH="$INSTALL_PATH/rules"

# track log script path
TLOG_PATH="$INSTALL_PATH/tlog"

# syslog kernel log path
KERNEL_LOG_PATH="/var/log/messages"

# syslog auth log path
AUTH_LOG_PATH="/var/log/secure"

# bfd application log path
BFD_LOG_PATH="/var/log/bfd_log"

# log all events to syslog [0 = off; 1 = on]
OUTPUT_SYSLOG="1"

# log file path for syslog logging
OUTPUT_SYSLOG_FILE="$KERNEL_LOG_PATH"

# template of the email message body
EMAIL_TEMPLATE="$INSTALL_PATH/alert.bfd"

# contains list of files to search for addresses that are excluded from bans
IGNORE_HOST_FILES="$INSTALL_PATH/exclude.files"

# grab the local time zone
TIME_ZONE=`date +"%z"`

# grab the local unix time
TIME_UNIX=`date +"%s"`

# lock file path
LOCK_FILE="$INSTALL_PATH/lock.utime"

# lock file timeout
LOCK_FILE_TIMEOUT="300"