Thread: [Fwknop-discuss] SPA over TCP?
Brought to you by:
mbr
From: Alexander P. <ap...@ma...> - 2008-11-06 17:23:49
|
[Starting a new thread with a repeat of the following message, which accidentally got appended to an unrelated thread.] Folks: Does it make sense to generate an SPA packet over TCP instead of UDP? (Not over an existing connection, but by starting a new connection.) Perhaps the SPA packet could be the first packet of the 3-way handshake (with the rest of the handshake never completing)? Or if that doesn't work, could the handshake complete and then the SPA packet be the first data packet and then the connection closed? Here is a situation where something along these lines might be useful: Sometimes you find yourself on a network (say a public wifi being run by an airport) that is severely blocked, e.g., only allows outgoing TCP/80. How to reach my server under those circumstances? I was thinking of configuring my server to recognize SPA packets on TCP/80, and then to *also* have SSH listen on port 80! To prevent fwknopd from getting bogged down trying to SPA-decrypt all the legitimate SSH traffic, you would have to configure your iptables firewall appropriately, such as like this: INPUT: iptables -p tcp --dport 80 -m state --state EXISTING -j ACCEPT iptables -p tcp --dport 80 -m state --state NEW -j mySPAchain iptables -p tcp --dport 80 -j ULOG iptables -p tcp --dport 80 -j DROP mySPAchain: (usually empty, or for 30 seconds might have a rule:) iptables -s xxx.xxx.xxx.xxx -j ACCEPT Here ulogd would be configured to write to a PCAP file, and fwknopd configured to watch that file. When fwknopd recognizes an SPA packet, it is supposed to temporarily put an accept rule into mySPAchain, as shown above. Will this work? If user1 can somehow send an SPA packet on TCP/80, it should be in state NEW, thus iptables goes into the mySPAchain subchain, but there won't be a rule, so it returns from that chain and then proceeds with the ULOG target, and thus the SPA packet is seen by fwknopd. When user1 now launches their ssh connection on TCP/80, the first packet again shows up as NEW, so again iptables goes into mySPAchain, but now there is a matching rule with target ACCEPT, and so the TCP connection gets established for sshd (configured to listen on port 80), and that ssh packet never reaches ULOG and thus never reaches fwknopd. The subsequent ssh packets match EXISTING and via ACCEPT make it to sshd, and never reach ULOG/fwknopd. Meanwhile, some other user2 can send an SPA packet on TCP/80, and this one *will* reach ULOG and thus user2 can also get in. Questions: 1) Any thoughts on the above? Bad idea? 2) Can fwknop generate an SPA packet over TCP? (I don't think the -T option applies here.) 3) What about the MS Windows client for generating SPA packets? Can it generate SPA over TCP? Thanks! Alexander Perlis |
From: Michael R. <mb...@ci...> - 2008-11-07 03:34:05
|
On Nov 06, 2008, Alexander Perlis wrote: > [Starting a new thread with a repeat of the following message, which > accidentally got appended to an unrelated thread.] > > Folks: > > Does it make sense to generate an SPA packet over TCP instead of UDP? > (Not over an existing connection, but by starting a new connection.) > > Perhaps the SPA packet could be the first packet of the 3-way handshake > (with the rest of the handshake never completing)? Or if that doesn't > work, could the handshake complete and then the SPA packet be the first > data packet and then the connection closed? I would argue that there are circumstances where SPA packets over TCP can be useful, but in general while I believe that technically RFC 793 allows data to be included within a SYN packet, this is not recommended. At least, some intrusion detection systems look for such packets - I work on the Dragon IDS, and Dragon has code that looks explicitly for data within SYN packets and generates alerts if so. Whether or not this is truly useful from an IDS perspective (considering that such packets can be spoofed if you don't care about establishing a connection) is separate question. The fact remains that some IDS's will generate events, and this may cause unwanted attention to your SPA packets if sent in this way. Currently, fwknop can sent SPA packets over TCP in two ways: - Via an established connection with a real TCP server. This could be a server such as SSHD itself, or the minimal fwknop_serv daemon. All that is required is that the server accepts a TCP connection, and then the client can send one packet with the SPA payload data, and the connection is then closed. The fwknopd daemon still sniffs the packets from the wire in either case - fwknop_serv does not validate them in any way, and neither would SSHD (other than to say "this isn't part of the SSH protocol, bye"). One important feature when talking about sending SPA packets over TCP is when combining SPA with the Tor network. In Tor, data can only be sent after a virtual circuit is built over an established TCP connection. - Via a spoofed TCP ACK packet. This is less conspicuous than sending over a SYN packet, but may be filtered depending on intermediate firewall configs. > Here is a situation where something along these lines might be useful: > Sometimes you find yourself on a network (say a public wifi being run by > an airport) that is severely blocked, e.g., only allows outgoing TCP/80. > How to reach my server under those circumstances? > > I was thinking of configuring my server to recognize SPA packets on > TCP/80, and then to *also* have SSH listen on port 80! To prevent > fwknopd from getting bogged down trying to SPA-decrypt all the > legitimate SSH traffic, you would have to configure your iptables > firewall appropriately, such as like this: > > > INPUT: > iptables -p tcp --dport 80 -m state --state EXISTING -j ACCEPT > iptables -p tcp --dport 80 -m state --state NEW -j mySPAchain > iptables -p tcp --dport 80 -j ULOG > iptables -p tcp --dport 80 -j DROP > > mySPAchain: (usually empty, or for 30 seconds might have a rule:) > iptables -s xxx.xxx.xxx.xxx -j ACCEPT > > > Here ulogd would be configured to write to a PCAP file, and fwknopd > configured to watch that file. When fwknopd recognizes an SPA packet, it > is supposed to temporarily put an accept rule into mySPAchain, as shown > above. > > Will this work? If user1 can somehow send an SPA packet on TCP/80, it > should be in state NEW, thus iptables goes into the mySPAchain subchain, > but there won't be a rule, so it returns from that chain and then > proceeds with the ULOG target, and thus the SPA packet is seen by > fwknopd. When user1 now launches their ssh connection on TCP/80, the > first packet again shows up as NEW, so again iptables goes into > mySPAchain, but now there is a matching rule with target ACCEPT, and so > the TCP connection gets established for sshd (configured to listen on > port 80), and that ssh packet never reaches ULOG and thus never reaches > fwknopd. The subsequent ssh packets match EXISTING and via ACCEPT make > it to sshd, and never reach ULOG/fwknopd. Meanwhile, some other user2 > can send an SPA packet on TCP/80, and this one *will* reach ULOG and > thus user2 can also get in. > > Questions: > > 1) Any thoughts on the above? Bad idea? I believe that would work (do you mean "ESTABLISHED,RELATED" instead of "EXISTING"?). If you aren't concerned about an IDS generating alarm bells, I could update the fwknop client to allow SPA data to be sent over SYN packets. This would require root access on the client system though because a raw socket would have to be used. > 2) Can fwknop generate an SPA packet over TCP? (I don't think the -T > option applies here.) Use the --TCP-sock argument. > 3) What about the MS Windows client for generating SPA packets? Can it > generate SPA over TCP? I think so, but it has been a while since I tried that. Thanks, -- Michael Rash http://www.cipherdyne.org/ Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271 > > Thanks! > Alexander Perlis > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Fwknop-discuss mailing list > Fwk...@li... > https://lists.sourceforge.net/lists/listinfo/fwknop-discuss |
From: Sean G. <sea...@gm...> - 2008-11-07 05:32:50
|
On Fri, Nov 7, 2008 at 5:31 AM, Michael Rash <mb...@ci...> wrote: > On Nov 06, 2008, Alexander Perlis wrote: > <snip> >> >> Will this work? If user1 can somehow send an SPA packet on TCP/80, it >> should be in state NEW, thus iptables goes into the mySPAchain subchain, >> but there won't be a rule, so it returns from that chain and then >> proceeds with the ULOG target, and thus the SPA packet is seen by >> fwknopd. When user1 now launches their ssh connection on TCP/80, the >> first packet again shows up as NEW, so again iptables goes into >> mySPAchain, but now there is a matching rule with target ACCEPT, and so >> the TCP connection gets established for sshd (configured to listen on >> port 80), and that ssh packet never reaches ULOG and thus never reaches >> fwknopd. The subsequent ssh packets match EXISTING and via ACCEPT make >> it to sshd, and never reach ULOG/fwknopd. Meanwhile, some other user2 >> can send an SPA packet on TCP/80, and this one *will* reach ULOG and >> thus user2 can also get in. >> >> Questions: >> >> 1) Any thoughts on the above? Bad idea? > I would think that an alternative would be to use udp (perhaps port 53) to send the packets. I would imagine that most WiFi hotspots would actually make use of transparent proxy/cache, like squid to which all tcp traffic would be sent. It is most unlikely that the packets on port 80 would make it directly to the destination. This would fail dismally in the case of modifications to the syn packets, since most caches would first complete the handshake, before sending on the packet, and would discard spurious information in the packets. <snip> >> 3) What about the MS Windows client for generating SPA packets? Can it >> generate SPA over TCP? > > I think so, but it has been a while since I tried that. > > Thanks, Actually the windows client currently doesn't send SPA packets over TCP. Manipulation of raw sockets to either make use of the syn or ack packets would restrict the client to versions of windows which support raw sockets. In addition it would require an extensive rewrite. Regards Sean |
From: Alexander P. <ap...@ma...> - 2008-11-12 20:23:36
|
Mike wrote: > I would argue that there are circumstances where SPA packets over TCP > can be useful, but in general while I believe that technically RFC 793 > allows data to be included within a SYN packet, this is not recommended. > [...] The fact remains that some IDS's will generate events, and > this may cause unwanted attention to your SPA packets if sent in this > way. Good point. Sean wrote: > I would think that an alternative would be to use udp (perhaps port > 53) to send the packets. I would imagine that most WiFi hotspots > would actually make use of transparent proxy/cache, like squid to > which all tcp traffic would be sent. It is most unlikely that the > packets on port 80 would make it directly to the destination. This > would fail dismally in the case of modifications to the syn packets, > since most caches would first complete the handshake, before sending > on the packet, and would discard spurious information in the packets. Ah yes, all of that is a problem. Agreed that UDP/53 is unlikely to be blocked, so I can use that for the SPA portion. Somewhat off-topic then (as far as fwknop is concerned), what's an outgoing TCP port that's unlikely to be blocked yet also unlikely to be serviced by a proxy? I've found that some Windows-centric networks don't allow outgoing TCP/22 (I guess because use of SSH isn't so common in the Windows world and thus perhaps unfamiliar to a Windows admin), so I'm looking for a good alternative to use for the SSH portion of the connection. It could even be a small handful of ports (just wondering what folks' experiences have been on different networks?), and I'll have sshd listen on all of them. Oh, here's a thought: what about TCP/443? Anyone experience a situation where 443 is serviced by a proxy somehow, or blocked outright (as an outgoing port)? Mike continues: > [...] If you aren't concerned about an IDS generating alarm > bells, I could update the fwknop client to allow SPA data to be sent > over SYN packets. This would require root access on the client system > though because a raw socket would have to be used. Based on this discussion, I wouldn't use such a functionality at this time for my current purposes. >> 2) Can fwknop generate an SPA packet over TCP? (I don't think the -T >> option applies here.) > > Use the --TCP-sock argument. Confusing (for me at least) is how this works. The man page and the fwknop output refer to "established socket" or "established connection". This makes me think I must separately establish the connection, and then fwknop somehow goes out and hunts through the list of open connections and finds one that matches the destination server and port and then somehow hijacks that and inserts a packet into that TCP stream, magically doing so without messing up the other client who originally created that TCP connection (i.e., not messing up their byte counts, sequence numbers, etc.) Maybe the answer is the thing you mentioned with the ACK packets. Maybe those can be injected into an existing stream without messing it up? As must be evident by now, I haven't delved into TCP details recently. Or does fwknop actually open the TCP connection (do the 3-way handshake), then send the SPA data packet, and then close the connection? Or it maybe does both: if it can locate an existing connection, use the ACK approach, and otherwise establish a new (temporary) connection? You did mention that it can send data over TCP in two different ways, and it isn't clear how the single --TCP-sock option chooses between those two ways. Is it automatic? At any rate, I suggest updating the man page and also the fwknop output to make all this clearer. For example, the fwknop output might include [+] Establishing tcp connection to 123.45.67.89:80... [+] Sending 161 byte message... [+] Closing tcp connection... or [+] Located existing tcp connection to 123.45.67.89:80 owned by PID xxx... [+] Sending 161 byte ACK message... Something along these lines might also help clarify, when an error occurs, *what* was currently being attempted. Right now, if I try to use "--TCP-sock" against a host:port that isn't listening, I get [+] Sending 161 byte message to 123.45.67.89 over established tcp/23 socket... [*] Could not acquire TCP/23 socket with 123.45.67.89: Bad file descriptor at /usr/bin/fwknop line 1003, STDIN> line 1. This output strikes me as unclear whether the host:port is unreachable, or whether fwknop found an existing connection (or perhaps successfully established its own) but then had an error trying to subsequently write a 161-byte data packet onto the wire. Thanks. Alexander |
From: Michael R. <mb...@ci...> - 2008-11-14 03:46:13
|
On Nov 12, 2008, Alexander Perlis wrote: > Mike wrote: > > I would argue that there are circumstances where SPA packets over TCP > > can be useful, but in general while I believe that technically RFC 793 > > allows data to be included within a SYN packet, this is not recommended. > > [...] The fact remains that some IDS's will generate events, and > > this may cause unwanted attention to your SPA packets if sent in this > > way. > > Good point. > > > Sean wrote: > > I would think that an alternative would be to use udp (perhaps port > > 53) to send the packets. I would imagine that most WiFi hotspots > > would actually make use of transparent proxy/cache, like squid to > > which all tcp traffic would be sent. It is most unlikely that the > > packets on port 80 would make it directly to the destination. This > > would fail dismally in the case of modifications to the syn packets, > > since most caches would first complete the handshake, before sending > > on the packet, and would discard spurious information in the packets. > > Ah yes, all of that is a problem. Agreed that UDP/53 is unlikely to be > blocked, so I can use that for the SPA portion. I'm planning on adding support for the fwknop client emulating application layer protocols such as DNS and HTTP to the extend that proxies will accept SPA packets, but the actual body (past the required application layer characteristics) would be SPA data. > Somewhat off-topic then (as far as fwknop is concerned), what's an > outgoing TCP port that's unlikely to be blocked yet also unlikely to be > serviced by a proxy? I've found that some Windows-centric networks don't > allow outgoing TCP/22 (I guess because use of SSH isn't so common in the > Windows world and thus perhaps unfamiliar to a Windows admin), so I'm > looking for a good alternative to use for the SSH portion of the > connection. It could even be a small handful of ports (just wondering > what folks' experiences have been on different networks?), and I'll have > sshd listen on all of them. > > Oh, here's a thought: what about TCP/443? Anyone experience a situation > where 443 is serviced by a proxy somehow, or blocked outright (as an > outgoing port)? I think outbound tcp/443 is a great candidate for a port that is commonly allowed, and it looks like you can tunnel SSH over an SSL proxy with a project called "Corkscrew", but I haven't tried it: http://wiki.kartbuilding.net/index.php/Corkscrew_-_ssh_over_https > Mike continues: > > [...] If you aren't concerned about an IDS generating alarm > > bells, I could update the fwknop client to allow SPA data to be sent > > over SYN packets. This would require root access on the client system > > though because a raw socket would have to be used. > > Based on this discussion, I wouldn't use such a functionality at this > time for my current purposes. Ok. > >> 2) Can fwknop generate an SPA packet over TCP? (I don't think the -T > >> option applies here.) > > > > Use the --TCP-sock argument. > > Confusing (for me at least) is how this works. The man page and the > fwknop output refer to "established socket" or "established connection". > This makes me think I must separately establish the connection, and then > fwknop somehow goes out and hunts through the list of open connections > and finds one that matches the destination server and port and then > somehow hijacks that and inserts a packet into that TCP stream, > magically doing so without messing up the other client who originally > created that TCP connection (i.e., not messing up their byte counts, > sequence numbers, etc.) Sorry this is not clear in the fwknop man page. I've made a minor update to state the following: -T, --TCP-sock Have the fwknop client send an SPA packet over an established TCP connection (created by the fwknop client to the specified listening port on the server with the --Server-port argument). This is not normally done, but is useful for compatibility with the Tor for strong anonymity; see http://tor.eff.org/. In this case, the fwknopd server uses the fwknop_serv daemon to listen on a TCP port (62201 by default). > Maybe the answer is the thing you mentioned with the ACK packets. Maybe > those can be injected into an existing stream without messing it up? As > must be evident by now, I haven't delved into TCP details recently. > > Or does fwknop actually open the TCP connection (do the 3-way > handshake), then send the SPA data packet, and then close the connection? It does the later. While packet data can be injected into an existing TCP connections (although I would not say this is necessarily reliable depending on how packets are routed and other factors), fwknop makes no attempt to do this. It would be complex, would require root access on the client system, and would require sniffing the wire itself. The fwknop client is compatible with many different types of systems by leveraging the normal sockets API to create TCP connections. The fwknop client _can_ (with root access) created an orphaned TCP ACK packet with an SPA payload, but --TCP-sock does not do this. > Or it maybe does both: if it can locate an existing connection, use the > ACK approach, and otherwise establish a new (temporary) connection? You > did mention that it can send data over TCP in two different ways, and it > isn't clear how the single --TCP-sock option chooses between those two > ways. Is it automatic? > > At any rate, I suggest updating the man page and also the fwknop output > to make all this clearer. For example, the fwknop output might include > > [+] Establishing tcp connection to 123.45.67.89:80... > [+] Sending 161 byte message... > [+] Closing tcp connection... Agreed, done. > or > > [+] Located existing tcp connection to 123.45.67.89:80 owned by PID > xxx... > [+] Sending 161 byte ACK message... > > > Something along these lines might also help clarify, when an error > occurs, *what* was currently being attempted. Right now, if I try to use > "--TCP-sock" against a host:port that isn't listening, I get > > [+] Sending 161 byte message to 123.45.67.89 over established tcp/23 > socket... > [*] Could not acquire TCP/23 socket with 123.45.67.89: Bad file > descriptor at /usr/bin/fwknop line 1003, STDIN> line 1. > > This output strikes me as unclear whether the host:port is unreachable, > or whether fwknop found an existing connection (or perhaps successfully > established its own) but then had an error trying to subsequently write > a 161-byte data packet onto the wire. Hmmm, the "Bad file descriptor" message is a bit strange. If I try to send an SPA packet to a TCP server that is not listening (and is not filtered so my client stack receives the RST) I get: [*] Could not acquire TCP/62201 socket with 127.0.0.1: Connection refused at ./fwknop line 1005, <STDIN> line 1. Btw, I'm going to release fwknop-1.9.9 shortly. Thanks, --Mike > Thanks. > Alexander > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Fwknop-discuss mailing list > Fwk...@li... > https://lists.sourceforge.net/lists/listinfo/fwknop-discuss |
From: Sean G. <sea...@gm...> - 2008-11-14 04:38:44
|
On Fri, Nov 14, 2008 at 5:46 AM, Michael Rash <mb...@ci...> wrote: > On Nov 12, 2008, Alexander Perlis wrote: > <snip> > > I think outbound tcp/443 is a great candidate for a port that is > commonly allowed, and it looks like you can tunnel SSH over an SSL proxy > with a project called "Corkscrew", but I haven't tried it: > > http://wiki.kartbuilding.net/index.php/Corkscrew_-_ssh_over_https > I have used corkscrew in the past. By default most prosy servers (squid in particular is one), defines SSL_PORTS. These are the ports which are permitted, as destination ports for using CONNECT requests. The default configuration, will not permit CONNECT requests to low ports such as 22 etc etc. <snip> Regards Sean |