Other SSHGuard And SASLAUTHD

B

BillFinkNC

I have installed security/sshguard and what I'm finding in my logs are an awful lot of these:

Code: 
Mar 15 06:36:32 rmx saslauthd[18614]: do_auth  : auth failure: [user=billy] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
[/user]
security/sshguard isn't going to block anything and why?

My issue is there's not any indications where these 'attempts' are coming from. Mind you, they'd never get past anything, there's perhaps ONE account on the entire box that has a shell assigned to it inside the /etc/pwd.

I know security/sshguard when it sees > 4 bad entries such as that, it's supposed to drop those IP's into the /etc/hosts.allow at the top and 'block' them.

But if there aren't any indications where they're coming from, how can this be accomplished - better yet, would anyone have any better script that looks at say...the last 10 lines in the /var/log/messages and just turn that service off for say 60 seconds??? I'd be happy to add any script anyone has come up with for my scenario..billy/">
My assumption here is that security/sshguard isn't going to block anything and why?

My issue is there's not any indications where these 'attempts' are coming from. Mind you, they'd never get past anything, there's perhaps ONE account on the entire box that has a shell assigned to it inside the /etc/pwd.

I know security/sshguard when it sees > 4 bad entries such as that, it's supposed to drop those IP's into the /etc/hosts.allow at the top and 'block' them.

But if there aren't any indications where they're coming from, how can this be accomplished - better yet, would anyone have any better script that looks at say...the last 10 lines in the /var/log/messages and just turn that service off for say 60 seconds??? I'd be happy to add any script anyone has come up with for my scenario.
 
security/sshguard won't block because it's not looking for messages like these. Currently it only reliably blocks potential intruders based on specific messages in /var/log/auth.log.

If you want to protect more than just SSH you may want to have a look at security/py-fail2ban. Fail2ban can recognize a lot more services and it's relatively easy to add your own checks to it.
 
SirDice said:
security/sshguard won't block because it's not looking for messages like these. Currently it only reliably blocks potential intruders based on specific messages in /var/log/auth.log.

If you want to protect more than just SSH you may want to have a look at security/py-fail2ban. Fail2ban can recognize a lot more services and it's relatively easy to add your own checks to it.
Click to expand...

The port security/sshguard You can configure to monitor _most_ unsuccessful attempts at login for MOST service or application authentication methods. Of course, this is what I've been used to - but saslauthd has never given me an IP from where the script kid is coming from.

However, I took your advice, (try something new and different) compiled and installed security/py-fail2ban - as I poke about the configuration files, I didn't happen to notice any monitoring of saslauthd or the auth.log which is where the notices are coming in from.

Forgive me, that's a totally new port I've absolutely NO experience with what-so-ever. I could only imagine it's just adding a few lines inside /usr/local/etc/fail2ban/jail.d/jail.conf? For someone who's been working with it for some time will likely write "just enter these lines" without too much effort - any help by chance in that area? It'll take me an additional day to find that research and put it into place.

May I thank you ahead of time for your assistance - I really appreciate it!
 
This is the entries I have put inside jail.conf for [service=smtp]

Code: 
[sendmail-auth]
port    = submission,465,smtp
logpath = "/var/log"

[sendmail-reject]
port     = smtp,465,submission
logpath  = "/var/log/maillog"
 
Last edited by a moderator:
So I installed security/fail2ban and used the above entry
Code: 
[sendmail-auth]
port = submission,465,smtp
logpath = "/var/log"

[sendmail-reject]
port = smtp,465,submission
logpath = "/var/log/maillog"
...and since then, there continues to be these EVERY single day - needless to say, there are hundreds. Just what is it that Fail2Ban was supposed to do???

