[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: rpc.statd attack?

This is just a comment based on all the emails that I have been seeing here
(not that I read them all, but...).

In theory if you are going to leave your system setup on a public network, then
you should really be filtering ALL connections to the box and ONLY ONLY ONLY
allowing the services that you want through.

I don't remember if ipchains/filtering is in the default kernel, but if it is
not then it should be and everyone should have everything blocked :)

Then install a good basic rule set, something like:

## Flush all rules and set policies

## DENY ALL (This logs deny'ies - DEFAULT = DENY)
$IPCHAINS -I input -l -j REJECT

## Allow ICMP (But, REJECT echo requests (ping))
$IPCHAINS -I input -p icmp -j ACCEPT
$IPCHAINS -I input -l -p icmp -s 8 -j REJECT

## Allow SSH
$IPCHAINS -I input -p tcp -d 22 -j ACCEPT

## Allow Localhost
$IPCHAINS -I input -s -d -j ACCEPT

## Only allow packets without SYN flag set.
## SYN being set means we are trying to establish a connection
## without it being set means the connection IS established.
## This allows outbound to return.
$IPCHAINS -I input -p tcp \! -y -j ACCEPT

There is possibly a better way to do this, but I don't like the ipchains
interface, so I have not bothered to learn it.  But at any rate this is a great
basic rule set to keep you out of having issues like this.

Just my thoughts.  Comments?


On Tue, Jan 09, 2001 at 12:31:59PM -0800, crusius@stanford.edu wrote:
> I got the following (alarming) messages on syslog:
> Jan  8 13:34:23 yuban syslogd: Cannot glue message parts together
> Jan  8 13:34:23 yuban /sbin/rpc.statd[159]: gethostbyname error for ^X\xf7\xff\xbf^X\xf7\xff\xbf^Y\xf7\ xff\xbf^Y\xf7\xff\xbf^Z\xf7\xff\xbf^Z\xf7\xff\xbf^[\xf7\xff\xbf^[\xf7\xff\xbf%8x%8x%8x%8x%8x%8x%8x%8x%8 x%236x%n%137x%n%10x%n%192x%n\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\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\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\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
> Jan  8 13:34:23 yuban \xc7^F/bin\xc7F^D/shA0\xc0\210F^G\211v^L\215V^P\215N^L\211\xf3\xb0^K\xcd\200\xb0^ A\xcd\200\xe8\177\xff\xff\xff
> it looks like an attack (specially when I see /bin/sh hidden in
> there). I searched the lists and it seems that this problem should
> have been corrected before potato was released. Any reason for
> worries, or is there any reason why I should think it was an
> unsuccessful attack?

Reply to: