topic Re: Blocking P2P file sharing w/PIX 515 in Network Security

Blocking P2P file sharing w/PIX 515

madlm — Fri, 21 Feb 2020 07:45:06 GMT

I found the link below about how to set up an ACL for blocking P2P file sharing. My question is that I was under the impression that the PIX blocked all ports coming in by default and that the only ports allowed are 80 and those defined by the fixup protocol statements....if this is true do I really need to follow the below link info?

http://www.cisco.com/en/US/tech/tk583/tk372/technologies_tech_note09186a00801e419a.shtml

See below....

PIX Version 6.3(3)

interface ethernet0 auto

interface ethernet1 10baset

interface ethernet2 auto

nameif ethernet0 outside security0

nameif ethernet1 inside security100

nameif ethernet2 dmz security4

enable password xxxx

passwd xxxxx

hostname pixCL

domain-name eisenmann.com

fixup protocol dns maximum-length 512

no fixup protocol ftp 21

fixup protocol ftp 20-21

fixup protocol h323 h225 1720

fixup protocol h323 ras 1718-1719

fixup protocol http 80

fixup protocol ils 389

fixup protocol rsh 514

fixup protocol rtsp 554

fixup protocol sip 5060

fixup protocol sip udp 5060

Re: Blocking P2P file sharing w/PIX 515

Patrick Iseli — Tue, 16 Nov 2004 15:53:48 GMT

No, you have to see the fixup protocol more like a proxy service (http. smtp..)that filters out some commands for certain protols and a control mechanism for other ones like h323, sip ... that controls that communication of that protols which ports are used in replys for example.

Definition in command reference v 6.3:

http://www.cisco.com/en/US/products/sw/secursw/ps2120/products_command_reference_chapter09186a00801727a8.html#wp1067379

Usage Guidelines

The fixup protocol command performs the Adaptive Security Algorithm based on different port numbers other than the defaults. This command is global and changes things for both inbound and outbound connections, and cannot be restricted to any static command statements.

To enable a service like http you need a static and an access-list.

YES all inbound connection without a specific access-list on the outside interfacse are by default blocked. But in case of P2P Applications if there is no limitation on an inside access-list the inside hosts can access anything on the Internet and even with an access-list that would just permit foe exmaple http ans https most of that P2P Applications are still working as they use http as standard protocol.

The only way ona PIX to block them is to block the destination IP and ports.

sincerely

Patrick

Re: Blocking P2P file sharing w/PIX 515

sachinraja — Tue, 16 Nov 2004 20:29:26 GMT

To add to patricks post, you can block the following :

depending on the P2P applications, you can configure extended access-lists and block the P2P communication.

for kaaza, block tcp & udp ports 1214

for gnutella, block tcp & udp ports 6346 / 6347

Refer to the following URL for more information of P2P blocking:

http://www.cisco.com/en/US/tech/tk583/tk372/technologies_tech_note09186a00801e419a.shtml#edonkey

All the best !!

Re: Blocking P2P file sharing w/PIX 515

rckymtn — Tue, 16 Nov 2004 23:47:52 GMT

By default the PIX will permit all outbound traffic through. It will also permit all reply traffic to the outbound traffic through.

The PIX will however block all incoming traffic unless you create an Access List to permit certain traffic through.

Once you create an Access List and apply it to an interface, then ANY traffic that you want to permit to pass through that interface MUST be permitted via an Access List statement.

Access Lists are parsed in a top down fashion. Therefore, the firt Access List statement will take precedence over the next Access List statement. Because of this, you must be absolutely certain that the Access List statements are in the proper order to permit or deny the traffic the way you think it should be.

Richard J. Bramble

ribrambl@rmcare.com

Re: Blocking P2P file sharing w/PIX 515

Patrick Iseli — Thu, 18 Nov 2004 01:51:01 GMT

Take a look at this web site:

http://outpostfirewall.com/guide/rules/preset_rules/p2p.htm

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.1dd67f13

So until now it looks like that right:

#Blubster/Piolet Configuration

access-list outbound deny tcp any 128.121.20.0 255.255.255.240 eq www

access-list outbound deny tcp any 128.121.4.0 255.255.255.0 eq www

#eDonkey

access-list outbound deny tcp any any eq 4662

#Kaaza

access-list outbound deny tcp any any eq 1214

access-list outbound deny udp any any eq 1214

#Gnutella

access-list outbound deny tcp any any range 6346 6347

access-list outbound deny ucp any any range 6346 6347

access-list outbound permit ip any any

access-group outbound in interface inside

Please new ones !!!

sincerely

Patrick

Re: Blocking P2P file sharing w/PIX 515

gfullage — Thu, 18 Nov 2004 04:45:37 GMT

I wrote that "Blocking P2P file-sharing apps with the PIX" doco you reference, and believe me, blocking port 1214 will NOT block P2P apps like Kazaa. They do initially try to get out on 1214 but if that is blocked then they'll try any port, including port 80. You can't simply block Kazaa and the like with an access-list.

