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

Questions to the functionality of Snort

StefanS_01
Hi all,

I have here ASL last version / patches.

For the information:

it is a question in the detail of servers in the DMZ.
Some servers in the DMZ have a Snort Sensor.

For example.

In the ASL IDS rules following things are not allowed (drop).

ISAPI .ida attempt // WEB-IIS cmd.exe access 

The IDS  logging file of the ASL looks as follows.

2005:02:10-21:51:43 (none) snort[7290]: [1:1243:0] D WEB-IIS ISAPI .ida attempt [Classification: Web Application Attack] [Priority: 1]:  {PROTO006} 24.159.16.146:4825 -> 192.168.100.31:80
2005:02:10-21:51:43 (none) snort[7290]: [119:3:1] (http_inspect) U ENCODING  {PROTO006} 24.159.16.146:4825 -> 192.168.100.31:80
2005:02:10-21:51:43 (none) snort[7290]: [119:13:1] (http_inspect) NON-RFC HTTP DELIMITER  {PROTO006} 24.159.16.146:4825 -> 192.168.100.31:80
2005:02:10-21:51:43 (none) snort[7290]: [119:4:1] (http_inspect) BARE BYTE UNICODE ENCODING  {PROTO006} 24.159.16.146:4825 -> 192.168.100.31:80
2005:02:10-21:51:43 (none) snort[7290]: [119:15:1] (http_inspect) OVERSIZE REQUEST-URI DIRECTORY  {PROTO006} 24.159.16.146:4825 -> 192.168.100.31:80
2005:02:10-21:51:44 (none) snort[7290]: [1:1243:0] D WEB-IIS ISAPI .ida attempt [Classification: Web Application Attack] [Priority: 1]:  {PROTO006} 24.159.16.146:4825 -> 192.168.100.31:80
2005:02:10-21:51:44 (none) snort[7290]: [119:3:1] (http_inspect) U ENCODING  {PROTO006} 24.159.16.146:4825 -> 192.168.100.31:80
2005:02:10-21:51:44 (none) snort[7290]: [119:13:1] (http_inspect) NON-RFC HTTP DELIMITER  {PROTO006} 24.159.16.146:4825 -> 192.168.100.31:80
2005:02:10-21:51:47 (none) snort[7290]: [119:3:1] (http_inspect) U ENCODING  {PROTO006} 24.159.16.146:4825 -> 192.168.100.31:80
2005:02:10-21:51:47 (none) snort[7290]: [119:13:1] (http_inspect) NON-RFC HTTP DELIMITER  {PROTO006} 24.159.16.146:4825 -> 192.168.100.31:80

And the Snort Sensor in the DMZ sees following:

#2025-(4-47325)        [cve][icat][bugtraq][arachNIDS][snort] WEB-IIS ISAPI .ida access        2005-02-10 21:51:28        24.159.16.146:4825        192.168.100.31:80        TCP     
#2026-(4-47324)        [cve][icat][bugtraq][arachNIDS][snort] WEB-IIS ISAPI .ida attempt        2005-02-10 21:51:28        24.159.16.146:4825        192.168.100.31:80        TCP     
#2027-(4-47323)        [snort] (http_inspect) NON-RFC DEFINED CHAR   2005-02-10 21:51:25        24.159.16.146:4825        192.168.100.31:80        TCP     
#2028-(4-47322)        [snort] WEB-IIS cmd.exe access     

My issues to that:

Why does the Snort Sensor see said rules in the DMZ?
Why does IDS from ASL not see this action " WEB-IIS cmd.exe access"     ?

Thx

Stefan


