Het probleem
Recentelijk heb ik Suricata als IPS/IDS op Ubuntu 18.04 LTS in mijn thuisnetwerk draaien. Alles lijkt naar behoren te werken echter ondervind ik problemen wanneer ik "suricata-update" vanaf localhost uitvoer. Er wordt verbinding gemaakt met de externe server, de nieuwe ruleset wordt gedownload en vervolgens blijft de verbinding hangen.
Als ik Suricata afsluit (zodat deze niet het netwerkverkeer analyseert tijdens het updaten) en vervolgens wederom "suricata-update" start wordt het proces zonder problemen doorlopen. Na wat netwerkverkeer te hebben gecaptured lijkt Suricata invloed te hebben op de manier waarop TCP-verbindingen worden beeïndigd waardoor deze niet op de juiste manier worden afgesloten.
Configuratie
Hardware:
Omdat ik verder op mijn netwerk geen (merkbare) problemen ondervind heb ik het netwerkverkeer gecaptured wanneer Suricata was ingeschakeld en wanneer deze was uitgeschakeld. Hierbij viel op dat de TCP-sessie op een andere manier wordt beeïndigd dan wanneer Suricata is ingeschakeld:
Suricata Uitgeschakeld
Suricata Ingeschakeld
(Voorlopige) conclusie
Wanneer Suricata dus is uitgeschakeld verstuurt de server een FIN waarna de client reageert met ACK/RST. In dit geval wordt de verbinding afgesloten en zijn er geen problemen.
Wanneer Suricata is ingeschakeld verstuurt de client een FIN waarop de server reageert met FIN/ACK waarna hij vervolgens wacht op de laatste ACK van de client die nooit wordt verstuurd. Hierdoor blijft de verbinding hangen.
Wat kan dit gedrag veroorzaken?
Recentelijk heb ik Suricata als IPS/IDS op Ubuntu 18.04 LTS in mijn thuisnetwerk draaien. Alles lijkt naar behoren te werken echter ondervind ik problemen wanneer ik "suricata-update" vanaf localhost uitvoer. Er wordt verbinding gemaakt met de externe server, de nieuwe ruleset wordt gedownload en vervolgens blijft de verbinding hangen.
Als ik Suricata afsluit (zodat deze niet het netwerkverkeer analyseert tijdens het updaten) en vervolgens wederom "suricata-update" start wordt het proces zonder problemen doorlopen. Na wat netwerkverkeer te hebben gecaptured lijkt Suricata invloed te hebben op de manier waarop TCP-verbindingen worden beeïndigd waardoor deze niet op de juiste manier worden afgesloten.

Configuratie
Hardware:
- Zotac Nano CI327
- https://www.zotac.com/us/product/mini_pcs/ci327-nano
- Ubuntu 18.04
- Kernel 4.15.0-33-generic #36-Ubuntu SMP
- Suricata 4.0.5
- IPS (nfqueue) mode
- Er worden alleen alerts gegenereerd, er wordt niets geblockt (dit werkt overigens wel)
Omdat ik verder op mijn netwerk geen (merkbare) problemen ondervind heb ik het netwerkverkeer gecaptured wanneer Suricata was ingeschakeld en wanneer deze was uitgeschakeld. Hierbij viel op dat de TCP-sessie op een andere manier wordt beeïndigd dan wanneer Suricata is ingeschakeld:
Suricata Uitgeschakeld
code:
1
2
3
4
5
6
7
8
9
10
11
| |Time | 192.168.0.253 | | | | 151.101.36.133 | |-------------------------------------------------------------------------- |0.000484564| ACK - Len: 2096 |Seq = 11862 Ack = 913 | |(50282) <------------------ (443) | |0.000056075| ACK | |Seq = 913 Ack = 13958 | |(50282) ------------------> (443) | |0.002127332| FIN, PSH, ACK - Len: 713 |Seq = 13958 Ack = 913 | |(50282) <------------------ (443) | |0.000752845| RST, ACK | |Seq = 913 Ack = 14672 | |(50282) ------------------> (443) | |
Suricata Ingeschakeld
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
| |Time | 192.168.0.253 | | | | 151.101.36.133 | --------------------------------------------------------------------------- |0.099170938 | PSH, ACK - Len: 746 |Seq = 3834 Ack = 917 | |(49584) <------------------ (443) | |0.001415054 | FIN, ACK | |Seq = 917 Ack = 4580 | |(49584) ------------------> (443) | |0.000362508 | FIN, PSH, ACK - Len: |Seq = 4580 Ack = 917 | |(49584) <------------------ (443) | |0.015219163 | ACK | |Seq = 4612 Ack = 918 | |(49584) <------------------ (443) | |0.221637496 | FIN, PSH, ACK - Len: |Seq = 4580 Ack = 918 | |(49584) <------------------ (443) | |0.223160755 | FIN, PSH, ACK - Len: |Seq = 4580 Ack = 918 | |(49584) <------------------ (443) | |0.462741260 | FIN, PSH, ACK - Len: |Seq = 4580 Ack = 918 | |(49584) <------------------ (443) | |0.901200343 | FIN, PSH, ACK - Len: |Seq = 4580 Ack = 918 | |(49584) <------------------ (443) | |1.783914410 | FIN, PSH, ACK - Len: |Seq = 4580 Ack = 918 | |(49584) <------------------ (443) | |3.588937004 | FIN, PSH, ACK - Len: |Seq = 4580 Ack = 918 | |(49584) <------------------ (443) | |7.172869978 | FIN, PSH, ACK - Len: |Seq = 4580 Ack = 918 | |(49584) <------------------ (443) | |14.335458930| FIN, PSH, ACK - Len: |Seq = 4580 Ack = 918 | |(49584) <------------------ (443) | |28.662381550| FIN, PSH, ACK - Len: |Seq = 4580 Ack = 918 | |(49584) <------------------ (443) | |
(Voorlopige) conclusie
Wanneer Suricata dus is uitgeschakeld verstuurt de server een FIN waarna de client reageert met ACK/RST. In dit geval wordt de verbinding afgesloten en zijn er geen problemen.
Wanneer Suricata is ingeschakeld verstuurt de client een FIN waarop de server reageert met FIN/ACK waarna hij vervolgens wacht op de laatste ACK van de client die nooit wordt verstuurd. Hierdoor blijft de verbinding hangen.
Wat kan dit gedrag veroorzaken?
