OPNsense Forum
Archive => 18.1 Legacy Series => Topic started by: Dzioobasek on February 05, 2018, 08:46:07 am
-
I have this issue from early 18 release. I can open admin login panel site but when i provide login data and press login it drops connection. When im checking alerts tab theres nothing blocked. As far as i checked ET open/emerging-policy ruleset is blocking. I have to disable it, because even if its on alert action only its still blocking. Any tips?
-
Find the rule that causes this, report to ET or Joomla for inspection.
18.1.2 will let you know more about drops being made by the rule set to find the offending rule (if you don't already know).
Cheers,
Franco
-
Cool, but why its blocking when its not set to drop action? Anyway if ill know which rule from this ruleset is blocking me it would be great because its last thing i need to set before i connect entore network via opnsense :)
-
If it's not supposed to drop then it may be a TCP reassembly issue with Suricata or some other sanity check not passing.
Cheers,
Franco
-
looks like some much needed changes to suricata.yaml coming in 18.1.2.
I tried to change the eve event log drop type to allow alerts but that caused IDS to crash for me in 18.1.1. Worked in 17.7.12 though.
-
Hi,
Change mentioned was: https://github.com/opnsense/core/commit/897842d
Cheers,
Franco
-
This changed worked ok in 17.7.12, but crashes IDS with 18.1.1. I just tried it again and it crashes IDS. Service won't start. No errors posted in the log either. Weird
-
Hmm, anything noted in /var/log/suricata.log as to why it crashes?
EDIT: Forgot to say it works from here on the latest -devel
-
No errors in the suricata log. Service just does not start.
If I try to restart the service, the suricata log has no entries at all until I remove the -drop
My suricata.yaml has no modifications from default.
-
Ok, for now all I can do is back that change out of 18.1.2.
Cheers,
Franco
-
Let me rephrase. Suricata doesn't crash, just doesn't start which is why there are no log entries.
Are there any other changes to suricata.yaml, or has the suricata version been updated from 4.0.3?
I can try the devel version and see if that makes a difference.
-
Installed the devel version 18.7.a_11
No difference. IDS will not start with the drop added to the log.
I just saw that suricata.yaml is reinstalled every time you reboot and all changes are gone, so that is why I never saw the issue previously with version 17.7.12. The drop type was never really implemented.
So now what I do is make the drop change in suricata.yaml then restart the suricata service which never starts up.
It acts the same with version 17.7.12.
So how do I make a permanent change in Suricata? I'm thinking you need a reboot, but the change goes away.
-
#### UPDATE ####
Don't pull that nice feature just yet. It didn't work for me because of the way I implemented it.
Apparently you cannot just make that drop change to suricata.yaml and restart the service. You have to reboot, then it works. The service never starts up if you just change suricata.yaml and restart the service.
I also had to make these drop changes to suricata.yaml in the templates folder so the change is applied to the working file on the reboot.
Everything works fine now in 17.7.12, 18.1.1, and 18.7.a_11. Tested all three.
-
Huh, I was getting worried that I will not see what's blocked again (as without this fix, not all dropped packets and corresponding rules are logged)... :P
Good to know dcol just needed a reboot :D
-
Oh ok. That's why we have opnsense-patch to provide error free patching. :)
https://github.com/opnsense/core/commit/897842d
translates to:
# opnsense-patch 897842d
Run again to remove. Easy and safe*.
Reverting the revert then. Thanks for the investigation.
Cheers,
Franco
(* for the most part)
-
@Dzioobasek:
Apply the patch (via putty for example), restart your OPNsense just to be sure, then access the Joomla login page.
If blocked, go to your alerts and verify the results.
It has to be there, with the patch, IPS will alert you for all blocked packets (without it, it does for just a few). So if you don't apply it, you might miss the offending rule.
-
@Dzioobasek:
Apply the patch (via putty for example), restart your OPNsense just to be sure, then access the Joomla login page.
If blocked, go to your alerts and verify the results.
Buddy im noob :) I mosty wait for official updates :P Anyway after 18.1.2 I have all rules enabled and updated and its not blocking my joomla admin panel :)
Great work guys.
PS
Does opnsense has any bandwitch controller enabled by default? I have plugged few clients to opnsense and now instead 100mbps i have 40mbps on speedtest.net. When i was only connected client it was running at full speed
-
Let's find the cause by finding the trigger first:
1. Temporarily disable just the IPS -> speedtest at least twice
2. Temporarily disable IDS entirely -> speedtest at least twice
3. Enable them -> speedtest at least twice
Please report back your findings.
P.S. Remember: do not enable "promiscuous mode"
-
God im so lame :P
I forgot i was switching gateways when i was accesing joomla and forgot to switch back to opnsense. Now its at full speed again.
Tho it started blocking panel access again but alert are displayed correctly now and i have found rule which was responsible - ET CURRENT_EVENTS Possible Successful Generic Phish (set)
All working like a charm now, thank you guys!
-
Awesome :)
You're welcome!