[Dshield] Defense against server attacks

Jon R. Kibler Jon.Kibler at aset.com
Mon Dec 1 23:23:50 GMT 2003


Johannes:

Thanks for your comments. At least it shows me that we are trying to do things right. Please see more detailed remarks, embedded below.

Again, thanks!
--
Jon R. Kibler
Chief Technical Officer
A.S.E.T., Inc.
Charleston, SC  USA
(843) 849-8214


"Johannes B. Ullrich" wrote:
> 
> I think your question comes down to good log monitoring. The particular
> attack may have been detected as a syn-flood, depending on what kind of
> log information you collect.

Wasn't a syn flood -- snort didn't say boo about this incident in its logs. I am 99% sure that the server was connecting, getting our 220 prompt, (probably gagging on our 220 prompt -- many miscreant SMTP engines do), dropping the connection, and retrying -- maybe even trying multiple connections at once, but at least completing proper SMTP connections before dropping the connection.

> 
> Overall, I assume you are not just interested in detecting this
> particular attack, but instead in detecting the next, so far
> unknown to you, attack.

RIGHT!!!

> 
> A couple things that help:
> 
> * Monitor the availability of your services from the outside
>   and the inside of your network. 

We already do that -- both from another internal connection with a 'hidden' ISP connection, and from remote servers -- each of which keep watch on each other.

> "nagios" is a nice package to

We have our own internal packages to do this, but we will take a look at nagios to see what it may add to our current capabilities.

>   do this. Alternatively, there are comercial services that do
>   this for you. If you are interested in e-mail, just setup an
>   autoresponder, and a script on some external system (e.g.
>   your home system) that sends an e-mail every 5 minutes and
>   measures rund trip time.

The problem with the attack we say yesterday was that there was no unusual load per se on our MTA -- just a lot of garbage connections.

> * A decent IDS is always a good idea. Try snort if you don't
>   have one already.

Been there, done that... snort didn't even burp on this incident.

> * Monitor your bandwidth usage. There are many tools to do
>   this (ntop, mrtg, iptraf). Setup alerts if bandwidth use
>   exceeds certain limits.

We have bandwidth monitors -- again, stuff we developed years ago in house. The problem with the attack we had yesterday was that we really didn't see that heavy of bandwidth hit -- 60% max. We looked at ntop some time ago, but I will get someone to assess the tools you listed to see if there is anything we can gain from their use.

> * setup a central log server and some scripts to watch for
>   odd occurrences. I personally like syslog and swatch to get
>   started, and 'logsurfer' if you need more control. But all
>   this depends on your existing infrastructure.

Again, been there, done that... and that is why we even know we had a problem. Once again, we are using in house developed tools (some are over a dozen years old -- some of the first tools we developed) and they did the proper alerts. I will have someone take a look at swatch and logsurfer to see if they can help in any way.

> 
> Important note: Do not rely on e-mail alone to receive the
> alerts. How will you be alerted if the mail server is down ;-).
> Either use a secondary e-mail account to monitor the primary account,
> or use a modem that can send signals to a pager. This solution is
> ideal as it will still work if your Internet connection is down.

We have servers scattered around on different ISPs that monitor each other's activities and immediate report any dropouts. Each has their own independent mail server. It would take a rather wide spread attack -- and someone with insider knowledge -- to really take out our monitoring network. (In fact, this monitoring capability was used to help one of our ISPs find a problem with one of their border routers where it occasionally just stopped allowing traffic through.) The long pole in the tent here is the delay we sometime experience in receiving text messages on our cell phones -- and I haven't found a good answer for that one yet!

Johannes, again, thanks for the info... it gives us some new tools to explore. But your feedback also gave me the 'warm-fuzzies' that we were at least doing things as right as technology will allow us to do!

Great help!
Thanks. 
Jon Kibler

> 
> > Any thoughts on how to detect something like this while it is in progress and what
> > can be done if such an attack is detected? We have blocked the offending netblock at
> >  our border (the idiot used their real IP address -- or at least the address of
> > whatever system they compromised), which protects our MTA, but does little for
> > our network bandwidth problem.
> 
> --
> CTO SANS Internet Storm Center               http://isc.sans.org
> phone: (617) 786 1563
>   fax: (617) 786 1550                          jullrich at sans.org





==================================================
Filtered by: TRUSTEM.COM's Email Filtering Service
http://www.trustem.com/
No Spam. No Viruses. Just Good Clean Email.



More information about the list mailing list