Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 11 replies
  • Subscribers 2 subscribers
  • Views 2737 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

7.501 IPS False Positive Gotcha

James Bourne
Hello all,

We have an OpenFire XMPP chat server in our DMZ. It had been running fine for months. Upgraded to 7.501 yesterday (ASG425a cluster).

After the upgrade, queries from the OpenFire / LDAP to our AD server running on the trusted network were taking minutes to return.

The cause was inexplicable. You could SSH, you could do a command line LDAP bind and query, MySQL continued to work etc. etc. We packet traced with Wireshark and saw all sorts of connection resets.

Thankfully someone else has posted on the forums about 7.501 IDS oddities. A quick look in the IDS logs yielded:

WEB-MISC Microsoft Active Directory LDAP query DoS attempt

This is clearly incorrect so I disabled rule 16202 and everything is back to normal.

What I don't understand is:

1. Why the upgrade would start triggering these events? New patterns?
2. When I had all notifications all turned on no emails were emitted?

Anyway it's solved now so I hope this is of use for someone else trying to debug upgrade oddities.


This thread was automatically locked due to age.
Parents
  • 0
    When I hear people complain that IPS pegs their CPU, I remember a mistake I made several years ago; for some reason, at one client, I put "External (Network)" along with "Internal (Network)" in 'Local networks'.  When they got a little busy, the thing would lock up, and the reports later showed petabits of traffic - not bad for a 100mb interface connected to a T1!  Once that error was corrected, the 120 almost thought it was sleeping.

    Cheers - Bob
  • 0 in reply to BAlfson
    sure Bob, the IPS is configured to monitor only "Internal Network"....
  • 0 in reply to mdallagi
    ...just a little question: is astaro v7.5x using barnyard?
  • 0 in reply to mdallagi
    ...just a little question: is astaro v7.5x using barnyard?


    ps aux|grep barn

    Hi, I don't see it running on 7.501, but I have seen it in Astaro before.

    Barry
  • 0 in reply to BarryG
    ps aux|grep barn

    Hi, I don't see it running on 7.501, but I have seen it in Astaro before.

    Barry


    infact this is the reason of my question.
    On a v7.405 I can see:

    root      9525  0.0  0.3   7808  6668 ?        S    Nov10   0:00 /sbin/barnyard -D -c /etc/snort/barnyard.conf -d /var/log/snort/ -p /etc/snort/rules/classification.config -s /etc/snort/rules/sid-msg.map -g /etc/snort/rules/gen-msg.map -f snort.alert

    but barnyard is missing on a v7.501....

    However, on my ASG v7.501, I found strange logs on ips.log such as:

    ....
    2009:11:10-16:26:22 ASG7 snort[6638]: FATAL ERROR: Unterminated rule in file /etc/snort/rules/astaro.rules, line 5149    (Snort rules must be contained on a single line or     on multiple lines with a '\' continuation character     at the end of the line,  make sure there are no     carriage returns before the end of this line)
    2009:11:10-16:26:22 ASG7 snort_inline: Reading from iptables
    2009:11:10-16:26:23 ASG7 snort[6656]: Parsing Rules file /etc/snort/snort.conf
    ....

    or:
    ....
    2009:11:10-17:13:30 ASG7 snort[16659]: 394 out of 512 flowbits in use.
    2009:11:10-17:13:31 ASG7 snort[16659]: Warning: OpenPcap() device eth0 success with warning:         arptype 65534 not supported by libpcap - falling back to cooked socket
    2009:11:10-17:13:31 ASG7 snort[16659]: Initializing daemon mode
    2009:11:10-17:13:31 ASG7 snort[16672]: PID path stat checked out ok, PID path set to /var/run/
    2009:11:10-17:13:31 ASG7 snort[16672]: Writing PID "16672" to file "/var/run//snort_eth0_2.pid"
    2009:11:10-17:13:31 ASG7 snort[16659]: Daemon parent exiting
    2009:11:10-17:13:31 ASG7 snort[16672]: Daemon initialized, signaled parent pid: 16659
    2009:11:10-17:13:31 ASG7 snort_inline: Reading from iptables
    2009:11:10-17:13:32 ASG7 snort[16673]: Parsing Rules file /etc/snort/snort.conf
    ....

    and this logs appears very often and during this events the CPUs go at 100% breaking the traffic to and from the published internal servers and I loose even the connection to the web dashboard of this ASG !

    The IPS setting for this ASG is:

    - Local networks = Internal network
    - Attack Patterns = No extra warning and unuseful rules not selected
    - Anti-DoS/Flooding = not used
    - Anti-portscan = enabled with drop traffic and limit logging
    - Exception = Created some exception for well know hosts
    - Advanced = two modified rules and specified the HTTP, DNS, SMTP and SQL servers on Performance tuning
Reply
  • 0 in reply to BarryG
    ps aux|grep barn

    Hi, I don't see it running on 7.501, but I have seen it in Astaro before.

    Barry


    infact this is the reason of my question.
    On a v7.405 I can see:

    root      9525  0.0  0.3   7808  6668 ?        S    Nov10   0:00 /sbin/barnyard -D -c /etc/snort/barnyard.conf -d /var/log/snort/ -p /etc/snort/rules/classification.config -s /etc/snort/rules/sid-msg.map -g /etc/snort/rules/gen-msg.map -f snort.alert

    but barnyard is missing on a v7.501....

    However, on my ASG v7.501, I found strange logs on ips.log such as:

    ....
    2009:11:10-16:26:22 ASG7 snort[6638]: FATAL ERROR: Unterminated rule in file /etc/snort/rules/astaro.rules, line 5149    (Snort rules must be contained on a single line or     on multiple lines with a '\' continuation character     at the end of the line,  make sure there are no     carriage returns before the end of this line)
    2009:11:10-16:26:22 ASG7 snort_inline: Reading from iptables
    2009:11:10-16:26:23 ASG7 snort[6656]: Parsing Rules file /etc/snort/snort.conf
    ....

    or:
    ....
    2009:11:10-17:13:30 ASG7 snort[16659]: 394 out of 512 flowbits in use.
    2009:11:10-17:13:31 ASG7 snort[16659]: Warning: OpenPcap() device eth0 success with warning:         arptype 65534 not supported by libpcap - falling back to cooked socket
    2009:11:10-17:13:31 ASG7 snort[16659]: Initializing daemon mode
    2009:11:10-17:13:31 ASG7 snort[16672]: PID path stat checked out ok, PID path set to /var/run/
    2009:11:10-17:13:31 ASG7 snort[16672]: Writing PID "16672" to file "/var/run//snort_eth0_2.pid"
    2009:11:10-17:13:31 ASG7 snort[16659]: Daemon parent exiting
    2009:11:10-17:13:31 ASG7 snort[16672]: Daemon initialized, signaled parent pid: 16659
    2009:11:10-17:13:31 ASG7 snort_inline: Reading from iptables
    2009:11:10-17:13:32 ASG7 snort[16673]: Parsing Rules file /etc/snort/snort.conf
    ....

    and this logs appears very often and during this events the CPUs go at 100% breaking the traffic to and from the published internal servers and I loose even the connection to the web dashboard of this ASG !

    The IPS setting for this ASG is:

    - Local networks = Internal network
    - Attack Patterns = No extra warning and unuseful rules not selected
    - Anti-DoS/Flooding = not used
    - Anti-portscan = enabled with drop traffic and limit logging
    - Exception = Created some exception for well know hosts
    - Advanced = two modified rules and specified the HTTP, DNS, SMTP and SQL servers on Performance tuning
Children
No Data