[Oisf-users] IPv6 & Extension header
Michel SABORDE
michel.saborde at gmail.com
Thu Mar 29 14:27:40 UTC 2012
Results are the same with -r.
Le 29 mars 2012 15:09, Peter Manev <petermanev at gmail.com> a écrit :
> Hi Michel,
>
> If you read the pacaps (-r option, read pcap) from your tests - would the
> results be the same?
> If you would like, you could share privatelly the pcaps with the yaml conf?
>
> Thanks
>
> On Thu, Mar 29, 2012 at 2:05 PM, Michel SABORDE <michel.saborde at gmail.com>wrote:
>
>> Thanks for your anwswer.
>>
>> I already looked into everything you mentioned.
>>
>> I'm doing the three-way handshake and i added the correct ip6tables rule
>> to prevent the kernel from sending the RST.
>>
>> I also looked into checksums and disabled the checksum_validation from
>> suricata config file, i also checked with wireshark, all the checksums are
>> correct.
>>
>>
>>
>> It must be something else.
>>
>> Le 29 mars 2012 13:39, Peter Manev <petermanev at gmail.com> a écrit :
>>
>>> also you could try/check - with scapy make sure your checksm-ing is
>>> correct.... and it is disabled in the yaml conf
>>>
>>>
>>> On Thu, Mar 29, 2012 at 1:24 PM, Peter Manev <petermanev at gmail.com>wrote:
>>>
>>>> Hi,
>>>>
>>>> When you are using the Scapy script - are you doing the three-way
>>>> handshake with scapy?
>>>>
>>>> Because if so - there is a rule that you have to add to your iptables ,
>>>> since scapy would send S , the server would return the SA and the kernel/OS
>>>> would send back a Reject since it never send a S (it is not aware that
>>>> scapy send it).
>>>>
>>>> The way around this is to put a iptables rule that would stop the R
>>>> coming from the client to the www server.
>>>>
>>>> Also just have a look at the traffic with wireshar/tcpdump to see if
>>>> that is not the problem.
>>>>
>>>> Thanks
>>>>
>>>> On Thu, Mar 29, 2012 at 12:55 PM, Michel SABORDE <
>>>> michel.saborde at gmail.com> wrote:
>>>>
>>>>> Hello everyone,
>>>>>
>>>>> I'm trying to test the IPv6 implementation of suricata so i'm doing a
>>>>> bunch of tests.
>>>>> For that, i have installed a clean apache2 on a clean server with a
>>>>> single html page called bad.html and i made a simple rule to do an alert if
>>>>> someone tries to access it :
>>>>>
>>>>> alert tcp any any <> any any (msg:"[ALERT] bad.html";
>>>>> content:"bad.html"; nocase; sid:1; rev:1;)
>>>>> If i do a simple access with my browser (iceweasel) from a remote
>>>>> computer, the alert is triggered.
>>>>> At this point, everything looks fine.
>>>>>
>>>>> If i now try to access it "manually" with a scapy script by adding
>>>>> some extension headers, no alert is triggered and i can retrieve the html
>>>>> page.
>>>>> I tried with :
>>>>> - Fragmentation header
>>>>> - Hop-By-Hop header
>>>>> - Destination header
>>>>> - Routing header type 0 without any addresses
>>>>>
>>>>> I tried to change the rule from tcp to ip :
>>>>>
>>>>> alert ip any any <> any any (msg:"[ALERT] bad.html";
>>>>> content:"bad.html"; nocase; sid:1; rev:1;)
>>>>> Then, the alert is triggered only with :
>>>>> - Hop-By-Hop header
>>>>> - Destination header
>>>>> But not with :
>>>>> - Fragmentation header
>>>>> - Routing header type 0 without any addresses
>>>>>
>>>>> Maybe i missed something in the config file of suricata ?
>>>>> My opinion is that suricata should always trigger the alert in every
>>>>> case.
>>>>>
>>>>> I'm using suricata 1.2.1 on a debian 6.0 with a 2.6.32 kernel.
>>>>>
>>>>> Thanks in advance for your help
>>>>>
>>>>> _______________________________________________
>>>>> Oisf-users mailing list
>>>>> Oisf-users at openinfosecfoundation.org
>>>>> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Peter Manev
>>>>
>>>>
>>>
>>>
>>> --
>>> Regards,
>>> Peter Manev
>>>
>>>
>>
>
>
> --
> Regards,
> Peter Manev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20120329/7a4071fd/attachment-0002.html>
More information about the Oisf-users
mailing list