gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUnet-developers] port knocking?


From: Christian Grothoff
Subject: [GNUnet-developers] port knocking?
Date: Wed, 25 Feb 2004 05:28:57 -0500
User-agent: KMail/1.5.4

Just wanted to broadcast some idea here. As you may know, GNUnet (typically) 
has to open a port such that other peers can connect (forget about NAT/SMTP 
for this discussion).  Now, after recently talking to somebody at some big US 
ISP, I learned that ISPs perform port-scans to detect "bad" users running 
"servers".  Ok, they're mostly after open spam relays these days, but they 
could certainly go after anything (and some ISPs don't like P2P).

Using port knocking (see http://www.portknocking.org/ for details) it might be 
possible to defeat such scans.  Of course, for GNUnet the knocking sequence 
would not be a 'secret' (we're not trying to do any meaningful authentication 
on the sender), but rather just a defense against being discovered by a 
portscan.  Sure, if the adversary actually joins GNUnet and then happens to 
discover the peer, that can't be prevented.  But where at the moment any 
adversary can just scan certain ports and discover a GNUnet peer, port 
knocking would void that kind of attack.

Freenet tries (tried?) to defend against discovery by masking as a webserver 
until the client has identified itself as another freenet node  (can't find a 
reference, sorry).  Portknocking would of course be an even stronger defense.

Before anyone starts hacking, here are some issues I'd like to know the answer 
to first:

- how do we open a port while making it look on the outside like we deny (or 
at least reject) all connections?  I mean, we should match exactly what the 
kernel does when nobody is listening, and (at least depending on the firewall 
config) does mean no playing of TCP SYN-ACK (and possibly not even FIN).  I'm 
not sure how exactly this can be achieved.

- how do we listen to a bunch of ports? Sure, that's trivial if we just want a 
couple, but what if we want, say, all 65535 ports? What if other services 
already use some of these ports? This question goes together with:

- how do we determine the port sequence? Sure, we could probably generate a 
random sequence of (available) ports and add it to HELO.  Alternatively (and 
with less protocol breakage and less bandwidth usage) we could just compute 
it from the public key (but in which (port) range do we map the numbers? what 
if they happen to be used by some other application?).

- when do we require port knocking (for UDP? always for TCP? only for TCP if 
the HELO advertisement specifies the requirement?)? The knocking will have 
some overhead (especially latency!) for establishing connections, so only 
using it if the other peer actually requires it might make sense (maybe some 
users don't care about being easily discovered; after all, a traffic sniffer 
will quickly reveil everything anyway). 


My general feeling is to have the peer (or user for NAT?) pick a few (3-6) 
available ports on startup and advertise it with the HELO depending on its 
configuration (new transport "TCP-Stealth").  For UDP, we probably don't need 
to do anything since unless we're probed with a packet which looks like a 
GNUnet handshake the message is dropped anyway (unless we want to 
additionally protect us from adversaries that specifically probe for GNUnet 
peers but lack the HELO advertisements for these peers).  


Of course, the biggest question is if there's anyone who'd care for this tiny 
extra bit of security (or maybe more appropriately, obscurity).  As I said 
before, portknocking would not help against an adversary that either joins 
GNUnet or that can perform traffic sniffing.  It only protects against lazy, 
clueless random adversaries.

Christian





reply via email to

[Prev in Thread] Current Thread [Next in Thread]