Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

vpn.drew.edu / vpn.uu.edu / vpn.valpo.edu (SonicWall) #14

Open
DimitriPapadopoulos opened this issue Jun 8, 2022 · 9 comments
Open

vpn.drew.edu / vpn.uu.edu / vpn.valpo.edu (SonicWall) #14

DimitriPapadopoulos opened this issue Jun 8, 2022 · 9 comments

Comments

@DimitriPapadopoulos
Copy link
Contributor

DimitriPapadopoulos commented Jun 8, 2022 •
edited
Loading

Gateway vpn.drew.eduis not detected:

$ what-vpn -v -K vpn.drew.edu

Sniffing vpn.drew.edu ...
  Is it AnyConnect/OpenConnect? connection error
  Is it Juniper/Pulse? no match
  Is it PAN GlobalProtect? no match
  Is it Barracuda? no match
  Is it Check Point? timeout
  Is it SSTP? connection error
  Is it OpenVPN? no match
  Is it Fortinet? no match
  Is it Array Networks? no match
  Is it F5 BigIP? no match
  Is it SonicWall NX? no match
  Is it Aruba VIA? no match
  => timeout
$

It is clearly a SonicWall VPN:
https://vpn.drew.edu
@DimitriPapadopoulos
Copy link
Contributor Author

DimitriPapadopoulos commented Jun 8, 2022 •
edited
Loading

The timeout originates here:

what-vpn/what_vpn/sniffers.py

Line 106 in d76f7aa

resp = conn.recv()

We shouldn't need to pass the -K option, it should be on by default.

@DimitriPapadopoulos
Copy link
Contributor Author

DimitriPapadopoulos commented Jun 8, 2022 •
edited
Loading

Is it expected that path /sslvpnclient?launchplatform=mac&neProto=3&supportipv6=yes returns a 404?

404

@DimitriPapadopoulos DimitriPapadopoulos changed the title vpn.drew.edu vpn.drew.edu / vpn.valpo.edu Jun 8, 2022
@DimitriPapadopoulos
Copy link
Contributor Author

DimitriPapadopoulos commented Jun 8, 2022 •
edited
Loading

Gateway vpn.valpo.edu is not detected either:

$ what-vpn -v vpn.valpo.edu

Sniffing vpn.valpo.edu ...
  Is it AnyConnect/OpenConnect? no match
  Is it Juniper/Pulse? no match
  Is it PAN GlobalProtect? no match
  Is it Barracuda? no match
  Is it Check Point? no match
  Is it SSTP? no match
  Is it OpenVPN? no match
  Is it Fortinet? no match
  Is it Array Networks? no match
  Is it F5 BigIP? no match
  Is it SonicWall NX? no match
  Is it Aruba VIA? no match
  => no match
$

Yet it is SonicWall according to the HTML code of https://vpn.valpo.edu/spog/welcome:

<!DOCTYPE html><html><head><meta charset=utf-8><meta name=viewport content="width=device-width,initial-scale=1"><meta name=brandName content="SonicWall"><meta name=modelNameShort content="SMA">

@DimitriPapadopoulos DimitriPapadopoulos changed the title vpn.drew.edu / vpn.valpo.edu vpn.drew.edu / vpn.valpo.edu (SonicWall) Jun 8, 2022
@DimitriPapadopoulos DimitriPapadopoulos changed the title vpn.drew.edu / vpn.valpo.edu (SonicWall) vpn.drew.edu / vpn.valpo.edu / vpn.uu.edu (SonicWall) Jun 8, 2022
@DimitriPapadopoulos DimitriPapadopoulos changed the title vpn.drew.edu / vpn.valpo.edu / vpn.uu.edu (SonicWall) vpn.drew.edu / vpn.uu.edu / vpn.valpo.edu (SonicWall) Jun 8, 2022
@dlenski
Copy link
Owner

dlenski commented Jun 8, 2022

We shouldn't need to pass the -K option, it should be on by default.

The use case for this option is to do what-vpn hundreds or thousands of potential servers as in the "surveys" described in the README.

If you get timeouts/SSL errors/DNS errors, you don't want to waste time re-trying TLS/HTTPS connections to such servers, in order to speed up the overall run.

In "normal" usage I don't think this behavior is desirable, since some servers have flaky behavior that will (for example) abruptly disconnect TLS sockets when they get HTTPS requests that they don't understand. This monstrosity is a chief offender.

@DimitriPapadopoulos
Copy link
Contributor Author

