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

Intrusion Prevention System does not work

DF6870
Hello,
I am trying to secure the transit between two layer 3 networks with an astaro device by using the ips engine. To test the ips, I have the network interfaces 192.168.2.1/24 and 10.1.1.244/24 attached to eth0 and eth1 on my astaro in a dedicated test lab. I have a test notebook with windows 2000 sp2 (no security updates installed), ip address 10.1.1.243/24. On the other network I have a Backtrack Pentest Suite running, ip address 192.168.2.3/24. My aim is that the astaro ips blocks exploits originating from the pentest device destined to the win2k machine. Therefore I have created a permit any any firewall rule, disabled nat, activated the ips with all attack patterns and set drop as ips action rule. The network 10.1.1.0/24 is listed as network to be protected.

I know that my plain old win2k machine is affected by the vulnerabilities described in CVE-2003-0352 and CVE-2008-4250. I started some exploits on my pentest suite against the win2k machine. While watching the ips.log on the astaro I receive the following log message:

2012:01:26-11:41:43 asg425 snort[11622]: id="2101" severity="warn" sys="SecureNet" sub="ips" name="Intrusion protection alert" action="drop" reason="SHELLCODE x86 OS agnostic fnstenv geteip dword xor decoder" group="310" srcip="192.168.2.3" dstip="10.1.1.243" proto="6" srcport="37479" dstport="135" sid="17322" class="Executable code was detected" priority="1"  generator="1" msgid="0"

It seems as if the snort engine successfully identified my exploit as expected. Unfortunately neither the single packet containing the exploit nor the complete tcp connection is dropped by my astaro. The exploit works and I can gain admin access on the win2k machine; like not having any ips in between. The same happens if I select to terminate the connection as ips action. Then action=reject is logged instead of action=drop but the exploit works again. I am able to reproduce this behaviour with both vulnerabilities.

Has anybody else already successfully implemented and tested an astaro ips in a similiar situation and can give me some hints what I might have done wrong?


This thread was automatically locked due to age.
Parents
  • 0
    Please do post back with the result of Support's look at you situation.  I wonder - have you have inadvertantly configured IPS to warn only?

    Cheers - Bob
  • 0 in reply to BAlfson
    Can anyone recommend a good snort testing tool? would like to test mine out.
  • 0 in reply to NewImage
    I can confirm that the IPS is configured to drop (and not only warn). I tested "Silently Drop" and "Terminate Connection". On the pattern tab I have all patterns activated and set all actions to "Drop". So far everything should be configured properly because the ips.log shows action=drop, too.

    A simple way to test the IPS engine is to simulate what the snort rules call a "speedera ping attack". You can use a regular unix ping command with parameter "-s 666" to provoke this. This executes a harmless ping with a payload size of 666 bytes. In the default configuration this attack is handled as "warn only" by the IPS engine and you should see it as such in the ips.log. But in the advanced tab you can create a custom modification to set the action of rule 480 (the speedera attack) to drop. After you have applied these changes you have to wait until the IPS engine has completely reloaded (up to 10 minutes). Afterwards a ping -s 666 should be dropped by the astaro. Unfortunetely, this does not work either in my case.
Reply
  • 0 in reply to NewImage
    I can confirm that the IPS is configured to drop (and not only warn). I tested "Silently Drop" and "Terminate Connection". On the pattern tab I have all patterns activated and set all actions to "Drop". So far everything should be configured properly because the ips.log shows action=drop, too.

    A simple way to test the IPS engine is to simulate what the snort rules call a "speedera ping attack". You can use a regular unix ping command with parameter "-s 666" to provoke this. This executes a harmless ping with a payload size of 666 bytes. In the default configuration this attack is handled as "warn only" by the IPS engine and you should see it as such in the ips.log. But in the advanced tab you can create a custom modification to set the action of rule 480 (the speedera attack) to drop. After you have applied these changes you have to wait until the IPS engine has completely reloaded (up to 10 minutes). Afterwards a ping -s 666 should be dropped by the astaro. Unfortunetely, this does not work either in my case.
Children
No Data