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