Re: IDS: Identification

[Max Vision <vision@whitehats.com>]

Archive: http://msgs.securepoint.com/ids
FAQ IDS: http://www.sans.org/newlook/resources/IDFAQ/ID_FAQ.htm
FAQ NIDS: http://www.ticm.com/kb/faq/idsfaq.html
IDS: http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
HELP: Having problems... email questions to ids-owner@uow.edu.au
NOTE: Remove this section from reply msgs otherwise the msg will bounce.
SPAM: DO NOT send unsolicted mail to this list.
UNSUBSCRIBE: email "unsubscribe ids" to majordomo@uow.edu.au
-----------------------------------------------------------------------------
On Fri, 2 Feb 2001, Mark Squire wrote:
> One of my first posts here.  Lets say an active intruder has been
> identified on the network, and lets say myself, the security analyst
> is able to sniff his connection to see what he is up to.  Once his
> connection is sniffed, is there a reliable way to trace all of his
> actions back to his original IP and gateway?  Would that information
> be in his packets themselves, or would I have to do some kind of
> traceroute trickery?
>

If you have a reliable session (e.g. these aren't commands in single
packets, such as the control channel of a ddos like tfn2k) then you
already have their source IP address.  That IP could either be the
attacker (if they are one of the droves of kiddies) or more likely another
victim machine that has been compromised and is used as a bounce for the
present attack.

Traceroute is only useful for determining the route that your packets take
in travelling to the attacker - this information is rarely useful.

All you need is to 1> fix your network so you aren't vulnerable anymore,
2> reinstall the compromised host(s), 3> report the incident to the proper
channels.  Depending on your corporate security policy your proceedure
might just be to shuffle an internal report, or it might be as severe as
contacting your CERT and law enforcement.  If so, they will be able to
contact the right parties based on the IP address and the traceroute won't
be necessary.

If you decide to launch your own investigation beware of what you are
getting into (in terms of legal liability with your company, and with
whichever other victim hosts may be involved in the intrusion).  Usually
you will have the intruder's IP already and can talk to the ISP that owns
it - if this fails and the source IP was another victim, then you might
try correlating dns queries that happened at the same time.  Sometimes an
attacker who uses multiple machines (their own machine and an
intermediary) will slip up and let their own machine resolve the IP of the
target.  This is certainly the case in poorly constructed (or well
constructed depending on your perspective) denial of service tools - I've
seen attack tools that rely on sending spoofed packets at a target, but
then ping the host right afterwards (which is a dead giveaway).. or to
call the tool like ./attack www.example.com, which means that their system
had to send a query to your dns server to translate www[.example.com] into
an IP first, then sends it's spoofed traffic.  It's a combination design
flaw/user error that might help with your(or whomever's) investigation.

Good luck,

Max Vision
http://whitehats.com/