Hi, Yesterday I got to take a look at a network capture of a Microsoft Outlook client connecting to a Microsoft Exchange server with Ethereal 9.5. I was amazed that a large chunk of the communication between Outlook and Exchange had already been reverse engineered. This is really a fantistic job, guys!
I am particularly interested in the packets flowing to and from the portmapper on tcp port 135 of a Microsoft machine. One of the problems one faces when firewalling this kind of traffic, is that additional connections (in this case to ports >1023 on the server) are used for the actual information exchange between applications (depending on information from the portmapper). I am less interested in the application traffic itself (MAPI in the Outlook-Exchange scenario), but for a packet filtering firewall it's a boon if it can open ports dynamically depending on packet payload information. This is the classic ftp-protocol problem where a data connection is opened depending on ip address + port info passed over the ftp control connection. >From the packet trace I understand that the packet to watch out for is the "Map Reply" packet coming from the server. Under Linux 2.4, netfilter/iptables offers a fairly easy way to write protocol helper modules (even with NAT support). I have already written one for Quake3 master connection (thanks to Ethereal network traces). My questions are: - Is this the only packet that tells the client to open a connection to another port ? - If so, is the packet type of "02" (third byte of the tcp payload) a unique way of identifying this type of packet ? - Is it possible to find a packet on the wire of type "02" that does not contain info on what port(s) to open, or do the End-Point Mapper replies always contain info about related ports ? - Would someone be so kind as to explain me how to get to the IP address and port info from there without me having to go through all the protocol documentation (actually I could not find anything relevant on the internet apart from references to this book: http://www.amazon.com/exec/obidos/ASIN/1578701503/103-6700691-4147863) I assume that the interpretation of the packet is a little more complicated than a mere "the embedded IP address is at offset x and the embedded port number is at offset y", like with Quake3 :-) If it would make things easier, I could hook up with someone who is willing to answer some of my questions on irc after having sent him a packet capture to go from... Basically I would like to know more about the "Tower array" thing, the "Floor"s, etc. Once I know how to interpret all relevant data, I guess it wouldn't take too long to come up with a netfilter module that is able to understand dce rpc, which could be really useful in scenario's with MS Exchange servers in DMZs etc. (I know how to make Exchange use fixed ports via some registry keys, but having a firewall that is able to do dynamic filtering would be very cool). Thanks in advance, Filip
