VPN improvement in 6.5 ?

Forum for all technical support and trouble shooting of the WinGate VPN.

Moderator: Qbik Staff

VPN improvement in 6.5 ?

Postby jeff » Dec 20 08 4:36 am

Hi,

I'm happy to see a new release of Wingate .... but ... any improvement on the VPN version ??

Is there a way to secure the first TLS/SSL handshake to reduce DOS capabilities ? Having the IP + Port + "VPN logical Name" is all you need to have access to the authentication process of the server. All these informations are easy to listen-capture (all in "clear text"). Adding a kind of "ignition key" (as openvpn does with its ta.key) that permit to pre-authenticate clients that connect and give them the right to authenticate to the VPN server. (Other clients trying to connect without the key would not be allow to authenticate).

I'm still having problems connecting more than 25 clients simultaneously to a "full mesh network". I don't really nead a full mesh network. I have 5 datacenters on wich all clients need to connect. I would like to keep the datacenters as "VPN clients" (only UDP packet incomming) and keep away the VPN server on it's own Internet access, without any LAN.
It would be great to have 2 kinds of clients : "Normal clients" (...) and "Master Clients" (on which any clients of the masternode can connect, if selected).

Tunnel creation could then offer another option :
- allow tunnel to Masternode Only
- allow tunnel to/from all MasterClients only (new option)
- allow tunnel to/from all nodes

Then, when a client connect to a MasterNode, he would be able to open VPNs to the MasterClients only (Data Centers) only (and not all of the other clients).
That would be a great functionnality.

I'm also having problems with PAT (Port address Translation) routers (netGear, bewan, ...) . I wonder how clients learn other clients UDP port ? Because when using these routers, it's seems that some clients sends UDP packets to the translated-UDP-port (wich is not forwarded, but assigned by the router), and not to the 'normal UDP port' (the one that is forwarded). The result is that communication does'nt work until the local client sends packets to the other client, and then, the router opens a "network windows" and packets can also come in, regardless the "original" UDP port.

Best regards

Happy Christmas.

Jeff
Jeff
jeff
 
Posts: 37
Joined: Apr 22 04 8:57 am

Re: VPN improvement in 6.5 ?

Postby adrien » Jan 10 09 10:42 am

Hi Jeff

There were no significant changes to VPN for 6.5, only those bug-fixes that were common between WinGate and WinGate VPN.

In terms of your points, you are concerned about DOS attacks on authentication in WinGate?

Because WinGate allows different SSL certs per hosted VPN on the same IP:port, we need to determine which VPN the client is connecting to in order to select the certificate.

Alternatives to this approach could be

a) use client certificates, and same server certificate for all hosted VPNs.
b) some sort of pre-auth as you say.

I don't know however that client certificates would be a smaller attack surface. In the end, if the authentication process is bullet-proof, it should be fine to leave it exposed to the internet. Using the WinGate user database could help here if you are only using VPN. This is very efficient in terms of evaluation of authentication. The OS user database uses SSPI, which I would expect is fairly robust although will definitely use more resources esp on an Active Directory.

Re Master Nodes, Master Clients etc...

The ability of a LAN client connected to a Node to participate in the VPN is a function of which routes are exported by that node (and assuming it's not a single user license on that node). I guess you would be interested in more rules about which nodes can make tunnels to which other nodes?

Re VPN tunnels.

When traversing a NAT firewall, the VPN tunnel packets will be translated by the NAT, and the originator of the packet can't really tell what the port number will be changed to. So when the other end of the tunnel receives a packet, it uses that new peer port if it knows that the other end is behind a NAT. However up until that point, if the other end hasn't yet received a packet from the node behind the NAT yet, it will use the original port number advertised by that node which will only be accessible if that same port number is being redirected by that node's NAT.
adrien
Qbik Staff
 
Posts: 5441
Joined: Sep 03 03 2:54 pm
Location: Auckland

Re: VPN improvement in 6.5 ?

Postby jeff » Jan 15 09 9:49 am

Hi Adrien;

Thanks for your answer.

In Fact, Wingate VPN has been inspected by our 'crypto' ingeniers. The problem for them is that anybody 'listenning' to the outgoing packets can get all elements to have access to the server's authentication process.
(ip:port looking at the IP packets and vpn-logicalname looking at the TCP stream.). And then sending many packets to the server 'could' make him fail.
Once, I suggested you add an option to auto blacklist IP of clients that fail to authenticate. That could be a way to prevent someone to try using the 'listened' informations too many time.


RE I guess you would be interested in more rules about which nodes can make tunnels to which other nodes?

YES !!! I'm dreaming of it !


Re VPN tunnels.

In fact there are sometimes some strange behaviors. Most of the time, we use CISCO routers, and we only use NAT, (no PAT) and we keep the original UDP sourceport for the outgoing packets. That works great.
When Using NAT and PAT, we can realy see some strange behaviors, especialy with many tunnels ...
Some routers may have problems translating too many different ports ... It looks like they have problems to send the ingoing packets to the Wingate Machine using theese ports. As far as the original UDP port is forwarded in each local router, why does the peer sends to the translated port ? Sending trafic to the node's advertised port would work even better => The forwarding rule is 'static' in the router.

But that's also why IP world is so fascinating !!

Great Job !!

Jeff


PS : I opened a ticket GNO-82078 for some "undesired history messages". The ticket seems to be opened, but I didn't receive any email confirmation, as I usualy do. So I wonder if it's really opened ... Thx
Jeff
jeff
 
Posts: 37
Joined: Apr 22 04 8:57 am

Re: VPN improvement in 6.5 ?

Postby adrien » Feb 28 09 1:08 am

Hi Jeff

So you are worried about dictionary attacks against the VPN server auth process, since anyone who can obtain the VPN name and IP:port can go as far as making an SSL connection then trying to crack the binary protocol?

Or just DOS attacks?

I think this would be difficult. Firstly all communications over the control connection (once SSL is negotiated) are done with our special binary message format. Authentication is layered over this, and so the attacker would need to figure out (possible):

a) how to create valid binary message. Invalid packets (without self-integrity) would cause a comms error and disconnect.
b) what the command IDs are for authentication, which is a challenge response process
c) what the auth protocol is. Using NTLM would be relatively easy to figure out (if they got this far), the Qbik auth one is non standard, based on MD5.

The first message is sent by the server, so it's possible the attacker could use this packet to try and figure out the binary message format I guess. It's pretty simple.

They would need to get past these steps to attack the server auth process.

However, it's possible if you're worried about DOS attacks, that some other mechanism could be exploited or a hole found.

If you want to prevent such attacks you would need to rate-limit connections from any given client IP to the control port. WinGate 7 will allow this, since it has data counters, and counter monitoring with rate derivation and threshold triggers (upper and lower) on any value or derived value (e.g. current absolute value, delta per-second, delta per-minute etc). This would allow WinGate 7 to report an incident if the rate of auth failures from any given client IP exceeded any value per second or per minute (or hour or day). The incident response (defined in notification plans) could automatically blackhole the client IP as well as notify a human (with escalation even if desired).


re VPN tunnels.

The reason we change the port that we reply to tunnel packets on, is so that people behind a NAT don't need to set up any port forwarding in general in their NAT device. When you have more than one node behind a NAT, then port forwarding is required.

There are different types of NAT. When we first set this up, there weren't really cone NATs, so we couldn't assume that if we republished a nodes translated port that it would be accessible to any other nodes. However cone NAT is becoming the standard way for UDP, so we could use punch-through to the server, server learns translated node tunnel port, and advertises that to connected nodes.

Regards

Adrien
adrien
Qbik Staff
 
Posts: 5441
Joined: Sep 03 03 2:54 pm
Location: Auckland

Re: VPN improvement in 6.5 ?

