BFM / iptables - reccomended vs default settings & admin respose options

Spook

Verified User
Joined
Jan 3, 2006
Messages
138
Log parsing allows alerts after event action / response. I can't recall if I toggled this on or if by default it was on.. At any rate I turned it on.
RE: admin user -> admin settings -> security

  • post event alerts will possibly be generated for a blocked IP (skip list = no)
  • should procedure to prevent post event alerts be block + skip at admin response?
  • other settings adjustments EG:
    - Parse service logs for brute force attacks [y/n] Feature 1227
    - Reset count of IP/User failed attempts [x] hours after last attempt
    - Clear failed login attempts from log [x] days after entry was made

I've not fully read over feature 1227 but it reads technical.. response to a feature request where real world use may be clear?

It would be great if someone could provide an example of how log parsing is of use?
IE: why is it even an option?

I don't know enough to simply relate it accordingly.
 
Hello,


When you start learning things it's a good idea to use defaults provided by Directadmin.
If you want to start with BFM, then you'll need to manually install all the required scripts via root console (SSH).
Then later you might see wether or not the defaults suit you.


If you unsure how to get it work, then you'll probably need to get it configured for you. Here on the forums you can find those who might do it for you without cost, others (including me) would charge for it.
 
Hi Alex,

I've been working with BFM and the additional scripts for maybe a month now.

IE: over here

Searching the vB for very focused detail posts is very time consuming, and I do try to put ample time looking before asking of the community.

If you could provide a real world example for me to relate to of usefulness of the log parsing option it would help to make more sense to me and as a reply to my above query, no?
 
I'm a little bit confused with your message, and don't understand how exactly can I help you. Yes, BFM alerts about attacks, and it's alert are post event alerts. I don't see how can it be another. Do you?

If you want to hide those post event alerts, then please check this: http://www.directadmin.com/features.php?id=1332

If you wish to prevent notices from being sent out, but still have the IPs blocked, then set this in your directadmin.conf:
hide_brute_force_notifications=1

Here is one Example:


Notify Admins after an IP has100 login failures on any account.
Notify Admins after a User has100 login failures from any IP.
Remove an IP from the BF blacklist after600 minutes (0 = never)
Reset count of IP/User failed attempts24 hours after last attempt.
Clear failed login attempts from log4 days after entry was made.

and here is another:

Notify Admins after an IP has12 login failures on any account.
Notify Admins after a User has200 login failures from any IP.
Remove an IP from the BF blacklist after 4320 minutes (0 = never)
Reset count of IP/User failed attempts72 hours after last attempt.
Clear failed login attempts from log1 days after entry was made.

As you see they much differ. For now I won't say what variant is the best. We are still watching it, and get sometimes support tickets asking to remove an IP from a banlist.

In the first example an IP would be blocked after 100 attempts made within 24 hours. In the second example an IP would be blocked after 12 login failures made within 72 hours. A server with the second example is a VPS with 3-4 customers, and is under a continuous attacks from wide ranges of IP. Every IP does 1-2 attempts and quits. There is a thread on the forums about similar attacks.

If to compare with CSF/BFM then it usually blocks attackers after 10-30 attempts:

Login tracking is an extension of lfd, it keeps track of POP3 and IMAP logins
and limits them to X connections per hour per account per IP address. It uses
iptables to block offenders to the appropriate protocol port only and flushes
them every hour and starts counting logins afresh. All of these blocks are
temporary and can be cleared manually by restarting csf.

Thus, if you use CSF/LFD with enabled Login Failure blocking, then there is almost no chance for BFM to overtake it. LFD will block the IP much before BFM will detect it.
 
Last edited:
HI Alex,

I thank you for your time and reply. The information you presented is helpful.

The question I posed is perhaps silly, and helped to make things more unclear.


Log Parsing = Y

My experience is that I get alerts that have already been dealt with if not choosing skip + block at the same time.

Handling the BFM alert event as above, I guess would be the same as turning Log Parsing = N

Log Parsing = N

-This- settings I guess is what I am wondering about since I've never turned it off. I don't know if I understand the scope of turning this on/off. Seems simple enough in some ways but a real world example of why this is an option could make things clearer to me.



The only scenario I can think of is that an admin doesn't have time to deal with the alerts and needs the logs to be checked so reminder alerts are generated. Seems like a reasonable option for a server with tons of websites I guess.

However, AFAIK the alerts will pile up in the message system also serving as a reminder of historical BFM alerts.

Since I am considering setting 'log parsing' = N, I wanted to discover any unknown consequences before changing the setting.

I suppose that I am missing the primary perspective. Log parsing = Y, is the added feature (as opposed to not parsing the log) and I just need to digest the technical info in Feature 1227 to understand.

EG: /usr/local/directadmin/data/templates/custom/brute_filter.list and others.

Thinking about this more I am getting the impression that the extended features made possible by log parsing is how other firewalls like CSF can work cooperatively with BFM..

I guess I should rephrase the question (sort of) to:

How does "Log Parsing = Y" provide benefit? ..examples of how it's been an asset?
 
Back
Top