Bug #3671
closed
PFSense crashes and reboots on running nmap or nessus scans from inside the network
0%
Description
I've had this problem for a year or two now. Every time we run a nmap or nessus scan against more than 3-4 hosts, PFSense crashes and reboots.
This is 100% repeatable and can be used by someone inside the network as a denial of service attack against the network.
Files
Updated by Chris Buechler almost 11 years ago
- Status changed from New to Rejected
this isn't true in the least. At least several well-known names in vulnerability assessment use pfSense because it handles huge numbers of connections (multi-million in some cases) so well.
It's possible it would happen in some circumstances, like bad hardware, or a combination of hardware that doesn't play nicely with the base FreeBSD version in use. Put it under additional RAM usage, or stress in general, and something breaks.
Start a thread on the forum or mailing list with the info from the crash dump, and people can offer suggestions on the cause. The absolute worst you can do with nmap or Nessus to a properly-functioning system is exhaust the state table, which will just drop new connection attempts until some of the active ones are closed or expired. The same will happen with every stateful firewall in existence.
Updated by Yash Kadakia almost 11 years ago
- File crash-report.txt crash-report.txt added
Chris,
This crash happens like clock-work, irrelevant of the PFSense utilization or any other factors. Start a nmap or nessus scan and within minutes you hear the tone of PFSense restarting.
I have reproduced this bug across multiple installations / versions of PFSense and across 2-3 different hardware combinations.
This crash only takes place when NMap is run with -A or all scripts enabled.
I just ran this right now and it took about 2-3 minutes before the crash happened.
nmap -sS -sV -PN -A -vvv -O 202.xxx.xxx.0/24 -p1-65535 -T5
I've attached the crash logs as well with this post.
Updated by Chris Buechler almost 11 years ago
and, like I said, something specific to what you're doing. You're running 32 bit on something where you should run 64 for additional memory purposes. Though it'd work if you just read the crash report - "kmem_map too small." You're exhausting the amount of kernel memory the system is permitted to have, if you make the state table very large, you have to increase kmem_map in accordance with that. Otherwise you reach a point where the kernel can't obtain any more memory, which forces it to crash.