|
Notes |
|
|
(0000360)
|
|
dloper
|
|
2011-06-15 23:19
|
|
The following changes adds a check to the system to validate the certificate and the user ID. Since ClearOS correlates the naming of both, we can use simple logic to overcome the issue. This is a workaround at the moment and there may be a better way to handle the issue that scales better.
Change /etc/openvpn/clients.conf:
#user nobody
#group nobody
script-security 2
management localhost 7505
client-connect /etc/openvpn/cert-validate.script
This enables the localhost only management portal via telnet. We will use this to disconnect clients that are in violation of the rules. Please note that removing nobody causes an additional security concern in that a compromise of the OpenVPN daemon can result in privilege escalation. It is vital that moving forward OpenVPN and these associated scripts be assigned to a non-privileged but named user and group.
/etc/openvpn/cert-validate.script:
#!/bin/bash
address=$trusted_ip':'$trusted_port
if [ $username == $common_name ]; then
exit 0
else
/etc/openvpn/killopenvpnuser $address
fi
/etc/openvpn/killopenvpnuser:
#!/usr/bin/expect
set arg1 [lindex $argv 0]
set timeout 10
spawn telnet localhost 7505
expect " for more info"
send "kill $argv\n"
expect "client(s) killed"
send "quit\n"
Please note that only one user may be connected to the localhost management port at a time. If connected manually to the port then it will cause the user to be passed. This is likely the case as well if the client floods the server and is rejected with the first request but granted the second while the system purges the initial connection. |
|
|
|
(0000361)
|
|
dloper
|
|
2011-06-15 23:19
|
|
|
|
|
(0000362)
|
|
user2
|
|
2011-06-16 05:13
|
|
|
|
|
(0000363)
|
|
dloper
|
|
2011-06-16 08:01
|
|
The major logic bug here is that only one session of expect can be passed to the telnet session at a time so what happens if more that one instance comes. The answer is two fold...queue the disconnect requests, and two, stall the openvpn request indefinitely until disconnect.
One thing I noticed is that the script (cert-validate.script) will keep the authentication request in limbo until it exits normally. This sort of solves the problem in itself in that it can pass expect script and wait for a positive outcome. If none is forthcoming it will continue to keep the client at bay with:
"SENT CONTROL [server.clearos.lan]: 'PUSH_REQUEST' (status=1)".
In fact, the client side will continue to produce these messages long after OpenVPN has denied the host.
Additionally, a more scalable architecture may be to call a central script that spins off the cert-validate.script so that it can perform even more additional services. For example, it may want to set up specific firewall rules for this client. |
|