[prev in list] [next in list] [prev in thread] [next in thread]
List: snort-sigs
Subject: Re: [Snort-sigs] TCP header reserved bits
From: Y M <snort () outlook ! com>
Date: 2015-07-28 19:33:39
Message-ID: COL129-W90460FD4C9B212271F63ECA88D0 () phx ! gbl
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Thank you Geoffrey, appreciate the time you put into testing this. I will try to dig \
deeper into it.
Thanks again.
YM
Date: Tue, 28 Jul 2015 15:17:04 -0400
Subject: Re: [Snort-sigs] TCP header reserved bits
From: gserrao@sourcefire.com
To: snort@outlook.com
CC: snort-sigs@lists.sourceforge.net
whoops, attaching example pcap.
On Tue, Jul 28, 2015 at 3:16 PM, Geoffrey Serrao <gserrao@sourcefire.com> wrote:
YM,
I tested the flags option with the attached pcap and you're absolutely right that \
those 3 highest order bits in the flag section can't be tested with the 'flags' \
keyword.
If you're up for writing a shared object rule the tcp flags in their entirety are \
available to you in the TCPHeader structure:
typedef struct _TCPHeader
{
uint16_t source_port;
uint16_t destination_port;
uint32_t sequence;
uint32_t acknowledgement;
uint8_t offset_reserved;
uint8_t flags;
uint16_t window;
uint16_t checksum;
uint16_t urgent_pointer;
} TCPHeader;
You could create a shared object rule that looks at the flags byte and alerts if the \
first three bits are set.
On Tue, Jul 28, 2015 at 2:06 PM, Y M <snort@outlook.com> wrote:
Thanks Geoffrey.
Interesting. My interpretation of the documentation and aligning that with the TCP \
header, the "E" and "C" flags will check whether the last 2 bits of of the higher \
order bits of byte offset 13, i.e.: CWR and ECE. Precisely, I was attempting to \
address the match against the first 3 bits of the lower order bits of byte offset 12 \
excluding the ECN-E/NS bit, similar to what is described in RFC4413, or at least my \
interpretation of it.
I could be completely off here, so please correct if I am wrong.
Thanks again!
YM
Date: Tue, 28 Jul 2015 13:38:29 -0400
Subject: Re: [Snort-sigs] TCP header reserved bits
From: gserrao@sourcefire.com
To: snort@outlook.com
CC: snort-sigs@lists.sourceforge.net
YM,
It looks like you can still use 'flags:2' to check if the low order reserved bits \
field in a TCP header have been set.
229 case '1': /* reserved bit flags */
230 case 'c':
231 case 'C':
232 idx->tcp_flags |= R_CWR; /* Congestion Window Reduced, RFC 3168 \
*/ 233 break;
234
235 case '2': /* reserved bit flags */
236 case 'e':
237 case 'E':
238 idx->tcp_flags |= R_ECE; /* ECN echo, RFC 3168 */
239 break;
> From the online snort manual under the 'flags' keyword section:
The reserved bits '1' and '2' have been replaced with 'C' and 'E', respectively,
to match RFC 3168, "The Addition of Explicit Congestion Notification (ECN) to IP".
The old values of '1' and '2' are still valid for the flag keyword, but
are now deprecated.
On Tue, Jul 28, 2015 at 12:46 PM, Y M <snort@outlook.com> wrote:
I was wondering if there is a content modifier or some way to check whether the low \
order reserved bits of byte offset 12 in the TCP header is set. There is nothing I \
could find about this in the documentation. I also checked gid:129 rules and couldn't \
infer that the check/detection is available.
Any pointers or help is welcome.
Thanks.
YM
------------------------------------------------------------------------------
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
http://www.snort.org
Please visit http://blog.snort.org for the latest news about Snort!
[Attachment #5 (text/html)]
<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Thank you Geoffrey, appreciate the time you \
put into testing this. I will try to dig deeper into it.<br><br>Thanks \
again.<br>YM<br><br><div><hr id="stopSpelling">Date: Tue, 28 Jul 2015 15:17:04 \
-0400<br>Subject: Re: [Snort-sigs] TCP header reserved bits<br>From: \
gserrao@sourcefire.com<br>To: snort@outlook.com<br>CC: \
snort-sigs@lists.sourceforge.net<br><br><div dir="ltr">whoops, attaching example \
pcap. <br></div><div class="ecxgmail_extra"><br><div class="ecxgmail_quote">On Tue, \
Jul 28, 2015 at 3:16 PM, Geoffrey Serrao <span dir="ltr"><<a \
href="mailto:gserrao@sourcefire.com" \
target="_blank">gserrao@sourcefire.com</a>></span> wrote:<br><blockquote \
class="ecxgmail_quote" style="border-left:1px #ccc solid;padding-left:1ex;"><div \
dir="ltr"><div><div><div>YM,<br><br></div>I tested the flags option with the attached \
pcap and you're absolutely right that those 3 highest order bits in the flag section \
can't be tested with the 'flags' keyword. <br><br></div>If you're up for writing a \
shared object rule the tcp flags in their entirety are available to you in the \
TCPHeader structure:<br><br>typedef struct _TCPHeader<br> { \
<br> uint16_t source_port;<br> \
uint16_t destination_port;<br> uint32_t \
sequence;<br> uint32_t \
acknowledgement;<br> uint8_t \
offset_reserved;<br> uint8_t \
flags;<br> uint16_t window;<br> \
uint16_t checksum;<br> uint16_t urgent_pointer;<br> } \
TCPHeader;<br><br><br></div>You could create a shared object rule that looks at the \
flags byte and alerts if the first three bits are set. <br></div><div \
class="ecxgmail_extra"><br><div class="ecxgmail_quote"><span>On Tue, Jul 28, 2015 at \
2:06 PM, Y M <span dir="ltr"><<a href="mailto:snort@outlook.com" \
target="_blank">snort@outlook.com</a>></span> wrote:<br></span><blockquote \
class="ecxgmail_quote" style="border-left:1px #ccc solid;padding-left:1ex;">
<div><div dir="ltr"><span>Thanks Geoffrey.<br><br>Interesting. My interpretation of \
the documentation and aligning that with the TCP header, the "E" and "C" flags will \
check whether the last 2 bits of of the higher order bits of byte offset 13, i.e.: \
CWR and ECE. Precisely, I was attempting to address the match against the first 3 \
bits of the lower order bits of byte offset 12 excluding the ECN-E/NS bit, similar to \
what is described in RFC4413, or at least my interpretation of it.<br><br>I could be \
completely off here, so please correct if I am wrong.<br><br>Thanks \
again!<br>YM<br><br></span><div><span><hr>Date: Tue, 28 Jul 2015 13:38:29 \
-0400<br>Subject: Re: [Snort-sigs] TCP header reserved bits<br></span>From: <a \
href="mailto:gserrao@sourcefire.com" \
target="_blank">gserrao@sourcefire.com</a><br>To: <a href="mailto:snort@outlook.com" \
target="_blank">snort@outlook.com</a><br>CC: <a \
href="mailto:snort-sigs@lists.sourceforge.net" \
target="_blank">snort-sigs@lists.sourceforge.net</a><div><div \
class="h5"><div><div><br><br><div dir="ltr"><div>YM,<br><br></div>It looks like you \
can still use 'flags:2' to check if the low order reserved bits field in a TCP header \
have been set. <br><div><div><br>229 \
case '1': /* reserved bit flags \
*/<br>230 \
case 'c':<br>231 \
case 'C':<br>232 \
idx->tcp_flags |= R_CWR; /* Congestion Window Reduced, RFC 3168 \
*/<br>233 \
break;<br>234 <br>235 \
case '2': /* reserved bit flags \
*/<br>236 \
case 'e':<br>237 \
case 'E':<br>238 \
idx->tcp_flags |= R_ECE; /* ECN echo, RFC 3168 \
*/<br>239 \
break;<br><br><br><br><br>From the online snort manual under the 'flags' keyword \
section: <br><br>The reserved bits '1' and '2' have been replaced with 'C' and 'E', \
respectively, to match RFC 3168, "The Addition of Explicit Congestion Notification \
(ECN) to IP". The old values of '1' and '2' are still valid for the <tt>flag</tt> \
keyword, but are now deprecated.
<br></div></div></div><div><br><div>On Tue, Jul 28, 2015 at 12:46 PM, Y M <span \
dir="ltr"><<a href="mailto:snort@outlook.com" \
target="_blank">snort@outlook.com</a>></span> wrote:<br><blockquote \
style="border-left:1px #ccc solid;padding-left:1ex;">
<div><div dir="ltr">I was wondering if there is a content modifier or some way to \
check whether the low order reserved bits of byte offset 12 in the TCP header is set. \
There is nothing I could find about this in the documentation. I also checked gid:129 \
rules and couldn't infer that the check/detection is available.<br><br>Any pointers \
or help is welcome.<br><br>Thanks.<span><font color="#888888"><br>YM<br> \
</font></span></div></div> \
<br>------------------------------------------------------------------------------<br>
<br>_______________________________________________<br>
Snort-sigs mailing list<br>
<a href="mailto:Snort-sigs@lists.sourceforge.net" \
target="_blank">Snort-sigs@lists.sourceforge.net</a><br> <a \
href="https://lists.sourceforge.net/lists/listinfo/snort-sigs" rel="noreferrer" \
target="_blank">https://lists.sourceforge.net/lists/listinfo/snort-sigs</a><br> <a \
href="http://www.snort.org" rel="noreferrer" \
target="_blank">http://www.snort.org</a><br> <br>
<br>
Please visit <a href="http://blog.snort.org" rel="noreferrer" \
target="_blank">http://blog.snort.org</a> for the latest news about \
Snort!<br></blockquote></div><br></div></div></div></div></div></div> \
</div></div> </blockquote></div><br></div>
</blockquote></div><br></div></div> </div></body>
</html>
------------------------------------------------------------------------------
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
http://www.snort.org
Please visit http://blog.snort.org for the latest news about Snort!
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic