Blocking shifty VPN providers with OpenAppID/Snort
-
Hey All,
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?
-
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.
-
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.
-
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.
-
What you have is a botnet with a brute force attack and or tcp flood attacks. Only enterprise class firewalls have this feature, ie sophos, fortinet, and there's no guarantee it will work to stop it. But I found ways.
As for ISP not detecting. The ISP or most of them don't care to block or firewall any attacks from their network outbound. Most don't even have a firewall for servers they colocate for clients. Their excuse is to not block any colocation client traffic which is complete nonsense. They didn't even know if it was a server or a coworkers desktop inside frontier. Eg Frontier networks, they don't protect any customer who buys business internet from them in which botnets source from their networks. They claim to have no department to take care of a rogue hacker server in their network. They wash themselves of liability. In turn advocating hackers in their network. Frontier ISP claimed we need to change away from default ports for services which won't prevent bots from trying every port.
So we had to buy both software on the server and dual firewall updates that support botnet and tcp flooding. Which are off by default. That the tech support didn't even know about what it was. Even after enabling it. It stopped some but not all of the attack. Maybe another brand firewall would have been more effective. It cost us thousands. So any normal non business and business customer are at complete risk of attacks from this server and servers listed in my logs still today. Shocking but disgusting.
The sad thing was, that if I didn't turn in 'audit login' information on the servers then 1 million more attempts would have made it thru the "pseudo firewall"
We called fortinet and sophos for help if they could give a demo firewall to test and 2 weeks later they wouldn't. Even though they couldn't guarantee their filter would work or not. They told us to buy and try.
If you still need help with this do reach out for my services.