Page 1 of 2 12 LastLast
Results 1 to 25 of 27
  1. #1
    Join Date
    Aug 2001
    Posts
    160

    bfd and APF - limit number of "failed logins"

    ok see "people" trying to BF into my servers with +100 attempts, was wondering if it ain't possible to set APF & BFD to block the ips at lets say 10 incorrect attemps?»

    Cheers

  2. #2
    Join Date
    Aug 2001
    Posts
    160
    Anybody...?

  3. #3
    Join Date
    Jan 2002
    Location
    Boston
    Posts
    5,014
    In the rules folder in your main BFD directory and you will see a list of service such as pop3, sshd, apache etc. Open that file and change the TRIG="#" setting to the number you want it to set for.

  4. #4
    Join Date
    Aug 2001
    Posts
    160
    Originally posted by OKIHost
    In the rules folder in your main BFD directory and you will see a list of service such as pop3, sshd, apache etc. Open that file and change the TRIG="#" setting to the number you want it to set for.
    Current TRIG was already set to 3 :/


    LP="/var/log/secure"
    TLOG_TF="sshd"
    TRIG="3"
    TMP="/usr/local/bfd/tmp"

    ## SSH
    ARG_VAL1=`$TLOGP $LP $TLOG_TF.1 | grep sshd | grep -viw "error: Bind" | sed 's/::ffff://' | $
    ARG_VAL2=`$TLOGP $LP $TLOG_TF.2 | grep sshd | grep -viw "error: Bind" | sed 's/::ffff://' | $
    ARG_VAL3=`$TLOGP $LP $TLOG_TF.3 | grep sshd | grep -viw "error: Bind" | sed 's/::ffff://' | $
    ARG_VAL4=`$TLOGP $LP $TLOG_TF.4 | grep sshd | grep -viw "error: Bind" | sed 's/::ffff://' | $
    ARG_VAL=`cat $TMP/.sshd`


    Help on this is very appreciatted

    Just in:
    The following are event logs for 745 login failures from 213.248.55.24

  5. #5
    Join Date
    Jan 2002
    Posts
    1,053
    Do you have BFD setup to add the IP address to the APF deny hosts file?

  6. #6
    Join Date
    Aug 2001
    Posts
    160
    Originally posted by Josh Stein
    Do you have BFD setup to add the IP address to the APF deny hosts file?
    Yes i have

    This is really becoming a issue....

  7. #7
    Join Date
    Jan 2002
    Posts
    1,053
    Originally posted by Rui
    Yes i have

    This is really becoming a issue....
    Try using a third-party admin since you are unable to fix the problem yourself.

  8. #8
    Join Date
    Aug 2001
    Posts
    160
    Somehow I think this was the problem:

    Code:
    # [Dev. Mode]
    # !!! Do not leave set to (1) !!!
    # When set to enabled; 5 minute cronjob is set to flush the firewall; set
    # this mode off (0) when firewall determined to be operating as desired.
    ##
    lets hope so

  9. #9
    Join Date
    Oct 2003
    Location
    Long Island, New York
    Posts
    220
    Rui,

    edit the file: /etc/cron.d/bfd, and set the line:

    */10 * * * * root /usr/local/sbin/bfd -q

    to:

    */5 * * * * root /usr/local/sbin/bfd -q

    or even:

    */3 * * * * root /usr/local/sbin/bfd -q.

    By default, it only checks once every 10 minutes. This may leave an attacker up to 10 minutes to run their brute force attack. Setting this to 5 or less minutes increases the amount of work the machine has to do (parsing logs etc.) but decreases the attack window.

    Sadly, there is no way to set a harder limit at this time.
    TWSites.com - Business Web Hosting Solutions & Server Management Since 2003

  10. #10
    That answers it for me too - I found that a brute force cracker can get over 200 attempts on my server in under 5 minutes before they are banned.

  11. #11
    Join Date
    Aug 2001
    Posts
    160
    DoCk - lets hope that makes it better, cheers

  12. #12
    Join Date
    Apr 2005
    Location
    Bangalore
    Posts
    20
    Make sure that you have only "friendly IP`s" in ignore.hosts

  13. #13
    Join Date
    Jan 2004
    Posts
    593
    I don't think the cron is the issue. Yes it helps to prevent to attacker by limiting time, but it doesn't do a single thing for the IP until the time is up. The reason why the attacks can go for 200+ attempts is that BFD doesn't ban the ip when it needs to. If you notice the logs, it will show the same IP for hundreds of attacks, but from different ports. To BFD this makes it look like a different IP.

    I believe this to be the only downfall of BFD. This should be changed for future versions. As for now, rely on the 3 minute cron.
    Check out my new Chrome Extension - Server Admin Tool
    frustratedtech.com - Helpful Server Tech Advice

  14. #14
    Join Date
    Oct 2003
    Location
    Long Island, New York
    Posts
    220
    The reason why they are from different ports is because of the way TCP/IP works. In order to have multiple simultaneous connections, the client must use multiple ports. This doesn't have much to do with the way BFD works... BFD is a log parsing script. In order to have a true solution, we would need something built into ssh itself.
    TWSites.com - Business Web Hosting Solutions & Server Management Since 2003

  15. #15
    Join Date
    Jan 2004
    Posts
    593
    Block all access for the users: root, guest, test, admin, webmaster
    This will knock nearly 70% of all access attempts.

    DoCK, BFD completely ignores the fact that it IS the same IP. After a certain amount of unauthorised accesses, BFD is supposed to ban the IP. This only works if you access from the same port say 3 times. Due to the fact that servers have thousands of ports, it makes no sense on why BFD would be coded the way it is.
    Check out my new Chrome Extension - Server Admin Tool
    frustratedtech.com - Helpful Server Tech Advice

  16. #16
    Join Date
    Aug 2001
    Posts
    160
    Vertica1Host - how about block all users except root (or the one that will give me access to root?)

    Can it be easily done?

  17. #17
    Join Date
    Oct 2003
    Location
    Long Island, New York
    Posts
    220
    Be careful doing all of this editing, you can easily mess up your server and you won't be able to log into it anymore.

    This can be accomplished best in your server's control panel if you have one, otherwise editing /etc/passwd will do the trick. Change something like this:

    user:x:32305:32311::/home/user:/bin/bash

    to this:
    user:x:32305:32311::/home/user:/bin/false

    Leave one user with access, just for you.

    Edit /etc/group and where it says wheel, add an entry containing the username. Save and test this right away, make sure you can login using your username and su to root. You can also more safely do this operation with a control panel if you have it.

    After this, edit /etc/ssh/sshd_config and uncomment the "Protocol" line to read "Protocol 2". Uncomment and change the "PermitRootLogin" line to read "PermitRootLogin no".

    Restart sshd with service sshd restart, then test it.
    TWSites.com - Business Web Hosting Solutions & Server Management Since 2003

  18. #18
    Join Date
    Aug 2001
    Posts
    160
    Well I have cpanel on all my servers so i guess i should do this via cpanel then?

  19. #19
    Join Date
    Oct 2003
    Location
    Long Island, New York
    Posts
    220
    Sure, everything but editing sshd configs can be done using the control panel.

    See: "Manage Wheel Group Users"

    and "Manage Shell Access"
    TWSites.com - Business Web Hosting Solutions & Server Management Since 2003

  20. #20
    Join Date
    Apr 2002
    Location
    Troy, MI
    Posts
    324
    This is more nonsence than anything -- BFD cares less what client port your on and only parses logs for user and IP nothing else -- all other log elements are irrelivent.

    With that said BFD is cron based and will ban any events that occure in the period between it last run and the next run -- BFD tracks log file changes and only reviews log entries appended since bfd last run -- so if you run BFD too often you wont see enough hits in the log to reach a BFD trigger but if you run it too far apart then youl get hundreds of brute force hits before BFD does anything -- it a matter of balence and is just the way BFD was designed.

    Typical usage is to run bfd somewhere between 3 and 5 minutes.
    Ryan MacDonald
    Lead Administrator | TotalChoice Hosting
    Choice Does Matter! | Serving over 26,000 clients

  21. #21
    Join Date
    Aug 2001
    Posts
    160
    Were is located the list of banned ips and logs?

    I thougth it was here /usr/local/bfd/tmp


  22. #22
    Join Date
    Oct 2003
    Location
    Long Island, New York
    Posts
    220
    /etc/apf/deny_hosts.rules, in addition to whatever else you might have banned using apf -d.
    TWSites.com - Business Web Hosting Solutions & Server Management Since 2003

  23. #23
    Join Date
    Apr 2002
    Location
    Troy, MI
    Posts
    324
    That a tmp path for bfd to store tracking information on each log file -- it tracks the size of each log.

    BFD log is located at /var/log/bfd_log and it places bans in /etc/apf/deny_hosts.rules.
    Ryan MacDonald
    Lead Administrator | TotalChoice Hosting
    Choice Does Matter! | Serving over 26,000 clients

  24. #24
    Join Date
    Jan 2004
    Posts
    593
    I see, BFD is not an on-the-fly type of software and relies on the timing of the cron to process all bans.

    I appoligise. I was unaware that this was not a realtime banning program. I've looked through the documentation and I didn't see it stated anywhere that it was not.

    This is great software and I'll continue to use it and encourage others to as well.
    Check out my new Chrome Extension - Server Admin Tool
    frustratedtech.com - Helpful Server Tech Advice

  25. #25
    Join Date
    Apr 2002
    Location
    Troy, MI
    Posts
    324
    In time BFD will eventually become a real time authentication tracking and auditing software but while it is being developed and maturing it will remain cron based.
    Ryan MacDonald
    Lead Administrator | TotalChoice Hosting
    Choice Does Matter! | Serving over 26,000 clients

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •