Hello!
(about Security)
My name is Dave. I'm doing a research/development/implementation and promotion
of your openvpn client as part of my University Studies here at Windsor,
Ontario, Canada.
I have to say, I am absolutely loving OpenVPN. However, there was one
interesting security concern I noticed, which I would like to potentially
engage. As part of the nature of dynamic IP networks, OpenVPN will likely have
clients sending/receiving arp packets. It is this exact freedom offered by
ARP, which poses a rather dangerous situation for the real networks that
OpenVPN can bridge to, as well as other OpenVPN clients.
This threat goes as follows: openvpn server goes up, offers bridge to physical
lan (say 192.168.5.0, mask 255.255.255.0, gateway 192.168.5.1) - client
connects, openvpn server gives client 192.168.5.200 (say we assigned the
clients a range of 192.168.5.200 to 192.168.5.254 in the
server.conf).
-Now the client frequently sends to FF:FF:FF:FF:FF:FF : ARP 192.168.5.1
is at <client's macaddress>, when he tries to arp-poison the gateway.
The problem, is that these arp packets will get through, uncontrolled. After a
client poisons a physical network, even though OpenVPN will not forward any
redirected traffic destined for 192.168.5.1 to <client's mac address>, the
poisoned targets on the physical LAN will still try to send their traffic to
the openvpn bridge.
What I was wondering, would be if I could engage the possibility of myself
adding <client's mac address> to the envoronment variables accessible during
the auth-user-pass-verify, client-connect, and client-disconnect scripts.
Doing so would allow openvpn users to create connection scripts, so that
ebtables entries could be added/removed from the kernel or firewall to restrict
the flow of potentially evil arp packets. Example of such a usage below:
#Entries similar to below in connect/disconnect script (should use insertions
or similar):
ebtables -A FORWARD -i tap0 -p arp --arp-ip-src $ifconfig_pool_remote_ip
--arp-mac-src $<client's mac address variable> -j ACCEPT
#Entries similar to below ran once around startup:
ebtables -A FORWARD -i tap0 -p arp --arp-opcode 1 -j ACCEPT
#drop all other arp replies
ebtables -A FORWARD -i tap0 -p arp -j DROP
As evidenced by the example above, perhaps a <client-mac-addr> environment
variable would really help users mitigate this security concern - and I would
like to try to develop it myself, perhaps for rc21!
Also important, are packets from one openvpn client -- destined to another
openvpn client -- passed through the server's tap adapter before going to
another client? For instance, suppose I was a client, and I started saying to
target FF:FF:FF:FF:FF:FF: 192.168.5.1 is at <my mac address> - Can ebtables
entries controlling tap0 stop client-to-client traffic - or does such traffic
never leave the openvpn process? That would also have some bearing on how much
more security the addition of a <client's mac address> could generate for
client-to-client interactions.
Hopefully I'll be able to help your team out with developing a fix for this in
time for my presentation, if not by identifying the above security concern.
I am on a deadline, but I look forward to any input! :)
Dave
_________________________________________________________________
New: Messenger sign-in on the MSN homepage
http://go.microsoft.com/?linkid=9677403