This thread was automatically locked due to age.
  • 0 in reply to StefanS_01
    something is not configured right i think..or there is a massive hole in the IDS.  Let's check the settings to rule out #1.

    what do you have setup in the global settings?  Is local networks blank?  

    Then under rules:
    Which groups do you have turned on..and are those groups on alert or drop?
  • 0 in reply to William Warren
    OK, step by step.

    IDS ASL Settings:

    Local Network,

    DMZ, Internal, ISDN-Network

    Advance Setting

    all http-Servers, dns-Servers etc (most in the DMZ).

    Info:

    the destination Adress from the example is a http-server.

    corresponding rule is acting, otherwise no "drop" would come.

    Stefan
  • 0 in reply to StefanS_01
    [ QUOTE ]
    OK, step by step.

    IDS ASL Settings:

    Local Network,

    DMZ, Internal, ISDN-Network

    Advance Setting

    all http-Servers, dns-Servers etc (most in the DMZ).

    Info:

    the destination Adress from the example is a http-server.

    corresponding rule is acting, otherwise no "drop" would come.

    Stefan 

    [/ QUOTE ]
    Ok in the performance tuning i would empty everything out.  In the local networks empty it out.  
    In the rules groups(which was not specified) I am assuming you have all web groups actiavated and changed to alert(yellow triange with an exclamation point)..you may have to change those to drop.  If they are already on drop then please disregard this statement.
  • 0 in reply to William Warren
    I will test that once.
    But why local network empty?

    There is a tool with that I the rules can test?
    I think there of "Nessus" of the Web // Internet  to our server, you know a URL ?
  • 0 in reply to StefanS_01
    emptying local networks guarentees all traffic goes through the ids..[:)]
  • 0 in reply to StefanS_01
    download this cd.  it is a linux bootable cd of various security and pent testing tools.  One of the many is nessus.  HIt your ASL with this..[:)]

    http://new.remote-exploit.org/index.php/Auditor_mirrors
  • 0 in reply to William Warren
    Hi,

    No matter how I test, permits ASL IDS sporadically violations of rules.


    Example from today:

    IDS System in DMZ

    #24-(4-53702)        nessus[snort] WEB-FRONTPAGE /_vti_bin/ access        2005-02-18 06:24:08        208.11.171.50:4013        192.168.100.51:80 

    ASL IDS:

    2005:02:18-06:23:31 (none) snort[32602]: [1:1288:0] D WEB-FRONTPAGE /_vti_bin/ access [Classification: access to a potentially vulnerable web application] [Priority: 2]:  {PROTO006} 208.11.171.50:4013 -> 192.168.100.51:80


    I lose so slowly the confidence into the ASL IDS.  [:(]


    Hello Astaro support, an idea in addition??

    thx

    Stefan
  • 0 in reply to StefanS_01
    OK the rule "WEB-FRONTPAGE /_vti_bin/ access" just filters http traffic for GET messages which contains /_vti_bin/. So basically that rule prevents users from accessing the directory /_vti_bin/ on an webserver. The GET packet which contains the string  /_vti_bin/ will be simply droped by the intrusion prevention system.

    I made some testings. I put my Laptop behind my ASL 5.103. Then I enabled the rule and switched it to drop. Then I opened my browser and tried to surf to http://www.anything.de/_vti_bin/. The IPS loged and droped the packet and no GET request reached the webserver (I monitored the log of the webserver to be sure). So the IPS works like it should.
    Could you please make the same test?

    Also let's compare the IPS rule. Maybe your rule differs from the rule used in Astaro's IPS:
    reject tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"D WEB-FRONTPAGE /_vti_bin/ access"; flow:to_server,established; uricontent:"/_vti_bin/"; nocase; classtype:web-application-activity; sid:1288[;)]

    Astaro uses IPS (Snort) in Inline Mode. So every packet has to pass through the IPS. So I don't think that packet can be bypassed.
    Does the problem only occure on some packets or on all packets of the same type? Does the problem only occure at the moment of very high load on the system? How many users are behind the ASL? How much traffic is routed through ASL a month?

    cheers
    Xeno
  • 0 in reply to Xeno
    Hi xeno,

    with the more exact analysis the following shows up.
    This problem shows up predominantly if the ASL IDS system is in  the "event buffering" mode.

    In the text file with the E-Mail at the Admin one sends all violations of rules are correctly indicated (Drop), but the Snort system in the DMZ sees the same violations of rules.

    Now too your questions.
    The Snort system in the DMZ uses the same rules as the ASL
    IDS system.
    The system has few load 0,15 to 0,20, I thinks also it sufficiently reserves has, Athlon 2000 and 512MB RAM.

    Stefan