18.1.1 IPS still blocking access to joomla admin panel (SOLVED)

Started by Dzioobasek, February 05, 2018, 08:46:07 AM

Previous topic - Next topic
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.


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
OPNsense v18 | HW: Gigabyte Z370N-WIFI, i3-8100, 8GB RAM, 60GB SSD, | Controllers: 82575GB-quad, 82574, I221, I219-V | PPPoE: RDS Romania | Down: 980Mbit/s | Up: 500Mbit/s

Team Rebellion Member

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)