Can some one explain me a simple question.. How is it, with a default FIREWALL, that was delivered with the temple from shorewall. It is possible for some one to connect and use KAZAA, even when it filtered out for normall internet, and Not KAZAA.. Others can connect via kaza, and download with any problems.. And with ICQ, to transfer a FILE, u have to make so many adjustments, to get it to works, same goes for MSN
On Sunday 25 August 2002 11:11 am, Reginald R. Richardson wrote:> Can some one explain me a simple question.. > > How is it, with a default FIREWALL, that was delivered with the temple > from shorewall. > It is possible for some one to connect and use KAZAA, even when it > filtered out for normall internet, and Not KAZAA.. > > Others can connect via kaza, and download with any problems.. > > And with ICQ, to transfer a FILE, u have to make so many adjustments, to > get it to works, same goes for MSNShorewall''s defaults allow any outbound connection and no inbound connections that aren''t related to an existing connection. There are only two modules in the standard kernels for determining if an inbound connection is related -- FTP and IRC. In particular, there are no modules (at least in standard kernels) that deal with ICQ or MSN messenger. If and when such modules become standard then Shorewall support for these applications will also be standard. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
I was also curious about why Kazaa works through the firewall. I looked at the network traffic and came to the conclusion that it is because of the usage of the Kazaa supernodes. When you start Kazaa it initially opens a connection to a supernode (which is allowed by the default firewall rules). Your client sends a list of the files you are sharing to the supernode. After that, others can search for files and download them from you via the supernode. The download is relayed through the supernode to your Kazaa client using the connection the client initially opened. If this is correct then it would also mean that the Kazaa client cannot function as a supernode if it is behind a firewall that does not allow incoming connections on the appropriate ports. /Magnus -----Original Message----- From: shorewall-users-admin@shorewall.net [mailto:shorewall-users-admin@shorewall.net]On Behalf Of Reginald R. Richardson Sent: Sunday, 25 August, 2002 20:11 To: shorewall-users@shorewall.net Subject: [Shorewall-users] ICQ --- Kazaa Can some one explain me a simple question.. How is it, with a default FIREWALL, that was delivered with the temple from shorewall. It is possible for some one to connect and use KAZAA, even when it filtered out for normall internet, and Not KAZAA.. Others can connect via kaza, and download with any problems.. And with ICQ, to transfer a FILE, u have to make so many adjustments, to get it to works, same goes for MSN
On Mon, 26 Aug 2002, Magnus Hyllander wrote:> I was also curious about why Kazaa works through the firewall. I looked at > the network traffic and came to the conclusion that it is because of the > usage of the Kazaa supernodes. When you start Kazaa it initially opens a > connection to a supernode (which is allowed by the default firewall rules). > Your client sends a list of the files you are sharing to the supernode. > After that, others can search for files and download them from you via the > supernode. The download is relayed through the supernode to your Kazaa > client using the connection the client initially opened. >That is certainly a plausible explaination. At any point in time, you can determine the active connections through your firewall and can understand which system initiated the connection. Here are two entries from the output of "shorewall show connections": tcp 6 13 TIME_WAIT src=193.www.xxx.y dst=206.124.146.177 sport=28274 dport=80 src=206.124.146.177 dst=193.136.203.26 sport=80 dport=28274 [ASSURED] use=1 tcp 6 38 TIME_WAIT src=206.124.146.177 dst=206.191.151.2 sport=53676 dport=110 src=206.191.151.2 dst=206.124.146.177 sport=110 dport=53676 [ASSURED] use=1 206.124.146.177 is the IP address of www.shorewall.net (a.k.a. mail.shorewall.net). In the first entry, host 193.www.xxx.y connected to www.shorewall.net on TCP port 80. In the second case, mail.shorewall.net has connected using pop3 to 206.191.151.2 (mail server at my former ISP). Because 206.124.146.177 uses ProxyARP, the second half of the above entries is simply the reverse of the first. Here''s an entry that uses NAT: tcp 6 431999 ESTABLISHED src=192.168.1.5 dst=64.iii.jjj.kkk sport=1338 dport=1863 src=64.iii.jjj.kkk dst=206.124.146.178 sport=1863 dport=1338 [ASSURED] use=1 Here, local system 192.168.1.5 (my Windows XP box) connected to tcp port 1863 on 64.iii.jjj.kkk. Since that box is using NAT (static in that case but SNAT/MASQ will look the same), the second half of the entry is not the reverse of the first. Rather, the second half of the entry reflects the connection on the opposite side of the firewall (in this case, the internet side). There, the local IP address is 206.124.146.178 (the external address associated with 192.168.1.5 in my /etc/shorewall/interfaces file).> If this is correct then it would also mean that the Kazaa client cannot > function as a supernode if it is behind a firewall that does not allow > incoming connections on the appropriate ports. >I agree. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net