IDS: RE: Security Policy
Frank Knobbe (FKnobbe@home.com)
Tue, 30 Mar 1999 19:10:18 -0600
FAQ: See http://www.ticm.com/kb/faq/idsfaq.html
IDS: See http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
HELP: Having problems.. Then email questions to ids-owner@uow.edu.au
NOTE: You MUST remove this line from reply messages as it will be filtered.
SPAM: DO NOT send unsolicted mail to this list.
USUB: email "unsubscribe ids" to majordomo@uow.edu.au
---------------------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> -----Original Message-----
> From: Steve Riley [mailto:sriley@bwdrensburg.co.uk]
> Sent: Tuesday, March 30, 1999 9:14 AM
> To: ids@uow.edu.au
> Subject: IDS: Security Policy
>
> [...]
> We are trying to develop a security procedure to follow
> in the event of an external intrusion or attack.
SANS has a nice booklet that helps with Intrusion Response procedures.
You can get it at http://www.sans.org
> We have come up against two problems. The first is how
> do we determine the source of a spoofed IP address. For
> example..if we know the intruder is currently attemping
> a DoS attack how can we gleam information about the
> intruder and his/her whereabouts.
> [...]
> 1) Plug the hole (if there is one)
> 2) Determine the source
> 3) Speak to the admin@source
> 4) Determine if the IP was spoofed / forged
> 5) Hope thats the end
I think you miss a couple important contact points such as your ISP
and/or phone company. Good ISPs have a NOC that can assist you with
the investigation. They can be very helpful in identifying the source
of a spoofed attack. Basically they check and see where the crap
enters their system. From then on either they contact the other ISP,
or refer that back to you. Depending where/how the attack originates,
it's a lost battle. But a lot of times it's very helpful.
I had a case where a client thought he was under a SYN/FRAG attack. We
investigated and it turned out it was a legitimate web server in CA
spitting out garbage along with useful HTTP data (Although they have
been informed, the problem has not been fixed to this day...I suspect
a wrong router MTU...).
I would re-order the above list to:
1) Plug the hole, *if necessary*. If there is a security risk, plug
it. If not, for example only a DMZ server is compromised and no
internal intrusion has occurred, monitor, log and start gathering
evidence.
2) Determine the source.
3) If you can't determine the source, contact your ISP and request
their assistance.
4) Contact the source ISP (with your ISP (conf. call) or without).
5) Prepare your evidence and decide if you want to press charges
(which may or may not be possible), or file a report with a law
enforcement agency (depending on how/where the attack originated).
6) Hope thats the end :)
> If the attacks continue and admin@source knows who
> is the attacker or cannot be bothered helping is there
> a professional body to which you can take your case or
> does it become a legal battle between us and the
> source.
You can always request the assistance of your favorite security
consultant or someone trained in IR forensics.
One point I'm still not sure about is when to file a report with CERT.
Would that be point 2.5, 3.5 or 4.5 ?
Regards,
Frank Knobbe
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.0.2
Comment: PGP encrypted email preferred
iQA/AwUBNwF1+ilma9DCzQQeEQIW4wCfZM/xnIupqgd9IGfmCGltFx+mkwAAn08f
ZLhFd2be419P5W7BMh0iJdWd
=/UZN
-----END PGP SIGNATURE-----