TCP/UDP "crashing" when Nessus-Scan is running
Hello from munich,
has anybody an idea of what could cause the following behaviour:
When doing a Nessus-Scan from VLAN A to VLAN B after some time (Whether existing or non-existent IP addresses are scanned, regardless of the throttling applied) the whole TCP/UDP communication in ALL VLANs (also those not affected by the scan) go down. BUT: as soon as the scan is stopped it all comes back and is fine again AND the whole time , even when TCP/UPD is "down" as described, pinging (ICMP) is OK.
Has anybody an idea on what that could be ? It must be the Watchguard, as only it has all routes to all networks.
Many thanks and kind regards,
Markus
0
Sign In to comment.
Comments
For the record, what firewall model do you have and what Fireware version is it running?
Anything helpful in Traffic Monitor when the scan starts up?
Its a clustered M590 with v12.12.B733447
No, all you can see are the Packets allowed or denied . No System-errors or similar ...
what puzzles me is that: it looks as if theres a buffer running full or so. But instead of dropping all packets from the causing IP (the "attacker") the WG keeps on trying to deliver it all whilst failing with it and dragging everything with it into the abyss.
Search your logs for ddos messages. It could be the default threat protection triggering the drop if the scan is exceeding the client or server limits.
@mboscolo : yes there are many ddos messages. But, in my understanding, the WG should drop/block the "attacking" IP, not shut down tcp-Traffic accidentally.
Default Packet Handling is configured to drop packets once a threshold is exceeded. Two of the options will block, port scan, and IP Scan. All other events will drop packets from the source and will not process any new connections until the rate drops below the threshold. The Auto Block source IP of unhandled will block the External packets. But most admins find that option too disruptive because it can block the IP of legitimate users in certain cases.
@mboscolo : Thanks for that. But that also does not explain, why while the scan was running, TCP-Traffic in ALL VLANs (even those not beeing involved in the scan (neither source not target) was completely disrupted.
As i understand it: the Firebox should only drop/isolate/block the traffic from source to target. nothing else .. but thats exactly what NOT happened.