I'm obviously missing an/the entry for stopping these attempts - ANY HELP here?
Code: 
[NOPARSE]
Mar 18 00:28:02 rmx saslauthd[18613]: do_auth  : auth failure: [user=bill] [service=smtp] [realm=mydomain.com] [mech=pam] [reason=PAM auth error]
Mar 18 00:28:03 rmx saslauthd[18615]: do_auth  : auth failure: [user=bill] [service=smtp] [realm=mydomain.com] [mech=pam] [reason=PAM auth error]
Mar 18 00:28:04 rmx saslauthd[18612]: do_auth  : auth failure: [user=bill] [service=smtp] [realm=mydomain.com] [mech=pam] [reason=PAM auth error]
Mar 18 00:28:05 rmx saslauthd[18611]: do_auth  : auth failure: [user=bill] [service=smtp] [realm=mydomain.com] [mech=pam] [reason=PAM auth error]
Mar 18 00:28:06 rmx saslauthd[18614]: do_auth  : auth failure: [user=bill] [service=smtp] [realm=mydomain.com] [mech=pam] [reason=PAM auth error]
Mar 18 00:28:07 rmx saslauthd[18613]: do_auth  : auth failure: [user=bill] [service=smtp] [realm=mydomain.com] [mech=pam] [reason=PAM auth error]
[/NOPARSE]
 
Last edited by a moderator:
The names between the brackets ([]) refer to scripts in the filter.d directory. In this case they refer to filter.d/sendmail-auth.conf and filter.d/sendmail-reject.conf. They contain the specific regexp that looks for those messages. You may need to tweak them a little as most as based on Linux and the message might be a little different on FreeBSD. You also need to define an "action". This is what will be done if one of those rules hit. A common action is to add an IP address to the firewall. You probably want to use action.d/pf.conf or action.d/ipfw.conf depending on your firewall.
 
RE: "Common Action" is to add the IP address to some action. In my case I'd simply add it to the blackhole route. Thats what and how I use security/sshguard for our script-kiddie friends out there.

...however, this has been my issue ALL along. There is/are _no_ IP address that is stated for those alerts when they are occurring. Hence my reaching out here looking for a solution. I don't have too much hair left, but I'm sick and tired of not being able to stop these brute attacks from taking place. (All because there are not any IP's noted where these attacks are coming from when that warning is added to the log-file.)

I feel strongly that a script to monitor the log and search for the time and service (based on the number of notices that appear, say after 10 consecutive attempts) that's being bombarded with those scans and shut that service off for say... 5 or 10 seconds. My thinking is every 10->15 minutes scan that log and when 5 or more of those entries are found, stop the service for a while, then start it back up when they realize it'd take 'em a year to brut-force (successfully) at the passwords. I cannot over emphasize this is all because the IP's are not displayed or left in the log.

For example and what I have in mind because there is no IP address I can block; (Forgive me, I'm not a shell programmer but here are my thoughts and I may likely be totally 'out there' when or if this doesn't make any sense: But _please_ forgive my ignorance in programming using the shell. I've dabbled only with scripts I find by Googlin' 'em and understand them. I just am not familiar with proper syntax.

My thinking is to search that log for
Code: 
'reason=PAM auth error'
I already realize this code is nowhere near syntatically (sp?) correct, but I'm sure you get the idea. (too, I tried using all of the 'blocks' I'm supposed to use to enclose my code, but I kept running into too many looping 'codes'.
Code: 
$i = 0
$x = 0
while $x < 10
tail -10 /var/log/auth.log | grep -i 'auth error'
$looking_for = $_
if $looking_for =~ 'auth error' then
  $i = $i + 1
  if $i > 5 then
               $string_was_found = 1
              /etc/rc.d/sendmail stop  (or /etc/rc.d/sasld stop)
  else next $i
  wait 10 seconds
         if $string_was_found = 1
        /etc/rc.d/sendmail start (or /etc/rc.d/sasld start)
  else next $x
I'm really sorry if this message doesn't have the blocks in the proper places, did the best I could. I recognize the above wouldn't work - that's why I'm hoping those who are fluent with shell scripting can lend a hand. Because THIS would work, with properly placed and syntax being correct.

Even if nothing else happens here - I _truly_ appreciate your time assisting me.

Bill
 
Last edited by a moderator:
I just thought, with this being the output:
Code: 
[NOPARSE]auth failure: [user=root] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error][/NOPARSE]
Can't I add a switch to sendmail to be more verbose and include the IP's these clowns are coming in from?
 
Last edited by a moderator:
Last edited by a moderator:
You must log in or register to reply here.
Back
Top