Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 21 replies
  • Subscribers 2 subscribers
  • Views 88928 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

Is IPS dead or have all the internet attacks just stopped?

AdrienBelcourt
Gents and Ladies,

I have zero length IPS log files for the first time in 5 years.  It is configured with every single attack and warning pattern switched on and alerting.  That is over 9,500 patterns and NOT one is picking up anything to be worried about either for outgoing traffic or incoming traffic.  

My questions are

1. Is your IPS quiet as a grave too?   
2. Are all your IPS log files in /var/log/ips/2011/04/ all zero lenth when you gunzip them?
3. How do you tell how many patterns are actually loaded in snort, when the gui says 9500 odd?

I am used to many things with Astaro IPS including patterns shutting down my clients' firewalls, but I am not used to zero length log files and feel rather uncomfortable about this. 

So, I tried to get IPS to respond by running half a dozen different scans (including PCI scans) using Nessus, nmap and LanSpy.  Found out some DNS vulnerabilities, but IDS still stoney quiet.  Restarting snort with /var/mdw/scripts/snort restart shows a pile of stuff including about 50 lines of this: "DynamicPlugin: Rule [3:16418] not enabled in configuration, rule will not be used."  but googlepedia suggests this is not a problem.  

Where are you at with this?  

Thanks in advance for your replies.

Best Regards,

Adrien.


