Hi all,
Warning to readers: Long message...
On Wed, 25 Dec 2002, Ripunjay Bararia (ILUG-MUM) wrote:
Greetings, Merry Christmas to all... By Proxy based firewalls do you mean that the internal users on my NATted LAN do not have a default route to the internet and they need to connect to the net using only a proxy (squid etc...), well that is a bit of a problem as the squid is there for http only rest every one on the LAN need to be able to connect to the external FTP servers the upload and MySQL servers for updating things etc thus not a very easy thing to implement.
The default route will always point to the machine that acts as gateway for your LAN. As for blocking KaZaa, I found some interesting info here,
http://www.checkpoint.com/ (continuation) techsupport/documentation/smartdefense/cpai-2002-13.htm
The information presented there is specific to Checkpoint firewall but can be used to implement similar things using iptables + <a proxy>
Some info from the site: KaZaA is usually communicating through port 1214/TCP. Make sure that your security policy blocks this port (On the Perimeter Firewall). For traveling users, connecting to the corporate networks via VPN, this step usually have no effect. Therefore, it is highly recommended to block KaZaA at the Desktop Policy.
Since the KaZaA service was designed to traverse firewalls and use port 80 (http) it is necessary to use NG Feature Pack 3 P2P catcher. (this is Checkpoint Specific) This would verify that KaZaA is blocked, even if it is using port 80.
Outgoing KaZaa connections should have some HTTP headers in them distinguishing them from the rest. You can probably implement a simple rule using Squid (I am guessing). I don't know about TIS FW toolkit and Socks, may be somebody on list can throw some light on how these might be useful here.
Else use Snort to check for KaZaa packet patterns and then block those on the internal interface of your FW using Snort Addon scripts. For more info see www.snort.org.
Here are "Bane Banaye" snort rules from their distribution: :) --------------------------- policy.rules: alert tcp $EXTERNAL_NET any -> $HOME_NET 1214 (msg:"P2P Fastrack (kazaa/morpheus) GET request"; flags:A+; content:"GET "; depth:4; reference:url,www.musiccity.com/technology.htm; reference:url,www.kazaa.com; classtype:protocol-command-decode; sid:1383; rev:3;) policy.rules:alert tcp $EXTERNAL_NET any -> $HOME_NET 1214 (msg:"P2P Fastrack (kazaa/morpheus) traffic"; flags:A+; content:"X-Kazaa-Username"; reference:url,www.kazaa.com; classtype:protocol-command-decode; sid:1699; rev:2;) sid-msg.map:1383 || P2P Fastrack (kazaa/morpheus) GET request || url,www.kazaa.com || url,www.musiccity.com/technology.htm sid-msg.map:1699 || P2P Fastrack (kazaa/morpheus) traffic || url,www.kazaa.com --------------------------
A much simpler hassle-free setup might be following:
* Block 1214/TCP inbound on perimeter FW * Block 1214/TCP _both_ inbound and outbound for Desktop clients. This is easier if you use Linux on desktops, simple iptables rules. If you use XP use built in firewall / Set Security Policies tighter. IF you use Win98 use ZoneAlarm or something similar to disable KaZaa from connecting. Apply secure policies using poledit.exe on Win9x.
And if all this doesn't suffice, make sure you have stricter policies for use of resources on your corporate LAN, and report offenders to higher management. ;)
I have blocked kazaa.com from both the proxy and using BIND (made a new zone kazaa.com and put * A 127.0.0.1, record in there, internally every one uses the internal DNSes only.) Still users and myself are able to use kazaa without the users seeing the kazaa.com's homepage, which no one every saw, too busy to download *.* from the WEB...
Now you know why...
have fun, Rajesh