Need urgent help regarding security

Steve Bertrand iaccounts at ibctech.ca
Thu Nov 17 13:39:56 GMT 2005


> 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".

I do agree with you. When it happened to me, generally the whole process
of finding out where the origination of the attack (at least the network
it was launched from), what they had done on the box, how they intruded
in the first place etc was <15 minutes. I understand that in a critical
environment where important data can be compromised it has to be taken
offline as quickly as possible.

> 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.

Agreed again. However in at least 3 cases I've dealt with, they were
pretty much the same other than some minor differences. I've always had
backups too. However there is always that fear that they could have
infiltrated other boxen on the network, which if you just 'broke' one
aspect of their intrusion suddenly, may provoke them to do something
nastier then they originally intended.

I guess it's a lose-lose situation any way you look at it.

> 
> 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 at jabber.ccc.de | email:..........wcmaier at ml1.net | 
> | \.........wcmaier at cae.wisc.edu | \..........wcmaier at cae.wisc.edu |
> *------------------[ BSD Unix: Live Free or Die ]------------------*
> 
> _______________________________________________
> freebsd-questions at freebsd.org mailing list 
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to 
> "freebsd-questions-unsubscribe at freebsd.org"
> 



More information about the freebsd-questions mailing list