Blocking shifty VPN providers with OpenAppID/Snort
A Former User last edited by
I am attempting to block a VPN app on my network that utilizes multiple countries/ip addresses/ports. I have tried tracking/blocking the ip networks via a firewall alias, but the ip addresses constantly change. The client app also automatically detects via ICMP requests when I block its most commonly used port and reverts to Port 443, which is a huge pain.
Furthermore, the app does not use a named service to handle connection setup or persist connections. It is all ip addresses, which as far as I can tell, change regularly too. Therefore, it passes right through my dns blacklisting on unbound. Short of blocking essential network services, this app cannot be blocked.
I researched OpenAppID as a solution and I see that it has a lot of promise to potentially solve my problem. I installed snort with only the openappid rules enabled so far. No problems there. However, through my research, I noticed there was a lot of interest in 2014 when it was open sourced, but after that community support/interest seems to have trickled out. Is this the case?
Due to lack of documentation, outside of the developer guide on the snort website, I am having trouble wrapping my head around how I can detect and block this VPN.
I did a packet capture of a connection setup and teardown, then analyzed it with wireshark. I did notice some similarities in the data, but I feel like I am missing something about how all this works. I am a developer for a living, so writing this rule isn't the issue so much as how to tackle the underlying problem itself so I don't code myself down a rabbit hole.
Can anyone provide some insight into how you would approach this problem?
bmeeks last edited by bmeeks
The app you describe seems specifically designed to thwart attempts at detection/blocking. You might not win this battle with technology. If we are talking a corporate network environment, perhaps getting buy-in from management for them to use the threat of termination of employees for improper app usage is a better answer?? Where I worked before retirement, we all had to sign a document acknowledging that we understood the potential consequences of improper company network usage. This could involve termination. This threat kept 99% of the employees in line, and then that random 1% who pushed the rules too far did get terminated for their risk taking.
boobletins last edited by boobletins
You might look at JA3 hashing, but you should know that if they are using a common SSL/TLS implementation you could end up blocking more traffic than intended.
Another option would be to simply IP ban any machine sending the initial ICMP request (to what I presume is a non-standard port) and let HR/IT handle it from there.
Another would be to identify the service provider, read their documentation to discover how they go about avoiding detection, and then block based on that documentation (or an analysis of the installation from a VM). There is a way they are using C&C servers or hard-coding to move the IPs around just like any malware, and you should be able to detect it with enough knowledge about how it's updating.
bmeeks last edited by
What is your network environment? By that I mean is it a typical corporate or business network? Is it something like a school or college campus network?
In other words, is it a set up where you could really lock down important network glue such as DNS? If you provide your own internal DNS server, then you can set up pfSense to redirect all DNS traffic to your internal host. That would shutdown at least one covert communications channel (UDP port 53).
You could use a web proxy to intercept all HTTP and HTTPS traffic. If you have control of the configuration of machines behind your firewall, then you could place certificates on them and use MITM technology to enable inspection of even encrypted web traffic via the proxy. That would shutdown two other communication holes (HTTP and HTTPS). Finally, you could simply drop all outbound ICMP requests except those to known safe targets like google.com or something. That way users could test basic connetivity if necessary, but only with known safe hosts. Those users that tried ICMP with other hosts could be reported to the proper departments as @boobletins suggested for possible disciplanary action.