On Mon, 16 Nov 1998, Brian wrote:
No, but I see stuff from this:
Nov 16 15:14:34 venus in.telnetd[17889]: connect from 209.119.115.65 Nov 16 15:14:35 venus in.telnetd[17890]: connect from 209.119.115.65
Hrrrm, so far I'm routing the following to Null0: 38.29.63.0/24 207.104.58.0/24 209.67.50.0/24 209.119.115.0/24 And blocking/logging all inbound telnet connections (besides, real men use SSH 8-)... Am I forgetting anything?
On Mon, Nov 16, 1998 at 06:51:53PM -0500, Adam Rothschild wrote:
Am I forgetting anything?
Yeah. Calling the providers where the attack is originating from. Calling your local law enforcement agencies and alerting them to the problem at hand Calling your local fbi agent and telling them what is going on. Calling CERT and opening up a case I'm sure if you get CERT+FBI+Local law agencies calling *ANY* noc, someone is going to notice. And for fun, call CNN, or some other news agency, and say "xxx hasn't dealt with this after many phone calls, etc..". If none of those paths provides you with the desired response, unplug your ethernet cable. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net | http://puck.nether.net/~jared/
It looks worse Jared, This appears to be a concerted effort. This type of attack is propogating to new origin IP's by the hour. There seems to be a pattern forming.... DNS server is compromised. (Bind ? Autohack ?) local programs set up to crack local passwords. (Dumps results to FTP directory) local program set up to port probe/asttack other DNS's. (Dumps results to FTP directory) Someone said Linux servers appear to be primary targets.. I suggest maybe Linux servers were more likely to have a vulnerable configuration... Probers running locally,( that I saw), did not *seem* to discriminate. (Conjecture Based on output of parasitic programs) I hate to profer alt.net.conspiracy...... But... the above data was collected both by myself, as well as another NANOG member who may want to remain anonymous... (He didn't post it to the group) CERT does have an alert posted, but I am not sure they know how pervasive this is..... Jared Mauch wrote:
On Mon, Nov 16, 1998 at 06:51:53PM -0500, Adam Rothschild wrote:
Am I forgetting anything?
Yeah.
Calling the providers where the attack is originating from.
Calling your local law enforcement agencies and alerting them to the problem at hand
Calling your local fbi agent and telling them what is going on.
Calling CERT and opening up a case
I'm sure if you get CERT+FBI+Local law agencies calling *ANY* noc, someone is going to notice.
And for fun, call CNN, or some other news agency, and say "xxx hasn't dealt with this after many phone calls, etc..".
If none of those paths provides you with the desired response, unplug your ethernet cable.
- jared
-- Jared Mauch | pgp key available via finger from jared@puck.nether.net | http://puck.nether.net/~jared/
On Mon, Nov 16, 1998 at 08:34:23PM -0500, Richard Irving put this into my mailbox:
It looks worse Jared,
This appears to be a concerted effort. This type of attack is propogating to new origin IP's by the hour. There seems to be a pattern forming....
DNS server is compromised. (Bind ? Autohack ?) local programs set up to crack local passwords. (Dumps results to FTP directory) local program set up to port probe/asttack other DNS's. (Dumps results to FTP directory)
Someone said Linux servers appear to be primary targets.. I suggest maybe Linux servers were more likely to have a vulnerable configuration... Probers running locally,( that I saw), did not *seem* to discriminate. (Conjecture Based on output of parasitic programs)
Based on what I have seen since roughly May 1998, I would guess that all these nameservers are the victims of the old named-4.9.6 buffer overflow. They then get compromised, trojaned, and get 'mscan' (available on rootshell) installed. Mscan then performs DNS walks (via AXFR) across entire domains, probing for named vulnerabilities, imap vulnerabilities, sunrpc(statd) vulnerabilities, and pop3 vulnerabilities. Chances are it's been upgraded to do more. Essentially, all the person has to do is point mscan at some large institution, net/com/edu, let it run for a few hours, come back, and they will most likely have in their list of vulnerable servers 5 or 10 more servers that can be hacked in the same manner. Solutions, to either prevent or at least delay people from hacking your boxes (if they haven't been there for months already): * Turn off public AXFR from your nameservers. bind 8 makes this very easy. * KEEP YOUR SYSTEMS UP TO DATE. Make sure your customers are doing this too. Almost all of the systems comprimised in this manner had RedHat or FreeBSD or Solaris installed, and then nobody installed patches. RPMs are easy to download and install for RedHat, and Solaris makes this almost as easy with patchadd. * NEVER connect a new machine to the network unless it has been fully patched and tested. This is old sysadmin knowledge, but it seems to have been forgotten in this day and age of plug and play operating systems. I know of a researcher who installed Linux on his home machine (connected via ISDN), got hacked into and was completely plowed 3 days later. I am not exaggerating. If you are vulnerable, they will find you, and they will find you *before* you 'get a chance' to patch your boxes. * If you see this message and run out to test your machine with ISS or somesuch because you haven't patched in a year, do not assume that you are safe simply because ISS says so. The folks who hack into boxes like this almost always patch the hole they used to get in. Look for hidden files, stuff in /dev that's not supposed to be there, etc - essentially anything suspicious. At least once per day, sometimes more often, my machines are probed by people using mscan, backorifice, NetBus, wingate scanners, and other nefarious utilities. Would that I had the time to report them all - unfortunately, I don't, and until I can come up with some intelligent scripts to process the reports, my Incident Pile is growing. This is a bad sign. This is getting to be off topic, but I am not seeing anything new here. These are the *same* old hacks, the *same* old probes, that have been going on continuously for 6 months to a year now. You're just finding more and more people stupid enough not to cover their tracks. (Or more sysadmins wising up to the fact that their new PII-300 running linux isn't supposed to take 5 minutes to come up with a shell prompt.) Most importantly, if you find yourself hacked into, before you rm -rf the drive, before you do anything other than unplug its ethernet, notify CERT and your local law enforcement agency (FBI in the US). Even if they aren't able to trace your specific cracker, it helps *very* much to have a paper trail and to have Actual Law Enforcement Agents look at your case, just on the off chance that it might turn into something large. Your local FBI agent is very friendly, and is there to help you. The other portion is communication. If your box has been hacked, and you don't know what to do, ask for help. It is not a disgrace to get hacked; even I've overlooked patches and gotten myself hacked a few times. It happens. You clean up, reinstall, and life goes on. (and who ever said IRC wasn't good for anything? }:P ) -dalvenjah -- Dalvenjah FoxFire (aka Sven Nielsen) "Hath not a dude eyes? If you prick us, Founder, the DALnet IRC Network do we not get bummed? If we eat bad guacamole, do we not blow chunks?" e-mail: dalvenjah@dal.net - Keanu Reeves as Shylock in The Critic whois: SN90 WWW: http://www.dal.net/~dalvenjah/
On Mon, 16 Nov 1998, Richard Irving wrote:
This appears to be a concerted effort. This type of attack is propogating to new origin IP's by the hour. There seems to be a pattern forming....
Has anyone considered that this might be a worm? The attacked hosts have all exhibited the same characteristics: stock Red Hat 5.1 install, running (probably) the stock named that came with it, which is a known vulnerable bind release. There are a -lot- of these boxen out there. Plus, the mechanical attacks on particular ports. This sounds fairly automated to me...but hey, what do I know? ;-) -- Edward S. Marshall <emarshal@logic.net> /> Who would have thought that we -o) http://www.logic.net/~emarshal/ // would be freed from the Gates of /\\ Linux Weenie, Open-Source Advocate </ hell by a penguin named "Tux"? _\_v
On Mon, 16 Nov 1998, Edward S. Marshall wrote:
The attacked hosts have all exhibited the same characteristics: stock Red Hat 5.1 install, running (probably) the stock named that came with it,
Not entirely true. I watched a FreeBSD 2.2.x/BIND 8.1.2 box get tickled harmlessy... Go to bed, porscanning twit kiddies. It's late now, and Teletubbies ain't on. 8-)
I think he meant the compromised hosts, or the hosts that the attacks were coming from, were all RH 5.1 with an old rev of BIND. My 3.0-current box with 8.1.2 handled it fine, as well. At 22:30 11/16/98 -0500, Adam Rothschild wrote:
On Mon, 16 Nov 1998, Edward S. Marshall wrote:
The attacked hosts have all exhibited the same characteristics: stock Red Hat 5.1 install, running (probably) the stock named that came with it,
Not entirely true. I watched a FreeBSD 2.2.x/BIND 8.1.2 box get tickled harmlessy...
Go to bed, porscanning twit kiddies. It's late now, and Teletubbies ain't on. 8-)
William S. Duncanson caesar@starkreality.com The driving force behind the NC is the belief that the companies who brought us things like Unix, relational databases, and Windows can make an appliance that is inexpensive and easy to use if they choose to do that. -- Scott Adams
You guys might be overlooking a very major security hole with linux, besides bind. Rpc.Mountd. If you haven't patched yet, do so now, because exploits have been publically available for a while now and this is a remote attack that will compromise root. The easiest thing to do if you don't have time to sit and upgrade every linux box on your network with the latest rpc.mountd, or kill it off, or whatever you plan on doing, might be to just go on your router and put up an access-list denying all inbound connections on port 111 (the rpc portmapper). Even though its pretty trivial to guess what port rpc.mountd is on (2049) instead of using the portmapper, the exploits aren't configured to do so (at least not ot my knowledge). And if you're still worried you could firewall both 111 and 2049. Well good luck. 8) On Mon, 16 Nov 1998, William S. Duncanson wrote:
I think he meant the compromised hosts, or the hosts that the attacks were coming from, were all RH 5.1 with an old rev of BIND. My 3.0-current box with 8.1.2 handled it fine, as well.
At 22:30 11/16/98 -0500, Adam Rothschild wrote:
On Mon, 16 Nov 1998, Edward S. Marshall wrote:
The attacked hosts have all exhibited the same characteristics: stock Red Hat 5.1 install, running (probably) the stock named that came with it,
Not entirely true. I watched a FreeBSD 2.2.x/BIND 8.1.2 box get tickled harmlessy...
Go to bed, porscanning twit kiddies. It's late now, and Teletubbies ain't on. 8-)
William S. Duncanson caesar@starkreality.com The driving force behind the NC is the belief that the companies who brought us things like Unix, relational databases, and Windows can make an appliance that is inexpensive and easy to use if they choose to do that. -- Scott Adams
And one more thing. I am not Linux specialist, but I see a resious problem because this compromised servers are usially troyaned by the 'Linux Root Kit' hidding all hacker's activity. If anyone have some tools to detect this rootkit (it include more than 200 files changed in the system), point it, please - all my attempts to contact RedHat and other Linux developers caused nothing. The excellent (-:)) set of exploits and troyans is stored at ftp://ftp.technotronic.com/ (this is the place where russion hackers have got this toolkits first from), but I saw some self-changed toolkits from other places. The only advice I can provide. First, compare MD5 checksums if you can. If you can not, make find /dev -type f -print and ls -ld /dev and, if you see some FILES like 'ptyp' or 'fmpd1' or directory ..., it's no doubt the traces of the hacker (if not, this means NOTHING - anyone can use another configuration). I did not saw real usages of this mountd exploits, but they does exist. What I have seen was - imapd, qpopper exploits to get root access withouth user account; lprm, ufsrestore (not in linux), X11 exploits to get root access from the user's account. But... if you have not this exploits, this means nothing. On Tue, 17 Nov 1998, Michael Freeman wrote:
Date: Tue, 17 Nov 1998 12:26:42 +0000 (Local time zone must be set--see zic manual page) From: Michael Freeman <mikef@boris.talentsoft.com> To: "William S. Duncanson" <caesar@starkreality.com> Cc: Adam Rothschild <asr@millburn.net>, "Edward S. Marshall" <emarshal@logic.net>, Richard Irving <rirving@onecall.net>, nanog@merit.edu Subject: Re: Exodus: this is bad
You guys might be overlooking a very major security hole with linux, besides bind. Rpc.Mountd. If you haven't patched yet, do so now, because exploits have been publically available for a while now and this is a remote attack that will compromise root. The easiest thing to do if you don't have time to sit and upgrade every linux box on your network with the latest rpc.mountd, or kill it off, or whatever you plan on doing, might be to just go on your router and put up an access-list denying all inbound connections on port 111 (the rpc portmapper). Even though its pretty trivial to guess what port rpc.mountd is on (2049) instead of using the portmapper, the exploits aren't configured to do so (at least not ot my knowledge). And if you're still worried you could firewall both 111 and 2049. Well good luck. 8)
On Mon, 16 Nov 1998, William S. Duncanson wrote:
I think he meant the compromised hosts, or the hosts that the attacks were coming from, were all RH 5.1 with an old rev of BIND. My 3.0-current box with 8.1.2 handled it fine, as well.
At 22:30 11/16/98 -0500, Adam Rothschild wrote:
On Mon, 16 Nov 1998, Edward S. Marshall wrote:
The attacked hosts have all exhibited the same characteristics: stock Red Hat 5.1 install, running (probably) the stock named that came with it,
Not entirely true. I watched a FreeBSD 2.2.x/BIND 8.1.2 box get tickled harmlessy...
Go to bed, porscanning twit kiddies. It's late now, and Teletubbies ain't on. 8-)
William S. Duncanson caesar@starkreality.com The driving force behind the NC is the belief that the companies who brought us things like Unix, relational databases, and Windows can make an appliance that is inexpensive and easy to use if they choose to do that. -- Scott Adams
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
On Tue, 17 Nov 1998 22:24:41 +0300 (MSK), "Alex P. Rudnev" <alex@Relcom.EU.net> said:
Alex> The only advice I can provide. First, compare MD5 checksums if Alex> you can. rpm -Va takes a while, but it is useful in checking out security problems. rob
On Tue, 17 Nov 1998, Alex P. Rudnev wrote:
And one more thing. I am not Linux specialist, but I see a resious problem because this compromised servers are usially troyaned by the 'Linux Root Kit' hidding all hacker's activity. If anyone have some tools to detect this rootkit (it include more than 200 files changed in the system), point it, please - all my attempts to contact RedHat and other Linux developers caused nothing.
Systems using RPM-based package management (Redhat and most other distributions) can use the verify function to check their system's files vs. what was installed. The command to check the entire system is 'rpm -V -a'. The output looks something like: S.5....T c /etc/exports S.5....T c /etc/hosts.allow S.5....T c /etc/motd Periods (.) mean the test passed, otherwise you'll get a fail flag.. 5: MD5 checksum S: file size L: symlink T: mtime D: device U: user G: group M: file modes A 'c' between the flags and the filename indicates that this is a configuration file (and as such commonly modified). More information should be in the rpm manpage. Hope this info helps. -- Greg <a href="mailto:greg@rage.net">|\/\/| Greg Retkowski |\/\/|</a><br> <a href="http://www.rage.net/">|/\/\|"Save the Factories"|/\/\|</a><br>
Btw. Remember - not only troyaned files are the problem, but some additional services can (and WAS) be added into the system. Like special version of ssh. This case no MD5 checksumms differ from the distribution, but you should detect additional ports open for the listening. --- Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
On Tue, 17 Nov 1998, Alex P. Rudnev wrote:
'Linux Root Kit' hidding all hacker's activity. If anyone have some tools to detect this rootkit (it include more than 200 files changed in the system), point it, please - all my attempts to contact RedHat and other Linux developers caused nothing.
If you're using Red Hat (or other distributions which use RPM), RPM itself can help. The command 'rpm -Va' performs checksum, MD5, ownership, permissions, and create_time checks against all packages installed on your system. For a shorter list, I use "rpm -Va | grep -v ' c '", which will exclude config files (which are generally always changed, and need to be reviewed...and in my case, unauthorized changes are caught by tripwire). The vulnerability here is the rpm databases, which could be mangled by the attacker (outright modification, or the simple use of the rpm system to install the hacked binaries). For other *ix distributions, there's always tripwire to detect what has been changed. I also use it to keep an eye on my config files and the various parts/dependencies of the rpm system (rpm executable, databases, glibc, etc). Like RPM, however, it also has a vulnerability of intentional corruption of the executable and databases. To safeguard the databases and executables like tripwire, I use the tried-and-true 'copy on a write-protected floppy' method. One could also pgp sign the individual files and just keep your keyrings and pgp executable on a write-protected floppy (as well as proper safeguards for your private keyring used to sign 'em). One technique that stops older rootkits cold is to mount /usr as read-only. BUT, it seems that newer rootkits know how to remount 'em, so it's no real protection unless the media itself is read-only like a cdrom. I also keep copies of some critical binaries on a protected floppy. Things like ifconfig, netstat, ps, and file. Of course, all of the above is pro-active, steps must have been taken prior to the break-in. And in some cases, troublesome and time-consuming steps must be followed pedantically following system configuration changes. As another poster so astutely noted that the sysadmins of hacked machines rarely pay attention to forums such as these, it is also true that they also don't pay attention to proper security measures at all. (generally in the realm of 'watching the watchers'...tripwire is useless against an advanced hacker if you've not properly safeguarded its databases). Hope in detecting the presence of a rootkit isn't totally lost if you haven't done these things (although if the test is positive, you'll be spending a lot of time with that machine for the next few days). If your 'file' command isn't corrupted, a simple 'file /dev/* |grep [Tt]ext' command will typically reveal the presence of most current and older rootkits, as they (so far) tend to hide their config files in /dev. In text. As a side note, I've seen a rootkit attack where the attacker had a c program to compile locally (I assume to link against my shared libs; why it wasn't just a statically linked binary I dunno). The brick wall here was that my production machines don't have any compilers on 'em. [although I do have perl, so my mileage will vary here].
The excellent (-:)) set of exploits and troyans is stored at ftp://ftp.technotronic.com/ (this is the place where russion hackers have got this toolkits first from), but I saw some self-changed toolkits from other places.
The only advice I can provide. First, compare MD5 checksums if you can. If you can not, make
find /dev -type f -print
and
ls -ld /dev
and, if you see some FILES like 'ptyp' or 'fmpd1' or directory ..., it's no doubt the traces of the hacker (if not, this means NOTHING - anyone can use another configuration).
I did not saw real usages of this mountd exploits, but they does exist. What I have seen was - imapd, qpopper exploits to get root access withouth user account; lprm, ufsrestore (not in linux), X11 exploits to get root access from the user's account.
But... if you have not this exploits, this means nothing.
On Tue, 17 Nov 1998, Michael Freeman wrote:
Date: Tue, 17 Nov 1998 12:26:42 +0000 (Local time zone must be set--see zic manual page) From: Michael Freeman <mikef@boris.talentsoft.com> To: "William S. Duncanson" <caesar@starkreality.com> Cc: Adam Rothschild <asr@millburn.net>, "Edward S. Marshall" <emarshal@logic.net>, Richard Irving <rirving@onecall.net>, nanog@merit.edu Subject: Re: Exodus: this is bad
You guys might be overlooking a very major security hole with linux, besides bind. Rpc.Mountd. If you haven't patched yet, do so now, because exploits have been publically available for a while now and this is a remote attack that will compromise root. The easiest thing to do if you don't have time to sit and upgrade every linux box on your network with the latest rpc.mountd, or kill it off, or whatever you plan on doing, might be to just go on your router and put up an access-list denying all inbound connections on port 111 (the rpc portmapper). Even though its pretty trivial to guess what port rpc.mountd is on (2049) instead of using the portmapper, the exploits aren't configured to do so (at least not ot my knowledge). And if you're still worried you could firewall both 111 and 2049. Well good luck. 8)
On Mon, 16 Nov 1998, William S. Duncanson wrote:
I think he meant the compromised hosts, or the hosts that the attacks were coming from, were all RH 5.1 with an old rev of BIND. My 3.0-current box with 8.1.2 handled it fine, as well.
At 22:30 11/16/98 -0500, Adam Rothschild wrote:
On Mon, 16 Nov 1998, Edward S. Marshall wrote:
The attacked hosts have all exhibited the same characteristics: stock Red Hat 5.1 install, running (probably) the stock named that came with it,
Not entirely true. I watched a FreeBSD 2.2.x/BIND 8.1.2 box get tickled harmlessy...
Go to bed, porscanning twit kiddies. It's late now, and Teletubbies ain't on. 8-)
William S. Duncanson caesar@starkreality.com The driving force behind the NC is the belief that the companies who brought us things like Unix, relational databases, and Windows can make an appliance that is inexpensive and easy to use if they choose to do that. -- Scott Adams
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
Just got to this list. Has any one called the FBI yet. It looks like a full-scale raid. At 08:34 PM 11/16/98 -0500, Richard Irving wrote:
It looks worse Jared,
This appears to be a concerted effort. This type of attack is propogating to new origin IP's by the hour. There seems to be a pattern forming....
DNS server is compromised. (Bind ? Autohack ?) local programs set up to crack local passwords. (Dumps results to FTP directory) local program set up to port probe/asttack other DNS's. (Dumps results to FTP directory)
Someone said Linux servers appear to be primary targets.. I suggest maybe Linux servers were more likely to have a vulnerable configuration... Probers running locally,( that I saw), did not *seem* to discriminate. (Conjecture Based on output of parasitic programs)
I hate to profer alt.net.conspiracy...... But...
the above data was collected both by myself, as well as another NANOG member who may want to remain anonymous... (He didn't post it to the group)
CERT does have an alert posted, but I am not sure they know how pervasive this is.....
Jared Mauch wrote:
On Mon, Nov 16, 1998 at 06:51:53PM -0500, Adam Rothschild wrote:
Am I forgetting anything?
Yeah.
Calling the providers where the attack is originating from.
Calling your local law enforcement agencies and alerting them to the problem at hand
Calling your local fbi agent and telling them what is going on.
Calling CERT and opening up a case
I'm sure if you get CERT+FBI+Local law agencies calling *ANY* noc, someone is going to notice.
And for fun, call CNN, or some other news agency, and say "xxx hasn't dealt with this after many phone calls, etc..".
If none of those paths provides you with the desired response, unplug your ethernet cable.
- jared
-- Jared Mauch | pgp key available via finger from jared@puck.nether.net | http://puck.nether.net/~jared/
___________________________________________________ Roeland M.J. Meyer, ISOC (InterNIC RM993) e-mail: <mailto:rmeyer@mhsc.com>rmeyer@mhsc.com Internet phone: hawk.mhsc.com Personal web pages: <http://www.mhsc.com/~rmeyer>www.mhsc.com/~rmeyer Company web-site: <http://www.mhsc.com/>www.mhsc.com/ ___________________________________________ Who is John Galt? "Atlas Shrugged" - Ayn Rand
Folks. All (ALL) Linux-based NS servers or other LInux servers with IMAPD turned on (default) and withouth imapd patch (I do not know if it exist at all) can be treaten as COMPROMISED. I have found (and closed) more than 20 backdoored servers over the world in a week (and it was done by ONLY ONE HACKER)! What do you discuss? This was not serious attack, it was (I think) usial network scanning they are doing (or was doing) EVERY DAY. On Mon, 16 Nov 1998, Richard Irving wrote:
Date: Mon, 16 Nov 1998 20:34:23 -0500 From: Richard Irving <rirving@onecall.net> To: Jared Mauch <jared@puck.nether.net> Cc: Adam Rothschild <asr@millburn.net>, list@inet-access.net, nanog@merit.edu Subject: Re: Exodus: this is bad
It looks worse Jared,
This appears to be a concerted effort. This type of attack is propogating to new origin IP's by the hour. There seems to be a pattern forming....
DNS server is compromised. (Bind ? Autohack ?) local programs set up to crack local passwords. (Dumps results to FTP directory) local program set up to port probe/asttack other DNS's. (Dumps results to FTP directory)
Someone said Linux servers appear to be primary targets.. I suggest maybe Linux servers were more likely to have a vulnerable configuration... Probers running locally,( that I saw), did not *seem* to discriminate. (Conjecture Based on output of parasitic programs)
I hate to profer alt.net.conspiracy...... But...
the above data was collected both by myself, as well as another NANOG member who may want to remain anonymous... (He didn't post it to the group)
CERT does have an alert posted, but I am not sure they know how pervasive this is.....
Jared Mauch wrote:
On Mon, Nov 16, 1998 at 06:51:53PM -0500, Adam Rothschild wrote:
Am I forgetting anything?
Yeah.
Calling the providers where the attack is originating from.
Calling your local law enforcement agencies and alerting them to the problem at hand
Calling your local fbi agent and telling them what is going on.
Calling CERT and opening up a case
I'm sure if you get CERT+FBI+Local law agencies calling *ANY* noc, someone is going to notice.
And for fun, call CNN, or some other news agency, and say "xxx hasn't dealt with this after many phone calls, etc..".
If none of those paths provides you with the desired response, unplug your ethernet cable.
- jared
-- Jared Mauch | pgp key available via finger from jared@puck.nether.net | http://puck.nether.net/~jared/
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
On Tue, Nov 17, 1998 at 02:14:53PM +0300, Alex P. Rudnev wrote:
Folks. All (ALL) Linux-based NS servers
even running bind 8.1.2? (I am) -- Steve Sobol [sjsobol@nacs.net] Part-time Support Droid [support@nacs.net] NACS Spaminator [abuse@nacs.net] Spotted on a bumper sticker: "Possum. The other white meat."
No. Check your version like this: dig chaos txt version.bind. @dns.server.your.net unless you've hacked your source. - jared On Wed, Nov 18, 1998 at 03:01:33PM -0500, Steven J. Sobol wrote:
On Tue, Nov 17, 1998 at 02:14:53PM +0300, Alex P. Rudnev wrote:
Folks. All (ALL) Linux-based NS servers
even running bind 8.1.2? (I am)
-- Steve Sobol [sjsobol@nacs.net] Part-time Support Droid [support@nacs.net] NACS Spaminator [abuse@nacs.net]
Spotted on a bumper sticker: "Possum. The other white meat."
-- Jared Mauch | pgp key available via finger from jared@puck.nether.net | http://puck.nether.net/~jared/
On Mon, 16 Nov 1998, Brian wrote:
No, but I see stuff from this:
Nov 16 15:14:34 venus in.telnetd[17889]: connect from 209.119.115.65 Nov 16 15:14:35 venus in.telnetd[17890]: connect from 209.119.115.65
Both of our BSDi nameservers as well. Just a while after your were hit. Definatly a pattern forming here. Nov 16 15:57:05 iron telnetd@ns1.mv.net[10984]: connect from 209.119.115.65 Nov 16 15:57:06 iron telnetd@ns1.mv.net[10985]: connect from 209.119.115.65 Nov 16 16:06:01 nickel telnetd@ns2.mv.net[1118]: connect from 209.119.115.65 Nov 16 16:06:01 nickel telnetd@ns2.mv.net[1120]: connect from 209.119.115.65 -- Rob @ MV Staff robh@cs.mv.net (603) 629-0000
They went for our FreeBSD box too, and around the same time everyone else is being scanned, I'm starting to think that this has got to be a worm. Nov 16 16:08:31 ns1 telnetd[6355]: connect from mcserver.com Nov 16 16:08:31 ns1 telnetd[6354]: connect from mcserver.com On Mon, 16 Nov 1998, Robert C. Henney wrote:
On Mon, 16 Nov 1998, Brian wrote:
No, but I see stuff from this:
Nov 16 15:14:34 venus in.telnetd[17889]: connect from 209.119.115.65 Nov 16 15:14:35 venus in.telnetd[17890]: connect from 209.119.115.65
Both of our BSDi nameservers as well. Just a while after your were hit. Definatly a pattern forming here.
Nov 16 15:57:05 iron telnetd@ns1.mv.net[10984]: connect from 209.119.115.65 Nov 16 15:57:06 iron telnetd@ns1.mv.net[10985]: connect from 209.119.115.65
Nov 16 16:06:01 nickel telnetd@ns2.mv.net[1118]: connect from 209.119.115.65 Nov 16 16:06:01 nickel telnetd@ns2.mv.net[1120]: connect from 209.119.115.65
-- Rob @ MV Staff robh@cs.mv.net (603) 629-0000
--------------------------------------------------------------------- Jari Takkala - <takkala@netwave> / <jtakkala@digital-network.net> System Administrator - Digital-Network http://www.digital-network.net ---------------------------------------------------------------------
participants (16)
-
Adam Rothschild -
Alex P. Rudnev -
alex＠relcom.EU.net
-
Dalvenjah FoxFire -
Edward S. Marshall -
Greg Retkowski -
Jared Mauch -
Lon R. Stockton, Jr. -
Michael Freeman -
Richard Irving -
Rob Walker -
Robert C. Henney -
Roeland M.J. Meyer -
Steven J. Sobol -
Takkala -
William S. Duncanson