 |
||
 |
 |
 |
 |
 |
| You do indeed misunderstand info on IM and blackholing traffic by Senor Barborito 08/17/2003, 1:54am PDT | ||||
 |
 |
|||
Ice Cream Jonsey wrote:Senor Barborito wrote: What happens to IM with this is that when you startup the IM client, that client makes an outbound connection request to the ICQ servers. The firewall recieves the outbound request, checks against it's ruleset and if it's an OpenBSD firewall, sees this line: 'pass out on $ExternalInterface inet proto tcp all flags S/SA keep state.' The firewall/router/whatever is handling your NAT, now knowing that since all TCP/IP outbound traffic is permitted (and what's more, state maintained so that future packets from that session won't have to be checked against the ruleset - that session in general is now marked 'good') makes a note of which machine on the network sent that packet and then let's it go out. When the response comes back from ICQ servers, with the list of buddies currently online ensuite, those packets examined, determined to be response packets to the original outbound packet from your ICQ program, and are thrown back at the machine the firewall/router has noted as being the origin of the whole session to begin with. "Great, I can sign on to ICQ. But what about getting messages from conversations I started?" Those messages do not actually come from the machines of the people you're talking with but rather are exchanged through the AIM/ICQ main servers to which you already have an established connection (see above). Two people who have firewalls would have a very hard time having conversations (since nobody would accept the unrequested inbound connection) if it were any other way. Yeah, you heard me - AOL (who now own ICQ) or Microsoft or Yahoo could trivially read any and all of your IM conversations. When I hand out passwords for user accounts on one of my machines, I make the person getting the account download Trillian and establish a 128-bit Blowfish-ciphered SecureIM connection with me for just this reason. "Great, so that means I get the full functionality of IM then, right?" No. File transfers are direct connections between your machine and the machine of the person sending you the file - Microsoft sure as hell isn't going to pay for the bandwidth required to play proxy for all your ereet IM warezing/MP3 trading you filthy pirate. Any kind of operation requiring a direct connection might not work if you both have firewalls/routers/a NAT (these are pretty much the same thing to a small extent, and certainly for our purposes today) - if just one of you has an actual live IP that doesn't blackhole you're fine. "But wait, I'm firewalled, how can my friend who isn't firewalled send me a file on IM? I mean, if he initiates that request to send me a file my firewall will just block it." Here's how modern IM programs do it - first off your friend's ICQ client will quietly send a message through ICQ servers to your client (you and your friend never see this exchange) saying 'hey my stupid user wants to send your stupid user another worthless file.' Then, your friend's ICQ client will attempt to connect to your machine directly and since you're running a firewall which blackholes all incoming packets not part of an already-established outbound connection, you'll promptly drop those packets. Once the connection attempt has timed out (say, two-four seconds) your friends machine will send another through-the-ICQ-server message to your client (all without you or your friend knowing) saying 'Hey I can't directly connect to you - why don't you try to directly connect to me?' So you send an outbound connection request to your friend's unfirewalled machine, which happily accepts it. The data from the file he wishes to send you is carried over on the 'return-stroke' packets of that established connection (which your firewall now allows). "Cool, well what if we both have blackholing firewalls/routers/NATs and we want to exchange files?" This is where things get icky. Depending on the IM program you're using you may have to consider from among different options: 1. The first, and most straightforward method: most firewalls provide some means for you to punch a small hole in them. If I couldn't allow the firewall on the Caltrops webserver to have a hole punched for incoming traffic on port 80 (the assigned HTTP port), you wouldn't be reading this right now. Most firewalls have some method of allowing you to open specific ports on them so that incoming traffic for that port can flow through. Most IM programs list the port ranges they use (usually in the 5000s). Opening up those ports on your firewall is step one. If it's a hardware firewall/NAT you may (I apologize I should be more definitive here but I'm exhausted while writing this and can't think very well) need to setup a port-redirect to the specific machine you want to use the ports. 2. The new AIM beta allows (supposedly) two people with firewalls to send files two and from each other, provided they both have the new beta client. How? Well, they haven't said precisely how, yet, but I have two theories, one of which is simple and one of which is extremely complex but (I think) a fun read. The first is that AOL really is acting as a proxy for all file transfers between two hosts each of which is firewalled/NATd. AOL-TW is a giant in the realm of communications, and it really wouldn't surprise me if they COULD pull this off. But, here's what I think they actually are doing . . . See, it is possible to hijack an TCP/IP transmission if you have the right sequencing numbers for the packets of the connection. What distinguishes one packet coming on down the wire from any other? Well, not much. To maintain integrity of communications, TCP/IP has sequencing numbers - useful for making sure that you didn't miss a packet in a communiction, and also that the packet you are getting is really from the host you have a connection with. If you want to see how the stacks of various operating systems measure up in the randomness of their sequencing numbers, check the following: Strange Attractors in TCP/IP Sequence Numbers. To learn more about sequence numbers in general, the following from Novell is extremely useful (pdf): TCP Sequencing and Sliding Windows. While I am not at all certain the following is possible, especially on networks with firewalls that have good egress filtration rules, here is my theory on how AIM is accomplishing this without acting as proxy: Essentially, a two-way simultaneous connection hijack of two established connections with an unfirewalled third party (AOL's IM servers, in this case). Something like this: once it has been determined that neither side can create a direct connection because both are firewalled, the client that attempted to send the file in the first place whines to AIM's servers. AIM's servers send a message to both clients to establish a new connection with it. On the original connection, AIM's servers quietly pass each client the correct sequence number for the other client's new connection. Client A then sends Client B a packet with the next sequence number for Client B's new connection with the AIM servers. Client B responds with a packet with the next sequence number for Client A's new connection with AIM servers. The end result is that each client's firewall hears what it needs to hear to pass the packets through, and the data gets directly through to each machine despite neither machine having requested a direct connection to the other. If this is how they're accomplishing it (and again, I don't know for certain, I thought there were some basic rules with fundamental Internet Protocol that might prevent it), then hats off to them on a bloody brilliant solution - it struck me just today as I was making this post that this was one way around the classic problem of two firewalls clients wanting a direct connection. Based on my admittedly very scant knowledge of TCP/IP, though, this 'feels' like the right answer. Now I really want to know if this is how they're doing it - or if such a thing is even possible. I can think of a slew of neat uses. Ice Cream Jonsey wrote: I wish I could give you more help, but I've shied away from Linksys routers specifically because Linksys is continually plagued with new ways of hacking their equipment - Cisco isn't much better and that's why I've come to rely on OpenBSD for my filtration needs. Also, just a note of interest - take a look at the *BSD graph on that first sequencing link there while keeping in mind that more entropy = more sequencing security. A pity for Cisco (the other big winner there) that the security of IOS is not in line with their sequencing implementation. --SB |
||||
 |
 |
|||
|
