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

IPS Detect L3retriever Ping

skydiver
I started receiving this IPS alert this weekend: 
Message........: ICMP L3retriever Ping

Details........: www.snort.org/.../466

Time...........: 2010:06:02-11:35:54

Packet dropped.: yes

Priority.......: 2 (medium)

Classification.: Attempted Information Leak IP protocol....: 1 (ICMP)



Source IP address: 10.98.12.x

- www.dnsstuff.com/.../ptr.ch

- www.ripe.net/.../whois

- ws.arin.net/.../whois.pl

- cgi.apnic.net/.../whois.pl

Source port: 0

Destination IP address: 10.19.12.200

- www.dnsstuff.com/.../ptr.ch

- www.ripe.net/.../whois

- ws.arin.net/.../whois.pl

- cgi.apnic.net/.../whois.pl

Destination port: 0


The alert is being generated with the source in one LAN network segment and the destination on another LAN network segment.  These are being generated when the first Windows XP box accesses a shared network folder on the computer at the second network segment.

Any ideas as to why this may be occurring?  The shared folder has been in place for a while and this just started happening in the past week.    I need to understand exactly what is causing this because this is a PCI environment and the target of the scan is a PCI device.


This thread was automatically locked due to age.
  • 0
    I am getting exactly the same.
    Anyone ?
  • 0
    Only for me it was our SSL VPN users as the source.  It started right after an pattern update?(Eastern Time)  Right after this appeared in the log I got hammered with alerts and it hasn't stopped.  Most of the vpn users, if not all are, not using XP.

    2010:05:31-10:32:54 fw snort[23721]: 
    2010:05:31-10:32:54 fw snort[23721]: +-----------------------[thresholding-config]----------------------------------
    2010:05:31-10:32:54 fw snort[23721]: | memory-cap : 1048576 bytes
    2010:05:31-10:32:54 fw snort[23721]: +-----------------------[thresholding-global]----------------------------------
    2010:05:31-10:32:54 fw snort[23721]: | none
    2010:05:31-10:32:54 fw snort[23721]: +-----------------------[thresholding-local]-----------------------------------
    2010:05:31-10:32:54 fw snort[23721]: | none
    2010:05:31-10:32:54 fw snort[23721]: +-----------------------[suppression]------------------------------------------
    2010:05:31-10:32:54 fw snort[23721]: | none
    2010:05:31-10:32:54 fw snort[23721]: -------------------------------------------------------------------------------
    2010:05:31-10:32:54 fw snort[23721]: Rule application order: activation->dynamic->pass->drop->sdrop->reject->alert->log
    2010:05:31-10:32:54 fw snort[23721]: Log directory = /var/log/snort
    2010:05:31-10:32:54 fw snort[23721]: Warning: 'ignore_any_rules' option for Stream5 UDP disabled because of UDP rule with flow or flowbits option
    2010:05:31-10:32:54 fw snort[23721]: 377 out of 512 flowbits in use.
    2010:05:31-10:32:54 fw snort[23721]: Warning: OpenPcap() device eth0 success with warning:         arptype 65534 not supported by libpcap - falling back to cooked socket
    2010:05:31-10:32:54 fw snort[23721]: Initializing daemon mode
    2010:05:31-10:32:54 fw snort[23847]: PID path stat checked out ok, PID path set to /var/run/
    2010:05:31-10:32:54 fw snort[23847]: Writing PID "23847" to file "/var/run//snort_eth0_1.pid"
    2010:05:31-10:32:54 fw snort[23721]: Daemon parent exiting
    2010:05:31-10:32:54 fw snort[23847]: Daemon initialized, signaled parent pid: 23721
    2010:05:31-10:33:42 fw snort[23847]: 
    2010:05:31-10:33:42 fw snort[23847]: [ Port Based Pattern Matching Memory ]
    2010:05:31-10:33:42 fw snort[23847]: +-[AC-BNFA Search Info Summary]------------------------------
    2010:05:31-10:33:42 fw snort[23847]: | Instances        : 913
    2010:05:31-10:33:42 fw snort[23847]: | Patterns         : 307903
    2010:05:31-10:33:42 fw snort[23847]: | Pattern Chars    : 6087878
    2010:05:31-10:33:42 fw snort[23847]: | Num States       : 3253568
    2010:05:31-10:33:42 fw snort[23847]: | Num Match States : 321716
    2010:05:31-10:33:42 fw snort[23847]: | Memory           :   69.99Mbytes
    2010:05:31-10:33:42 fw snort[23847]: |   Patterns       :   12.85M
    2010:05:31-10:33:42 fw snort[23847]: |   Match Lists    :   18.96M
    2010:05:31-10:33:42 fw snort[23847]: |   Transitions    :   37.97M
    2010:05:31-10:33:42 fw snort[23847]: +-------------------------------------------------
    2010:05:31-10:33:42 fw snort[23847]: Snort initialization completed successfully (pid=23847)
    2010:05:31-10:33:42 fw snort[23847]: Not Using PCAP_FRAMES


    What is the recommended action?
  • 0
    I'm getting the same messages when someone logs on to a DC across LAN segments. The alerts are from the DC at 10.9.x.x to the PC at 10.9.y.y
  • 0
    I am also now getting lots of these IPS alerts, They started on Monday 5/31 and according to my logs we also got a new Pattern Up2Date 12520 earlier that same day. I'm getting them for both Lan to Lan and Lan to SSL VPN connections although the VPN connections seem to cause a lot more IPS Alerts.

    -Obe
  • 0
    Do you have both network segments listed in 'Local networks' in IPS?

    If so, then you'll need to decide if you want to disable the rule or create an exception for the DC as a source.

    Cheers - Bob
  • 0 in reply to BAlfson
    I have this, too.

    And i think it is the reason why a permanent SSL-VPN does not work very well.

    The bad traffic comes not through this VPN but it stops working every morning!

    Some packet filter rules created for this IPS-event?

    Frank
  • 0
    I am also getting this reported although my case seems a little more elevated ...

    I am still receiving notifications from my firewall thru email.
    June 1st was the last time I was able to login via webadmin (have not tried SSH as am not familiar)
    My connection via ACC was cut last night at 10:12pm (no webadmin access was avail thru ACC since June 1st, either)
    I have reported attacks on my weekly report :
    1  466  ICMP L3retriever Ping  Protocol Anomaly / ICMP  12 123  86.49%
    2  15306  1 853  13.22%
    3  13974  WEB-CLIENT Internet Explorer XHTML element memory corruption attempt  Client / Browser  25  0.18%
    4  15362  WEB-CLIENT obfuscated javascript excessive fromCharCode - potential attack  Client / Browser  9  0.06%
    5  8443  WEB-CLIENT Mozilla regular expression heap corruption attempt  Client / Browser  3  0.02%
    6  13320  WEB-CLIENT 3ivx MP4 file parsing cpy buffer overflow attempt  Client / Browser  1  0.01%
    7  3634  WEB-CLIENT Bitmap width integer overflow multipacket attempt  Client / Browser  1  0.01%
    8  15517  WEB-CLIENT AVI DirectShow quicktime parsing overflow attempt  Client / Browser  1  0.01%

    Any help would be appreciated..
  • 0
    I was getting the same messages and it was blocking normal traffic. I disabled 466 in IPS advanced.
  • 0 in reply to BSavage
    Well known false positive (well, to me anyway)... most of my customers' sites have had to have this rule disabled.  check the source PCs to make sure there's nothing running on them that would do such scans; if you don't find anything, it's a false positive.
  • 0 in reply to BrucekConvergent
    Brucek can you think of an environment where disabling this rule could lead to an exploit?  What target service is this detection designed to try to take advantage of that we would need to be wary of (ie. SQL, Windows sharing, etc.)?  The Snort explanations don't really help much in this regard.

    FYI, this is where the ability to manage the IPS engine exclusions via Astaro Command Center would be most helpful for those of us running with multiple ASG's.  Anyone agreeing with this please vote for this issue on the Astaro New Idea page:
    [URL="http://feature.astaro.com/forums/17359-astaro-gateway-feature-requests/suggestions/832659-astaro-command-center-ips-ruleset-management?ref=title"]feature.astaro.com/.../suggestions
    /832659-astaro-command-center-ips-ruleset-management?ref=title[/URL]