Vulnerability scan being dropped
-
Erin0
- OpenVpn Newbie
- Posts: 1
- Joined: Thu Jun 24, 2021 5:19 pm
Vulnerability scan being dropped
Hello... We have a third party vulnerability scan done periodically. During this scan they reported that the port exposed to the internet dropped during the scan as if an IDS kicked in and blocked them. I have verified on the firewall this is not the case, both through config and logs, and was wondering if the OpenVPN Access Server has this type of functionality. Can the OpenVPN Access Server detect and block vulnerability type scans? Thank you
-
chilinux
- OpenVPN Power User
- Posts: 156
- Joined: Thu Mar 28, 2013 8:31 am
Re: Vulnerability scan being dropped
As far as I know, there is no IDS is built into OpenVPN AS.
Did they give any further details as to exactly what they were seeing when they decided they were being blocked? Were they get TCP RST packets? ICMP Host Unreachable packets? ICMP Port Unreachable packets? They thought they were being silently dropped?
It may be possible they were expecting to see more exposed ports than they got back. By default, the OpenVPN AS services should only show up on two ports for a TCP scan (443 and 943) and only a single port for a UDP scan (1194). It is possible to reconfigure the product so TCP port 943 also is not exposed to the internet such as putting it on an intranet address.
By default the OpenVPN AS web server allows connections from web clients using TLS version 1.1 or higher. For OS distributions that use OpenSSL version 1.0.x, this can be raised to require TLS v1.2 or higher. And for OS distributions that provide OpenSSL 1.1.x, this can be raised to require TLS v1.3.
If the third party vulnerability scan tool doesn't meet with the minimal TLS version requirement set in OpenVPN AS, it tool's attempt perform a TLS handshake will fail and be disconnected. Unless you are catering to users on end of life operating systems (like WIndows 7), it should be safe to set TLS 1.3 as the minimum since all major supported OS and browsers that have been kept up to date support it at this point. But if they are using a scanning tool that doesn't yet support the require TLS version they may see that as if it is an IDS blocking it.
Lastly, the Zope web server used by OpenVPN AS may not honor HTTP "keep-alive" sessions in all the situations that other major web servers do (such as Apache, NGINX or IIS). Most robust HTTP clients (such as all major web browsers) will detect when keep-alive is not honored between requests and simply reconnect accordingly. If their vulnerability scan tools aren't as robust, they may treat that situation as being dropped by an IDS.
Without more information that gives specifics, it is hard to pin-point exactly what we are discussing and what might be causing the behavior they have vaguely indicated takes place.
Did they give any further details as to exactly what they were seeing when they decided they were being blocked? Were they get TCP RST packets? ICMP Host Unreachable packets? ICMP Port Unreachable packets? They thought they were being silently dropped?
It may be possible they were expecting to see more exposed ports than they got back. By default, the OpenVPN AS services should only show up on two ports for a TCP scan (443 and 943) and only a single port for a UDP scan (1194). It is possible to reconfigure the product so TCP port 943 also is not exposed to the internet such as putting it on an intranet address.
By default the OpenVPN AS web server allows connections from web clients using TLS version 1.1 or higher. For OS distributions that use OpenSSL version 1.0.x, this can be raised to require TLS v1.2 or higher. And for OS distributions that provide OpenSSL 1.1.x, this can be raised to require TLS v1.3.
If the third party vulnerability scan tool doesn't meet with the minimal TLS version requirement set in OpenVPN AS, it tool's attempt perform a TLS handshake will fail and be disconnected. Unless you are catering to users on end of life operating systems (like WIndows 7), it should be safe to set TLS 1.3 as the minimum since all major supported OS and browsers that have been kept up to date support it at this point. But if they are using a scanning tool that doesn't yet support the require TLS version they may see that as if it is an IDS blocking it.
Lastly, the Zope web server used by OpenVPN AS may not honor HTTP "keep-alive" sessions in all the situations that other major web servers do (such as Apache, NGINX or IIS). Most robust HTTP clients (such as all major web browsers) will detect when keep-alive is not honored between requests and simply reconnect accordingly. If their vulnerability scan tools aren't as robust, they may treat that situation as being dropped by an IDS.
Without more information that gives specifics, it is hard to pin-point exactly what we are discussing and what might be causing the behavior they have vaguely indicated takes place.