MSN uses port 1863 to transmit messages and for file transfer.
Lot of people have said that the file-transfer using MSN happens via port range 6891-6900. But when I experimented, I found that MSN is using same 1863 port. Linux machines are able to identify this port as “msnp”. I used “tcpdump” to verify this. Whenever MSN attempts to send a file across the Internet, I creates several smaller packets (typically in the range of 536-1350 bytes) and sends them one after the other. During the file transfer process, if there are messages (text or IM) to be transmitted, the message data block is piggy-backed on the file-transfer packets and sent across.
I was desperately looking for filtering the MSN based file-transfer for some official purposes and wrote some iptables rules based on the Internet literature that said file transfers happen via 6891-6900 by TCP. Then, to validate the rules, I used tcpdump again on the gateway machine to monitor the packets that are originated from my machine.
tcpdump src host dev02 -i eth1 -vvv
To my surprise, the file transfer was still happening also the ports are blocked. Then I made an “iptables” rule to drop all the packets other than 1863 and repeated the experiment. Still the file-transfer was happening. I could see using tcpdump that the packet transfer is happening via port 1863.
tcpdump src host dev02 and dst port 1863 -i eth1 -vvv
So, it became apparant that the file-transfer and the text messaging are all happening via port 1863 instead of the port range 6891-6900. I then decided to write an iptables rule to filter the packets using the packet size constraint. A rule was written to drop packets that are more then 600 bytes assuming that the IM packets shall never reach the limit.
iptables -A FORWARD -i eth1 -m length -p tcp –length 600:65535 –dport 1863 -j DROP
iptables -A FORWARD -i eth1 -p tcp –dport 1863 -j ACCEPT
iptables -A FORWARD -i eth1 -p tcp -j DROP
I did see that the packet size is around 1350 bytes when files are transferred and that’s why I chose 600 bytes as the limit. When I monitoring using the “tcpdump” command as before, I was surprise to see that the protocol adjusted the packet size automatically to 560 bytes to continue the transmission. It tried with 1350 bytes for 3 times and as the acknowledgments were not received, it’s flow control mechanism reduced the packet size to 560 bytes and finished the transfer. So, I had to redo the iptables rule:-
iptables -A FORWARD -i eth1 -m length -p tcp –length 600 512:65535 –dport 1863 -j DROP
It worked like charm.
The happiness did not last long. When people logout and tried logging in, they were not able to login at all. When I investigated the cause of this problem, I could see that the packets that are exchanged during the login process is more than 512 bytes (typically 1350 bytes). So, I had to relax the rule for a brief time to let people login to MSN messenger service. I enabled the file-transfer restriction after everybody logged in by enabling the iptables rule.
NOTE: iptables based filtering shall work only for packets that travel across the network. If the MSN file-transfer happens inside the LAN, MSN cleverly does the file-transfer using P2P where the gateway is not involved at all.
Although, this is not a very good solution, it is definitely worth knowing about!
Happy firewalling!.