1
Zenarmor (Sensei) / Re: Zenarmor - Syn flood has been detected.
« on: May 16, 2024, 10:31:38 am »
Hello,
I was able to go more deeper into this rabbit hole.
And if you are using NMAP it definitely triggers the synflood on ZenArmor as well it consumes syncache, after that memory saturation will happen each subsequent NMAP run. My observations:
NMAP run like these flags >
A. NMAP and OPN
- Scanning is done only on 1 IP at time fro ma range, there are no parallel probes ran
- The server where NMAP runs has only 4 services permitted (4 ports Ingress), rest is blocked
- When NMAP starts port scans, every session/packet that doesn't have one of these 4 destination ports is being blocked by OPN.
- NMAP sent only 1 probe for a working OPEN connection (permitted by OPN)
- If there is no reply for a probe, NMAP will sent 1 more retry (blocked by OPN)
- This is seen and confirmed by reviewing the OPNsense logs.
B. NMAP and Zenarmor
- Following up from A. ZenArmor will show in the logs vmstat that syncache is being massively consumed
- Within few seconds all syncache is being eaten UP and synflood message is triggered by ZenArmor
Now what I dont understand,
1. Why ZenArmor shows syncache is being eaten up. When only 4 Sessions/packets are being allowed by OPNsense and rest is dropped?
2. Shouldn't the FW protect against synflood specifically resources utilization if a synflood is happening?
3. Shouldn't ZenArmor, recognize this as Port Scanning rather than a Syn flood attack?
For me is extremely weird (I dont understand) that NMAP triggers syncache consumption and a synflood on ZenARmor, which after wards start to consume RAM, as most of the probes are being blocked by OPN forehand.
Important:
When NMAP ran with addition flag -f the above behavior, no syncache utilization or synflood is being seen or reported by Zenarmor.
For me here are like two problems:
1. Why Synflood is triggered from NMAP when most of the services being blocked + it is not recognized as port scan
2. Zenarmor doesn't looks like does anything if a scan probe is fragmented
Regards,
S.
I was able to go more deeper into this rabbit hole.
And if you are using NMAP it definitely triggers the synflood on ZenArmor as well it consumes syncache, after that memory saturation will happen each subsequent NMAP run. My observations:
NMAP run like these flags >
Code: [Select]
nmap -sS -p-
A. NMAP and OPN
- Scanning is done only on 1 IP at time fro ma range, there are no parallel probes ran
- The server where NMAP runs has only 4 services permitted (4 ports Ingress), rest is blocked
- When NMAP starts port scans, every session/packet that doesn't have one of these 4 destination ports is being blocked by OPN.
- NMAP sent only 1 probe for a working OPEN connection (permitted by OPN)
- If there is no reply for a probe, NMAP will sent 1 more retry (blocked by OPN)
- This is seen and confirmed by reviewing the OPNsense logs.
B. NMAP and Zenarmor
- Following up from A. ZenArmor will show in the logs vmstat that syncache is being massively consumed
- Within few seconds all syncache is being eaten UP and synflood message is triggered by ZenArmor
Now what I dont understand,
1. Why ZenArmor shows syncache is being eaten up. When only 4 Sessions/packets are being allowed by OPNsense and rest is dropped?
2. Shouldn't the FW protect against synflood specifically resources utilization if a synflood is happening?
3. Shouldn't ZenArmor, recognize this as Port Scanning rather than a Syn flood attack?
For me is extremely weird (I dont understand) that NMAP triggers syncache consumption and a synflood on ZenARmor, which after wards start to consume RAM, as most of the probes are being blocked by OPN forehand.
Important:
When NMAP ran with addition flag -f the above behavior, no syncache utilization or synflood is being seen or reported by Zenarmor.
For me here are like two problems:
1. Why Synflood is triggered from NMAP when most of the services being blocked + it is not recognized as port scan
2. Zenarmor doesn't looks like does anything if a scan probe is fragmented
Regards,
S.