DimitriPapadopoulos commented Jun 8, 2022 •
edited
Loading

Same with vpn.uu.edu:

$ what-vpn -K -v vpn.uu.edu

Sniffing vpn.uu.edu ...
  Is it AnyConnect/OpenConnect? connection error
  Is it Juniper/Pulse? no match
  Is it PAN GlobalProtect? no match
  Is it Barracuda? no match
  Is it Check Point? timeout
  Is it SSTP? connection error
  Is it OpenVPN? no match
  Is it Fortinet? no match
  Is it Array Networks? no match
  Is it F5 BigIP? no match
  Is it SonicWall NX? connection error
  Is it Aruba VIA? no match
  => timeout
$

Again a SonicWall:

vpn uu edu

@DimitriPapadopoulos
Copy link
Contributor Author

DimitriPapadopoulos commented Jun 8, 2022 •
edited
Loading

About -K I am unable to understand the rationale for not making it the default.

For example, even if SonicWall detection was updated, the script would still fail with a timeout in Check Point detection before even making it to SonicWall detection:

$ what-vpn -v vpn.uu.edu

Sniffing vpn.uu.edu ...
  Is it AnyConnect/OpenConnect? connection error
  Is it Juniper/Pulse? no match
  Is it PAN GlobalProtect? no match
  Is it Barracuda? no match
  Is it Check Point? timeout
  => timeout (tried 5/12 sniffers)
$ 

$ what-vpn -K -v vpn.uu.edu

Sniffing vpn.uu.edu ...
  Is it AnyConnect/OpenConnect? connection error
  Is it Juniper/Pulse? no match
  Is it PAN GlobalProtect? no match
  Is it Barracuda? no match
  Is it Check Point? timeout
  Is it SSTP? connection error
  Is it OpenVPN? no match
  Is it Fortinet? no match
  Is it Array Networks? no match
  Is it F5 BigIP? no match
  Is it SonicWall NX? connection error
  Is it Aruba VIA? no match
  => timeout
$

@dlenski
Copy link
Owner

dlenski commented Jun 9, 2022

About -K I am unable to understand the rationale for not making it the default.

So you'd prefer to have the --keep-going-after-exception behavior as the default, but with a flag to the the opposite?

Perhaps --stop-after-exception to keep the current default behavior?

@DimitriPapadopoulos
Copy link
Contributor Author

DimitriPapadopoulos commented Jun 9, 2022 •
edited
Loading

I may be missing something, but it looks like failure on timeout in a sniffer may result in skipping all the following sniffers. That's not something we want. If so, yes, the default should be -K.

Actually, we should probably handle SSL exceptions and timeouts differently:

  • An SSL error in a sniffer will probably be followed by the same exception in the next sniffer. It doesn't make much sense to retry upon an SSL failure.
  • A timeout in the CheckPoint sniffer doesn't imply a timeout in the next sniffer, so we should try the next sniffer upon a timeout.

In short:

  • We should always try all sniffers in case of a timeout. I don't even see the need for an option to disable that, as it may result in false-negatives.
  • We shouldn't keep testing other sniffers in case of an SSL error. I don't see the need for an option to disable that.

@dlenski
Copy link
Owner

dlenski commented Jun 10, 2022

Actually, we should probably handle SSL exceptions and timeouts differently:

Agreed, but based on the practical experience of running this I think the default behavior should actually be reversed…

  • An SSL error in a sniffer will probably be followed by the same exception in the next sniffer. It doesn't make much sense to retry upon an SSL failure.

Many VPN servers are buggy and they don't really speak HTTP(S) in a general-purpose way. Some of them abruptly terminate TLS sockets or mis-encode their output, when they get HTTP requests that they don't understand… because they're aimed at different VPN protocols. (There's one related-ish case where we explicitly check for, and ignore, such misbehavior.)

If we give up after an SSL failure, we'll get some false negatives.

  • A timeout in the CheckPoint sniffer doesn't imply a timeout in the next sniffer, so we should try the next sniffer upon a timeout.

When doing a large "survey" run, the most common cause of a timeout is that the DNS name exists… but it isn't listening on the given port. That's going to repeat over and over.

Perhaps what we really need here are separate flags to --{give-up,keep-going}-after-timeout, ``--{give-up,keep-going}-after-ssl-errors`, and then we can argue about the sensible defaults :)

@DimitriPapadopoulos DimitriPapadopoulos mentioned this issue May 6, 2023
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@dlenski @DimitriPapadopoulos