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 > > s...@wks:~$ grep ^Port /etc/ssh/sshd_config > Port <what_goes_here?> > s...@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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/fwknop-discuss ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/fwknop-discuss
