Snort Alerts-tab bug?
-
When I try to open the tab Alerts, I get a message from the browser that sayt something like "Unable to load page" or something to that effect. I'm not sure about the exact english translation. This have happened to me on both my pfsense installation with Snort.
This happens when I on the Alerts tab change the number of alerts to view to 1000 and then directly press Enter. Then I get the download alerts dialog asking me to select where to save it, and I cancel that without downloading.
After this I can no longer access the Alerts tab. I have tried uninstalling and reinstalling the package with the "Remove Blocked Hosts After Deinstall" checked, and "Remove Snort Log Files After Deinstall" checked, and "Keep Snort Settings After Deinstall" not checked.
Have this happened to someone else? Anyone who knows how to solve this?
-
pfSense has changed some of the PHP code to make it more secure.
Changes related to $get vs $post php commands. I think this might get cleaned up in pfSense 2.2?
http://www.programmerinterview.com/index.php/general-miscellaneous/html-get-vs-post/
-
What browser are you using? Some browsers are more picky about CSRF than others. pfSense and many of the available packages have been undergoing some security review relative to cross-site request forgery. As part of this review, many pages are being updated to use $_POST postback calls instead of using the older $_GET requests with query strings in the URL. I use Internet Explorer 11 and have not seen too many problems (although now and then if you hit BACK in the browser you can lose the session cookie and get an error). Some folks have reported Chrome to be a bit less forgiving than IE and Firefox.
Also, make sure you clear your browser cache or use whatever magic key sequence your browser uses to force a fresh download of the PHP page. I have seen problems in the past with page caching causing this to happen where you get the error page once, and then that error page is cached by the browser and served up repeatedly.
Bill
-
I have been using mostly Firefox 30.0, but also Internet Explorer 11 and Chrome. This does not seem to be a client thing. Atleast when the error have happened and the page with Snort / Alerts results in no page. I'll try setting up a pfSense installation in VMware to figure out exactly what causes this.
-
@DBa:
I have been using mostly Firefox 30.0, but also Internet Explorer 11 and Chrome. This does not seem to be a client thing. Atleast when the error have happened and the page with Snort / Alerts results in no page. I'll try setting up a pfSense installation in VMware to figure out exactly what causes this.
Please let me know what you discover. I have not experienced this behavior in any of my prior use or testing. Are you in the United States and/or using English language settings?
Bill
-
@DBa:
I have been using mostly Firefox 30.0, but also Internet Explorer 11 and Chrome. This does not seem to be a client thing. Atleast when the error have happened and the page with Snort / Alerts results in no page. I'll try setting up a pfSense installation in VMware to figure out exactly what causes this.
Please let me know what you discover. I have not experienced this behavior in any of my prior use or testing. Are you in the United States and/or using English language settings?
Bill
Hi Bill these are my observations for the CSRF Browser Issue:
From Alerts Tab, click on WAN Interface Button
Select a "!" to Resolve an IP
Select whois lookup
close whois window
Click back
(Confirm Form Resubmission (ERR_CACHE_MISS) error pops up - Need to hit back 2-3 times to get it to open GUI)
Once this occurs once, it doesn't do this for the WAN interface again.
From the Alerts Tab, click on LAN Interface Button
Same results as above.
Flipping back and forth from Wan/Lan in the Alerts Tab will repeat the same issues
I use Chrome but in IE11 its not as frequent but still can get Webpage has expired.
-
@DBa:
I have been using mostly Firefox 30.0, but also Internet Explorer 11 and Chrome. This does not seem to be a client thing. Atleast when the error have happened and the page with Snort / Alerts results in no page. I'll try setting up a pfSense installation in VMware to figure out exactly what causes this.
Please let me know what you discover. I have not experienced this behavior in any of my prior use or testing. Are you in the United States and/or using English language settings?
Bill
Hi Bill these are my observations for the CSRF Browser Issue:
From Alerts Tab, click on WAN Interface Button
Select a "!" to Resolve an IP
Select whois lookup
close whois window
Click back
(Confirm Form Resubmission (ERR_CACHE_MISS) error pops up - Need to hit back 2-3 times to get it to open GUI)
Once this occurs once, it doesn't do this for the WAN interface again.
From the Alerts Tab, click on LAN Interface Button
Same results as above.
Flipping back and forth from Wan/Lan in the Alerts Tab will repeat the same issues
I use Chrome but in IE11 its not as frequent but still can get Webpage has expired.
Unfortunately there is not much to do about this. For security reasons the push is to use $_POST requests instead of URL query strings and $_GET requests. Each $_POST request is assigned an unique session ID as part of the CSRF protection scheme. That's why on 2.1 and higher there are two icons for DNS lookups. The pale one simply opens a pop-up dialog window to display data. That window does not allow any interaction save closing it. The other icon opens a completely new PHP page and thus the previous session ID is lost. So when you try to use the BACK button in the browser to return to the previous page, it bombs due to the mismatched session ID.
Instead of using the BACK button in the browser, just start back over and click Services…Snort to re-enter the Snort menu tabs. This will open the ALERTS tab PHP page in a completely new session and it won't try to use the cached one in history like the BACK button does. I know that is a few extra mouse clicks, but this is one pitfall of a completely browser-based GUI when you also need high security.
Bill
-
Thanks Bill, you would think that when you close the Whois page, the pfsense diag_dns.php page is still loaded in its own window. Why would it loose the session id for that? It shouldn't have anything to do with the other tab that was called by diag_dns.php?
Also why does it only happen once on the Alert Interface section. If that was the case, you would expect the behavior to repeat for each lookup?
Security is always a good thing!! :)
