Re: [Fwknop-discuss] Fwknop not hiding the port?

[Michael R. <mb...@ci...>]

On Jan 18, 2006, Sean Cassidy wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
> 
> Michael Rash wrote:
> > Do you have your Netfilter policy configured to drop all packets to
> > tcp/22 (in the INPUT chain)?  If fwknopd is not running, you should have
> > no access whatsoever to tcp/22 from an external IP.  Even after you
> > start fwknopd this should still be the case, but fwknopd should grant
> > you access after a valid SPA packet has been generated by the fwknop
> > client.
> 
> Alright I did this. But a new problem arose. Here is my iptables command:
> 
> iptables -A INPUT -m tcp -p tcp --dport 22 -j DROP
> 
> That, as expected, drops everything coming to port 22. (Also, shouldn't
> I make a rule that only drops _connections_ to port 22, not all data?
> Since when the Fwknop rule expires, won't my connection be dropped?)

Yes, indeed.  As far as your existing Netilter policy is concerned, you
could accomplish what you need with the following two commands:

iptables -P INPUT DROP
iptables -I INPUT 1 -m state --state ESTABLISHED,RELATED -j ACCEPT

Then, when you start fwknopd (by starting the init script), fwknopd will
create a jump rule as the very first rule in the INPUT chain which jumps
packets to the FWKNOP_INPUT chain.  (Note that this jump rule does not
actually get created until fwknopd monitors a valid SPA packet).  Any
valid SPA packet will cause an ACCEPT rule to be put within the
FWKNOP_INPUT chain, and this rule will allow a tcp connection (or
whatever other traffic you want) to be allowed and tracked by Netfilter
(assuming you have the conntrack modules compiled into your kernel).
Then, when fwknopd removes the ACCEPT rule, all subsequent packets will
be jumped back into the INPUT chain where they will hit the
ESTABLISHED,RELATED rule, and accepted.  Obviously, this really only
works when Netfilter is setup with connection tracking, etc., or if you
set a really long FW_ACCESS_TIMEOUT value.

> But, when I run fwknopd, it says it adds a rule to let me on, but I
> can't connect at all. Here is my command on my client:
> 
> fwknop -A tcp/22 --gpg-recip XXXXXXXX --gpg-sign XXXXXXXX -w -k
> 192.168.1.98 && sleep 2; ssh 192.168.1.98

Looks good.  Note that if you apply and compile the OpenSSH-4.2p1 patch,
you can then just do:

ssh -K "--last" 192.168.1.98

> But, here's a strange thing, (and I think this was noted in your
> presentation at ShmooCon, with www.whatismyip.com, which seems like a
> hack, but I don't know of a better way either), when I receive mail that
> it added or dropped a rule on the server, that its using my external IP
> address, not my internal one, even though I specified that with fwknop
> on the client side. I have also tried the (-s) argument on the client to
> ameliorate this problem to no avail. Does Fwknop not work on internal LANs?

I don't know how your network is setup, but assuming that packets from
your local system are not going over the open internet because you are
sending the SPA packet to an RFC 1918 address, then -w is not going to
help.  The -s switch should work here, or if you want to hard code the
IP that is granted access within the SPA packet use -a <IP>.  You
mentioned above that fwknopd sends you an email saying that it created a
rule.  If you look through the appropriate syslog file (usually
/var/log/messages depending on your syslog config), what source address
has fwknopd actually opened Netfilter for?  You should see a message
like "received valid GPG encrypted packet ... from <IP>".

BTW, I've been thinking about the resolution via whatismyip.com.  I
have a more secure mechanism that I will probably release in the next
version which involves GPG keys, but the "last-hop" problem will always
exist to a degree even when encryption gets involved.

> This problem also expands externally, as in, if I use port forwarding on
> my router (both ssh and udp/62201 are forwarded) it still doesn't work.

Basically, if the SPA packet and attempted ssh connections are routed
the same to the fwknopd server, then it should work.  If you run an
sniffer on the fwknopd server, can you confirm that the SPA packet and
the attempted ssh connection are both seen and come from the same source
address?

Michael Rash
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F  AC69 95D8 5D6B A742 839F


> Thanks for your help so far,
> Sean
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFDzwTwO+qYJSawWRsRA5wbAJ4pFWeNg7R/fTah2LKORdrRckH8/ACfQAS/
> voEV5U53hxN5ow/KZZIpzYw=
> =kxwi
> -----END PGP SIGNATURE-----
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Fwknop-discuss mailing list
> Fwk...@li...
> https://lists.sourceforge.net/lists/listinfo/fwknop-discuss