My modified pfsense 2.2.3 crash while testing with HP Webinspect
-
I installed pfsense 2.2.3 with ospf+freeradius+openvpn modules on vmware 12.1.0 and windows 8.1.
I tried to test web vulnerability via: HP Webinspect Dynamic Application Security Testing (DAST) v10.50.327.10 tool…While on testing process, unfortunately pfsense crashed :(
I attached a photo from vmware screen..
Can anybody help me to find & resolve this problem please? It seem the pfsense is no reliable!
-
That's too far down in the bt to even guess. If you reboot it and log into the web interface, you should be prompted to submit a crash report. Do that, and let me know what IP it came from.
You should upgrade to 2.2.6, some of the components in 2.2.3 have known vulnerabilities that were fixed in the 3 releases since then. Though none of them would result in a kernel panic. I'm guessing it's most likely you have a small amount of RAM and a large state table size and ended up exhausting kernel memory or something along those lines by opening a large number of connections, not triggered any actual security issue.
-
@cmb:
That's too far down in the bt to even guess. If you reboot it and log into the web interface, you should be prompted to submit a crash report. Do that, and let me know what IP it came from.
Thank you for your reply, but I did changed some functionality in gui, it did not asked about send crash report. So can you help me to find crash log file manually,where is it?
@cmb:
Though none of them would result in a kernel panic. I'm guessing it's most likely you have a small amount of RAM and a large state table size and ended up exhausting kernel memory or something along those lines by opening a large number of connections, not triggered any actual security issue.
It's good news about it's not triggered any actual security issue, but it does nerves me about large number of connections because I choose pfsense for large number of connections scale support!
-
Unfortunately after crash system does not boot :(
What can I do now to rollback to last state?
How to prevent this happens?
-
@cmb:
That's too far down in the bt to even guess. If you reboot it and log into the web interface, you should be prompted to submit a crash report. Do that, and let me know what IP it came from.
Thank you for your reply, but I did changed some functionality in gui, it did not asked about send crash report. So can you help me to find crash log file manually,where is it?
cmb is one of the pfSense developers. If you're making changes in the GUI, and various other PHP code that manages everything for pfSense, then there's always a chance that you're going to break things. If you'd like to detail what kinds of changes you made, then maybe someone who is more developer-inclined can help… but when you change the core code that runs things, there's a good chance that no one can help you without seeing exactly what you changed.
From your error screenshot after rebooting, it looks like an incorrect variable type is being used where it shouldn't be. You might want to look at line 524 in /etc/inc/config.lib.inc and see if you might have changed something somewhere that would affect whatever variable is being used in that line. But that's about as much help as I'm going to be on an issue like that, as I'm far from a developer. To get it back to being functional, you'll likely need to boot into single user mode from the console and revert whatever change(s) you made back to the original code, or fix your changes so that they work properly.
-
It's good news about it's not triggered any actual security issue, but it does nerves me about large number of connections because I choose pfsense for large number of connections scale support!
I have no idea if that's actually the case, it was just a wild guess. If you only had, say, 256 MB RAM, but configured a large state table size that could consume more than 256 MB RAM, and hence you caused the system to run out of kernel memory, it can't do anything but crash. The defaults when unmodified prevent such things from occurring.
I didn't realize you were using a modified system. You've broken something in your changes judging by those PHP errors, as virgiliomi noted. If you're not being prompted for a crash report, you've broken something in that in your changes too. The files would be under /var/crash/.
If you can replicate the crash on an unmodified pfSense 2.3, then I'm interested in more specifics. As is, this thread is about your modified product and seems to have no relation to stock releases.
-
@cmb:
If you only had, say, 256 MB RAM, but configured a large state table size that could consume more than 256 MB RAM, and hence you caused the system to run out of kernel memory, it can't do anything but crash.
In previous testing state amount of ram was 2048MB and in current testing state amount of ram is 3072MB and for while without crash ;) , but thank you for your suggestion.
@cmb:
If you're not being prompted for a crash report, you've broken something in that in your changes too. The files would be under /var/crash/.
I did backup the .vmdk file from crashed state and the /var/crash/ folder is contain one file only named: minfree! why crash file did not created? I can't remember did any changes or recompile binary related to collect or write crash file, can you help me to find an scope to look for broken "collect or write crash file" relate please?
@cmb:
If you can replicate the crash on an unmodified pfSense 2.3, then I'm interested in more specifics. As is, this thread is about your modified product and seems to have no relation to stock releases.
I'm very interested too but it's better to find the problem in mine.
Thank you again!