[7.910][BUG][FIXED] IPS updates still produce timeouts?

67ef1d: OK, so I understood v8's strategy of update patterns correctly and what I see should not happen at all.
As soon as I am at home again, I will send the results.

There could be a negative performance impact as I use a virtual environment, but an AMD x2 2.2GHz and 1GB RAM reserved for the VM should still be enough - IMHO.

regards,
Thomas

changing or excluding rules should no longer result in an ips restart, and the asg should not go offline.
Instead the ips is supposed to re-load its ruleset. This can take several minutes depending on cpu,
but the reload should not prevent packets from being processed.

Maybe I missed this new feature in the release notes but its most welcome feature if that is how it is going to work from now. But when you say that its processing packets although it might take a few minutes to restart, I don't really understand that. All traffic stops when the IPS is loading initially (old v7.xx behavior). Are you saying that now when the IPS is reloading due to adding more rules or disabling certain rules, the packets are flowing freely? I personally haven't observed that phenomenon.

OK, so I understood v8's strategy of update patterns correctly and what I see should not happen at all.
As soon as I am at home again, I will send the results.

I will be interested in knowing the results also. I almost hate touching IPS once everything is up and running because of the way it usually stops all traffic. From what I understand now, changing any rules should have no impact on the traffic at all??? Which means we are vulnerable to attacks during that time (hypothetically)??? or if we have a bad up2date the traffic will keep flowing although snort is stuck in reload phase???

Hi t-work,
1gb on v8b will be marginal, you should at least allow 1.5gb


Ian M

Just to prove the point I deleted an IPS rule that I have had disabled since v7.xx. My ASG went off-line for about 2 minutes.
I couldn't connect to the web, review existing pages.

I also received an e-mail advice that snort wasn't running and was restarted.

Hi,

here I have the trace. Hope it helps.

regards,
Thomas

I almost hate touching IPS once everything is up and running because of the way it usually stops all traffic. From what I understand now, changing any rules should have no impact on the traffic at all??? Which means we are vulnerable to attacks during that time (hypothetically)??? or if we have a bad up2date the traffic will keep flowing although snort is stuck in reload phase???

No, the ips is not "switched off".
There are 3 different kinds of ips related reloads, which all cause a full stop/start cycle in V7:
1. Adding/removing/Changing ips exceptions. Does not cause any IPS restart.
2. Changing rules, modifying rules, etc. Causes an IPS reload. As of Version 2.5.0, snort supports a "soft" reload mode, where the rule parsing/building is done in a separate thread.
While the reload thread parses/builds the new ruleset, the main thread keeps processing packets using the old rules.
Once the reload thread finished, the main thread switches to the new one (this takes effect immediately).
3. Pattern up2dates. These usually result in changes to (binary) plugins. Updating those "on the fly" is not supported yet. Thus a "temporary" snort is started (which uses the new ruleset). Once the new instance is up, packets are routed to this temporary instance and the main snort
does the V7 "stop/start" cycle. Once that completes, the temporary snort shuts down and packets are processed by the main one.

So, to summarize, the ASG should no longer be offline for prolonged periods during ips rule changes.

here I have the trace. Hope it helps.

Sorry, no, it doesn't, because the trace says its working [:S]

10507 sendmsg(7, {msg_name(12)
10507 recvmsg(7, 0xffea5778, 0)         = ? ERESTARTSYS (To be restarted)
10507 --- SIGHUP (Hangup) @ 0 (0) ---

This is the "please reload the ruleset" trigger.
The main thread continues packet processing:

10507 recvmsg(7,
10507 sendmsg(7, 
10507 recvmsg(7,
10507 sendmsg(7, 
10507 recvmsg(7,  
10508 send(3, "May 12 02:13:04 snort[10507]"..., 36, MSG_NOSIGNAL) = 36

Here the reload thread kicks in (different thread ID).

and here, we see the main thread doing packet processing:

10507  {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\220\0\0\0\0\3\0\0\0\0\0\0\0\0\0\0\2\0\0\0\v\0\1\0\0\ts\370\10\0\2\0"..., 65536}], msg_controllen=0, msg_flags=0}, 0) = 144

The last message from the reload thread happened here:
10508 send(3, "May 12 02:13:16 snort[10507]"..., 103, MSG_NOSIGNAL) = 103

Which confuses me even more, because thats just 12 seconds after the reload thread
started.

Did you cancel the strace after the asg came back online or earlier?
Could I get the ips.log from the time period in question? Maybe that might help me to figure out what is going wrong...

I also received an e-mail advice that snort wasn't running and was restarted. 

Uh. Bad [:(]
Could you send the ips.log from the time when that happened?
If that does not contain useful info, could you also try to run the strace command
i posted, reproduce the issue and send me the output?

Thanks a lot!

I almost hate touching IPS once everything is up and running because of the way it usually stops all traffic. From what I understand now, changing any rules should have no impact on the traffic at all??? Which means we are vulnerable to attacks during that time (hypothetically)??? or if we have a bad up2date the traffic will keep flowing although snort is stuck in reload phase???

No, the ips is not "switched off".
There are 3 different kinds of ips related reloads, which all cause a full stop/start cycle in V7:
1. Adding/removing/Changing ips exceptions. Does not cause any IPS restart.
2. Changing rules, modifying rules, etc. Causes an IPS reload. As of Version 2.5.0, snort supports a "soft" reload mode, where the rule parsing/building is done in a separate thread.
While the reload thread parses/builds the new ruleset, the main thread keeps processing packets using the old rules.
Once the reload thread finished, the main thread switches to the new one (this takes effect immediately).
3. Pattern up2dates. These usually result in changes to (binary) plugins. Updating those "on the fly" is not supported yet. Thus a "temporary" snort is started (which uses the new ruleset). Once the new instance is up, packets are routed to this temporary instance and the main snort
does the V7 "stop/start" cycle. Once that completes, the temporary snort shuts down and packets are processed by the main one.

So, to summarize, the ASG should no longer be offline for prolonged periods during ips rule changes.

here I have the trace. Hope it helps.

Sorry, no, it doesn't, because the trace says its working [:S]

10507 sendmsg(7, {msg_name(12)
10507 recvmsg(7, 0xffea5778, 0)         = ? ERESTARTSYS (To be restarted)
10507 --- SIGHUP (Hangup) @ 0 (0) ---

This is the "please reload the ruleset" trigger.
The main thread continues packet processing:

10507 recvmsg(7,
10507 sendmsg(7, 
10507 recvmsg(7,
10507 sendmsg(7, 
10507 recvmsg(7,  
10508 send(3, "May 12 02:13:04 snort[10507]"..., 36, MSG_NOSIGNAL) = 36

Here the reload thread kicks in (different thread ID).

and here, we see the main thread doing packet processing:

10507  {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\220\0\0\0\0\3\0\0\0\0\0\0\0\0\0\0\2\0\0\0\v\0\1\0\0\ts\370\10\0\2\0"..., 65536}], msg_controllen=0, msg_flags=0}, 0) = 144

The last message from the reload thread happened here:
10508 send(3, "May 12 02:13:16 snort[10507]"..., 103, MSG_NOSIGNAL) = 103

Which confuses me even more, because thats just 12 seconds after the reload thread
started.

Did you cancel the strace after the asg came back online or earlier?
Could I get the ips.log from the time period in question? Maybe that might help me to figure out what is going wrong...

I also received an e-mail advice that snort wasn't running and was restarted. 

Uh. Bad [:(]
Could you send the ips.log from the time when that happened?
If that does not contain useful info, could you also try to run the strace command
i posted, reproduce the issue and send me the output?

Thanks a lot!