Hi Tony,
I don't recognize the specific attack, but it certainly looks like
other buffer overflow attacks that I've seen on syslog events. If
you don't know what service is being attacked you can either look
for the service by its pid (assuming it is still running), look
for a startup message with the same pid earlier in the messages
output, or start grepping source trees for each of the services
you are running.
Cheers,
-kls
On Sun, Apr 22, 2001 at 11:20:27PM +1000, Tony Nugent wrote:
> This very strange syslog exerpt (below) is taken from
> /var/log/messages on a moderately busy network server box with
> redhat 6.x on it.
>
> Does anyone know what it is?
>
> If it is any sort of security problems, I'd really like to know :)
>
> It is not alone, I have it happening on four similar boxes. But we
> have quite a few more, also rh6.x, where I haven't seen this at all.
> I'm not sure what's so different with these four - I can't see any
> pattern.
>
> Things to note about these server boxes:
>
> - they are all new-ish PIII's (celerons and better) with plenty of
> grunt, ram and hard drive space for what they need to do.
> Hardware is not a likely or obvious cause.
>
> - they have had all the relevant security updates applied.
> - but only some of the "bugfix" packages, none that
> (obviously) pertain to anything that is actually running.
>
> - they are providing the following services:
> - DNS - namecaching only
> - samba, dhcpd - LAN server, netbios logons and services
> - sendmail - local relaying only, no local accounts
> - xntpd, upsd, lpd - local services only
> - squid proxy - transparent proxy setup
> - sshd, inetd (telnet/tftp), mgetty - admin access only
> - portslave/pppd dialup (ISP) services - multiport serial card
> - router, firewall - of course :)
>
> - all network services are protected via:
> - such things as ACLs and so on in config files
> - tcp_wrappers (where applicable)
> - local (and "outer") firewalls
> - regular system-state and log message monitoring
> - tripwire and other such nice tools
> - misc other "secret weapons" :-)
>
> - the netbios name of the samba server (on each box) happens to be
> "server".
> - has this got anything to do with the "SERVER" entry in these
> logs?
> - samba does not usually write to syslog (except for
> start/stop messages), it usually uses its own logs (nothing
> strange to be found in them).
> - the netbios ports/broadcasts are totally blocked from
> communication to and from the internet side of the firewall.
>
> - the boxes are otherwise:
> - fully functional, everything appears to be working normally
> - no services crashed, or appear to be otherwise broken.
> - the installations verify ok with rpm.
> - netstat shows that the network services are as they should.
> - nothing on the boxes have been disturbed, no sign of
> intruders or anything similar.
>
> It is happening unpredictably and infrequently (once a week or less
> on each of the four).
>
> These rather verbose messages are generated at a rate of around 20
> per minute. (They can blow out the size of /var/log/messages).
> Most episodes usually only last a few minutes before the problem
> apparently corrects itself (like this particular one), but on
> several occasions they have gone on for several hours.
>
> It seems to be that it could be:
>
> - someone attempting to get a get a buffer overflow error
> condition and root compromise via a network daemon.
>
> - someone doing a denial of service attack on a network
> service.
>
> - a library compatability problem that has started to occur
> after some of the upgrades/updates have been applied.
>
> - a bug in something that has not been updated.
>
> - a very obscure bug, possibly harmless, that is being
> triggered by a specific set of conditions.
>
> Any hints would be appreciated on how to go about tracking this
> problem and what to do about it.
>
> Web searching didn't get me very far... I have spotted only one
> newsgroup message that mentions this specific problem, expressing
> much the same puzzlement about what this could be. That person
> didn't get any responses and still has no idea what this could be.
>
> Thanks in advance.
>
> Aside:
>
> Some of our boxes were hit by early versions of the ramen/tr0n
> worm through vulnerable bind daemons... found early, now fixed
> with no long-term damage.
>
> It might be worth mentioning here most of the servers running
> vulnerable versions had ACLs in /etc/named.conf -- and this on
> its own saved ALL these boxes from the attack... they were
> configured not to answer queries for outside sources.
>
> The number of denied bind.version quieries our servers are
> getting (not to mention network-wide portscans) is nothing
> short of amazing, sometimes several per day.
>
> What all this has done is give me hightened awareness of just how
> important it is to keep network service daemons as securely
> configured as possible, and the binaries kept up to date.
> (Maintaining updates on a large server farm is a major management
> issue!)
>
> Cheers
> Tony
> -=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-
>
> NB: this box is not really called "linuxbox" - name changed to
> protect the guilty :) (And apologies if the hi-bit characters
> prove problematic for some people).
>
> 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
> Apr 22 11:15:20 linuxbox SERVER[28174]: Dispatch_input: bad request line
>'BB(ñÿ¿)ñÿ¿*ñÿ¿+ñÿ¿XXXXXXXXXXXXXXXXXX%.232u%300$n%.199u%301$nsecurity.i%302$n%.192u%303$n\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\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\2201Û1É1À°FÍ\200\211å1Ò²f\211Ð1É\2!
> 11ËC\211]øC\211]ôK\211Mü\215MôÍ\2001É
>
> [ ... ]
>
> Apr 22 11:17:48 linuxbox SERVER[28228]: Dispatch_input: bad request line
>'BB4ÿÿ¿5ÿÿ¿6ÿÿ¿7ÿÿ¿XXXXXXXXXXXXXXXXXX%.244u%300$n%.201u%301$n%.253u%302$n%.192u%303$n\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\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\2201Û1É1À°FÍ\200\211å1Ò²f\211Ð1É\211ËC!
> \211]øC\211]ôK\211Mü\215MôÍ\2001É\211
> Apr 12 11:17:50 linuxbox SERVER[28229]: Dispatch_input: bad request line
>'BB0ÿÿ¿1ÿÿ¿2ÿÿ¿3ÿÿ¿XXXXXXXXXXXXXXXXXX%.240u%300$n%.205u%301$n%.253u%302$n%.192u%303$n\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\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\2201Û1É1À°FÍ\200\211å1Ò²f\211Ð1É\211ËC!
> \211]øC\211]ôK\211Mü\215MôÍ\2001É\211
>
>
>
> _______________________________________________
> Redhat-devel-list mailing list
> [EMAIL PROTECTED]
> https://listman.redhat.com/mailman/listinfo/redhat-devel-list
--
// .--=,
.....::://::::::::::::::::::::::::::::.. (o O & [EMAIL PROTECTED]
:::::::://:::://://://:/:://::||_// / V K
:::::://:::://:/:|//'/' // _,|' r , 'qk
:'''/____ // / // |_// // || .'~. .~`,
kls \_/-=\_/
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
