Odd ICMP packets and memory leak

Jason Pfingstmann wrote:
> First off, thanks to those who replied re: Happy Medium (linux/windows
> co-existance), I guess an A/B switcher is the way to go for now. ;)
>
> I have been trying to track down a memory leak our server has had for the
> last few days. It started Friday when the server would crash (more
> accurately the kernel would kick out user-space programs because of 100%
> memory usage - 1 GB physical and 1.9 GB swap -- overkill, but this was an
> LTSP server at one point) every 2 hours or so. I figured out this weekend
> that the problem is only present when the network is up and our iptables
> nat script is run. I then used iptraf to figure out what systems might be
> causing problems and found that 2 systems were sending out ICMP packets.
> One was infected with the Welchia worm which has been taken care of and
> the other didn't find any viruses (Using Norton with latest definitions).
> I am trying to pin-point this problem, and am thinking about just blocking
> all ICMP packets that are outbound over NAT as a temporary fix. I'm not
> going to be in the office until Wednesday and need to get this up and
> running tomorrow morning if possible. Here is what my iptraf monitor
> shows:
> ICMP echo req (92 bytes) from 192.168.0.146 to 192.166.55.110 on eth0 ICMP
> echo req (92 bytes) from 208.186.160.162 to 192.166.55.110 on eth1
>
> It repeats this one right after another, with various different
> destinations, all in the 192.x.x.x network.

Those addresses aren't private space addresses. You have packets going
out to the net it looks like to me. I would be curious to find out which
programs are pinging the net...

>
> I have tried various commands such as iptables -A INPUT -p ICMP -i eth0 -j
> DROP, but none have blocked this. Am I missing something obvious?

Try inserting this command before the others in your scripts...
unfortunately, iptables doesn't have (last I checked) a working -C flag.
If you are not using a script, try doing iptables -I INPUT 1 -p ICMP
-i eth0 -j DROP (or REJECT). This insert the drop rule as the first rule
in the INPUT chain. Rule placement is extremely important, if you placed
this line *after* you accept the packet using another rule this one will
be by-passed.

HTH
Patrick

>
> Thanks.
>
> Jason Pfingstmann
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change you mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss