Snort mailing list archives
Re: Snort-devel Digest, Vol 99, Issue 3
From: "Ed Borgoyn (eborgoyn)" <eborgoyn () cisco com>
Date: Thu, 9 Oct 2014 12:19:59 +0000
Muhammad:
If I understand your question correctly, you are asking how to build a Snort dynamic-preprocessor to perform custom
HTTP processing and detection functions.
The Snort manual provides guidance on developing new dynamic-preprocessors. Plus the
snort/src/dynamic-examples/dynamic-preprocessor area provides a simple example (framework) as a place to start. I’d
recommend starting with the example code and with other dynamic-preprocessors in the snort/src/dynamic-preprocessors
area.
You may also want to explore the snort/src/dynamic-examples/dynamic-rule example. Dynamic (or binary) rules provide
a more flexible mechanism to create complex detection rules.
Yes, you would develop in C.
I hope this helps.
Best Regards,
Ed Borgoyn, The Snort Development Team @Cisco
From: Muhammad Ridwan Zalbina <zalbinaridwan () gmail com<mailto:zalbinaridwan () gmail com>>
Date: Wednesday, October 8, 2014 at 11:07 PM
To: "snort-devel () lists sourceforge net<mailto:snort-devel () lists sourceforge net>" <snort-devel () lists
sourceforge net<mailto:snort-devel () lists sourceforge net>>
Subject: Re: [Snort-devel] Snort-devel Digest, Vol 99, Issue 3
hello, developers ?
can i ask something, is there away to make web detection engine from preprocessor of snort and core rule set of
modsecurity
and make it to analyze web attack passively ... and from the paper i read it use C/C++ to make the engine/software ...
:D
reply this please ...
On Tue, Oct 7, 2014 at 9:41 PM, <snort-devel-request () lists sourceforge net<mailto:snort-devel-request () lists
sourceforge net>> wrote:
Send Snort-devel mailing list submissions to
snort-devel () lists sourceforge net<mailto:snort-devel () lists sourceforge net>
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/snort-devel
or, via email, send a message with subject or body 'help' to
snort-devel-request () lists sourceforge net<mailto:snort-devel-request () lists sourceforge net>
You can reach the person managing the list at
snort-devel-owner () lists sourceforge net<mailto:snort-devel-owner () lists sourceforge net>
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Snort-devel digest..."
Today's Topics:
1. Re: Snort Segfault (Peter Fyon)
2. Re: Snort Segfault (Patrick Mullen)
----------------------------------------------------------------------
Message: 1
Date: Mon, 6 Oct 2014 20:48:51 -0400
From: Peter Fyon <peter.fyon () gmail com<mailto:peter.fyon () gmail com>>
Subject: Re: [Snort-devel] Snort Segfault
To: snort-devel () lists sourceforge net<mailto:snort-devel () lists sourceforge net>
Message-ID:
<CANqVG0c-3De1vo5RVz4JfBKEUfKZNX24T11NptXxV3Ew1MnVsw () mail gmail
com<mailto:CANqVG0c-3De1vo5RVz4JfBKEUfKZNX24T11NptXxV3Ew1MnVsw () mail gmail com>>
Content-Type: text/plain; charset="utf-8"
Looks like there's an issue with the precompiled protocol-dns.so rules
under ubuntu 14.04. Probably not a snort-devel related problem.
Peter
On Oct 6, 2014 5:10 PM, "Peter Fyon" <peter.fyon () gmail com<mailto:peter.fyon () gmail com>> wrote:
Hey list,
I recently found my snort setup was segfaulting randomly (although, until
I ran it through strace, I didn't see the segfault message come out
anywhere).
My snort box is sitting on a SPAN port with a single interface using the
nfq DAQ. It would run through an unknown number of packets and die. I'm
going to leave all the debug stuff at the bottom of this email for clarity,
but is this a netfilter issue or something to do with snort, or am I seeing
some malformed packets (I see a dns rule near the top of the backtrace)
causing the crash?
gdb output from a crash:
<snip>
Commencing packet processing (pid=12856)
Decoding Raw IP4
Program received signal SIGSEGV, Segmentation fault.
0xb7d9812b in checksum () from
/usr/lib/i386-linux-gnu/libnetfilter_queue.so.1
(gdb) bt
#0 0xb7d9812b in checksum () from
/usr/lib/i386-linux-gnu/libnetfilter_queue.so.1
#1 0xb7387195 in rule13667eval (p=0x875c7a0 <s_packet>) at
protocol-dns_kb945553-dns-cache-poison.c:313
#2 0xb7430e8f in CheckRule (p=0x875c7a0 <s_packet>, r=0xb73ae620
<rule13667>) at sf_snort_detection_engine.c:148
#3 0x080b713d in DynamicCheck (option_data=0xc884548, p=0x875c7a0
<s_packet>) at sp_dynamic.c:261
#4 0x0809ffec in detection_option_node_evaluate (node=0xc8cf770,
eval_data=eval_data@entry=0xbffff210) at detection_options.c:1140
#5 0x0808b30f in detection_option_tree_evaluate (root=0xc8ac790,
eval_data=eval_data@entry=0xbffff210) at fpdetect.c:580
#6 0x0808b778 in fpEvalHeaderSW (port_group=0xc8ac710, p=0x875c7a0
<s_packet>, check_ports=<optimized out>, ip_rule=0 '\000', omd=0x8ecc628)
at fpdetect.c:1341
#7 0x0808d0f5 in fpEvalHeaderUdp (omd=0x8ecc628, p=0x875c7a0 <s_packet>)
at fpdetect.c:1458
#8 fpEvalPacket (p=p@entry=0x875c7a0 <s_packet>) at fpdetect.c:1708
#9 0x08084b52 in Detect (p=p@entry=0x875c7a0 <s_packet>) at detect.c:523
#10 0x080852a9 in Preprocess (p=p@entry=0x875c7a0 <s_packet>) at
detect.c:247
#11 0x08078f28 in ProcessPacket (p=p@entry=0x875c7a0 <s_packet>,
pkthdr=pkthdr@entry=0xbffff410, pkt=pkt@entry=0x1381d460 "E", ft=ft@entry=0x0)
at snort.c:1867
#12 0x0807b0fc in PacketCallback (user=0x0, pkthdr=0xbffff410,
pkt=0x1381d460 "E") at snort.c:1704
#13 0x0812f197 in daq_nfq_callback (qh=0x120e2700, nfmsg=0x1381d420,
nfad=0xbffff47c, data=0xc8b3f40) at daq_nfq.c:455
#14 0xb7d967e3 in ?? () from
/usr/lib/i386-linux-gnu/libnetfilter_queue.so.1
#15 0xb7b37484 in nfnl_handle_packet () from
/usr/lib/i386-linux-gnu/libnfnetlink.so.0
#16 0xb7d96ded in nfq_handle_packet () from
/usr/lib/i386-linux-gnu/libnetfilter_queue.so.1
#17 0x0812f01d in nfq_daq_acquire (handle=0xc8b3f40, c=0,
callback=0x807afc0 <PacketCallback>, metaback=0x0, user=0x0) at
daq_nfq.c:530
#18 0x0809818b in DAQ_Acquire (max=max@entry=0, callback=callback@entry=0x807afc0
<PacketCallback>, user=user@entry=0x0) at sfdaq.c:540
#19 0x0807cea1 in PacketLoop () at snort.c:3210
#20 SnortMain (argc=7, argv=argv@entry=0xbffff7c4) at snort.c:907
#21 0x0804c0b6 in main (argc=7, argv=0xbffff7c4) at snort.c:807
(gdb)
It looked like it ran only through a couple hundred packets before
crashing:
root@server:/proc/net/netfilter# cat nfnetlink_queue
0 12856 29 2 65531 0 0 58 1
(a previous run it processed at least 152, I wasn't as diligent cat'ing
nfnetlink_queue this time)
Output from a crash through strace:
select(4, [3], NULL, NULL, {1, 0}) = 1 (in [3], left {0, 999984})
recv(3,
"\223\0\0\0\0\3\0\0\0\0\0\0\0\0\0\0\2\0\0\0\v\0\1\0\0\0\0\234\10\0\0\0"...,
66047, 0) = 147
sendmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000},
msg_iov(1)=[{"
\0\0\0\1\3\1\0\0\0\0\0\0\0\0\0\0\0\0\0\f\0\2\0\0\0\0\1\0\0\0\234", 32}],
msg_controllen=0, msg_flags=0}, 0) = 32
select(4, [3], NULL, NULL, {1, 0}) = 1 (in [3], left {0, 983779})
recv(3,
"\372\0\0\0\0\3\0\0\0\0\0\0\0\0\0\0\2\0\0\0\v\0\1\0\0\0\0\235\10\0\0\0"...,
66047, 0) = 250
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x8c} ---
rt_sigaction(SIGSEGV, {SIG_DFL, [], 0}, {0x807de00, [], 0}, 8) = 0
tgkill(12422, 12422, SIGSEGV) = 0
sigreturn() (mask []) = 13667
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_TKILL, si_pid=12422, si_uid=0}
---
+++ killed by SIGSEGV (core dumped) +++
Hope someone can help, it's super annoying having snort crash all the time.
Peter
-------------- next part -------------- An HTML attachment was scrubbed... ------------------------------ Message: 2 Date: Tue, 7 Oct 2014 10:41:50 -0400 From: Patrick Mullen <pmullen () sourcefire com<mailto:pmullen () sourcefire com>> Subject: Re: [Snort-devel] Snort Segfault To: Peter Fyon <peter.fyon () gmail com<mailto:peter.fyon () gmail com>> Cc: "snort-devel () lists sourceforge net<mailto:snort-devel () lists sourceforge net>" <snort-devel () lists sourceforge net<mailto:snort-devel () lists sourceforge net>> Message-ID: <CAMhPpEU5d4hqHr3sV7Hf992C5UnZbd0QVfaDHAJC2FrxTERRKA () mail gmail com<mailto:CAMhPpEU5d4hqHr3sV7Hf992C5UnZbd0QVfaDHAJC2FrxTERRKA () mail gmail com>> Content-Type: text/plain; charset="utf-8" Peter, Thank you for the report. I believe I have identified and corrected the issue. It should be released tomorrow (08 October 2014), so let me know if you continue to have problems after the update. In the mean time, you can disable detection for gid 3, sid 13667 and the crashes should go away. Thanks, ~Patrick On Mon, Oct 6, 2014 at 8:48 PM, Peter Fyon <peter.fyon () gmail com<mailto:peter.fyon () gmail com>> wrote:
Looks like there's an issue with the precompiled protocol-dns.so rules under ubuntu 14.04. Probably not a snort-devel related problem. Peter On Oct 6, 2014 5:10 PM, "Peter Fyon" <peter.fyon () gmail com<mailto:peter.fyon () gmail com>> wrote:Hey list, I recently found my snort setup was segfaulting randomly (although, until I ran it through strace, I didn't see the segfault message come out anywhere). My snort box is sitting on a SPAN port with a single interface using the nfq DAQ. It would run through an unknown number of packets and die. I'm going to leave all the debug stuff at the bottom of this email for clarity, but is this a netfilter issue or something to do with snort, or am I seeing some malformed packets (I see a dns rule near the top of the backtrace) causing the crash? gdb output from a crash: <snip> Commencing packet processing (pid=12856) Decoding Raw IP4 Program received signal SIGSEGV, Segmentation fault. 0xb7d9812b in checksum () from /usr/lib/i386-linux-gnu/libnetfilter_queue.so.1 (gdb) bt #0 0xb7d9812b in checksum () from /usr/lib/i386-linux-gnu/libnetfilter_queue.so.1 #1 0xb7387195 in rule13667eval (p=0x875c7a0 <s_packet>) at protocol-dns_kb945553-dns-cache-poison.c:313 #2 0xb7430e8f in CheckRule (p=0x875c7a0 <s_packet>, r=0xb73ae620 <rule13667>) at sf_snort_detection_engine.c:148 #3 0x080b713d in DynamicCheck (option_data=0xc884548, p=0x875c7a0 <s_packet>) at sp_dynamic.c:261 #4 0x0809ffec in detection_option_node_evaluate (node=0xc8cf770, eval_data=eval_data@entry=0xbffff210) at detection_options.c:1140 #5 0x0808b30f in detection_option_tree_evaluate (root=0xc8ac790, eval_data=eval_data@entry=0xbffff210) at fpdetect.c:580 #6 0x0808b778 in fpEvalHeaderSW (port_group=0xc8ac710, p=0x875c7a0 <s_packet>, check_ports=<optimized out>, ip_rule=0 '\000', omd=0x8ecc628) at fpdetect.c:1341 #7 0x0808d0f5 in fpEvalHeaderUdp (omd=0x8ecc628, p=0x875c7a0 <s_packet>) at fpdetect.c:1458 #8 fpEvalPacket (p=p@entry=0x875c7a0 <s_packet>) at fpdetect.c:1708 #9 0x08084b52 in Detect (p=p@entry=0x875c7a0 <s_packet>) at detect.c:523 #10 0x080852a9 in Preprocess (p=p@entry=0x875c7a0 <s_packet>) at detect.c:247 #11 0x08078f28 in ProcessPacket (p=p@entry=0x875c7a0 <s_packet>, pkthdr=pkthdr@entry=0xbffff410, pkt=pkt@entry=0x1381d460 "E", ft=ft@entry=0x0) at snort.c:1867 #12 0x0807b0fc in PacketCallback (user=0x0, pkthdr=0xbffff410, pkt=0x1381d460 "E") at snort.c:1704 #13 0x0812f197 in daq_nfq_callback (qh=0x120e2700, nfmsg=0x1381d420, nfad=0xbffff47c, data=0xc8b3f40) at daq_nfq.c:455 #14 0xb7d967e3 in ?? () from /usr/lib/i386-linux-gnu/libnetfilter_queue.so.1 #15 0xb7b37484 in nfnl_handle_packet () from /usr/lib/i386-linux-gnu/libnfnetlink.so.0 #16 0xb7d96ded in nfq_handle_packet () from /usr/lib/i386-linux-gnu/libnetfilter_queue.so.1 #17 0x0812f01d in nfq_daq_acquire (handle=0xc8b3f40, c=0, callback=0x807afc0 <PacketCallback>, metaback=0x0, user=0x0) at daq_nfq.c:530 #18 0x0809818b in DAQ_Acquire (max=max@entry=0, callback=callback@entry=0x807afc0 <PacketCallback>, user=user@entry=0x0) at sfdaq.c:540 #19 0x0807cea1 in PacketLoop () at snort.c:3210 #20 SnortMain (argc=7, argv=argv@entry=0xbffff7c4) at snort.c:907 #21 0x0804c0b6 in main (argc=7, argv=0xbffff7c4) at snort.c:807 (gdb) It looked like it ran only through a couple hundred packets before crashing: root@server:/proc/net/netfilter# cat nfnetlink_queue 0 12856 29 2 65531 0 0 58 1 (a previous run it processed at least 152, I wasn't as diligent cat'ing nfnetlink_queue this time) Output from a crash through strace: select(4, [3], NULL, NULL, {1, 0}) = 1 (in [3], left {0, 999984}) recv(3, "\223\0\0\0\0\3\0\0\0\0\0\0\0\0\0\0\2\0\0\0\v\0\1\0\0\0\0\234\10\0\0\0"..., 66047, 0) = 147 sendmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{" \0\0\0\1\3\1\0\0\0\0\0\0\0\0\0\0\0\0\0\f\0\2\0\0\0\0\1\0\0\0\234", 32}], msg_controllen=0, msg_flags=0}, 0) = 32 select(4, [3], NULL, NULL, {1, 0}) = 1 (in [3], left {0, 983779}) recv(3, "\372\0\0\0\0\3\0\0\0\0\0\0\0\0\0\0\2\0\0\0\v\0\1\0\0\0\0\235\10\0\0\0"..., 66047, 0) = 250 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x8c} --- rt_sigaction(SIGSEGV, {SIG_DFL, [], 0}, {0x807de00, [], 0}, 8) = 0 tgkill(12422, 12422, SIGSEGV) = 0 sigreturn() (mask []) = 13667 --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_TKILL, si_pid=12422, si_uid=0} --- +++ killed by SIGSEGV (core dumped) +++ Hope someone can help, it's super annoying having snort crash all the time. Peter------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Snort-devel mailing list Snort-devel () lists sourceforge net<mailto:Snort-devel () lists sourceforge net> https://lists.sourceforge.net/lists/listinfo/snort-devel Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel Please visit http://blog.snort.org for the latest news about Snort!
-- Patrick Mullen Response Research Manager Sourcefire VRT -------------- next part -------------- An HTML attachment was scrubbed... ------------------------------ ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ------------------------------ _______________________________________________ Snort-devel mailing list Snort-devel () lists sourceforge net<mailto:Snort-devel () lists sourceforge net> https://lists.sourceforge.net/lists/listinfo/snort-devel End of Snort-devel Digest, Vol 99, Issue 3 ******************************************
------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________ Snort-devel mailing list Snort-devel () lists sourceforge net https://lists.sourceforge.net/lists/listinfo/snort-devel Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel Please visit http://blog.snort.org for the latest news about Snort!
Current thread:
- Re: Snort-devel Digest, Vol 99, Issue 3 Muhammad Ridwan Zalbina (Oct 08)
- Re: Snort-devel Digest, Vol 99, Issue 3 Ed Borgoyn (eborgoyn) (Oct 09)