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?
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
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 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? }
)
-dalvenjah
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? 
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. 
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.
Just got to this list. Has any one called the FBI yet. It looks like a
full-scale raid.
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.
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)
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.
rpm -Va takes a while, but it is useful in checking out security
problems.
rob
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>
'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].
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.
even running bind 8.1.2?
(I am)
No.
Check your version like this:
dig chaos txt version.bind. @dns.server.your.net
unless you've hacked your source.
- jared
Not only...
But there is a lot of brainless schoolboys who are trying to use just
this 'imapd' exploit and (due to the number of them) trojaned a lot of
computers over the world. It's amazing but I saw few times the stack of
trojans installed one over another.
To be correct, there is a lot of _really used_ ways to broke the system.
The best (and easiest) was 'imapd' and 'qpopper' exploits (you simple run
scanner and it detects this services, then you run exploit and it reports
_you are root, go on_, then you ftp 'lrk3' or 'lrkb' or 'root_toolkit'
and install it.
Other way is to use sniffered accounts for the user access, and they you
have a lot of exploits to get root; the most popular are 'lprm' and 'X11'
exploits for linux, loadmodule and ufsrestore for Solaris and SunOS.
If you had not this security holes, it does not mean you was broken, but
your chance to be brocen decreases from 30% (for linux with IMAPD) to 1 -
2 % (for other holes).
I am not sure about BIND but I saw bind scanning and some logs looked
like:
ns.xxx.yyy volurentable
....
ns.zz.ww not volurentable
and I suspect someone have tried to use BIND's bugs too.