Monitor Details

Is there a page with the IP Addresses of the Monitors? I think they may be triggering IDS (UDP_Flood), but need to confirm the sources before attempting to fix.

UDP Flood appears to be poorly configured device(s) on one of the Australia Networks using the pool… would still be nice to have list of Monitor IP addresses so they can be excluded from any “catch”…

Allowing all traffic from the monitor nodes and restricting traffic from the rest of the world would kind of defeat the purpose of the monitoring nodes, IMHO.

1 Like

Its not about restricting, its about making sure that the monitors are not mistakenly picked up by any IDS/IDP

If your firewall is set up so tight that it will think the probes from the monitoring node are an attack, that same firewall configuration will cause issues for other legitimate users of your server as well. If your server’s scores are OK, then there’s nothing to worry about. But if you do see dropped packets, consider relaxing your firewall rules a bit.

2 Likes

I have a hashlimit rule in my iptables for inbound NTP at a rate of ‘avg 6/min burst 10’ per-IP, with a 3-min table expire… That (to me) is more than generous for any legitimate user. I do logging every now and then, and I find about 0.4% of the unique IPs have some amount of packets dropped. Though these 0.4% make up a little over 2% of the inbound traffic… Most are obvious runaways making multiple requests per-second around the clock, or some will pound out thousands of requests in a short amount of time then go silent… So maybe reflection attacks or something?

If you do decide to use the hashlimit module, be sure to bump up the settings (I use ‘htable-size 32768’ & ‘htable-max 262144’) to compensate for those crazy bursts in traffic, or just watch your syslog as it will spit out an error if the hashtable is full. Also it goes without saying to add udp 123 to NOTRACK in your raw table.