df_cryptostorm• 211d
Seeing as how I'm the person that implemented the snort IPS you're referring to, I thought I should weigh in.
As it says in the "Access Denied" message, Cryptostorm owns servers at various data centers all over the world. Whenever someone tries to perform an automated/noisy vulnerability scan while connected to the VPN, those data centers will be the ones who receive abuse complaints from whatever server/website is being targeted. If any data center receives enough abuse complaints about a particular server under their roof, they will shut down that server and suspend the associated account.
Several people were using cryptostorm while running automated vulnerability scanners such as OpenVAS, Nessus, and Nikto (We know because we were forwarded the abuse emails containing WAF/IDS logs from the target and that included the User Agent that advertises the scanner program used, which the attacker was too lazy or dumb to change). We don't know if it was some script kiddies playing with a few tools, or if it was an intentional attempt to get our servers shut down. Either way, it was the reason that at least 3 of our servers were shut down by the data center (they've since been replaced with other servers in different data centers).
Most VPN providers prevent their servers from getting shut down due to these types of attacks by simply enabling logging (yes, even if they claim not to), or at the very least they'll set up some sort of server-side identifier (ID number, etc.) tied to every connection that can be used to trace which session belongs to which customer. An obvious sign that your VPN provider is doing this is if you ever receive any emails from them complaining about you attacking something (how did they know it was you performing that scan/hack unless they were logging?).
Cryptostorm needed to implement something to prevent these attacks from killing our servers, but we also didn't want to start logging anything that could potentially be used to identify any individual customer (that would defeat the whole purpose of our anonymous token authorization system).
The best solution I could think of was to use snort's NFQ DAQ directly against the tunnel interface, along with a generic ruleset that would prevent the most basic attacks before they even left the server. This allows us to keep our servers online without having to associate our customers with their sessions. This was also the only method I could think of that would allow us to block outgoing attacks without having to store any real client IPs anywhere (including RAM). When a block occurs, your internal (10.x.x.x) VPN IP is what gets temporarily added to iptables, not your real IP, and those internal IPs are randomly generated.
I've tried to remove most of the rules that were so generic or all-encompassing that it would definitely cause false positives, but even then there will be a few legitimate requests that get caught in this IPS. In those cases, emailing us will get the rule removed or modified to be more specific.
Regarding your
http://example.com/?q=union%20select example, this was to prevent most SQL injection attacks because the majority of them do include "union select", but since that particular rule could also prevent someone from researching mysql related queries (
http://stackoverflow.com/questions/8572 ... lect-query or
http://stackoverflow.com/questions/3562 ... -in-clause for example), I'll go ahead and remove it.
As for your concern that we could possibly log all URLs or inject malicious HTML/JS/etc., you're right, we could (for HTTP at least). The implementation of this IPS isn't the reason for that possibility though. Any VPN server you're connected to could use something like
http://www.linux-magazine.com/Issues/2015/173/Netsed to transparently inject/replace data in any plaintext stream between you and the server. That's why, as others have pointed out, using HTTPS is still a necessity even when using a VPN. A VPN only encrypts traffic between you and the VPN server. If you're using any plaintext protocols (HTTP, telnet, FTP, etc.) then the VPN server or any hop/route between the server and the destination could potentially perform a MiTM attack.
We try to alleviate any trust concerns by providing as much information as possible about how our network is structured:
https://github.com/cryptostorm/cstorm_deepDNS
https://github.com/cryptostorm/voodoo.network
viewtopic.php?t=6332
https://github.com/cryptostorm/cryptost ... tion_files
and by providing the source code to our custom client:
https://github.com/cryptostorm/cstorm_widget
But in the end, regarding our server-side setup, we could be making this all up and could really be using ancient/insecure software, or we could be logging all packets. Seems like a lot of trouble though to research possible ways to operate a VPN without that sort of logging and then not implement it.
