[Oisf-users] Suricata "causing" alerts?

[James Moe]

Hello,
  suricata 2.0.7
  linux 3.16.7-21-desktop x86_64

  Suricata seems to be creating alerts to log.
  A backup job runs every morning at 1:20am, copying whatever has
changed on the host to the backup system. It generates an explosion of
"invalid ack" (2210029, 2210045) and "retransmission packet before
last ack" (2210020) log entries. I have set a threshold on these so
the log file does not consume all of the free space.
  The alerts continued until suricata was restarted at 10:00am. Then
all is quiet until 1:20am the next morning.
  The fact that the alerts stop after the restart is quite suspicious.
I had thought it was because the gro feature was set in the network
interface. As noted in the verbose output below, that is not the case
here.

  What else could cause suricata to generate these alerts until a restart?

----[ typical alerts ]----
05/09/2015-22:03:32.252659  [**] [1:2210021:2] SURICATA STREAM
ESTABLISHED retransmission packet before last ack [**]
[Classi05/11/2015-09:52:56.456176  [**] [1:2210029:1] SURICATA STREAM
ESTABLISHED invalid ack [**] [Classification: (null)] [Priority: 3]
{TCP} 192.168.69.245:2049 -> 192.168.69.246:956fication: (null)]
[Priority: 3] {TCP} 176.32.98.166:80 -> 192.168.69.246:33914
05/11/2015-10:01:59.731480  [**] [1:2210045:1] SURICATA STREAM Packet
with invalid ack [**] [Classification: (null)] [Priority: 3] {TCP}
192.168.69.245:2049 -> 192.168.69.246:956
----[ end ]----

----[ tail of verbose output ]----
11/5/2015 -- 10:02:21 - <Info> - Threshold config parsed: 2 rule(s) found
11/5/2015 -- 10:02:21 - <Info> - Core dump size set to unlimited.
11/5/2015 -- 10:02:21 - <Info> - fast output device (regular)
initialized: fast.log
11/5/2015 -- 10:02:21 - <Info> - drop output device (regular)
initialized: drop.log
11/5/2015 -- 10:02:21 - <Info> - Using 1 live device(s).
11/5/2015 -- 10:02:21 - <Info> - using interface eth0
11/5/2015 -- 10:02:21 - <Info> - Running in 'auto' checksum mode.
Detection of interface state will require 1000 packets.
11/5/2015 -- 10:02:21 - <Info> - Found an MTU of 1460 for 'eth0'
11/5/2015 -- 10:02:21 - <Info> - Set snaplen to 1476 for 'eth0'
11/5/2015 -- 10:02:21 - <Info> - Generic Receive Offload is unset on eth0
11/5/2015 -- 10:02:21 - <Info> - Large Receive Offload is unset on eth0
11/5/2015 -- 10:02:21 - <Info> - RunModeIdsPcapAutoFp initialised
11/5/2015 -- 10:02:21 - <Notice> - all 7 packet processing threads, 3
management threads initialized, engine started.
----[ end ]----





-- 
James Moe
moe dot james at sohnen-moe dot com
520.743.3936

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20150511/9fd4f118/attachment.pgp>