autossh with tunnel device forwarding
Andrea De Pasquale
has anybody ever considered using autossh with a tunnel device VPN, like explained in https://help.ubuntu.com/community/SSH_VPN ?
Do you think there will be any limitations doing this instead of the current local/remote port forwarding? May it become more difficult to configure?
Cheers,
-- Andrea De Pasquale
Matt Gregory
Hi Andrea,
Are you thinking of setting up the VPN on the Security Onion box itself? I would think it would be better to set that up on a perimeter device as a site-to-site link so that the VPN connection would be transparent to Security Onion.
Matt
--
You received this message because you are subscribed to the Google Groups "security-onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
To post to this group, send email to securit...@googlegroups.com.
Visit this group at http://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/groups/opt_out.
Matt Gregory
Also, that article points out some potential issues such as the overhead of TCP causing latency issues. You might look at another VPN solution, such as OpenVPN, that uses UDP.
Matt
Pietro Delsante
Doug Burks
"Note that using SSH in this fashion is not the "best" way to create a
permanent, stable VPN. Notably, SSH uses TCP, and TCP over TCP can
provide abysmal performance under pathological conditions."
Our current autossh implementation does NOT incur this kind of
overhead because we're not creating a second TCP stack.
One reason I like our autossh solution is that it means that all of
our MySQL instances listen on localhost only so we don't have to worry
about exposing MySQL to the network.
Also, our next round of ELSA packages will move us to ELSA's new web
services architecture where the central ELSA web interface will no
longer need to talk to both MySQL and Sphinx on the remote log node.
It will just need to talk to the web interface on the remote log node,
so we'll be able to remove one port from our port forwarding.
Thanks,
Doug
Doug Burks
http://securityonion.blogspot.com
Pietro Delsante
We are having quite a hard time finding a way to establish a reliable VPN connection between the sensor and the collector. We want to deploy our sensors on VMWare ESXi servers and we are looking for a self-contained solution, something we just plug in and it automatically calls back home initiating a VPN connection.
The best solution we've come up with is putting at least two VMs on each ESXi: one is the sensor, and the other is a firewall that should initiate a lan-to-lan VPN with our own perimetral firewall; the sensor should see the local firewall as its default gateway to reach the home network, and this way we would also be able to control the underlaying ESXi server by connecting to the firewall VM; however, controlling ESXi from a VM that runs inside it may not be the most clever thing to do...
Another option would be that of having some hardware component integrated in the appliance, something like Dell's DRAC cards; but DRACs don't do routing and can't act as a VPN endpoint. Sophos RED would be a perfect solution, but it is a separate appliance so we would need to ship our sensors with two different pieces of hardware, which is something we would rather avoid.
Anybody having the same issue?
Doug Burks
already encrypted and if you need to SSH to a remote sensor behind a
firewall, you could reverse forward port 22 over the autossh tunnel.
If you decide that you do need a VPN, you might want to take a look at:
http://wirewatcher.wordpress.com/2012/10/08/virtual-private-onions/
Doug
Matt Gregory
Pietro Delsante
What I did was:
*********************
#[... cut from code calculating "REVERSE_TUNNEL ...]
RPORT=21999
AVAIL=0
until [ $AVAIL -eq 1 ]; do
RPORT=$((RPORT + 1))
SSH_CMD="nc -z localhost $RPORT; echo \$?"
AVAIL=$(ssh -i $KEY $SSH_USERNAME@$SERVERNAME $SSH_CMD)
done
REVERSE_SSH="-R $RPORT:localhost:22"
HOSTNAME=$(hostname)
echo "Host $HOSTNAME" > /tmp/$HOSTNAME.ssh_conf
echo " Hostname localhost" >> /tmp/$HOSTNAME.ssh_conf
echo " Port $RPORT" >> /tmp/$HOSTNAME.ssh_conf
echo "" >> /tmp/$HOSTNAME.ssh_conf
/usr/bin/scp -i "$KEY" /tmp/$HOSTNAME.ssh_conf $SSH_USERNAME@$SERVERNAME:/var/spool/securityonion/ssh/$HOSTNAME.ssh_conf
# If the server isn't up, we want autossh to keep retrying so we set AUTOSSH_GATETIME to 0
export AUTOSSH_GATETIME=0
/usr/bin/autossh -M 0 -f -q -N -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -i "$KEY" -L 3306:127.0.0.1:3306 $REVERSE_TUNNEL $REVERSE_SSH $SSH_USERNAME@$SERVERNAME
*********************
As you can see, right after choosing the remote port to use, the sensor writes a local file /tmp/$HOSTNAME.ssh_conf that contains the SSH configuration to be used on the server to connect back; then it copies this file via scp on the server in /var/spool/securityonion/ssh.
On the server, I created an alias like that in .bashrc:
alias ssh="cat /var/spool/securityonion/ssh/* > ~/.ssh/config; ssh"
This way, when you launch ssh on the server, it will automatically create the ssh config file and you will be able to connect to the sensor using the autossh tunnel without needing to know the port.
The problem with this approach is that those ports are dynamically assigned when the sensor connects to the server after bootup, so there might be conflicts, for example when a sensor goes offline and another one chooses its port: they will be both assigned the same port and you won't know untill you're logged in.
However, the reason why I think this approach might not be enough are:
1. I need to be able to monitor the remote sensors with both Nagios (possibly with NRPE) and Cacti, I need data on both availability and load.
2. I still haven't found any clever way to send Snort's alerts via syslog from the SO server to a third party SIEM, like this:
SENSOR ----sguil-----> SERVER ----syslog----> SIEM
so for the moment I am having the sensors behave like that:
SENSOR ----syslog+sguil-----> SERVER ----syslog----> SIEM
So, I am duplicating fluxes from sensors to server (both syslog and sguil) and to be able to use the autossh tunnel for that, I should also open a local port forwarding for syslog: would this allow for traditional UDP syslog? On the other hand, how would TCP syslog perform in this scenario? Is there any other way to take events from Sguil on the server and forward them via syslog to a remote SIEM? I saw many people asking this but there seems to be no solution at the moment.
Doug Burks
<pietro....@gmail.com> wrote:
<snip>
/etc/init/securityonion.conf such that when the sensor first checks in
with the server and finds an available port, it will write that to a
local config file so that it will always use that port.
Alternatively, you could always use OpenVPN as described in the link I
sent you previously:
http://wirewatcher.wordpress.com/2012/10/08/virtual-private-onions/
> However, the reason why I think this approach might not be enough are:
>
> 1. I need to be able to monitor the remote sensors with both Nagios (possibly with NRPE) and Cacti, I need data on both availability and load.
> 2. I still haven't found any clever way to send Snort's alerts via syslog from the SO server to a third party SIEM, like this:
>
> SENSOR ----sguil-----> SERVER ----syslog----> SIEM
>
> so for the moment I am having the sensors behave like that:
>
> SENSOR ----syslog+sguil-----> SERVER ----syslog----> SIEM
>
> So, I am duplicating fluxes from sensors to server (both syslog and sguil) and to be able to use the autossh tunnel for that, I should also open a local port forwarding for syslog: would this allow for traditional UDP syslog? On the other hand, how would TCP syslog perform in this scenario? Is there any other way to take events from Sguil on the server and forward them via syslog to a remote SIEM? I saw many people asking this but there seems to be no solution at the moment.
Pietro Delsante
On Tuesday, July 30, 2013 12:28:16 PM UTC+2, Doug Burks wrote:
>
> At some point in the future, I'd like to modify
> /etc/init/securityonion.conf such that when the sensor first checks in
> with the server and finds an available port, it will write that to a
> local config file so that it will always use that port.
>
Good idea, but this would not save you from the risk of having two sensors with the same assigned ports, for example if you install a new sensor while an older one is offline.
How about having an arbitrator script on the server, which would be called by the sensor (for example via "ssh -c")? During install, the process would become:
1. Right after exporting its public key to the server, the sensor would run the arbitrator on the server by running ssh -c
2. The arbitrator would know about all the existing sensors and would assign some unique ports to the new sensor
3. The sensor would receive this info and write it to a local configuration file
4. In the future, every time the sensor connects to the server, it will always use those unique ports.
This process could be extended to also include a remote forward for the ssh port, so that the server could connect back to the sensor whenever it needs to. Of course, the server could also export its own public key to the sensor to allow for automatic ssh connections, and there might be a ~/.ssh/config file on the server containing configuration info for all the sensors, in the form:
Host <SENSOR_NAME>
HostName 127.0.0.1
Port <ASSIGNED_PORT>
User <SENSOR_USERNAME>
IdentityFile ~/.ssh/id_dsa
This would allow easy connection from the server to every known sensor.
If you want, I can try and produce some code around this idea.
>
> Could you just monitor /var/log/nsm/securityonion/sguild.log on the server?
>
Might be an option, but this would also require some scripting to convert the sguild.log format to the normal Barnyard2 syslog format that is commonly accepted by SIEMs, please see the other thread here: https://groups.google.com/forum/#!topic/security-onion/RXWxpatNlac
And this would not solve the problems of performing system monitoring with Nagios and Cacti on the remote sensors. We are probably going to use OpenVPN (or some IPSec solution like StrongSwan) for that, like per the article you linked earlier; however, I would also love to improve the autossh mechanism as it could still provide a good fallback mechanism whenever the VPN should fail.