<html><head></head><body>Is Af-Packet like a layer 2 switch in the sense of forwarding packets?<div><br></div><div>Could it be possible that a forwarding table got corrupted so the software did not know where to send some packets? Because based on the symptoms I shared before, it appears some traffic was making it through. Ping was reported to be working the whole time but more complex packets were having trouble.</div><div><br></div><div>Thanks.<br><br><font face="Arial"><font size="2">Leonard</font><br></font><br><br><br><div><strong>
From:
</strong>
Peter Manev <petermanev@gmail.com>
<br>
<strong>
To:
</strong>
Victor Julien <lists@inliniac.net>
<br>
<strong>
Cc:
</strong>
"oisf-users@lists.openinfosecfoundation.org" <oisf-users@lists.openinfosecfoundation.org>
<br>
<strong>
Sent:
</strong>
1/27/2016 4:16 AM
<br>
<strong>
Subject:
</strong>
Re: [Oisf-users] Suricata and DDoS Attack
<br><br><blockquote class="mori" style="margin:0 0 0 .8ex;border-left:1px solid #CCC;padding-left:1ex;">On Wed, Jan 27, 2016 at 9:59 AM, Victor Julien <lists@inliniac.net> wrote:<br>> On 27-01-16 03:00, Leonard Jacobs wrote:<br>>><br>>> With one of the networks we monitor, the ISP was under a DDoS attack<br>>> yesterday. It appears that Suricata kept functioning the whole time the<br>>> attack was occurring because we kept seeing events. However, somewhere<br>>> along the way the IPS appeared to lock up. The appliance was rebooted<br>>> and everything came back to normal.<br><br><br>What do you mean by "lock up" - process stops responding or it<br>segfaults or something else?<br>Anything strange in the last update in stats.log?<br><br>>><br>>> We run the IPS in AF-Packet mode. The actual network we monitor was not<br>>> directly under the DDoS attack but slow Internet response times was<br>>> experienced.<br>>><br>>> Is it possible that Suricata was experiencing some resource exhaustion?<br>>> Logs did not show anything wrong.<br>><br>><br>> Hard to say without more info. If it would happen again before killing<br>> Suricata, could you attach to with gdb and create a back trace?<br>><br>> gdb --attach $(pidof suricata)<br>><br>> then inside gdb<br>><br>> (gdb) set logging on<br>> (gdb) thread apply all bt<br>><br>><br>> Then press return till you get back to the prompt. Then type quit. This<br>> process has created a gdb.txt file containing a copy of the output that<br>> describe the state of the different threads. You can then attach this file<br>> to the bug report.<br>><br>> --<br>> ---------------------------------------------<br>> Victor Julien<br>> http://www.inliniac.net/<br>> PGP: http://www.inliniac.net/victorjulien.asc<br>> ---------------------------------------------<br>><br>> _______________________________________________<br>> Suricata IDS Users mailing list: oisf-users@openinfosecfoundation.org<br>> Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/<br>> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users<br>> Suricata User Conference November 9-11 in Washington, DC:<br>> http://oisfevents.net<br><br><br><br>-- <br>Regards,<br>Peter Manev<br>_______________________________________________<br>Suricata IDS Users mailing list: oisf-users@openinfosecfoundation.org<br>Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/<br>List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users<br>Suricata User Conference November 9-11 in Washington, DC: http://oisfevents.net</blockquote></div></div></body></html>