Hello,
When trying to scan the network, the network equipment detected tcp-syn traffic coming from my scanner’s ip. This came as a surprise to me, since I use alive tests: ICMP Ping, TCP-ACK Ping, ARP Ping, and the use of DoS checks is completely disabled in the Scan Config I use. What can cause this behavior?
Any help or pointers would be greatly appreciated!
Thank you!
Hi,
There are multiple reasons like, wrong scan config, wrong alive criteria, some VT´s sending it or just the volume of IPs due to your network size.
Hi, Lukas! I’m using “Full and Fast” config without any DoS, Brute Force and Defualt Accounts checks. I’m also using only ICMP, TCP-ACK and ARP Ping to config Alive tests.
Try ICMP only and not TCP or ARP ping … and see if this is better.
Could you please describe in more detail what exactly is and how to remove it? My hosts have ICMP disabled and I use it just in case)
Hello,
and welcome to this community forums.
Why do you think that a remote vulnerability scanner isn’t sending / shouldn’t send TCP-SYN packets during a TCP 3-Way Handshake to communicate with services on the remote target?
Hi, cfi!
I didn’t reveal the essence a bit. The fact is that my hardware detected a tcp-syn attack. This is not like setting up a regular tcp connection. What could it be?
And Thanks!)
The following existing documentation from 2 Read Before Use - OPENVAS SCAN – GOS 24.10.9 should give more insights:
Be aware of the following general side effects:
- Log and alert messages may show up on the target systems.
- Log and alert messages may show up on network devices, monitoring solutions, firewalls and intrusion detection and prevention systems.
- Firewall rules and other intrusion prevention measures may be triggered.
- Scans may increase latency on the target and/or the scanned network. In extreme cases, this may result in situations similar to a denial-of-service (DoS) attack.
- Scans may trigger bugs in fragile or insecure applications resulting in faults or crashes.
- Embedded systems and elements of operational technology with weak network stacks are especially subject to possible crashes or even broken devices.
- Logins (for example via SSH or FTP) are done against the target systems for banner-grabbing purposes.
- Probes via different protocols (for example, HTTP, FTP) are done to all exposed services for service detection.
- Scans may result in user accounts being locked due to the testing of default user name/password combinations.
The hardware might also mis-identify some of the requests as a tcp-syn attack.
Overall i wouldn’t worry much about this and this is a standard behavior when doing vulnerability scanning.
Thanks for the answer! Considering that I only use ICMP, TCP Ack, and ARP Ping for Alive tests, as well as DoS, Brute Force, and Default Accounts checks that are completely disabled, what other measures could you suggest to eliminate such situations?
what other measures could you suggest to eliminate such situations?
Why do you want to eliminate such situations? It is completely valid that a remote network vulnerability scanner is doing malicious attacking requests (even with DoS, Brute Force, and Default Accounts checks disabled) which could also trigger alerts on a target system and / or network equipment.
If you don’t want to see alerts on the network equipment you would probably need to either stop doing network vulnerability scanning or configure the network equipment adequately to filter out e.g. the IP of the scanner host from such alerts.
Edit: As mentioned earlier the alerts could be also false positives from network equipment side.
I understand all the possible costs. But scanning “drops” network equipment due to the powerful tcp-syn stream. I need to eliminate such situations so that the scans do not produce such an effect.
"It appears there is some confusion about the purpose and behavior of a TCP SYN scan. A SYN scan is a highly efficient technique for enumerating open TCP ports by initiating, but not completing, the three‑way handshake. This allows for rapid port discovery with minimal overhead.
Alternative methods—such as a full TCP connect scan—are also available and can be selected in Nmap’s configuration, and to my knowledge, in OpenVAS as well. Additionally, the scan concurrency level (i.e., number of simultaneous targets or probes) can be adjusted to match the requirements of the environment.
If a firewall is unable to handle the traffic generated by these standard reconnaissance techniques and becomes unstable or crashes, that indicates a fundamental performance or design limitation in the device. In such cases, the appropriate course of action is to replace the firewall with a more robust and properly engineered solution.
Eero
A TCP SYN occurs when scanning a target for open ports, and the default method is typically a TCP SYN scan. It consumes fewer resources than a full TCP connect scan.
Eero
It is quite difficult to give any real support here if information is only given step wise / in pieces:
I think this thread could largely benefit from some clear description.
Unfortunately i’m not able to give more support on this topic here and will stop to reply. But if the notes from @Eero doesn’t help and if adequate info / description is given maybe another community member can offer more help.
But in general i agree with @Eero, if the network equipment is breaking down during a standard “Full and Fast” scan there is an issue on network / hardware side which needs to be debugged and solved on that level.
From my perspective, this is a very clear and fairly typical issue — or at least it used to be back when firewalls didn’t have much processing power. A large number of concurrent connections fills up the firewall’s NAT session table, and the device either stops responding or crashes.
TCP SYN traffic is clearly Nmap-style port‑scanning activity.
The “TCP SYN attack” is most likely port‑scan traffic targeting a port that is closed on the firewall and therefore classified as ‘non‑valid traffic’.
‘Drops network equipment’ indicates that the firewall’s memory/CPU/session capacity is exhausted and the device reboots.
This kind of behaviour has been seen before.
Edit: In practice, the issue can be worked around by adjusting the Nmap settings inside OpenVAS, but that’s not really a proper solution. With enough budget you can simply get better firewalls, and if budget is limited, both OPNsense and pfSense can be run on inexpensive x86 hardware.
Eero
@Eero This is not my point 
What i have summarized is how the info was given step-wise / split in multiple posts in this thread after an answer was given, this is what i wanted to point out.
So something which had been initially only described as “network equipment detected tcp-syn traffic” got latern turned into a “scanning “drops” network equipment” which are two completely different things with different origin and which requires different answers.
Not all of us are professionals when it comes to vulnerability scanning, and I’m not sure that breaking the issue down any further would improve the situation. In my view, the problem has now been explained clearly enough, and as far as I’m concerned, the entire topic can be closed.
Eero
Yes, all what i’m pointing out is that providing a clear and descriptive initial question would prevent forwards and backwards like seen previously if some of the info (already known to the OP) is not immediately provided.
“Free support — you get exactly what you pay for.
And on that note, I’m cracking open a beer.”
Eero
I apologize for the fact that the question was not provided in a sufficiently detailed form. Anyway, I got a lot of answers.
P.S. It’s a little unclear to me how the topic of discussing a possible technical problem turned into a discussion of an “inaccurate description.” As far as I understand, the essence of the discussion lies in the consistent disclosure of the problem.
P.P.S. @Euro thanks for your answers too. They helped me realize that the answer to the question was hidden much deeper than I had imagined.