Thread: [Fwknop-discuss] fwknopd and FORWARD chain / OpenVZ
Brought to you by:
mbr
From: Suno A. <sun...@su...> - 2009-06-08 19:44:28
|
I am using http://en.wikipedia.org/wiki/Openvz and thus I have a bunch of VEs (Virtual Environments) running atop the HN (Hardware Node) -- each VE then appears/feels like a stand-alone Linux. The systems are Debian -- HN and VEs. Note: With OpenVZ there is always just one HN and usually one or more VEs. Of course, there might be no VE at all but ... I do all the firewalling on the HN i.e. the VEs are protected by using iptables rules within the FORWARD chain of the filter table on the HN. There is no need to do additional firewalling within the VEs itself. Now that this is working excellent, I want to plug fwknop into that setup of mine. Of course, I do not want to start firewalling within the VEs, rather, it must be possible to only run fwknopd on the HN and protect all VEs with this one instance of fwknopd on the HN. I already installed fwknop-server (the Debian package containing fwknopd) on the HN. I also started reading man files and the docu on http://www.cipherdyne.org/fwknop/ as well as the config files that come with fwknop-{server,client}. So far so good ... I figure it is possible to only run fwknopd on the HN and enable the setup to use FORWARD. /etc/fwknop/fwknop.conf says: ### Allow SPA clients to request access to services through an ### iptables firewall instead of just to it (i.e. access through the ### FWKNOP_FORWARD chain instead of the INPUT chain). This also ### requires the ENABLE_FORWARD_ACCESS variable to be set in the ### access.conf file for the specific SOURCE stanzas that should be ### allowed for forwarding access. ENABLE_IPT_FORWARDING N; So I set ENABLE_IPT_FORWARDING N; to ENABLE_IPT_FORWARDING Y; and then ... well, that is where I am not sure anymore how to proceed. My current understanding is to put ENABLE_FORWARD_ACCESS into /etc/fwknop/access.conf. However, looking at the examples in /usr/share/doc/fwknop-server/README.ACCESS I could not fine an example that would mention my use case. Can anyone help me to reach my goal i.e. integrate fwknopd into my forwarding setup? Also, I would like to also protect the sshd running on the HN not just the sshds running within the VEs. Is that possible with just one fwknopd running on the HN? |
From: Michael R. <mb...@ci...> - 2009-06-09 04:12:02
|
On Jun 08, 2009, Suno Ano wrote: > I am using http://en.wikipedia.org/wiki/Openvz and thus I have a bunch > of VEs (Virtual Environments) running atop the HN (Hardware Node) -- > each VE then appears/feels like a stand-alone Linux. The systems are > Debian -- HN and VEs. > > Note: With OpenVZ there is always just one HN and usually one or more > VEs. Of course, there might be no VE at all but ... > > I do all the firewalling on the HN i.e. the VEs are protected by using > iptables rules within the FORWARD chain of the filter table on the HN. > There is no need to do additional firewalling within the VEs itself. > > Now that this is working excellent, I want to plug fwknop into that > setup of mine. Of course, I do not want to start firewalling within the > VEs, rather, it must be possible to only run fwknopd on the HN and > protect all VEs with this one instance of fwknopd on the HN. Understood, and yes, fwknop can support this (see below). > I already installed fwknop-server (the Debian package containing > fwknopd) on the HN. I also started reading man files and the docu on > http://www.cipherdyne.org/fwknop/ as well as the config files that come > with fwknop-{server,client}. > > So far so good ... I figure it is possible to only run fwknopd on the HN > and enable the setup to use FORWARD. /etc/fwknop/fwknop.conf says: > > ### Allow SPA clients to request access to services through an > ### iptables firewall instead of just to it (i.e. access through the > ### FWKNOP_FORWARD chain instead of the INPUT chain). This also > ### requires the ENABLE_FORWARD_ACCESS variable to be set in the > ### access.conf file for the specific SOURCE stanzas that should be > ### allowed for forwarding access. > ENABLE_IPT_FORWARDING N; > > So I set ENABLE_IPT_FORWARDING N; to ENABLE_IPT_FORWARDING Y; and then > ... well, that is where I am not sure anymore how to proceed. My current > understanding is to put ENABLE_FORWARD_ACCESS into > /etc/fwknop/access.conf. However, looking at the examples in > /usr/share/doc/fwknop-server/README.ACCESS I could not fine an example > that would mention my use case. > > Can anyone help me to reach my goal i.e. integrate fwknopd into my > forwarding setup? I understand that the documentation is lacking in this area (I'm working on this). Here is how to get this working: - In the /etc/fwknop/fwknop.conf file, set: ENABLE_IPT_FORWARDING Y; You mentioned this above, and this is correct*. - In the /etc/fwknop/access.conf file, create a SOURCE stanza like this: SOURCE: ANY; OPEN_PORTS: tcp/22; ENABLE_FORWARD_ACCESS: Y; FW_ACCESS_TIMEOUT: 30; KEY: __CHANGEME__; (Or you can set the GPG_* variables too if you use GnuPG to encrypt incoming SPA packets from the fwknop client.) The key is the ENABLE_FORWARD_ACCESS variable. Then restart fwknopd: # /etc/init.d/fwknop restart Now, to request SSH access to one of the internal VE's use the fwknop client as follows - assuming that 123.1.2.3 is the external IP of the HN (where fwknopd is configured to sniff traffic), and 192.168.10.2 is an IP of a VE that you want to reach over SSH: $ fwknop -A tcp/22 --NAT-access 192.168.10.2:55000 -R -D 123.1.2.3 What this will do is allow you to SSH to port 55000 on 123.1.2.3 (use -p on the SSH command line), and this connection will be NAT'd through to the internal VE on 192.168.10.2. If you want to get more fancy, you can use the --NAT-rand-port option like so: $ fwknop -A tcp/22 --NAT-access 192.168.10.2 --NAT-rand-port -R -D 123.1.2.3 This will have the fwknop client request access to SSH via a randomly assigned port - which fwknop will print on the command line so you can see it - and then you can make your SSH connection to this port. > Also, I would like to also protect the sshd running on the HN not just > the sshds running within the VEs. Is that possible with just one fwknopd > running on the HN? Sure, in this case the best thing to do is create another SOURCE stanza identical to the above in the access.conf file, but just leave out the ENABLE_FORWARD_ACCESS variable. Thanks, and let me know if there are any issues. -- Michael Rash | Founder http://www.cipherdyne.org/ Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271 [*] Depending on your routing setup into the VE's, you may also need to set: ENABLE_IPT_SNAT Y; However, this is unlikely since it is usually only necessary if the default route on a system routes traffic out a different interface than where the incoming connection is made. For now, just keep ENABLE_IPT_FORWARDING set to "Y". |
From: Suno A. <sun...@su...> - 2009-06-09 07:34:43
|
Hi Michael (/me also waves at others :-), first of all, let me thank you for your terrific software. imho, never before has port knocking been so easy to set up (credit also goes to package maintainer(s), Franck Joncourt) plus I think never before has port knocking ever brought that much added-value to the table in order to justify the added costs (mainly time to maintain and set up; having .debs is a must-have to me) in running a port knocking environment. I have been waiting for something like fwknop for a long time now -- actually, I had this on my todo since 2003 now ;-] Michael> - In the /etc/fwknop/fwknop.conf file, set: Michael> Enable_IPT_FORWARDING Y; Done Michael> - In the /etc/fwknop/access.conf file, create a SOURCE stanza Michael> like this: Michael> Source: ANY; Michael> OPEN_PORTS: tcp/22; Michael> ENABLE_FORWARD_ACCESS: Y; Michael> FW_ACCESS_TIMEOUT: 30; Michael> KEY: __CHANGEME__; Excellent, that is what I thought it had to be but then, I found no hint/docu so I could not be sure. Michael> (Or you can set the GPG_* variables too if you use GnuPG to Michael> encrypt incoming SPA packets from the fwknop client.) Right. Actually that is what I am going to do but only after I get it working "the simple way" i.e. using Rijndael. Into that, SHA1 is considered insecure http://csrc.nist.gov/groups/ST/hash/statement.html and we are moving away from it http://www.debian-administration.org/users/dkg/weblog/48 http://ekaia.org/blog/2009/05/10/creating-new-gpgkey/ I figure fwknop is using SHA256 as its default cipher already which is good. However, what if I wanted to use SHA512? How to? Michael> The key is the ENABLE_FORWARD_ACCESS variable. Then restart Michael> fwknopd: Michael> # /Etc/init.d/fwknop restart yes, on Debian, using the official .deb this is reads /etc/init.d/fwknop-server restart Michael> Now, to request SSH access to one of the internal VE's use the Michael> fwknop client as follows - assuming that 123.1.2.3 is the Michael> external IP of the HN (where fwknopd is configured to sniff Michael> traffic), and 192.168.10.2 is an IP of a VE that you want to Michael> reach over SSH: Michael> $ fwknop -A tcp/22 --NAT-access 192.168.10.2:55000 -R -D Michael> 123.1.2.3 Michael> What this will do is allow you to SSH to port 55000 on Michael> 123.1.2.3 (use -p on the SSH command line), and this Michael> connection will be NAT'd through to the internal VE on Michael> 192.168.10.2. Right. About that. I am running a pretty fancy SSH setup using Monkeysphere and many settings to improve security which of course also includes the obvious things like for example moving sshd listening port away from port 22 to some port >1023. Anyways, I still have a missing link in my overall understanding of this i.e. in particular what you just said above. You say fwknop -A tcp/22 --NAT-access 192.168.10.2:55000 -R -D 123.1.2.3 will allow me to SSH to port 55000 on 123.1.2.3. Ok, well, here is where I got lost ... With this scenario, what listening port would be in /etc/ssh/sshd_config -- would it be 55000 or 22? To be precise, what would sa@wks:~$ grep ^Port /etc/ssh/sshd_config Port <what_goes_here?> sa@wks:~$ return in our above case? Michael> If you want to get more fancy, you can use the --NAT-rand-port Michael> option like so: Michael> $ fwknop -A tcp/22 --NAT-access 192.168.10.2 --NAT-rand-port Michael> -R -D 123.1.2.3 Michael> This will have the fwknop client request access to SSH via a Michael> randomly assigned port - which fwknop will print on the Michael> command line so you can see it - and then you can make your Michael> SSH connection to this port. Ok, I read http://www.cipherdyne.org/blog/2008/06/single-packet-authorization-with-port-randomization.html of course and yes, that my current understanding too. What sprung me first was that ... I cannot use my well beloved ~/.ssh/config stanzas anymore i.e. the shortcut "ssh myfancyserver" would not work anymore because of the randomized port yes? The stanza in ~/.ssh/config would then for example read like this Host fancyserver HostName 111.6.5.1 Port 8683 >> Also, I would like to also protect the sshd running on the HN not >> just the sshds running within the VEs. Is that possible with just >> one fwknopd running on the HN? Michael> Sure, in this case the best thing to do is create another Michael> SOURCE stanza identical to the above in the access.conf file, Michael> but just leave out the ENABLE_FORWARD_ACCESS variable. /me cheers ... it is actually that easy ;-] Michael> Thanks, and let me know if there are any issues. will do. I have a few things on my todo, but starting with mid June or so I am going to nose-dive into fwknop. I will be back ... ;-] |
From: Michael R. <mb...@ci...> - 2009-06-10 00:53:42
|
On Jun 09, 2009, Suno Ano wrote: > Hi Michael (/me also waves at others :-), first of all, let me thank you > for your terrific software. > > imho, never before has port knocking been so easy to set up (credit also > goes to package maintainer(s), Franck Joncourt) plus I think never > before has port knocking ever brought that much added-value to the table > in order to justify the added costs (mainly time to maintain and set up; > having .debs is a must-have to me) in running a port knocking > environment. > > I have been waiting for something like fwknop for a long time now -- > actually, I had this on my todo since 2003 now ;-] Glad you like fwknop. > Michael> - In the /etc/fwknop/fwknop.conf file, set: > Michael> Enable_IPT_FORWARDING Y; > Done > > > > Michael> - In the /etc/fwknop/access.conf file, create a SOURCE stanza > Michael> like this: > Michael> Source: ANY; > Michael> OPEN_PORTS: tcp/22; > Michael> ENABLE_FORWARD_ACCESS: Y; > Michael> FW_ACCESS_TIMEOUT: 30; > Michael> KEY: __CHANGEME__; > Excellent, that is what I thought it had to be but then, I found no > hint/docu so I could not be sure. Understood. > Michael> (Or you can set the GPG_* variables too if you use GnuPG to > Michael> encrypt incoming SPA packets from the fwknop client.) > Right. Actually that is what I am going to do but only after I get it > working "the simple way" i.e. using Rijndael. > > Into that, SHA1 is considered insecure > http://csrc.nist.gov/groups/ST/hash/statement.html and we are moving > away from it http://www.debian-administration.org/users/dkg/weblog/48 > http://ekaia.org/blog/2009/05/10/creating-new-gpgkey/ I figure fwknop is > using SHA256 as its default cipher already which is good. However, what > if I wanted to use SHA512? How to? SHA512 is not currently supported, although it would not be too hard to patch fwknop to use it. > Michael> The key is the ENABLE_FORWARD_ACCESS variable. Then restart > Michael> fwknopd: > Michael> # /Etc/init.d/fwknop restart > yes, on Debian, using the official .deb this is reads > /etc/init.d/fwknop-server restart Ah, yes, '/etc/init.d/fwknop-server restart' on Debian or Ubuntu. > Michael> Now, to request SSH access to one of the internal VE's use the > Michael> fwknop client as follows - assuming that 123.1.2.3 is the > Michael> external IP of the HN (where fwknopd is configured to sniff > Michael> traffic), and 192.168.10.2 is an IP of a VE that you want to > Michael> reach over SSH: > > Michael> $ fwknop -A tcp/22 --NAT-access 192.168.10.2:55000 -R -D > Michael> 123.1.2.3 > > Michael> What this will do is allow you to SSH to port 55000 on > Michael> 123.1.2.3 (use -p on the SSH command line), and this > Michael> connection will be NAT'd through to the internal VE on > Michael> 192.168.10.2. > Right. About that. I am running a pretty fancy SSH setup using > Monkeysphere and many settings to improve security which of course also > includes the obvious things like for example moving sshd listening port > away from port 22 to some port >1023. > > Anyways, I still have a missing link in my overall understanding of this > i.e. in particular what you just said above. You say fwknop -A tcp/22 > --NAT-access 192.168.10.2:55000 -R -D 123.1.2.3 will allow me to SSH to > port 55000 on 123.1.2.3. Ok, well, here is where I got lost ... > > With this scenario, what listening port would be in > /etc/ssh/sshd_config -- would it be 55000 or 22? To be precise, what > would > > sa@wks:~$ grep ^Port /etc/ssh/sshd_config > Port <what_goes_here?> > sa@wks:~$ > > return in our above case? There is no modification necessary for the port that sshd listens on. The fwknopd daemon builds the appropriate NAT rules such that a TCP connection made to port 55000 (in the above scenario) is translated to port 22 for packets that are forwarded through to your internal virtual instances. You could also just do: --NAT-access 192.168.10.2:22 -R -D 123.1.2.3 ...and then make your ssh connection to 123.1.2.3, and this connection will be NAT'd through to the internal 192.168.10.2 virtual instance. But, this would interfere a bit with the sshd server running on the 123.1.2.3 system itself in the sense that no normal ssh connection to 123.1.2.3 would go where you expect it would (to the local system). This is why using a different destination port (55000) for inbound connections to 123.1.2.3 can be used as a differentiator to say that you really want access to the internal IP. It also has the consequence that it is more difficult for anyone sniffing your traffic to be confident about what you are doing - the 55000 port is encrypted within the SPA packet and therefore is not accessible by such an attacker. They would have to watch all of your traffic to get a sense for what is going on - they can't just assume that the ssh connection is made to a port they would normally expect. This is where the randomization feature also comes in handy, since each and every ssh connection that is requested via SPA can travel over a completely different and randomly selected port. Note that to make this work, your kernel needs to have the iptables connection tracking modules available, but this is pretty standard. --Mike > Michael> If you want to get more fancy, you can use the --NAT-rand-port > Michael> option like so: > > Michael> $ fwknop -A tcp/22 --NAT-access 192.168.10.2 --NAT-rand-port > Michael> -R -D 123.1.2.3 > > Michael> This will have the fwknop client request access to SSH via a > Michael> randomly assigned port - which fwknop will print on the > Michael> command line so you can see it - and then you can make your > Michael> SSH connection to this port. > Ok, I read > http://www.cipherdyne.org/blog/2008/06/single-packet-authorization-with-port-randomization.html > of course and yes, that my current understanding too. > > What sprung me first was that ... I cannot use my well beloved > ~/.ssh/config stanzas anymore i.e. the shortcut "ssh myfancyserver" > would not work anymore because of the randomized port yes? > > The stanza in ~/.ssh/config would then for example read like this > > Host fancyserver > HostName 111.6.5.1 > Port 8683 > > > > > >> Also, I would like to also protect the sshd running on the HN not > >> just the sshds running within the VEs. Is that possible with just > >> one fwknopd running on the HN? > > Michael> Sure, in this case the best thing to do is create another > Michael> SOURCE stanza identical to the above in the access.conf file, > Michael> but just leave out the ENABLE_FORWARD_ACCESS variable. > /me cheers ... it is actually that easy ;-] > > > > Michael> Thanks, and let me know if there are any issues. > will do. I have a few things on my todo, but starting with mid June or > so I am going to nose-dive into fwknop. I will be back ... ;-] > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Fwknop-discuss mailing list > Fwk...@li... > https://lists.sourceforge.net/lists/listinfo/fwknop-discuss |