Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2006-05-04 InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

More on blue security DDOS - DDOS response

Published: 2006-05-04
Last Updated: 2006-05-08 01:17:33 UTC
by Dan Goldberg (Version: 1)
0 comment(s)
On May 1st Handler Jim Clausing wrote about the Woes of Blue Security at http://isc.sans.org/diary.php?storyid=1304

A couple of readers have written in about the threat of DDOS. One reader asks:
" I always read about large company X was under attack from a DDOS and within a few [hours|days] it was brought under control. My question is, how?"

I would like to start to compile a list of steps to respond to this. So if you have any suggestions send them in I will get a list out over the weekend.

thanks Dan
www.madjic.net

Update: May 07, 2006
An initial document regarding DDOS mitigation.  http://www.madjic.net/wiki/pmwiki.php?n=Main.DDOSMitigationTechniques
Please feel free to send changes or suggestions. I will continue to research and update this document over the course of the next several months.
Keywords:
0 comment(s)

Spam blocking by RBL, when is a good thing too much?

Published: 2006-05-04
Last Updated: 2006-05-08 00:35:44 UTC
by Dan Goldberg (Version: 2)
0 comment(s)
I was involved in a recent discussion that was interesting regarding a startup company that got a new (to it) ip address assignment from its ISP. As soon as they lit up their mail server emails started to get blocked by spam filters. It turned out that a previous owner of that IP block got themselves on several spam black hole lists.

It is a long standing issue with the various RBLs that it is easy to get blacklisted, and tough to get unlisted. Needless to say the company in question requested a new address assignment from the ISP and resolved the problem that way. Leaving that address to the next poor victim to deal with it.

I have seen this situation personally a few times in the last year. I have started to suggest that anyone working with an ISP to get a new address assignment check the address block with various RBLs before accepting and putting the addresses into production. I also recommend that they request the ISP perform this check prior to making the assignment, some are more cooperative than others. Sorry I will not mention any names of ISPs.

They know who they are, and if you ask them you will know too.

Dan
dan /at/ MADJiC /./ net
http://www.madjic.net/


Update:
Reader Yakov Shafranovich wrote:
"A while back when I co-chaired the ASRG, we wrote up a document which addresses RBL issues:

http://www.shaftek.org/publications/drafts/draft-irtf-asrg-bcp-blacklists-00.txt

Specifically section 2.5 would be relevant here."

Thanks for the hard work and intersting read! It seems to me that temporary blocking would best serve the community. Of course defining temporary could keep some attorneys very busy I suppose.

Update:
Another reader Melvin suggests that the following article should be required reading for small and medium size businesses deploying mail services in limited address space. the article describes using routing mail through an ISPs smarthost so as not to be filtered by RBLs.

I agree this is a great method to bypass this problem. In my opinion the "openness" of the Internet suffers when we are forced to take these kind of measures. There is a trade off involve here obviously.

Update:
It seems that this is a sore spot for many folks. Another writer who asked to remain anonymous wrote in that "he could spend much of his day chasing stale RBL entries" that it would serve his customer base, but is a waste of time based on what his team is supposed to be doing. He also mentions that a new trend towards reputation  based blocking has a whole new potential danger.

He advocates for individuals building local RBLs for local use. I would add to that that anyone using a product for spam filtering should be aware of what they are blocking with that tool and feed back to the producer if they see erroneous mesages in the filters. One more thing for admins to chase.

Update Sunday May 7th:
I have been pounded with mail on this topic! Can you imagine that? :-)
The consensus seems to be that once on an RBL it should be hard to get off. The obvious reason being that a spammer will dump an RBL'd host to move to one that can deliver the mail at the first chance so that the spam can still get through.

Here are some other URLs submitted by Brent Bice containing interesting reading too:
http://www.clifto.com/itemize.html
http://www.spamreaper.org/thankspammers.html

So I wonder what the long term solution is, create a small controlled whitelist of valid mail hosts on the Internet and block all the others? Blacklisting a known offender has its limitations.

We shall see ...
Keywords:
0 comment(s)

Port 8443 Spike

Published: 2006-05-04
Last Updated: 2006-05-04 23:43:18 UTC
by Dan Goldberg (Version: 1)
0 comment(s)
There is a recent spike in TCP port 8443 http://isc.sans.org/port_details.php?port=8443.  Any one have any details on what this traffic might be? Packets with payload would be great!

Update:
Many readers have written in commenting on what products use this TCP port.
This is a pretty sizable spike. It ispossible that there is some new exploit or scanning tool  being used. That is what I am looking for evidence of.

Okay we have a good handle on the products using port 8443:
ePO
Some web portal software
Alternate ssl port
Web app backend products
A backup package

The question still remains: what is the cause of the spike? It is legitimate traffic or malicious?
Keywords:
0 comment(s)
Diary Archives