This thread was automatically locked due to age.
  • 0
    thanks Barry & Jaznak,

    Jaznak, all those IPS alerts look like they are for traffic originating from LAN.  I wonder if there are any IPS alerts for hacking attempts from the outside world.   

    Barry, when I was running Astaro Versions 4-6 I would expect IPS alerts to build up even when I was not surfing at all due to the attempted exploits from the outside world.  So a zero count for IPS alerts is just does not feel right to me.  

    Again the problem is that we went from 500-1000 IPS alerts per day to Zero following a pattern update.  Best case is that IPS is still doing its job but the alerts are no longer working.  We all know the worst case....  

    What is a guaranteed way to get IPS to generate alerts?  I thought Nessus/Nmap vulnerability scans should be able to do that (from Top 10 Vulnerability Scanners).  

    IPS did not react at all while 9 different vulnerabilities were uncovered by Nessus.  

    I would have thought that IPS should be able to detect network surveillance using a tool like Nessus at least.  

    Try it on your own system - or send me your external IP, and I will send you a report of your vulnerabilities.   

    Will keep you posted.

    Adrien.
  • 0
    i ran nessus against my server with default 5593 of 9984 patterns
    first run with portscan detection on - no ips
    second run without portscan detection:
    -DOS Microsoft Exchange System Attendant denial of service attempt
    -WEB-MISC Microsoft ASP.NET information disclosure attempt
    -SPYWARE-PUT Hacker-Tool timbuktu pro runtime detection - udp port 407
  • 0 in reply to jaznak
    Thanks Jaznak,

    Which scan did you run and against which port? 

    I ran Nessus' "External Network Scan" against the Int on my firewall with 9984 of 9984 patterns enabled + "Add extra warnings" all ticked.  Switched off portscan and all flood detections.  

    Run Results - two different warnings: 
    - reason="DNS named version attempt" group="241" 
    - reason="ICMP PING speedera" group="410" (x140 - I was running ping tests)

    Nessus Results 62 reports, 6 medium severity, 10 open ports.  The medium reports (low severity are zero risk mostly):
    - Synopsis: The remote DNS server is vulnerable to cache snooping attacks.
    - Synopsis: The SSL certificate for this service is signed by an unknown certificate authority.  (x 3)
    - Synopsis: The remote host allows resuming SSL sessions. (x2)

    Nessus wins.  Network surveillance successful and IPS prevents nothing and detects two things.  These are real vulnerabilities.  

    Best Regards,
  • 0
    i did custom scan from int to dmz host.

    did it again with "external network scan", no flood/portscan check
    -WEB-MISC Microsoft ASP.NET information disclosure attempt
    -WEB-PHP horde help module arbitrary command execution attempt
    -DOS Microsoft Exchange System Attendant denial of service attempt
    -WEB-MISC carbo.dll access
    -SPYWARE-PUT Hacker-Tool timbuktu pro runtime detection - udp port 407
  • 0 in reply to AdrienBelcourt
    Thanks Jaznak,

    Which scan did you run and against which port? 

    I ran Nessus' "External Network Scan" against the Int on my firewall with 9984 of 9984 patterns enabled + "Add extra warnings" all ticked.  Switched off portscan and all flood detections.  

    Run Results - two different warnings: 
    - reason="DNS named version attempt" group="241" 
    - reason="ICMP PING speedera" group="410" (x140 - I was running ping tests)

    Nessus Results 62 reports, 6 medium severity, 10 open ports.  The medium reports (low severity are zero risk mostly):
    - Synopsis: The remote DNS server is vulnerable to cache snooping attacks.
    - Synopsis: The SSL certificate for this service is signed by an unknown certificate authority.  (x 3)
    - Synopsis: The remote host allows resuming SSL sessions. (x2)

    Nessus wins.  Network surveillance successful and IPS prevents nothing and detects two things.  These are real vulnerabilities.  

    Best Regards,



    Hi, you need to run nessus against a PUBLIC SERVER BEHIND THE FIREWALL, not the firewall itself.

    Astaro has too few services open for a meaningful scan.

    e.g., DNAT and open port 80 to an internal server.

    Barry
  • 0
    Barry,  

    Thanks again for your attention to this.  No need to shout, my friend.  I had already tried your SUGGESTION among many others, although that may not have been clear in my prior posts.  Anyways... good news........have a reproducable test.  So now on fast track to resolving problem through Astaro.  

    Bottom line, have confirmed IPS problem with a third system – mine.  Here’s the IPS alert stats:

    Jan=  551 
    Feb= 160 
    Mar=   22
    Apr=     4   

    Key event was pattern update on Feb 17th.

    Method I used
    1. cd  /var/log/ips/201?/??                                                                                     # Change to each month’s log folder
    2. gunzip *.gz                                                                                                                # to unzip each log file
    3. cat *.log | grep -v flood | grep -v portscan | grep reason –c                # counts the number of IPS alerts
    4. cat *.log | grep -v flood | grep -v portscan | grep -v reason | more  # shows the update/reboot logs
    5. cat *.log | grep -v flood | grep -v portscan | grep reason | more       # shows the IPS alerts

    Would be curious if you have a similar drop off.

    Best Regards,
  • 0
    Hi, you don't need to gunzip the logs; you can use zcat or zgrep, e.g.
    zgrep -v flood *.log.gz | grep -v portscan | grep -c reason

    my numbers @ home (7.509 currently):
    aug 9081
    sep 6447
    oct 981
    nov 868
    dec offline
    jan 8
    feb 18
    mar 43
    apr 35

    Looking at August and Sept, there are LOTS of alerts on RPC traffic from my PC ("Multiple RPC Records" and "Incomplete RPC segment"). Perhaps Astaro has disabled those alerts, or I made some changes to the attack patterns. Either way they don't look important.

    our 7.509 firewall @ work (filtering out the LAND attack false positives due to a misconfiguration):
    dec 17783
    jan 16936
    feb 10454
    mar 9597
    apr 4621

    our 8.102 firewall @ work, which has only been online 1 month (since 3/15):
    Mar 1376
    Apr 1490

    Barry
  • 0
    We are waiting for confirmation from Astaro that they have removed the IPS rules that were generating the bulk of the IPS alerts.  It seem there has been an exercise to remove rules generating a large amount of false positives.  

    When IPS quiet day after day, is it delivering security value?  I trust that it does, but trust without verification is an unwise security stance.  How do I verify?

    All the best,

    Adrien.
  • 0
    I have been in a similar situation here; even talking with Astaro support.

    February 20, 2011 was the last day I had IPS register any hits.  I still get portscan and other minor things but there has been nothing major for over 2 months.  Which I find incredibly odd because as i'm sure everyone here can agree there is at least some random script-kiddie poke in a given timeframe.

    I'm currently looking for some application or service (ideally free) that I can just launch an attack that an ASG is known to block and see if it detects and logs the dang thing.   Any suggestions?

    Unfortunately I followed my own advice and "upgraded to the latest version" to see if it fixed the issue and don't have any logs from the timeframe.  I was using v7 and upgraded to v8.

    Thanks

    *edit* Hmmm adrienjb I think you might be the other occurrence they mentioned to me on the phone.  Well mention consisting of "A client in the UK"

    *edit* HA! found my old thread from March 18, 2011, no useful info though compared to this thread.
  • 0 in reply to Tribmos
    Well hopefully you are having better luck with support.... My contact just keeps going back to "when you blackhole an IP you will no longer get traffic from them"...
    Which was part of my standard procedure for an IPS hit, though I would not expect the ~40 ip addresses to be the entire source of attacks for the whole internet.

    I understand that whatever is causing this is something obscure and will be difficult to find, but I am finding their process frustrating... or at least whomever is currently helping my case.