Postby jeff » Feb 28 09 12:38 pm

Hi Adrien

Thanks for this answer.

re VPN tunnels.
I understand a bit more what's the wingate strategy regarding UDP ports of clients, especialy for client-to-client links.
Server is watching for the external peer "sending port" (The NAT one), and then send it to other nodes.
In fact, all depends of wich type of NAT device is used.
An "intelligent" Nat device would be able to recognize which rule external/internal port to apply for input trafic regarding to the previous outgoing trafic.
And I guess when using some old "non firmware updated" NAT devices, I may found some trouble, espacially regarding client-to-client links.
But how does it work when the client never send datas to the server ( server set to "no participation", only control chanel using TCP) ? How does the other nodes learn the other nodes NAT port ? Does every client look at the peer seending UDP port to update it's local database ?
---
EDIT : I think the local client gets its own experience about remote node's port. Because sometimes, link is impossible between the two clients until the remote client node sends a packet to the local client node. And then everything goes OK between these 2 clients.

attacks against the VPN server auth process
In fact, i'm espacially worried about DOS attacks against the server.
Anyone knowing the basic parameters (ip/port/VPN Name) can install a Wingate machine and access to the anthenticate process of the server; for lifetime if he wants.
In fact, no need to know the "special binary message" of Wingate, because everything is included in the wingate application ! (I don't know them, and I can connect to a server using the basic parameters). One machine trying to connect may not be injury, by many machines could become injury.
In my case, I don't worry about incomming trafic that could make bandwith fail (because the servers doesn't host any datas nor datacenters, I just need need enough bandwith to keep every control channels up). I'm just affraid people beeing able to send many requests to the server, as much as they want (authentication is a request) may result to the server to hang up (malformed paquets, too many requests, ...). And as far as the server "Leads" every links of the network, it's a very critical node.

I guess all this was reported by our crypto/secrurity engeniers. I didn't read the report yet (I don't know when i'll receive it). When I get the report, I may give you more informations about their "fears". (Maybe using another way that the forum, wich is little bit 'too much' public !!)

Best regards
Jeff
jeff
 
Posts: 37
Joined: Apr 22 04 8:57 am

Re: VPN improvement in 6.5 ?

Postby adrien » Feb 28 09 3:23 pm

Hi Jeff

With any service that has an interface open to the internet there is the possiblity it will be attacked, so it needs to be hardened against such attacks.

If you use the WinGate user database, then getting to the authentication process is very little load. Much less than NTLM to a domain controller.

Another option would be to use an IDS to monitor the external interface to detect attacks. NetPatrol (our IDS product) allows also a control connection to WinGate and can be set to black hole IPs in WinGate which violate IDS policy. So you could protect the port like that.

From any one IP using WinGate VPN as an attack client however you are only going to get 1 request/VPN/minute. To get to a level that could start to cause problems I think you would need thousands of attack machines, or the attacker would need to write their own attack client. We need to properly test, which I think will require us to write our own attack client specifically for VPN.

We've definitely hardened the VPN control port up a lot in 6.5.3 build 1231 since the last version, rate monitoring in WinGate 7should also help.
adrien
Qbik Staff
 
Posts: 5441
Joined: Sep 03 03 2:54 pm
Location: Auckland

Re: VPN improvement in 6.5 ?

Postby jeff » Mar 01 09 2:22 am

Hi Adrien,

Thanks for the job, espacialy regarding security improvement.
I hope the updated version will also allow more clients to connect to the server. That would be really nice, because actually I cannot reasonably allow more than 25 clients, inclunding the 3 data centers, to connect to the same VPN server without having a server's crash.
The target for me is to connect about 100-110 clients this year.
I think that if the new version could allow me to connect at least 50 clients on the same server, that would be really great.Image

thx again.Image
Jeff
jeff
 
Posts: 37
Joined: Apr 22 04 8:57 am


Return to WinGate VPN

Who is online

Users browsing this forum: No registered users and 5 guests

cron