Last Updated: 2008-10-07 21:21:42 UTC
by Kyle Haugsness (Version: 1)
A paper on fastflux malware: http://honeyblog.org/junkyard/paper/fastflux-malware08.pdf
A cheat-sheet on malware reversing from fellow handler Lenny Zeltser: http://www.zeltser.com/reverse-malware/reverse-malware-cheat-sheet.html
A malware challenge site for those wanting to sharpen their skills: http://www.malwarechallenge.info/
Last Updated: 2008-10-07 20:06:49 UTC
by Kyle Haugsness (Version: 2)
Host-based IDS can be a powerful tool for identifying potential incidents. There are some major advantages in host-
based IDS over network-based IDS such as target-specific knowledge, identifying file modifications, and identifying rootkits that use encrypted network communication channels. However, the additional features usually result in additional maintenance and alerts.
How do you use host-based IDS to identify suspicious activity? Is there any organizations that rely solely on host-based IDS while ignoring network-based IDS? Since host-based IDS should be able to provide more concrete evidence that a host has been compromised - do you sometimes move straight to a forensic evaluation of the host upon receiving alerts from a host-based IDS? Is anyone using honeypots (or known-vulnerable hosts) anymore as an input to their host-based IDS systems for identifying targetted attacks?
Please send us your thoughts and comments via our contact page. We will update the diary as new submissions come in.
Update 1 from Francois:
"Incident response is only as good as how well you use your data and your tools. Missing information is a vulnerability in your controls or incident handling process. Host-based information is essential to any incident - even if only to tell you that the host was not affected.
Overlapping, correlating data can expose weaknesses in your controls. If there's any question whether a host is affected by an incident, you need supporting information to answer the question one way or another. If you don't have enough information to know, your process is broken.
Having both host and network information makes your controls and your incident process more robust and reliable.
Often an incident will cross different types of logs and systems, and you need to put the whole picture together. A portscan should show up in network traffic but may also trigger host-based IDS response. If your host-based IDS is triggered, and you can see where activity is restricted or stopped, you can be more confident about your controls. Defense-in-depth applies to detection processes.
Syslogs and Windows events are the most basic level of data and should be gathered and examined even if you don't have host-based IDS. The large volume of data needs to be filtered down but should still be examined. Having raw data is pointless if it cannot be looked at. A little good intelligence is better than a lot of raw data. Before collecting logs or sifting through data, you need to clearly define your objective. Again logging must be set up in a meaningful way. This means putting in enough time on the front-end, developing your processes and tools, to make the work meaningful."
Last Updated: 2008-10-07 15:55:10 UTC
by Kyle Haugsness (Version: 2)
Justin reports that Cogent is having peering problems, which seem to be confirmed here: http://www.internetpulse.net/. We will keep an eye on it and update this story as the day progresses.
Update 1: this appears to be resolved now as of 15:52 GMT (11:54 EST).