Re: Incident Response Script
- From: ibuprofin@xxxxxxxxxxxxxxxxxxxxxx (Moe Trin)
- Date: Tue, 18 Dec 2007 14:06:31 -0600
On Mon, 17 Dec 2007, in the Usenet newsgroup comp.os.linux.security, in article
<2007121721083550073-thegoodsoldiersvejkREMOVE@gmailcom>, Svejk wrote:
Bit Twister <BitTwister@xxxxxxxxxxxxxxxx> said:
Svejk wrote:
When I turn up at a compromised system, there is always pressure
(usually from the network guys) to pull the plug immediately.
All you need is to pull the network plug. Pull the power plug later.
I'd rather even do it before that.
There is no single answer. For example, the system _could_ be running
a watch-dog type of program that "checks the mail" (sees if the network
is alive and well - _POSSIBLY_ by sending a packet of _some_ kind to a
remote host just to see that the connection is there, and if not, that
application hits the big Red Button). The only acceptable action would
be to kill power so that the poison pill doesn't have time to react.
At the other extreme, the malware could be memory resident ONLY, and
yanking power will destroy any evidence. Damned if you do, damned if
you don't. So, what it _your_ threat model? What are you expecting?
I'd like to get a picture of the system (netstat, ps, who, lsof ...)
quickly. Could you recommend a suitable script that can be used as a
start to tailoring it for myself?
Hehehe,
No, I can see where he's coming from, and it's not quite that simple.
cmd1 args > /somewhere/cmd1.rpt
cmd2 args > /somewhere/cmd2.rpt
.
.
.
cmdx args > /somewhere/cmdx.rpt
Yes, and assuming cmd1..cmdx can be trusted. etc.
Big ball of tar, and no easy way out of it. Your best bet might be to
have a Read/Write media that you can trivially mount (problem - there
may be a poison pill running that detects a root OR EQUIVALENT login,
or su/sudo action and bang goes the ball game) that contains the needed
commands, but even that may not work in the presence of a co-opted kernel.
The best solution may still be yanking the power, moving the disk[s] to a
trusted box, and mounting them R/O.
And the odds are one command's syntax on one system won't work on
another etc - it's potentially a lot of work. Just wondered whether
anyone had already got one they could share.
How many types of systems are you working with? I see your headers
imply OSX 10.3.9, and you're posting to a Linux newsgroup, so you
would PROBABLY want to have O/S specific scripts. It's bad enough
within an operating system like Linux, where there are multiple
distributions (each knowing the "right" way to do things, unlike
those "other" guys). This not only implies a different set of
options to some commands (I support BSD and SysV systems, and run
into this problem constantly), but you MAY also run into stuff
being located in different directories and needing different tools
to access information. I'm ignoring the whizzy GUI crap that is
usually not only distribution specific, but may even vary from
release to release. You must work at the command line level.
A bit dated, but you might want to search for something called "The
Coroner's Toolkit" from Dan Farmer & Wietse Venema. I'm sure those
names may ring a bell.
The Coroner's Toolkit (TCT) - a Brief Introduction
TCT is a collection of tools - some large, some small, some in perl,
some in C - that are all either oriented towards gathering or analyzing
forensic data on a Unix system.
Web Results 1 - 10 of about 9,090 for "The Coroner's Toolkit". (0.19
seconds)
First hit is 'www.porcupine.org/forensics/tct.html'. The tct-1.18.tar.gz
is about 318k. That may give you food for thought.
Old guy
.
- References:
- Incident Response Script
- From: Svejk
- Re: Incident Response Script
- From: Bit Twister
- Re: Incident Response Script
- From: Svejk
- Incident Response Script
- Prev by Date: Recomended free ebook for linux adminstrator | http://freepdf-ebook.blogspot.com/2007/12/linux-administrator-guide-2nd.html
- Next by Date: Re: Incident Response Script
- Previous by thread: Re: Incident Response Script
- Next by thread: Re: Incident Response Script
- Index(es):