Re: [Snort-users] Updated IP Blacklisting patch (version 2)
Martin Roesch
Miller<eoin....@trojanedbinaries.com> wrote:
> I was thinking you could have it use the number from the precached event
> string as the alertid in the gen-msg.map file:
>
> Loading bruteforcer blacklist from
> /etc/snort/iplists/bruteforceblocker.blacklist
> Loading spamhaus blacklist from /etc/snort/iplists/spamhaus.blacklist
> Loading tor-exit blacklist from /etc/snort/iplists/tor-exitnode.blacklist
> Loading tor-server blacklist from /etc/snort/iplists/tor-server.blacklist
> Loading zeus blacklist from /etc/snort/iplists/zeustracker.blacklist
> IP List Config:
> =A0 =A0IP Blacklist active with 5241 entries
> =A0 =A0IP Whitelist active with 0 entries
> =A0 =A0Precached event strings:
> =A0 =A0 =A0 =A00 -> =A0Access attempt from bruteforcer blacklisted IP add=
ress
> =A0 =A0 =A0 =A01 -> =A0Access attempt from spamhaus blacklisted IP address
> =A0 =A0 =A0 =A02 -> =A0Access attempt from tor-exit blacklisted IP address
> =A0 =A0 =A0 =A03 -> =A0Access attempt from tor-server blacklisted IP addr=
ess
> =A0 =A0 =A0 =A04 -> =A0Access attempt from zeus blacklisted IP address
>
> So you could use numbers 0-4 with the above configuration and the user
> would have to update their own gen-msg.map to reflect this. So something
> like:
>
> 136 || 0 || spp_iplist: bruteforcer blacklisted ip
> 136 || 1 || spp_iplist: spamhaus blacklisted ip
> 136 || 2 || spp_iplist: tor-exit blacklisted ip
> 136 || 3 || spp_iplist: tor-server blacklisted ip
> 136 || 4 || spp_iplist: zeus blacklisted ip
>
> Now when using unified alerting, barnyard can look back at this and
> produce more meaningful output. However, when looking at the patch file
> and the updates that were done to src/generators.h it doesn't look like
> this is just a super simple quick fix (aka out of the scope of my super
> simple and poor programming skills). You aren't going to be flying back
> from Europe with 9 hours to kill again any time soon are you? :)
Hi Eoin,
That's what I was thinking of doing too. Really I think it's a one
liner change to do that, you just have to edit line 376 in
src/preprocessors/spp_iplist.c from:
SnortEventqAdd(GENERATOR_SPP_IPLIST, IPLIST_BLACKLIST, 1, 0, 0,
to
SnortEventqAdd(GENERATOR_SPP_IPLIST, (int)pn->data, 1, 0, 0,
and that ought to do it. Give it a shot and let me know if it works for yo=
u.
Marty
-- =
Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
Sourcefire - Security for the Real World - http://www.sourcefire.com
Snort: Open Source IDP - http://www.snort.org
---------------------------------------------------------------------------=
---
Enter the BlackBerry Developer Challenge =
This is your chance to win up to $100,000 in prizes! For a limited time, =
vendors submitting new applications to BlackBerry App World(TM) will have =
the opportunity to enter the BlackBerry Developer Challenge. See full prize =
details at: http://p.sf.net/sfu/blackberry
_______________________________________________
Snort-users mailing list
Snort...@lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=3Dsnort-users
Eoin Miller
> On Mon, Jul 6, 2009 at 5:50 PM, Eoin
> Miller<eoin....@trojanedbinaries.com> wrote:
>
>> I was thinking you could have it use the number from the precached event
>> string as the alertid in the gen-msg.map file:
>>
>> Loading bruteforcer blacklist from
>> /etc/snort/iplists/bruteforceblocker.blacklist
>> Loading spamhaus blacklist from /etc/snort/iplists/spamhaus.blacklist
>> Loading tor-exit blacklist from /etc/snort/iplists/tor-exitnode.blacklist
>> Loading tor-server blacklist from /etc/snort/iplists/tor-server.blacklist
>> Loading zeus blacklist from /etc/snort/iplists/zeustracker.blacklist
>> IP List Config:
>> 0 -> Access attempt from bruteforcer blacklisted IP address
>> 1 -> Access attempt from spamhaus blacklisted IP address
>> 2 -> Access attempt from tor-exit blacklisted IP address
>> 3 -> Access attempt from tor-server blacklisted IP address
>> 4 -> Access attempt from zeus blacklisted IP address
>>
>> So you could use numbers 0-4 with the above configuration and the user
>> would have to update their own gen-msg.map to reflect this. So something
>> like:
>>
>> 136 || 0 || spp_iplist: bruteforcer blacklisted ip
>> 136 || 1 || spp_iplist: spamhaus blacklisted ip
>> 136 || 2 || spp_iplist: tor-exit blacklisted ip
>> 136 || 3 || spp_iplist: tor-server blacklisted ip
>> 136 || 4 || spp_iplist: zeus blacklisted ip
>>
>> Now when using unified alerting, barnyard can look back at this and
>> produce more meaningful output. However, when looking at the patch file
>> and the updates that were done to src/generators.h it doesn't look like
>> this is just a super simple quick fix (aka out of the scope of my super
>> simple and poor programming skills). You aren't going to be flying back
>> from Europe with 9 hours to kill again any time soon are you? :)
>>
>
> Hi Eoin,
>
> That's what I was thinking of doing too. Really I think it's a one
> liner change to do that, you just have to edit line 376 in
> src/preprocessors/spp_iplist.c from:
>
> SnortEventqAdd(GENERATOR_SPP_IPLIST, IPLIST_BLACKLIST, 1, 0, 0,
>
> to
>
> SnortEventqAdd(GENERATOR_SPP_IPLIST, (int)pn->data, 1, 0, 0,
>
>
>
> Marty
>
>
Doh! I should have understood that line better when looking at it.
Updated the code and recompiled, it is working great!
--snip--
[136:1:1] Access attempt from spamhaus blacklisted IP address [**]
[Priority: 0] {UDP} x.x.x.32:3213 -> x.x.x.154:53
[136:3:1] Access attempt from tor-server blacklisted IP address [**]
[Priority: 0] {UDP} x.x.x.212:44503 -> x.x.x.32:53
[136:4:1] Access attempt from zeus blacklisted IP address [**]
[Priority: 0] {TCP} x.x.x.64:1889 -> x.x.x.1:80
--snip--
Thanks!
--
Eoin Miller
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/blackberry
_______________________________________________
Snort-users mailing list
Snort...@lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
Martin Roesch
Miller<eoin....@trojanedbinaries.com> wrote:> Marty,
>
> After the update to the code, there was an 15% or so up-tick in system
> processor utilization which is leading to exceptionally mild increase in
> packet loss. Not really a surprise since when SnortEventqAdd is called,
> it now does two lookups to find the number of the list and then the
> number of the list again to refrence the name:
>
> SnortEventqAdd(GENERATOR_SPP_IPLIST, (int)pn->data, 1, 0, 0,
>
> So to try and streamline this a bit more, I added a new int inside of
> IpListEval:
>
> void IpListEval(Packet *p, void *conext)
> {
> int foo;
>
>
> Then inside of the if(blacklist_detect) we grab (int)pn->data once and
> then save it as foo and just use foo when calling SnortEventqAdd:
>
> =A0 =A0 =A0 =A0if(blacklist_detect)
> =A0 =A0 =A0 =A0{
> =A0 =A0 =A0 =A0 =A0 =A0if(!noalerts)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0foo =3D (int)pn->data;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0SnortEventqAdd(GENERATOR_SPP_IPLIST, foo, =
1, 0, 0,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 list_names[fo=
o], 0);
>
>
> This drops the system processor utilization back down by about 10% or so
> and completely stops the packet loss we were experiencing. Some links to
> gnuplot graphs based off the snort.stats file are included below to
> support this are below:
>
> http://trojanedbinaries.com/security/snort/cpu.png
> http://trojanedbinaries.com/security/snort/dropped.png
Wow, 15%! That's a heck of a lot of overhead for a single added
pointer dereference. Is that 15% greater than what Snort was using
before or 15% of total system CPU? I took a little closer look at the
function and made a couple changes. Not sure of the performance
impact but evaluating the whitelist and bailing on a whitelist detect
before evaluating the blacklist should result in some savings. Let me
post the updated function:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
void IpListEval(Packet *p, void *conext)
{
struct addr saddr;
struct addr daddr;
s_ptrie_node_t *pn =3D NULL;
int whitelist_detect =3D 0;
int blacklist_detect =3D 0;
int bl_ref =3D 0;
if(!IsIP(p))
{
DEBUG_WRAP(DebugMessage(DEBUG_PLUGIN,
" -> spp_iplist: Not IP\n"););
return;
}
if(((IsTCP(p) && p->tcph->th_flags & TH_SYN)) ||
(IsUDP(p)) || (IsICMP(p)))
{
addr_pack(&saddr, ADDR_TYPE_IP, IP_ADDR_BITS, &p->iph->ip_src,
IP_ADDR_LEN);
addr_pack(&daddr, ADDR_TYPE_IP, IP_ADDR_BITS, &p->iph->ip_dst,
IP_ADDR_LEN);
if(ip_whitelist)
{
if(s_ptrie_find_entry_byaddr(ip_whitelist, &saddr) ||
s_ptrie_find_entry_byaddr(ip_whitelist, &daddr))
{
/* let's bail, should probably set do_detect to 0 too... */
return;
}
}
if(ip_blacklist)
{
if((pn =3D s_ptrie_find_entry_byaddr(ip_blacklist, &saddr)))
{
blacklist_detect =3D 1;
bl_ref =3D (int)pn->data;
}
else if((pn =3D s_ptrie_find_entry_byaddr(ip_blacklist, &daddr=
)))
{
blacklist_detect =3D 1;
bl_ref =3D (int)pn->data;
}
}
if(blacklist_detect)
{
if(!noalerts)
SnortEventqAdd(GENERATOR_SPP_IPLIST, bl_ref, 1, 0, 0,
list_names[bl_ref], 0);
if(!nodrops && InlineMode())
InlineDrop(p);
}
}
return;
}
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
If I was feeling a bit more foot-loose and fancy free I'd do something
like this:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
void IpListEval(Packet *p, void *conext)
{
struct addr saddr;
struct addr daddr;
s_ptrie_node_t *pn =3D NULL;
int whitelist_detect =3D 0;
int blacklist_detect =3D 0;
int bl_ref =3D 0;
if(!IsIP(p))
{
DEBUG_WRAP(DebugMessage(DEBUG_PLUGIN,
" -> spp_iplist: Not IP\n"););
return;
}
if(((IsTCP(p) && p->tcph->th_flags & TH_SYN)) ||
(IsUDP(p)) || (IsICMP(p)))
{
addr_pack(&saddr, ADDR_TYPE_IP, IP_ADDR_BITS, &p->iph->ip_src,
IP_ADDR_LEN);
addr_pack(&daddr, ADDR_TYPE_IP, IP_ADDR_BITS, &p->iph->ip_dst,
IP_ADDR_LEN);
if(ip_whitelist)
{
if(s_ptrie_find_entry_byaddr(ip_whitelist, &saddr) ||
s_ptrie_find_entry_byaddr(ip_whitelist, &daddr))
{
/* let's bail, should probably set do_detect to 0 too... */
return;
}
}
if(ip_blacklist)
{
if((pn =3D s_ptrie_find_entry_byaddr(ip_blacklist, &saddr)))
{
bl_ref =3D (int)pn->data;
goto bl_detect;
}
else if((pn =3D s_ptrie_find_entry_byaddr(ip_blacklist, &daddr=
)))
{
bl_ref =3D (int)pn->data;
goto bl_detect;
}
goto bl_done;
}
bl_detect:
if(!noalerts)
SnortEventqAdd(GENERATOR_SPP_IPLIST, bl_ref, 1, 0, 0,
list_names[bl_ref], 0);
if(!nodrops && InlineMode())
InlineDrop(p);
bl_done:
}
return;
}
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
But goto's are Bad so we'd never do that... :)
Marty
-- =
Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
Sourcefire - Security for the Real World - http://www.sourcefire.com
Snort: Open Source IDP - http://www.snort.org
---------------------------------------------------------------------------=
---
Enter the BlackBerry Developer Challenge =
This is your chance to win up to $100,000 in prizes! For a limited time, =
vendors submitting new applications to BlackBerry App World(TM) will have =
the opportunity to enter the BlackBerry Developer Challenge. See full prize =
details at: http://p.sf.net/sfu/blackberry
_______________________________________________
Snort-users mailing list
Snort...@lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
Eoin Miller
> On Tue, Jul 7, 2009 at 1:02 PM, Eoin
> Miller<eoin....@trojanedbinaries.com> wrote:> Marty,
>
>> After the update to the code, there was an 15% or so up-tick in system
>> processor utilization which is leading to exceptionally mild increase in
>> packet loss. Not really a surprise since when SnortEventqAdd is called,
>> it now does two lookups to find the number of the list and then the
>> number of the list again to refrence the name:
>>
>> SnortEventqAdd(GENERATOR_SPP_IPLIST, (int)pn->data, 1, 0, 0,
>> list_names[(int)pn->data], 0);
>>
>> So to try and streamline this a bit more, I added a new int inside of
>> IpListEval:
>>
>> void IpListEval(Packet *p, void *conext)
>> {
>> int foo;
>>
>>
>> Then inside of the if(blacklist_detect) we grab (int)pn->data once and
>> then save it as foo and just use foo when calling SnortEventqAdd:
>>
>> {
>> if(!noalerts)
>> foo = (int)pn->data;
>> SnortEventqAdd(GENERATOR_SPP_IPLIST, foo, 1, 0, 0,
>> list_names[foo], 0);
>>
>>
>> This drops the system processor utilization back down by about 10% or so
>> and completely stops the packet loss we were experiencing. Some links to
>> gnuplot graphs based off the snort.stats file are included below to
>> support this are below:
>>
>> http://trojanedbinaries.com/security/snort/cpu.png
>> http://trojanedbinaries.com/security/snort/dropped.png
>>
>
> Wow, 15%! That's a heck of a lot of overhead for a single added
> pointer dereference. Is that 15% greater than what Snort was using
> before or 15% of total system CPU? I took a little closer look at the
> function and made a couple changes. Not sure of the performance
> impact but evaluating the whitelist and bailing on a whitelist detect
> before evaluating the blacklist should result in some savings. Let me
> post the updated function:
>
>
>
> Marty
>
>
>
using ~35% of a core to monitor ~450Mbit/s of traffic. After adding the
second pointer dereference it was using ~50% of a core to monitor the
same amount of traffic. FYI, this test snort instance has no rules
loaded and is using Phil Wood's MMAP'd libpcap with a 1GigaByte buffer
of system RAM.
If you look at the cpu.png file
(http://trojanedbinaries.com/security/snort/cpu.png) you can see the
spike in the green line (system%) and the dip in the blue line (idle%) @
16:00. That was when snort was relaunched with the double pointer
derefrence in the call to the SnortEventqAdd function:
SnortEventqAdd(GENERATOR_SPP_IPLIST, (int)pn->data, 1, 0, 0,
list_names[(int)pn->data], 0);
But if you notice the dip in the green line and rise in the blue line
from 16:40-16:50, that was when I was running recompiled with the single
derefrence:
foo = (int)pn->data;
SnortEventqAdd(GENERATOR_SPP_IPLIST, foo, 1, 0, 0, list_names[foo], 0);
Tried your new first function you posted and the results appear the
same. Good deal less processor utilization and no more packet loss and
your new function makes more sense for those using the whitelisting
functionality. Tried to use the fancy free way with the goto's, but gcc
got all whiny about something.
--
Eoin Miller
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/blackberry
_______________________________________________
Snort-users mailing list
Snort...@lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
Martin Roesch
Might work better if I actually tried to compile the thing instead of
just banging it in in gmail. Try this one:
===============
void IpListEval(Packet *p, void *conext)
{
struct addr saddr;
struct addr daddr;
s_ptrie_node_t *pn = NULL;
int bl_ref = 0;
if(!IsIP(p))
{
DEBUG_WRAP(DebugMessage(DEBUG_PLUGIN,
" -> spp_iplist: Not IP\n"););
return;
}
if(((IsTCP(p) && p->tcph->th_flags & TH_SYN)) ||
(IsUDP(p)) || (IsICMP(p)))
{
addr_pack(&saddr, ADDR_TYPE_IP, IP_ADDR_BITS, &p->iph->ip_src,
IP_ADDR_LEN);
addr_pack(&daddr, ADDR_TYPE_IP, IP_ADDR_BITS, &p->iph->ip_dst,
IP_ADDR_LEN);
if(ip_whitelist)
{
if(s_ptrie_find_entry_byaddr(ip_whitelist, &saddr) ||
s_ptrie_find_entry_byaddr(ip_whitelist, &daddr))
{
/* let's bail, should probably set do_detect to 0 too... */
return;
}
}
if(ip_blacklist)
{
if((pn = s_ptrie_find_entry_byaddr(ip_blacklist, &saddr)))
{
bl_ref = (int)pn->data;
goto bl_detect;
}
else if((pn = s_ptrie_find_entry_byaddr(ip_blacklist, &daddr)))
{
bl_ref = (int)pn->data;
goto bl_detect;
}
goto bl_done;
bl_detect:
if(!noalerts)
SnortEventqAdd(GENERATOR_SPP_IPLIST, bl_ref, 1, 0, 0,
list_names[bl_ref], 0);
if(!nodrops && InlineMode())
InlineDrop(p);
}
}
bl_done:
return;
}
===============
--
Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
Sourcefire - Security for the Real World - http://www.sourcefire.com
Snort: Open Source IDP - http://www.snort.org
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
Martin Roesch
Miller<eoin....@trojanedbinaries.com> wrote:
> Seems to work great with the goto's now (thanks!). =A0Very small/non
> functionality niggle with the output/alerting: Was wondering about this:
>
> static void ProcessArgs(char *args){
> snprintf(eventstr, STD_BUF, "Access attempt from %s blacklisted IP
> address", arg);
>
> "attempt from" might mean to some the src address is blacklisted. Since
> iplist fires on both src and dst maybe have something like:
>
> snprintf(eventstr, STD_BUF, "Communication with %s blacklisted IP
> address", arg);
>
> Might help thwart some potential confusion down the road.
Good point, I'll make the change.
Any stats on CPU usage? Did the gotos or different arrangement result
in any savings?
Marty
-- =
Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
Sourcefire - Security for the Real World - http://www.sourcefire.com
Snort: Open Source IDP - http://www.snort.org
---------------------------------------------------------------------------=
---
Enter the BlackBerry Developer Challenge =
This is your chance to win up to $100,000 in prizes! For a limited time, =
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize=
=
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Snort-users mailing list
Snort...@lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
Eoin Miller
functionality niggle with the output/alerting: Was wondering about this:
static void ProcessArgs(char *args){
snprintf(eventstr, STD_BUF, "Access attempt from %s blacklisted IP
address", arg);
"attempt from" might mean to some the src address is blacklisted. Since
iplist fires on both src and dst maybe have something like:
snprintf(eventstr, STD_BUF, "Communication with %s blacklisted IP
address", arg);
Might help thwart some potential confusion down the road.
--
Eoin Miller
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Snort-users mailing list
Snort...@lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
Eoin Miller
> On Thu, Jul 9, 2009 at 9:34 AM, Eoin
> Miller<eoin....@trojanedbinaries.com> wrote:
>
> Good point, I'll make the change.
>
> Any stats on CPU usage? Did the gotos or different arrangement result
> in any savings?
>
>
> Marty
>
>
>
for some reason? These two processes were started within a second of
each other. The iplist with goto's ends up using slightly more time
after running for a few hours:
%CPU %MEM TIME+
COMMAND
54 3.6 58:09.50 snort -c /etc/snort/snort-goto-yes.conf -l
/root/goto-yes/log/ -A fast
26 3.6 54:21.04 snort -c /etc/snort/snort-goto-no.conf -l
/root/goto-no/log/ -A fast
Performance graphs are pretty similiar, there was a bit of a spike in
the version that is NOT using the goto's at one point. But overall the
non-goto version appears to be more streamlined ever so slightly:
http://trojanedbinaries.com/security/snort/cpu-goto-vs-original.png
Color Lines = goto version
Black Lines = without goto's
Not exactly what I was expecting. Also, since we are not using the
whitelisting functionality I can't say that there isn't an increase in
performance in that aspect, I would expect there to be one.
Martin Roesch
Miller<eoin....@trojanedbinaries.com> wrote:
> Looks like the gotos actually end up using slightly more processing time
> for some reason? These two processes were started within a second of
> each other. The iplist with goto's ends up using slightly more time
> after running for a few hours:
>
>
> COMMAND
>
> =A054 =A03.6 =A058:09.50 snort -c /etc/snort/snort-goto-yes.conf -l
> /root/goto-yes/log/ -A fast
> =A026 =A03.6 =A054:21.04 snort -c /etc/snort/snort-goto-no.conf -l
> /root/goto-no/log/ -A fast
>
> Performance graphs are pretty similiar, there was a bit of a spike in
> the version that is NOT using the goto's at one point. But overall the
> non-goto version appears to be more streamlined ever so slightly:
>
> http://trojanedbinaries.com/security/snort/cpu-goto-vs-original.png
>
> Black Lines =3D without goto's
>
> Not exactly what I was expecting. Also, since we are not using the
> whitelisting functionality I can't say that there isn't an increase in
> performance in that aspect, I would expect there to be one.
Great data, thanks for that.
What are the specs of the box you're running this on? You're seeing
~450Mbps of sustained traffic on the link?
Marty
-- =
Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
Sourcefire - Security for the Real World - http://www.sourcefire.com
Snort: Open Source IDP - http://www.snort.org
---------------------------------------------------------------------------=
---
Enter the BlackBerry Developer Challenge =
This is your chance to win up to $100,000 in prizes! For a limited time, =
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize=
=
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Snort-users mailing list
Snort...@lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
Eoin Miller
> On Thu, Jul 9, 2009 at 3:03 PM, Eoin
> Miller<eoin....@trojanedbinaries.com> wrote:
>
>> Looks like the gotos actually end up using slightly more processing time
>> for some reason? These two processes were started within a second of
>> each other. The iplist with goto's ends up using slightly more time
>> after running for a few hours:
>>
>>
>> COMMAND
>>
>> 54 3.6 58:09.50 snort -c /etc/snort/snort-goto-yes.conf -l
>> /root/goto-yes/log/ -A fast
>> 26 3.6 54:21.04 snort -c /etc/snort/snort-goto-no.conf -l
>> /root/goto-no/log/ -A fast
>>
>> Performance graphs are pretty similiar, there was a bit of a spike in
>> the version that is NOT using the goto's at one point. But overall the
>> non-goto version appears to be more streamlined ever so slightly:
>>
>> http://trojanedbinaries.com/security/snort/cpu-goto-vs-original.png
>>
>>
>> Not exactly what I was expecting. Also, since we are not using the
>> whitelisting functionality I can't say that there isn't an increase in
>> performance in that aspect, I would expect there to be one.
>>
>
> Great data, thanks for that.
>
> What are the specs of the box you're running this on? You're seeing
> ~450Mbps of sustained traffic on the link?
>
> Marty
>
>
>
quad proc dual core AMD Operton 2.4GHz. From /proc/cpuinfo (truncated
for brevity):
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 65
model name : Dual-Core AMD Opteron(tm) Processor 8216
stepping : 3
cpu MHz : 2400.085
cache size : 1024 KB
I can toss you a copy of the snort.stats file from the goto and non-goto
instances if that would help.
--
Eoin Miller
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Snort-users mailing list
Snort...@lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive: