ICMP Echos from Boreas should use non zero id and seq. aka "Identifier" and "Sequence Number" from RFC 792 ICMP Echo. And see targets as alive.
Boreas uses identifier=0 seq=0 for ipv4 ICMP Echo requests during alive checks. Some environments appear to not like this. Despite being allowed by the spec, I think this behaviour is possibly at the least confusing since most ping tools increment the seq by one per message starting from 1, and have identifier > 0
This causes some environments to have all alive test fail. We are moving to "Consider Alive" however we think it benefits others to report this issue.
ping (on Ubuntu) appears to pick seq 1..n and identifier=some number above 0 thats from the kernel I believe.
When trying to debug this problem someone may attempt to use ping and because it uses a non 0 identifier and seq it will be difficult to debug when compared to the behaviour exhibited by boreas.
Actual behavior
The ICMP Echo for alive test uses identifier=0 seq=0.
Steps to reproduce
Start a scan which uses the default alive check of ICMP Echo.
Use tcpdump on the target. As such tcpdump -v icmp and (src 192.168.1.1 or dst 192.168.1.1) &
You will see
SENT (1.0342s) ICMP [192.168.1.30 > 192.168.1.1 Echo request (type=8/code=0) id=0 seq=0] IP [ttl=64 id=25987 iplen=28 ]
You will not receive a response if the environment does not appear to allow identifier = 0 Echos.
GVM versions
I recognize these are older but given the code appears to be unchanged in the last 3-4 years I think the problem still exists.
libgvm boreas: DEBUG:2024-04-12 22h38.28 utc:1055519: alive_detection_init: Initialise alive scanner.
libgvm boreas: DEBUG:2024-04-12 22h38.28 utc:1055519: alive_detection_init: Initialisation of alive scanner finished.
libgvm boreas:MESSAGE:2024-04-12 22h38.28 utc:1055519: Alive scan 07f6713f-3b46-4edb-b282-948aecfb4079 started: Target has 1 hosts
libgvm boreas: DEBUG:2024-04-12 22h38.30 utc:1055519: scan: all ping packets have been sent, wait a bit for rest of replies.
libgvm boreas: DEBUG:2024-04-12 22h38.31 utc:1055519: stop_sniffer_thread: Try to stop thread which is sniffing for alive hosts.
libgvm boreas: DEBUG:2024-04-12 22h38.33 utc:1055519: stop_sniffer_thread: pthread_join() returned PTHREAD_CANCELED.
libgvm boreas: DEBUG:2024-04-12 22h38.33 utc:1055519: stop_sniffer_thread: Stopped thread which was sniffing for alive hosts.
libgvm boreas:MESSAGE:2024-04-12 22h38.33 utc:1055519: Alive scan 07f6713f-3b46-4edb-b282-948aecfb4079 finished in 5 seconds: 0 alive hosts of 1.
libgvm boreas: DEBUG:2024-04-12 22h38.34 utc:1055519: get_host_from_queue: Boreas already finished scanning and we reached the end of the Queue of alive hosts.
Expected behavior
ICMP Echos from Boreas should use non zero id and seq. aka "Identifier" and "Sequence Number" from RFC 792 ICMP Echo. And see targets as alive.
Boreas uses identifier=0 seq=0 for ipv4 ICMP Echo requests during alive checks. Some environments appear to not like this. Despite being allowed by the spec, I think this behaviour is possibly at the least confusing since most ping tools increment the seq by one per message starting from 1, and have identifier > 0
Ipv6 echos appear to use 234 as the identifier.
This causes some environments to have all alive test fail. We are moving to "Consider Alive" however we think it benefits others to report this issue.
ping
(on Ubuntu) appears to pick seq 1..n and identifier=some number above 0 thats from the kernel I believe.When trying to debug this problem someone may attempt to use
ping
and because it uses a non 0 identifier and seq it will be difficult to debug when compared to the behaviour exhibited by boreas.Actual behavior
The ICMP Echo for alive test uses identifier=0 seq=0.
Steps to reproduce
Start a scan which uses the default alive check of ICMP Echo. Use tcpdump on the target. As such
tcpdump -v icmp and (src 192.168.1.1 or dst 192.168.1.1) &
You will see
SENT (1.0342s) ICMP [192.168.1.30 > 192.168.1.1 Echo request (type=8/code=0) id=0 seq=0] IP [ttl=64 id=25987 iplen=28 ]
You will not receive a response if the environment does not appear to allow identifier = 0 Echos.GVM versions
I recognize these are older but given the code appears to be unchanged in the last 3-4 years I think the problem still exists.
gsa: (gsad --version) We do not use gsa
gvm: (gvmd --version) Greenbone Vulnerability Manager 21.4.5~git-f27009b24-HEAD
openvas: (openvas --version) OpenVAS 21.4.0~git-32ad87a4-HEAD
gvm-libs: gvm-libs 21.4.4~git-59c8402c-HEAD
Environment
Operating system:
Installation method / source: (packages, source installation)
We run a mostly unmodified source install.
Logfiles