Webmin Break-in Attempts and OSSEC/HIDS

9 posts / 0 new
Last post
#1 Wed, 05/20/2009 - 10:08
mdtiberi

Webmin Break-in Attempts and OSSEC/HIDS

I use OSSEC/HIDS for active security on my server and would like to have any webmin break-in attempt report to OSSEC to automatically add to hosts.deny and/or my firewall to block/shun the offending IP address.

However, in order for OSSEC to see this happening it needs to look at the syslogs and the format must follow Syslog RFC. The only log that I can tell that documents an unauthorized access is miniserv.error which does not follow the Syslog RFC format. Is there anyway to to change this to comply with the proper format? How about adding a webmin break-in to secure.log?

Thanks

Wed, 05/20/2009 - 10:12
andreychek

There's an option in Webmin -> Webmin -> Authentication called "Log blocked hosts, logins and authentication failures to syslog" that I think will do what you're after.

Enabling that should cause Webmin to log authentication failures to syslog (which will end up either in /var/log/secure, or /var/log/auth.log, depending on your distro).
-Eric

Wed, 05/20/2009 - 10:29
mdtiberi

Thanks Eric, gotta love webmins flexibility!

BTW, what does "Block Hosts" and "Block Users" actually do? Also what does the "Lock Users" do as well.

Thanks again

Wed, 05/20/2009 - 14:34 (Reply to #3)
andreychek

<div class='quote'>what does &quot;Block Hosts&quot; and &quot;Block Users&quot; actually do? Also what does the &quot;Lock Users&quot; do as well.</div>

Well, the options you're asking about are:

[code:1]
Block hosts with more than N failed logins for Y seconds.
Block users with more than Nfailed logins for Y seconds.
Also lock users with N failed logins
[/code:1]

While I haven't used any of those, based on the way they're worded, I'd imagine &quot;Block hosts with more than N failed attempts for Y seconds&quot; does just that -- if a given host tries to log in N times and continually fails, that the host will become blocked from Webmin for Y seconds.

Same with the &quot;Users&quot; -- if someone tries to log into a user account N times unsuccessfully, the account would be blocked for Y seconds.

And lastly, the lock account on N failed logins would be just that -- the account would be locked if there are N failed login attempts on it.
-Eric

Thu, 05/21/2009 - 14:24
mdtiberi

I was after specifically how it does these things. For example, does &quot;Block Host&quot; add the ip to TCP wrappers? to the firewall? How does webmin actually do the blocking?

Thu, 05/21/2009 - 14:31 (Reply to #5)
Joe
Joe's picture

<div class='quote'>For example, does &quot;Block Host&quot; add the ip to TCP wrappers? to the firewall?</div>

No, and no.

Webmin does it in the miniserv.pl webserver (when you have your own webserver, you can add blocking features right in). So, there is no dependency on outside tools, and it is compatible across all supported platforms, including those that don't have a firewall or TCP wrappers available.

--

Check out the forum guidelines!

Fri, 05/22/2009 - 08:25
mdtiberi

Thanks Joe, but I would like to add another layer or two of protection from hack attempts using OSSEC/HIDS.

I am still having issues with webmin logging authentication failures (Access denied) to /var/log/secure. The option is selected as Eric recommended but the offending ip in miniserv.error does show up in secure.log. Perhaps my facilities are selected incorrectly? They are set to authpriv.* ; auth.* ; syslog.*

Thanks

Sat, 05/23/2009 - 02:21 (Reply to #7)
sgrayban

I have never had the reason to use a second layer of security for webmin/usermin as the built-in feature works just as good for banning idiots.

Fri, 06/19/2009 - 09:43
miner

Using the Webmin blocking features, on Debian the failures, and blocks, are logged via syslog; and are picked up by OSSEC.

To trigger an iptables block by OSSEC, you'll probably have to write a pair of local rules.

One reason I can think of for doing this would be to identify malicious hosts, and use iptables to block them from everything, not just Webmin. The caution of course is to identify malicious hosts, and not include hapless and innocent users who are just fumbling their password.

Topic locked