repeated attempts delivering mail to 'unknown [EMAIL PROTECTED]'
hi, in the last 3 days, one of our mx domains has been the target of the following ( the real domainname replaced by DOMAIN.XX ) : Feb 6 08:11:27 celery postfix/smtpd[11548]: reject: RCPT from shawidc-mo1.cg.shawcable.net[24.71.223.10]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:12:12 celery postfix/smtpd[11548]: reject: RCPT from shawidc-mo1.cg.shawcable.net[24.71.223.10]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:12:59 celery postfix/smtpd[11548]: reject: RCPT from shawidc-mo1.cg.shawcable.net[24.71.223.10]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:14:10 celery postfix/smtpd[11548]: reject: RCPT from newmx2.fast.net[209.92.1.32]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:15:33 celery postfix/smtpd[11548]: reject: RCPT from unknown[65.38.170.150]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:17:51 celery postfix/smtpd[11571]: reject: RCPT from ns1.webmediainc.net[66.234.10.181]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:18:37 celery postfix/smtpd[11571]: reject: RCPT from ns2.v-manager.co.uk[81.29.66.101]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:20:07 celery postfix/smtpd[11571]: reject: RCPT from gatekeeper2.bgu.ac.il[132.72.24.74]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:24:58 celery postfix/smtpd[11596]: reject: RCPT from cmail.seanet.com[199.181.164.19]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:31:35 celery postfix/smtpd[11596]: reject: RCPT from unknown[212.12.160.4]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:35:42 celery postfix/smtpd[11647]: reject: RCPT from aomail4.emirates.net.ae[195.229.241.85]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:36:06 celery postfix/smtpd[11647]: reject: RCPT from smtp2.pcspeed.com[63.231.199.4]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:40:22 celery postfix/smtpd[11681]: reject: RCPT from shawidc-mo1.cg.shawcable.net[24.71.223.10]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:42:45 celery postfix/smtpd[11693]: reject: RCPT from unknown[209.67.219.114]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:43:53 celery postfix/smtpd[11693]: reject: RCPT from shawidc-mo1.cg.shawcable.net[24.71.223.10]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:47:50 celery postfix/smtpd[11719]: reject: RCPT from cvxbsd.convex.com.br[200.152.177.10]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:52:15 celery postfix/smtpd[11732]: reject: RCPT from shawidc-mo1.cg.shawcable.net[24.71.223.10]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:52:25 celery postfix/smtpd[11732]: reject: RCPT from shawidc-mo1.cg.shawcable.net[24.71.223.10]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:58:10 celery postfix/smtpd[11751]: reject: RCPT from hrndva-mx-01.mgw.rr.com[24.28.204.20]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:58:15 celery postfix/smtpd[11751]: reject: RCPT from hrndva-mx-01.mgw.rr.com[24.28.204.20]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:58:21 celery postfix/smtpd[11751]: reject: RCPT from hrndva-mx-01.mgw.rr.com[24.28.204.20]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:58:26 celery postfix/smtpd[11751]: reject: RCPT from hrndva-mx-01.mgw.rr.com[24.28.204.20]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:58:30 celery postfix/smtpd[11767]: reject: RCPT from austtx-mx-04.mgw.rr.com[24.93.40.211]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:58:31 celery postfix/smtpd[11751]: reject: RCPT from hrndva-mx-01.mgw.rr.com[24.28.204.20]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:58:36 celery postfix/smtpd[11767]: reject: RCPT from austtx-mx-04.mgw.rr.com[24.93.40.211]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:58:37 celery postfix/smtpd[11751]: reject: RCPT from hrndva-mx-01.mgw.rr.com[24.28.204.20]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:58:42 celery postfix/smtpd[11767]: reject: RCPT from austtx-mx-04.mgw.rr.com[24.93.40.211]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:58:47 celery postfix/smtpd[11767]: reject: RCPT from austtx-mx-04.mgw.rr.com[24.93.40.211]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:58:53 celery postfix/smtpd[11767]: reject: RCPT from austtx-mx-04.mgw.rr.com[24.93.40.211]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Feb 6 08:58:58 celery postfix/smtpd[11767]: reject: RCPT from
Re: repeated attempts delivering mail to 'unknown [EMAIL PROTECTED]'
* lars brun nielsen: in the last 3 days, one of our mx domains has been the target of the following ( the real domainname replaced by DOMAIN.XX ) : These are just regular spamming attempts. Nothing to worry about. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: repeated attempts delivering mail to 'unknown [EMAIL PROTECTED]'
Florian Weimer wrote: in the last 3 days, one of our mx domains has been the target of the following ( the real domainname replaced by DOMAIN.XX ) : These are just regular spamming attempts. Nothing to worry about. it's the network connection part of it that baffles me. we're past the tcp handshaking when smtp is invoked, which means there's a valid connection ( = src and dest exists ) - for me it implies that the spammer(bot) sends from multiple valid ips/networks, and with the ridiculous generated account names, i fail to see the point from the spammers view ( nothing is ever accepted ) -- expect neither good nor evil. - deal with it -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: repeated attempts delivering mail to 'unknown [EMAIL PROTECTED]'
lars brun nielsen schrieb: Feb 6 08:11:27 celery postfix/smtpd[11548]: reject: RCPT from shawidc-mo1.cg.shawcable.net[24.71.223.10]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] , an empty Return-Path:/Envelope-Sender, so those are bounces / non-delivery-notifications. an explanation eludes me, [...] Somebody is spamming while using adresses from your domain as the faked sender of those spam-mails. That's quite old news for some years; SPF was invented to avoid that. If you're lucky, you'll get some hundred of those bounces and be done with; if your're unlucky, you'll get some hundred *thousand* of them, or even more. -thh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: repeated attempts delivering mail to 'unknown [EMAIL PROTECTED]'
Thomas Hochstein wrote: Feb 6 08:11:27 celery postfix/smtpd[11548]: reject: RCPT from shawidc-mo1.cg.shawcable.net[24.71.223.10]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] , an empty Return-Path:/Envelope-Sender, so those are bounces / non-delivery-notifications. an explanation eludes me, [...] Somebody is spamming while using adresses from your domain as the faked sender of those spam-mails. That's quite old news for some years; SPF was invented to avoid that. If you're lucky, you'll get some hundred of those bounces and be done with; if your're unlucky, you'll get some hundred *thousand* of them, or even more. thanks - i see it now. lars -- expect neither good nor evil. - deal with it -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compromised system - still ok?
On Sun, 6 Feb 2005 17:48:32 +0100, DI Peter Burgstaller [EMAIL PROTECTED] wrote: I'm considering taking it back online with a 2.4.29-grsec-hi, what do you guys think? You were rooted, you should reinstall. It's not worth risking that he left something that you didn't find. -- Michael A. Marsh http://www.umiacs.umd.edu/~mmarsh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compromised system - still ok?
Sounds like you need to read the cert.org article on how to respond to system intrusions. See http://www.cert.org/security-improvement/modules/m06.html. Good luck, Scott Edwards http://www.daxal.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compromised system - still ok?
On Sun, Feb 06, 2005 at 12:40:55PM -0500, Michael Marsh wrote: On Sun, 6 Feb 2005 17:48:32 +0100, DI Peter Burgstaller [EMAIL PROTECTED] wrote: I'm considering taking it back online with a 2.4.29-grsec-hi, what do you guys think? You were rooted, you should reinstall. It's not worth risking that he left something that you didn't find. I see no evidence at all of being rooted, or even hints thereto. Yes, the backup account was compromized. It looks like there were quite some security measures in place, try to look hard for any attempt to kernel exploit or otherwise local exploit, and think about what files this backup account had access to. Of course, importance of the system matters too, if you were the NSA or something, I'd definitely reinstall, however, if you're not THAT paranoid, I think you can do with locking down backup account, checking all files writeable by backup (all files with recent ctime?), and places like /var/tmp, /tmp, etc. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compromised system - still ok?
also sprach Jeroen van Wolffelaar [EMAIL PROTECTED] [2005.02.07.0022 +0100]: however, if you're not THAT paranoid, I think you can do with locking down backup account, checking all files writeable by backup (all files with recent ctime?), and places like /var/tmp, /tmp, etc. Once an attacker is on the system, you cannot be sure anymore that you can track his/her actions down. Sophisticated root kits exist to cover all (!) traces. You can put another box in front of the suspect one and check whether any unexpected traffic flows. Use snort. Do that for an extended period of time. If you see anything suspicious, investigate, but don't hesitate. I would simply reinstall. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Compromised system - still ok?
Jeroen van Wolffelaar wrote: On Sun, Feb 06, 2005 at 12:40:55PM -0500, Michael Marsh wrote: On Sun, 6 Feb 2005 17:48:32 +0100, DI Peter Burgstaller [EMAIL PROTECTED] wrote: I'm considering taking it back online with a 2.4.29-grsec-hi, what do you guys think? You were rooted, you should reinstall. It's not worth risking that he left something that you didn't find. I see no evidence at all of being rooted, or even hints thereto. Yes, the backup account was compromized. It looks like there were quite some security measures in place, try to look hard for any attempt to kernel exploit or otherwise local exploit, and think about what files this backup account had access to. Of course, importance of the system matters too, if you were the NSA or something, I'd definitely reinstall, however, if you're not THAT paranoid, I think you can do with locking down backup account, checking all files writeable by backup (all files with recent ctime?), and places like /var/tmp, /tmp, etc. --Jeroen Unless the evidence of being rooted was hidden. This can be done with * replacing system binaries, so that, for instance, /bin/ls does not list the root kit files, and that /bin/ps does not display the rootkit * replacing kernel (or modules) so that process information relating to the root kit is hidden, and files are hidden * hiding the root kit files in 'empty' spaces on the filesystem, (ie, where no inodes are pointing to) * hiding the root kit files in the filesystem (amongs other files, a little bit in each inode maybe?) So can you be really sure that there was no root kit that succesfully exploited your system? Have you rebooted off a trusted kernel, and cryptographically checked every single file involved in booting? (Such as the grub/lilo, kernel, all modules, init), and visually or cryptographically checked all the rc.* files and /etc/inittab? Of course, doing all this might mean that you avoid booting the rootkit next time. But it could still be on the disk, waiting for when the attacker tries to return! Yes, if the system is not important, you might not bother re-installing it. However in my (fairly recent experience), it was _easier_ to reinstall than it was to check all those things. -- Geoff Crompton Debian System Administrator Strategic Data +61 3 9340 9000 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compromised system - still ok?
On Mon, 7 Feb 2005, Geoff Crompton wrote: You were rooted, you should reinstall. It's not worth risking that he left something that you didn't find. my opinion reinstalling is the equivalent of a script kiddie and probably lower in skill level of the script kiddie /opinion see below for reasons if one cares I see no evidence at all of being rooted, or even hints thereto. Yes, the backup account was compromized. It looks like there were quite some security measures in place, try to look hard for any attempt to kernel exploit or otherwise local exploit, and think about what files this backup account had access to. Of course, importance of the system matters too, if you were the NSA or something, I'd definitely reinstall, however, if you're not THAT paranoid, I think you can do with locking down backup account, checking all files writeable by backup (all files with recent ctime?), and places like /var/tmp, /tmp, etc. nsa and other 3-letter agencies will probably find out: - where the cracker came from - what else the cracker did on the suspect box - what other machines the cracker tried to access inside the network and what other files were changed on other servers - how they got in and repoduce how they got in - come to your door step and serve a warrant if one broke into a secret machine - are there automated jobs that run at fixed times or whenver you do something - how long have they been in the system before you noticed and sometimes they are in there for weeks or months before you start to notice because they started to use the cracked box - is the backup clean or is it suspect too - what files the cracker changed - what files the cracker added - .. on and on .. you can reinstall AFTER you can answer all the above questions or give up and give the point ot the script kiddie cracker resinstalling is bad because .. - you donno how they got in and they can get back in the same way again, and the 2nd time, they'd probably be less friendly - most crackers are not malicious and just wanna prove something to themself or their buddies - reinstalling and cleanup after a cracked box is very painful and can take days weeks of cleanup whether you reinstall or not - reinstallng does NOT clean up the other machines the cracker could have used .. ( esp passwordless login systems where they have free access to everything ) - reinstalling is bad because you didn't check your backups before restoring, and for all you know, you can be restoring their trojan that will wake up one day again in the future - if you didn't change your normal computer usage after the breakin, they will be back again - thousands of best practices security rules and policies to follow or not depending on ones paranoia or risk of something might happen vs the obvious required time/steps needed to protect against those possible crack attempts Unless the evidence of being rooted was hidden. This can be done with * replacing system binaries, so that, for instance, /bin/ls does not list the root kit files, and that /bin/ps does not display the rootkit those are trivial to check and verify .. few minutes one keeps a copy of all files and directories on another media ( cdrom ) - anything that shows up different is new file since the md5sum was done or its the cracker files - if you upgrade daily .. you're sorta assuming a few things, like you don't know or care that certain files changed on certain days or hopefulling logging it but how do you know it was changed due to update vs cracker got in and also got its files in your these are my changes for today checksums * replacing kernel (or modules) so that process information relating to the root kit is hidden, and files are hidden most rootkits leaves traces .. though it's getting better at hiding * hiding the root kit files in 'empty' spaces on the filesystem, (ie, where no inodes are pointing to) * hiding the root kit files in the filesystem (amongs other files, a little bit in each inode maybe?) ideal places for those is using the extra buytes of /etc/hosts /etc/resolv.conf /etc/hosts.conf /etc/passwd ( small files, where lots of unused bytes is available ) if they have hidden their stuff inside a secret filesystem of unused disk space... you need professional 3-letter help ... - reinstalling will not help you, as they probably outclass your/our security policies and a more likely scarier problem, is they installed a keyboard sniffer ( quietly sniffing all your passwds ) - do you login each time or do you login only once ?? Yes, if the
Re: Compromised system - still ok?
Some interesting points raised by Alvin. On the other hand, run rkhunter after updating its lists chkrootrit. See what they have to say about your system, but also watch out for false positives due to back-ported security patches (mostly for openssl, ssh, ..) in Debian. (step 1) If the machine is not critical, given the fact that you seem to have noticed the compromise rather early on and that your firewall blocked traffic to the telnetserver, you could invest some extra time in checking md5sums of important files (again rkhunter chkrootkit can help a bit here ), close the security hole and reboot to your new kernel. But before doing so, check your logfiles. Are you missing information for some days from a while ago? Or missing complete logfiles/days? Probably the attacker(s) had access to the box before - and long before you noticed - so they concealed their traces, and then you should go to step 2 without hesitation. Watch for suspicious traffic going to and from the box for a while, then forget about it. (step 2) If the machine is really important or serving important data, check the integrity of the data, back it up and take no chances but reinstall the box from scratch. Good luck. Roger -- Under capitalism, man exploits man. Under communism, it's just the opposite. J.K.Galbraith On Mon, 7 Feb 2005, Geoff Crompton wrote: You were rooted, you should reinstall. It's not worth risking that he left something that you didn't find. my opinion reinstalling is the equivalent of a script kiddie and probably lower in skill level of the script kiddie /opinion see below for reasons if one cares I see no evidence at all of being rooted, or even hints thereto. Yes, the backup account was compromized. It looks like there were quite some security measures in place, try to look hard for any attempt to kernel exploit or otherwise local exploit, and think about what files this backup account had access to. Of course, importance of the system matters too, if you were the NSA or something, I'd definitely reinstall, however, if you're not THAT paranoid, I think you can do with locking down backup account, checking all files writeable by backup (all files with recent ctime?), and places like /var/tmp, /tmp, etc. nsa and other 3-letter agencies will probably find out: - where the cracker came from - what else the cracker did on the suspect box - what other machines the cracker tried to access inside the network and what other files were changed on other servers - how they got in and repoduce how they got in - come to your door step and serve a warrant if one broke into a secret machine - are there automated jobs that run at fixed times or whenver you do something - how long have they been in the system before you noticed and sometimes they are in there for weeks or months before you start to notice because they started to use the cracked box - is the backup clean or is it suspect too - what files the cracker changed - what files the cracker added - .. on and on .. you can reinstall AFTER you can answer all the above questions or give up and give the point ot the script kiddie cracker resinstalling is bad because .. - you donno how they got in and they can get back in the same way again, and the 2nd time, they'd probably be less friendly - most crackers are not malicious and just wanna prove something to themself or their buddies - reinstalling and cleanup after a cracked box is very painful and can take days weeks of cleanup whether you reinstall or not - reinstallng does NOT clean up the other machines the cracker could have used .. ( esp passwordless login systems where they have free access to everything ) - reinstalling is bad because you didn't check your backups before restoring, and for all you know, you can be restoring their trojan that will wake up one day again in the future - if you didn't change your normal computer usage after the breakin, they will be back again - thousands of best practices security rules and policies to follow or not depending on ones paranoia or risk of something might happen vs the obvious required time/steps needed to protect against those possible crack attempts Unless the evidence of being rooted was hidden. This can be done with * replacing system binaries, so that, for instance, /bin/ls does not list the root kit files, and that /bin/ps does not display the rootkit those are trivial to check and verify .. few minutes one keeps a copy of all files and directories on another media ( cdrom ) - anything that shows up different is new file since the md5sum was done or its the cracker files - if you upgrade daily .. you're sorta assuming a few things,
Re: Compromised system - still ok?
In article [EMAIL PROTECTED] you wrote: you can reinstall AFTER you can answer all the above questions or give up and give the point ot the script kiddie cracker No, you make an image, reinstall, and if you have time (ie. you normally dont) then you can start the forensics. Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compromised system - still ok?
On Mon, 7 Feb 2005, Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: you can reinstall AFTER you can answer all the above questions or give up and give the point ot the script kiddie cracker No, you make an image, reinstall, and if you have time (ie. you normally dont) then you can start the forensics. yes about making an image ... i assume you mean - take the box down, - i hate taking the box down, as you can lose valuable info in its memory - i'd re-install into a new disk and leave the cracked one alone ( disks are super cheap ) - i would not reinstall on the cracked disk as it can have hidden filesystems - for forensics.. use a good cd or build a custom disk with with lot of fun forensics on it and fiddle till one finds all the answers :-0 after small or big cracking, one always have to make time, and take more preventative measures vs spending time on forensics unless you wanna lock um up :-) fun stuff c ya alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compromised system - still ok?
You'll want to evaluate the time and resources you'll consume, and to what end. Even in high profile cases, you have to do even more work to collect the damages awarded. It's like a triple whammy: 1. Your box gets compromised 2. You sue them 3. And then collect damages You'll quickly loose a case if there is any demonstration of negligence (that tail between your legs about the backup account - yea, you know, but didn't act. that's enough negligence to blow the case) All my comments are my own. Don't hesitate to seek professional counsel. Thanks, Scott Edwards Daxal Communications - http://www.daxal.com/ after small or big cracking, one always have to make time, and take more preventative measures vs spending time on forensics unless you wanna lock um up :-) fun stuff c ya alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compromised system - still ok?
On Sun, 6 Feb 2005, Scott Edwards wrote: You'll want to evaluate the time and resources you'll consume, and to what end. Even in high profile cases, you have to do even more work to collect the damages awarded. It's like a triple whammy: 1. Your box gets compromised 2. You sue them 3. And then collect damages collecting is non trivial .. nor is the process of filing suits however, if you got the fbi or local computer crime boyz involved, they can usually scare the pants off of the crackers, by showing up on their doorstep and taking away all their toys ( pc, routers ) - works great across the usa, even if the cracked box they came from was offshore, they can trace it back to somebody's bedroom or colo i think the fed's get involved if you can show that cracker came from the fed's machines :-) and/or if the damages exceeds a particular amount, which seems very victim friendly, which in the case of a security breach is fairly easy to reach in losses and more than likely, they're already tracking that cracker it's best when you can call the fbi (on the phone) and say, they're back, trace um NOW c ya alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compromised system - still ok?
On Sun, Feb 06, 2005 at 10:52:50PM -0800, Alvin Oga wrote: it's best when you can call the fbi (on the phone) and say, they're back, trace um NOW Obviously you've never done this. Good luck finding someone who even knows what TCP/IP is, let alone sufficient knowledge to be able to track a cracker in real time with no warning. - Matt signature.asc Description: Digital signature
Re: Compromised system - still ok?
On Sun, Feb 06, 2005 at 10:52:50PM -0800, Alvin Oga wrote: it's best when you can call the fbi (on the phone) and say, they're back, trace um NOW Obviously you've never done this. Good luck finding someone who even knows what TCP/IP is, let alone sufficient knowledge to be able to track a cracker in real time with no warning. - Matt And a cracker not connected to their systems, that is. Seriously, what are they to trace ? Where the IP is located ? That's obviously something you can do yourself. And then you'd still need to file a complaint to have someone get in touch with the ISP/organization. This takes time. And what if your cracker used an unprotected WiFi network, public library or university computer, ... ? Regards, Roger -- Under capitalism, man exploits man. Under communism, it's just the opposite. J.K.Galbraith -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
