[BlueOnyx:16373] Re: Security measures in general

[Michael Stauber]

Hi George,

> I'm curious about your views on another aspect of ProFTPd.
> 
> Nasty port scanners/dictionary attackers often hit SSH and, using
> denyhosts, those quickly land in hosts.deny and we brand the IP entry for
> ALL: services.
> 
> In your efforts, have you investigated the ProFTP ban engine, and what's
> your take on it?

Overall I think the ban engine in ProFTPd is not particularly useful. It
is *is* better than having nothing, but we actually can do better than that.

I wholeheartedly agree with you: Protecting just one service isn't good
enough. Having a bunch of different and incompatible mechanisms each
maintain their own blocks just doesn't cut it. Like said: It's better
than nothing, but we can (and should) handle this in a much better fashion.

This is also in the light of some pretty heavy targeted attacks that
we're seeing on our own servers at the moment. It's not just the usual
"drive by" brute force login attempts, but something a bit more serious,
more focused and targeted. /me waves at China.

As is the combination of APF Firewall and Dfix2 provide a pretty a
pretty good level of protection. Yet: Parsing logfiles for "bad"
activity and then creating firewall rules that deny further activity
from the same IP is akin to locking the barn after the burglar has
already started to pick the lock on your front door. We block early
enough to prevent more serious probes, but still: What if we could
already have a screening at the fence of the property that only lets a
selected crowd of people actually into our yard and to get as far as the
front door? That would be a pretty drastic improvement.

To cope with my new "friends" in China I quickly patched something
together that ties *all* Auth services into GeoIP and denies access too
everyone that's not from a list of allowed countries. That puts a pretty
heavy ban hammer onto the usual suspects from China, Russia, Romania and
so forth. As a result the number of attacks that actually make it as far
as seeing a login prompt dropped off by 95%. And the remaining 5% are
then easily detected by Dfix2 and blocked by APF.

Greg also did some pretty nifty improvisations on his own boxes to deal
with the attacks he gets and step by step worked them into nice solution
that's ready for general usage.

So the other day we spoke about a complete overhaul of our Security
Package and have made plans take the things that worked exceptionally
well for us to roll them into an updated and improved Security Package.

What we want to do is this:

- Update the excellent APF firewall to the latest version. Provide a GUI
for it. Am working on that at the moment.

- Modularize Dfix and make the rule files downloadable and editable via
the GUI. Also provide the ability to turn rules on or off via the GUI or
revert an edited rule back to the "stock" version of it. Greg is working
on the backend of this and I'll handle the GUI.

- Protect all network facing AUTH services with GeoIP and allow the
server admin (and also all users!) to lock down access to a list of
allowed countries or regions. Example: If you have an email user that
only logs in from France, then why should the login mechanism allow
logins from China, Russia or Indonesia on that account? That should
actually be a dead give-away that something fishy is going on. Now if he
travels to another country or goes on holiday, then the user might want
to add more countries to the allowed list or might temporarily want to
turn the protection off. So it should be configurable and preferably so
on a Vsite and user level. And technically that's actually not that
difficult to pull off.

- Share events about threats and attacks between servers. Say you
operate multiple servers that have the Security Package installed on all
of them. If they are in the same network (or if the attack is targeted
specifically against you) they will most likely hit all your servers in
short order. As is right now the Security Packages on all these
individual servers will just independently do their work separately on
all of these boxes. But we could easily set up an API that shares attack
events between boxes. So if one server decides to block an IP, all the
other servers get notified via the API and block it as well as
preventive measure.

- Likewise there will be an optional subscription channel that allows
you to tie your boxes into the official BlueOnyx-blacklist that Greg and
I will maintain. That list will contain blocks for known botnets and
other "bad" IP address ranges. It won't contain the dynamic blocks that
our boxes set up on a daily basis, but a more "static" area of the
internet out of which usually no good traffic originates.

So ... our general idea is: Don't just concentrate on the security
aspects of the individual services. Yes, make them as secure as
possible, run each of them with a sane and secure configuration. But
beyond that a security solution should take the whole picture into
account and should provide a working solution that covers all aspects
and provides a defense of all network facing services. Especially all
those services that require a login and (beyond a successful login)
provided elevated privileges.

As attackers are more and more networking their resources, we also
should start to network our defenses to provide a more flexible and
dynamic response to threats.

-- 
With best regards

Michael Stauber