Date: Wed, 16 Nov 2005 22:38:59 -0600 From: Will Maier <willmaier@ml1.net> To: freebsd-questions@freebsd.org Subject: Re: Need urgent help regarding security Message-ID: <20051117043859.GF26954@localdomain> In-Reply-To: <20051117025112.3707143D45@mx1.FreeBSD.org> References: <51190.68.165.89.71.1132194943.squirrel@mail.el.net> <20051117025112.3707143D45@mx1.FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 16, 2005 at 09:51:08PM -0500, Steve Bertrand wrote:
> Most *((cr/h)ackers* (and I use that term VERY loosely (aka:
> script kiddies)) are interested in rooting a box, and setting up a
> storage/sharing area that is free to them. This may not be the
> case, but it's better to 'observe' your foreign presence first.
I understand the rationale behind this advice, but I disagree. I
made my suggestion plain in another part of this thread, but (in
general) the first priority should be to disrupt the attack. For
some organizations (universities, especially), computing resources
are our number one asset. We have oodles of cycles and network
bandwidth -- a rooted box directly targets our valuables, even if
it's "only doing IRC or warez".
Moreover, the longer the hole remains open, the greater the chance
that the attacker will extend the breach. In most every scenario I
can imagine, this is unacceptable. Real forensic investigation can't
really even be performed until the box is offline; looking at /tmp
and other likely trouble spots is excellent advice, but should come
later in the process.
For now, take a snapshot of the network activity (using lsof, ngrep,
tcpdump, etc); I recommended lsof because it will reveal all open
files and network sockets very quickly. Dump the output to a file
and unplug the machine. tcpdump and friends will work well, too, and
give you a more indepth look at the network activity, but will also
require you to keep the box up for longer than I'd be comfortable.
OP has some asset that is being threatened or diminished by this
attack, be it his bandwith, CPU cycles, host/network integrity or
self confidence. He needs to identify that asset and work quickly to
protect it. In most cases, this will mean immediately removing the
box and preparing to rebuild the machine; if he's interested in
investigating, he can do that on an image of the disk (since
investigations are of little use if they ruin the evidence).
Allowing the attack to proceed may be moderately enlightening, but
(from the OP's message) it seems like the basic problem is known.
Crufty machines attract attacks.
--
o--------------------------{ Will Maier }--------------------------o
| jabber:..wcmaier@jabber.ccc.de | email:..........wcmaier@ml1.net |
| \.........wcmaier@cae.wisc.edu | \..........wcmaier@cae.wisc.edu |
*------------------[ BSD Unix: Live Free or Die ]------------------*
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051117043859.GF26954>