Best thing to do, if you can't use NBAR in the way I've detailed in the document, but you have some sort of rate-limiting available, is to allow port 1214, but rate-limit it right down to virtually nothing. If the initial 1214 connection succeeds then Kazaa and the like will use it, but because it's been rate-limited right down users will be unable to download anything, or it'll be so slow they'll eventually give up and try from home rather than work.

Re: Blocking P2P file sharing w/PIX 515

Patrick Iseli — Thu, 18 Nov 2004 14:50:50 GMT

Glenn,

I heard on the PVT Security meeting that it will be possible to block auch applications as P2P and Chat.

PIX OS 7.0 features:

Enterprise-class, advanced HTTP inspection services help protect from web-based attacks and other types of “port 80 misuse”

- Includes customizable policies for detecting and blocking tunneled

applications and attacks, including:

- Instant messaging applications (AIM, MSN Messenger, Yahoo)

- Peer-to-peer applications (KaZaA)

- Adds advanced TCP stream re-assembly and de-obfuscation engines for hidden attack detection

- Provides RFC compliance checking for protocol anomaly detection

- Supports HTTP command filtering for improved control and attack mitigation

Will this be in the same way as NBAR ?

sincerely

Patrick

Re: Blocking P2P file sharing w/PIX 515

madlm — Thu, 18 Nov 2004 19:17:44 GMT

What is the release date for 7.0 ?

Re: Blocking P2P file sharing w/PIX 515

Patrick Iseli — Thu, 18 Nov 2004 19:57:43 GMT

First quarter of 2005 as I heard.

Re: Blocking P2P file sharing w/PIX 515

gfullage — Thu, 18 Nov 2004 22:35:26 GMT

PIX v7.0 code is in Phase 2 of the beta at the moment, open beta (open to anyone) is scheduled at this point dor early December, and then it should go into a proper release on CCO early next year. That of course assumes that everything in the beta goes according to plan.

There is a more advanced inspection engine for numerous protocols in v7.0, the HTTP inspection engine will deifantely detect more things. again though this assumes that the traffic is on TCP/80, but if Kazaa or the like connect on a different port then the inspection engine isn't going to see it.

Re: Blocking P2P file sharing w/PIX 515

hugodrax — Wed, 24 Nov 2004 18:51:25 GMT

Does open beta mean a regular user who is not in Phase 2 can go into CCO and see 7.0 as one of the downloadable options?

Re: Blocking P2P file sharing w/PIX 515

shahryar.k — Wed, 24 Nov 2004 22:51:52 GMT

Hi,

I tried to configure using NBAR as detailed by your article but it doesnt seem to work. Imesh still manages to pass through unabated. Sometimes I can see some packets matches but thats it. I have checked out the PDLMs. The latest on Kazaa for e.g was in 2002. Similarly some of the others have not been updated. I am pasting the relevant portions of the config over here.

I think rate-limiting seems to be the better idea, as i do see some matches in the show policy map interface command.

Technical Support: http://www.cisco.com/techsupport

Compiled Sat 28-Aug-04 10:53 by cmong

Image text-base: 0x60008950, data-base: 0x60D0A000

ROM: System Bootstrap, Version 11.1(20)AA2, EARLY DEPLOYMENT RELEASE SOFTWARE (f

c1)

ROM: 3600 Software (C3640-IO3-M), Version 12.2(15)T14, RELEASE SOFTWARE (fc4)

XXX uptime is 1 week, 6 days, 5 hours, 0 minutes

System returned to ROM by reload

System image file is "slot0:c3640-io3-mz.122-15.T14.bin"

cisco 3640 (R4700) processor (revision 0x00) with 123904K/7168K bytes of memory.

Processor board ID 26614988

R4700 CPU at 100Mhz, Implementation 33, Rev 1.0

Bridging software.

X.25 software, Version 3.0.0.

2 Ethernet/IEEE 802.3 interface(s)

3 Serial network interface(s)

DRAM configuration is 64 bits wide with parity disabled.

125K bytes of non-volatile configuration memory.

20480K bytes of pService-policy input: P2P

Class-map: GNUTELLA (match-any)

3720 packets, 231680 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: protocol fasttrack file-transfer "*"

0 packets, 0 bytes

5 minute rate 0 bps

Match: protocol gnutella file-transfer "*"

0 packets, 0 bytes

5 minute rate 0 bps

Match: protocol napster non-std

0 packets, 0 bytes

5 minute rate 0 bps

Match: protocol kazaa2 file-transfer "*"

148 packets, 9493 bytes

5 minute rate 0 bps

Match: protocol http url "\.hash=*"

0 packets, 0 bytes

5 minute rate 0 bps

Match: protocol http url "/.hash=*"

0 packets, 0 bytes

5 minute rate 0 bpsrocessor board PCMCIA Slot0 flash (Read/Write)

Configuration register is 0x2142 (will be 0x2102 at next reload)

Best Regards

Shahryar Khan