Brute Force Detection

Current Release:

BFD is a modular shell script for parsing application logs and checking for authentication failures. It does this using a rules system where application-specific options are stored including regular expressions for each unique auth format. The regular expressions are parsed against logs using the ‘sed’ tool (stream editor) which allows for excellent performance in all environments. In addition to the benefits of parsing logs in a single stream with sed, BFD also uses a log tracking system so logs are only parsed from the point which they were last read. This greatly assists in extending the performance of BFD even further as we are not constantly reading the same log data. The log tracking system is compatible with syslog/logrotate style log rotations which allows it to detect when rotations have happened and grab log tails from both the new log file and the rotated log file.

You can leverage BFD to block attackers using any number of tools such as APF, Shorewall, raw iptables, ip route or execute any custom command. There is also a fully customizable e-mail alerting system with an e-mail template that is well suited for everyday use or you can open it up and modify it. The attacker tracking in BFD is handled using simple flat text files that are size-controlled to prevent space constraints over time, ideal for diskless devices. There is also an attack pool where trending data is stored on all hosts that have been blocked including which rule the block was triggered by.

In the execution process, there is simply a cron job that executes BFD once every 3 minutes by default. The cronjob can be run more frequently for those that desire it and doing so will not cause any performance issues (no less than once a minute). Although cron execution does not permit BFD to act in real time, the log tracking system ensures it never misses a beat in authentication failures. Further, using cron provides a reliable framework for consistent execution of BFD in a very simplified fashion across all *nix platforms.

Funding for the continued development and research into this and other projects is solely dependent on public contributions and donations. If this is your first time using this software we ask that you evaluate it and consider a small donation; for those who frequent and are continued users of this and other projects we also ask that you make an occasional small donation to help ensure the future of our public projects.

100 Replies to “Brute Force Detection”

  1. I am a major fan of rfxn.

    BFD actually saved my small company. I use APF & BFD and without it, I would be out of business because I can not afford the expertise that rfxn possesses.

    Thank you to the rfxn team! My donation en-route.

  2. Thanks Ryan. I’ll give Ash a try, then.

    Fail2Ban won’t do on this appliance because it’s written in Python and there isn’t enough RAM to fit.

  3. Hello

    I’m looking for a good way to ban IP’s trying to register with my Asterisk server illegally, and was thinking of installing BFD to work with iptables.

    Problem is, it’s an appliance running uClinux and Busybox, which provides the following shells: ash, hush, lash, and msh.

    Will BFD work with those shells?

    Thank you.

      1. I know this is an old entry but did anyone ever get rules put together for this? I would be very interested in see them or helping make them. I am currently running the FreePBX distro with Asterisk Ver.

  4. Hello,

    Running with bfd 1.4 and found a “minor bug” in bfd script:
    ATTACK_COUNT=RET_COUNT (line #150)
    otherwise the attack is considered valid (ATTACK_COUNT -ge TRIG) as the ATTACK_COUNT lines have been already written into the track.attack file (line #136)

    Best regards,

  5. Hi, I am trying to write a rule for dovecot.
    I created this:
    ARG_VAL=`$TLOG_PATH $LP $TLOG_TF |grep ‘mail dovecot: pop3-login: Disconnected:’ |awk ‘{print$10}’ | grep -o \
    -E ‘[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+’`

    When I run it against the maillog, the hackers IP is listed over and over, but when I create the above rule and I run /usr/local/sbin/bfd -s
    the rule runs but it does not capture the hacker’s IP. Could you please explain what the rule should return or how to write a new rule or just point me to a doc where you have described what the rule should be returning to the bfd script?
    Thank you

    1. Ok, I was able to figure out the rules must return the IP:user to the bfd script.

      Knowing this I can at last play with creating new rules. I found two problems with the bfd script while creating my new rule.
      1. the TRIG variable is reset to the default value from the conf.bfd file after the first time the rule’s TRIG value is met because the conf.bfd is reloaded. To fix this I moved the default TRIG value from the conf.bfd file to the top of the bfd script. Now the rule TRIG value does not get overwritten.
      2. The bfd/tmp directory contains files with the last size of the log file in them. The first time you run bfd the bfd/tmp directory gets populated with these files. Since they are empty, containing no size value, the first time you run the bfd program it skips the entire log file. Dam hard to see if your new rule logic is working if the entire log file you think you are processing is skipped! I changed the logic in this line in the tlog script from:
      echo “0 > $BASERUN/$TLOG
      echo “1” > $BASERUN/$TLOG
      now the first time you run the script it actually processes the log file and you can see if your new rule is working!
      Thank you for this bfd script, please include source documentation with it so the GNU community can contribute to it more easily.
      Thanks again.

      1. 1. The TRIG value reloading is intended, it is reset for each rule as it is processed. If you want to override this you can place a TRIG value inside the rule file itself.
        2. On first runs of BFD and for new rules, it is intended by design that BFD begin tracking a log from the point at which the log is currently at. It would, especially on larger servers, cause undue loads for BFD on installation or running of a new rule, process entire logs up to the current time stamp. As such it is a trade off that we have BFD start tracking a log from the point of installation / where the log is currently at when a new rule is run. The changes you have made, for your own needs, are perfectly valid.

  6. i have installed APF+BFD but seems like BFD is not taking effects. I have proftpd running which I tried to login using failed account but BFD doesn’t seems to be blocking it. Any idea?

    I already run bfd -s to start it.

    1. does the forum still exist? i found out ssh does get blocked by bfd but proftd doesn’t. I checked in proftd settings already to no avail. Not sure where I should get support on this issue…

  7. I’ve been using bfd for some time on older systems looking to get back into things and of course have been testing it on my new systems. Using Ubuntu 10 it doesn’t look like BFD is seeing anything. I get the idea something’s changed but can’t be too sure where to look. Any thoughts?

  8. could someone please show me an example of how to create a rule for trapping 10+ 404 error requests from apache log?

    I have been trying to create my own but sed an me dont seem to agree on anything \;)

    1. This script may work in your situation. I use it to catch php exploits. Place it in your rules directory as httpd.

      # failed logins from a single address before ban
      # uncomment to override conf.bfd trig value

      # file must exist for rule to be active

      if [ -f “$REQ” ]; then

      # Max logs to process at one time for this rule

      ## httpd errors
      ARG_VAL=`$TLOG_PATH $LP $TLOG_TF | grep -iE “File does not exist: /var/www/html/” | sed -e ‘s/::ffff://’ | awk ‘{print$8}’| tr -d ‘[],’ | grep -E ‘[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+’| tail -n $MLOG | sort -n`

Leave a Reply

Your email address will not be published. Required fields are marked *