ACL to prevent gnutela, outgoing kazaa, grokster traffic

Similar Questions

• Prevent advertising outgoing packets Spanning tree

  Hello

  I have a switch 2960 with a workstation that is connected.

  The switchport is configured for the portfast and the BPDUguard is enabled on the default switch

  When I have wireshark information on the connected pc then I see a lot of STP packets from the switch.

  I would like to disable these messages because the information located in the capture packets can be abused by an attacker who has access to this workstation, for the configuration of protocols spanning-tree of the company information.

  Is it possible to disable the spanning tree information that is sent from the switch?

  concerning

  Jan

  You should be able to configure bpdufilter to stop it. The only problem is that effectively stop you stp on this port, which could be dangerous.

  Understanding of the functioning of PortFast BPDU filtering

  BPDU filtering allows to avoid transmitting BPDUS on active PortFast ports that are connected to an end system.  When you enable PortFast on the switch, protocols spanning tree ports place in State shipping immediately, instead of going through the listening and learning States of transfer.

  By default, the tree covering weight sends BPDUS of all ports PortFast is only enabled or not. BDPU filtering is on a per-switch basis; After you enable BPDU filtering, it applies to all active ports PortFast on the switch.

  HTH,
  John

  Please note all useful messages *.

• Traffic Internet PIN for router ACL

  Hello, I create a router-on-a-stick typical configuration where remote locations running IOS Cisco direct Internet traffic out through an IPSec tunnel that ends on an ASA5510. I'm 99% it and can't seem to move between the rays and the Internet. I'm looking for advice on how to configure properly the ACL entering the router WAN interfaces spoke.

  My question is, what I specifically authorize the return of Internet traffic in the router speaks ACL? I was under the impression that what allows the Hub ASA IPSec traffic would include traffic Internet has hairpined through the ASA and I wouldn't need a specific ACL entry to addresses of Internet sources.

  The router has spoken, I work now is a 3620 running IOS 12.3.26. When I configure the ACL entering on the WAN Interface to allow only the esp/isakmp Hub ASA, I'm not able to receive traffic from the Internet. If I remove the inbound ACL everything works fine. Here are the current incoming ACL from the laboratory network router:

  access-list authorized note 130 incoming WAN connections

  Note access-list 130 IPSec

  Note LAN Access - list 130 subnets

  access-list 130 allow ip 192.168.75.0 0.0.0.255 192.168.168.0 0.0.0.255

  access-list 130 allow ip 192.168.50.0 0.0.0.255 192.168.168.0 0.0.0.255

  access-list 130 allow ip 10.199.199.0 0.0.0.255 192.168.168.0 0.0.0.255

  Note access-list 130 HUB ASA

  access-list 130 permit udp host 172.16.1.4 host 172.16.1.21 eq non500-isakmp

  access-list 130 permit udp host 172.16.1.4 host 172.16.1.21 eq isakmp

  access-list 130 allow esp 172.16.1.4 host 172.16.1.21

  access-list 130 allow host 172.16.1.4 ahp 172.16.1.21

  Note access-list 130 NTP to the router

  access-list 130 permit udp host 192.43.244.18 ntp host 172.16.1.21 eq eq ntp

  access-list 130 authorized note ICMP traffic

  access-list 130 permit icmp any echo host 172.16.1.21

  access-list 130 permit icmp any any echo response

  access-list 130 permit icmp any any source-quench

  access-list 130 permit icmp any a package-too-big

  access-list 130 allow icmp all once exceed

  access-list 130 refuse icmp a whole

  access-list 130 authorized note circulation of Managment

  Note 130-list of access allow ssh

  access list 130 permit tcp any any eq 22

  With the list above applied inbound access on my WAN Interface, internal hosts are able to ping Internet addresses (allowing a response to ICMP echo) but cannot browse the Internet.

  Should I enable a firewall on the router policy to allow the return of the Internet traffic? I thought that rule of ESP permits that would cover.

  Any help is appreciated!

  Dan

  Dan

  Unless you're running the IOS Firewall feature on your spoke routers then the router is unable to keep the State of outbound connections. So yes, you will need to also allow the traffic unencrypted in your inbound ACLs on the WAN interface because once the traffic is decrypted, it is then checked against the acl on the interface, see this link to order operations.

  http://www.Cisco.com/en/us/Tech/tk648/tk361/technologies_tech_note09186a0080133ddd.shtml

  On ASA/Pix firewalls you can tell the device to check against the acl on the external interface once that traffic has been decrypted with the command "sysopt connection" but I'm not aware of a similar option for IOS.

  Jon

• PowerConnect 6200 ACL does not seem to work

  Hello

  I have a total of four 6248 s two groups at different locations that are configured with VRRP + OSPF.  I tried to set up a simple ACL on either a VLAN to allow a portion of the traffic and block everything else, but I can't make it work.  I have tried many combinations to try to get this working, but so far without success.  It's just a simple ACL, which should allow the web/http traffic on the 10.1.30.100 server and blocks everything else.

  The only type of ACE that seem to work are either a "deny ip any any" or "permit ip any any" If you try an ACE with a destination host and subnet mask 0.0.0.0 it's just all this blocking.  Has anyone else had problems of the ACL or is it just my incompetence in preventing me from getting the 6200 ACL work properly?  I didn't have this problem, get the ACL list to work on our Cisco 2811 routers, just at the moment where I tried on the PC6248s.

  1. config
  2. int vlan 720
  3. no ip-group vlan720-in in access
  4. output
  5. No list of access-vlan720-en
  6. access-list vlan720-in permit tcp any 10.1.30.100 0.0.0.0 eq 80
  7. int vlan 720
  8. IP access-group vlan720-in in
  9. output
  10. output
  11. copy, run start
  12. There

  Just an update on this issue.  I worked with Dell to determine why the ACL does not seem to work.  We discovered that the 6200 apply ACL to the traffic as a VLAN ACL Cisco card as opposed to a router ACL entry.  This causes the ACL to apply to not only routed or transferred but also traffic switched in the same VLAN.

  This has been the source of my problems that my traffic is not limited to a single 6200.  I developed a simple laboratory to check that the 6200 applied traffic switched in the same VLAN ACL.

  First the 6200 has one ACL applied to VLAN5 both PC1 and PC2 are in VLAN 5.  They are both on the same subnet 192.168.5.0/24.  The ACL has a statement of "permit icmp any one" but nothing else.  The PC1 and PC2 are running Windows XP Pro with IIS is installed for the test.  The firewall on both is disabled.

  PC #1 IP: 192.168.5.2/24
  PC #2 IP: 192.168.5.3/24

  [6200]
  |    |
  |    |
  |   [2950T #2] <-->[PC #2]
  |
  |
  [2950T #1] <-->[PC #1]

  In this scenario PC1 and PC2 can ping each other without problem because of the permit icmp any any statement, but you cannot access the IIS site on each of the other computers.

  Dell said that this is normal and if you want communication VLAN VLAN you 'license ip ' to make it work properly.  I also found that traffic back from other VLANs were also denied because of the ACL applied on all of the incoming traffic.  As a solution, the license statement should be included for ALL traffic back to the limited subnet other subnets.  So in this case "ip enable any ".

  I find it a bit annoying that ACL is applied in the form of maps of VLAN not like real incoming router ACL as they are on similar Cisco devices as the 3750.  So there is a work around.  I hope they can solve the problem in a future update, because I really think that the 6200 is a great device.

  Here you can see the difference between VLAN ACLs cards and router entry ACL where they are applied in what concerns local traffic to VLAN.
  http://www.Cisco.com/en/us/docs/switches/LAN/catalyst3750/software/release/12.2_25_see/configuration/guide/swacl.html#wp1572522

• ACL (SVI)

  Can you advise how to install below ACL on a Layer 3 switch.

  Requirement:

  1. block all telnet and ssh traffic in/out of the VLAN 100

  2. allow all other traffic

  interface vlan 100

  IP 10.201.144.2 255.255.255.0

  Colm

  access-list 101 tcp refuse any 10.201.144.0 0.0.0.255 eq 22

  access-list 101 tcp refuse any 10.201.144.0 0.0.0.255 eq 23

  access list 101 ip allow any 10.201.144.0 0.0.0.255

  access-list 102 deny tcp 10.201.144.0 0.0.0.255 any eq 22

  access-list 102 deny tcp 10.201.144.0 0.0.0.255 any eq 23

  access-list 102 permit ip 10.201.144.0 0.0.0.255 any

  interface vlan 100

  IP access-group 101 out

  IP access-group 102 to

  The direction, that they are applied may seem a bit couterintuitive but don't forget

  (1) inbound on an SVI is the traffic from this subnet

  (2) outgoing on IVR traffic going to that subnet

  Jon

• RVS4000, port forwarding - with - IP-based ACL

  G ' Day!

  I want to know if it is possible to enable port forwarding and paste an IP based ACL on the attacker.

  Scenario:

  I replaced my gateway linux with a RVS4000 and reinstalled my linux machine as a file server with sshd running (now residing on my network behind the RVS4000).

  I have forwarded port 22 on the RVS4000 on my linux server - it works as expected. Now I want to restrict which IP addresses which may connect to port 22, that I can't go to work.

  After I forward port 22 to the linux server I can't control it with IP based ACL. Even if I deny all traffic to port 22, it will leave borrowing at the server linux as long as the port is active.

  I am doing something wrong or if this isn't just intended to work the way I want?

  acl based port will not work with the port forwarding on the device. Once you transfer the port are all allowede to enter this port. the acl will not take effect. I think that what you want to do the port binding is not a feature of this device.

• Basic ACL - PowerConnect 6224

  Interfaces:
  G1 = Internet
  G3, g4 = Server (1 GAL)

  G1 has no bound ACL

  I'm trying to bind ACL (s) to 1 SHIFT that will allow a specific Internet traffic-> server and all (later, restrict) the server-> Internet traffic
  (because it is linked to the GAL, as opposed to g1, ACL is applied to the "out" direction)
  (to simplify things I use src/dest all - but later restricted to the IP addresses of the server)

  My rules:

  access-list webau permit tcp any any eq 22
  access-list webau permit tcp any any eq http
  access-list webau permit tcp any any eq 443
  access-list webau permit tcp any any eq 3389
  access-list webau permit tcp any any eq 1935

  Binding of the ACL:

  interface port-channel 1
  IP access-group out webau

  This allowed successfully than traffic from Internet-> server on TCP port numbers specified - well.

  However, the server is unable to get out to the Internet at all.
  (for example, ping, telnet google.com 80)

  I would have thought with no ACLs in, we could deduct all the traffic of the LAG to the switch.

  I also tried:
  access-list permit Allowall each
  interface port-channel 1
  IP access-group Allowall in

  In addition, if I have add the rule to the ACL webau (related to out LAG1):
  Allow Access-list icmp a whole webau

  I can ping the server-> Internet

  or...
  access-list webau permit each

  Server-> Internet is OK

  Finally - any recommendation on whether to apply to ports/channel of the server, with OUT management (as I am) vs apply to the Internet port with direction IN

  Thank you!
  Nick

  
  

• ACL VPN question

  I have two questions that regarding ACL is used in the instructions on the Card Crypto:

  1. the two devices VPN should have the same ACE in the ACL? I know that without the second ACE site B below will not see as interesting udp traffic, but the will of the vpn tunnel fails because the ACL is not the same ACE?

  That is to say...

  Site has

  Access-list 110 permit tcp 10.0.1.0 255.255.255.0 10.0.2.0 255.255.255.0

  Access-list 110 permit udp 10.0.1.0 255.255.255.0 10.0.2.0 255.255.255.0

  Site B

  Access-list 110 permit tcp 10.0.2.0 255.255.255.0 10.0.1.0 255.255.255.0

  2. once a tunnel is established it will send ANY/ALL traffic destined to the remote network through this tunnel. If the first ACE in the ACL 110 to Site A list is used to bring up the tunnel, only tcp from to 10.0.2.0/24 10.0.1.0/24 traffic will use the tunnel or all traffic from 10.0.1.0/24 intended for the remote network to cross the tunnel?

  I guess my thought is this. The ACL is only used to determine valuable traffic and once the tunnel is up it is a free for all. Or the ACL only allows traffic that meets the criteria specified in the ACL list to flow once the tunnel is established?

  Thank you

  Brian

  Brian,

  Your statement

  'Or the ACL allows only traffic that meets the criteria specified in the ACL list to flow after the tunnel is established'

  Is correct, only the traffic that meets the ACL crypto will go through the vpn tunnel and all other traffic will be denied. If you need UDP traffic to travel through the tunnel, you need crypto ACL on both sides and not only on one side, that is, SITE A.

  Hope this helps,

  Jay

• Traffic RV016

  I have a RV016 with an internal address of 192.168.1.1.  Also on the 192.168.1.0 network is a gateway server that the rest of my clients are sitting behind.  The customers are located on a network of 172.16.3.0/24.  All servers in fact bridge is before the packages.  To do this, no NAT.  There is a static route to the 172.16.3.0 on the RV016.

  So my question is how do I get the 172.16.3.0 traffic to route through the RV016?  Computers on the subnet can ping the RV016 and get a response, so I know that the gateway server that forwards packets between the two subnets very well and that the static method Router RV016 works.  All traffic trying to go beyond the RV016 never makes.  He disappears the RV016.  I checked all the ACL and that they should leave all traffic internal through.  Someone at - it suggestions?

  What firmware is your RV016 on?

  If it works on firmware 4.0.3.03 - tm, you need an additional access rule created to pass traffic to the subnet-172.

  Page 3 of the note of firmware version contains more information.

  http://www.Cisco.com/en/us/docs/routers/CSBR/rv0xx/release/RV0xx_RN_v4-0-3-3.PDF

• Interaction of Ganymede + and radius ACS 2.6 download PIX ACLs

  We have ACS v2.6 running and control our connection to remote, routers and switches access. We are now looking to add support for a PIX firewall internal and want to use downloadable ACS ACL for the PIX. (to control outbound traffic through the PIX for authenticated users)

  We have achieved this help attributes RADIUS of Cisco IOS/PIX

  [009\001] cisco-av-pair on ACS. (and ACL restrictions of access on access to users)

  However the problem we noticed is that any user is valid in our database of CiscoSecure or SecureID can authenticate and gain access to through the firewall, even if they are not allowed to do this (and as it is by default on PIX from inside to outside is allowed unlimited full access).

  Was then imposed restrictions on network access on the CiscoSecure ACS for our PIX - to allow only access of corresponding user groups, but it did not work with RADIUS only GANYMEDE + (I guess that's because the RADIUS does not support approval).

  We must work with GANYMEDE + and the passes of the ACS to the bottom of the ACL number/ID for the PIX for users allowed.

  Question: We want to use downloadable s ACL of ACS for the PIX (for reasons of central support) is possible using GANYMEDE + and if yes how we re CiscoSecure ACS suitable for the ACL example below;

  pix_int list access permit tcp any host 10.x.x.x eq 1022

  pix_int list access permit tcp any host 10.x.x.x eq 1023

  Thank you

  Download ACL works only with the RADIUS, as described here:

  http://www.Cisco.com/warp/public/110/atp52.html#new_per_user

  You can continue to set the ACL on the PIX itself and simply pass the ACL via GANYMEDE number (as shown here: http://www.cisco.com/warp/public/110/atp52.html#access_list), but you can actually spend the entire ACL down via GANYMEDE, sorry.

• ACL tcp port filter

  Dear experts,

  I study the ACL to (stop) the tcp port filter at the bottom of the URL

  http://www.Cisco.com/en/us/Tech/tk648/tk361/technologies_configuration_example09186a0080100548.shtml

  In the section of "allow only internal networks to initiate a TCP Session ', grateful if someone could enlighten me the use of the 'established '.

  interface ethernet0 ip access-group 102 in ! access-list 102 permit tcp any any gt 1023 established

  What is different if the ACL is changed as a result of:

  access-list 102 permit tcp any any gt 1023

  RDG

  Both your ACL suggested 101 and 145 are quite correct.

  ACL 105: Note should say, allow traffic back on tcp/80, with the source port greater than 1023. The rest of your comment is correct.

  ACL 115: Note should say allow all traffic with a source port of HTTP (TCP/80) and destination port above 1023.

  ACL 125: Note should say allow all the return of traffic with a source port of HTTP (TCP/80). And Yes, you are right, it also includes the ACL 105 function.

  ACL 135: Note should say allow all traffic with a source port of HTTP (TCP/80). And Yes, you are right, it also includes the ACL 115 function.

• IOS ACL interaction w / inspect CBAC

  Sorry to bother you guys, but I'm banging my head against the wall with this one

  [Vs ACL CBAC Ip inspect]

  Specifically, SDM created the following configuration:

  inspect the IP name SDM_LOW cuseeme

  inspect the IP dns SDM_LOW name

  inspect the IP name SDM_LOW ftp

  inspect the IP h323 SDM_LOW name

  inspect the IP name SDM_LOW https

  inspect the IP icmp SDM_LOW name

  inspect the IP name SDM_LOW imap

  inspect the IP name SDM_LOW pop3

  inspect the IP name SDM_LOW netshow

  inspect the IP rcmd SDM_LOW name

  inspect the IP name SDM_LOW realaudio

  inspect the name SDM_LOW rtsp IP

  inspect the IP name SDM_LOW esmtp

  inspect the IP name SDM_LOW sqlnet

  inspect the name SDM_LOW streamworks IP

  inspect the name SDM_LOW tftp IP

  inspect the tcp IP SDM_LOW name

  inspect the IP udp SDM_LOW name

  inspect the name SDM_LOW vdolive IP

  !

  !

  interface FastEthernet4

  IP 100.100.100.1 255.255.255.0

  IP access-group 101 in

  inspect the SDM_LOW over IP

  access-list 101 deny ip 10.10.10.0 0.0.0.255 any

  access-list 101 permit icmp any host 100.100.100.1 - response

  access-list 101 permit icmp any host 100.100.100.1 time limit

  access-list 101 permit icmp any unreachable host 100.100.100.1

  access-list 101 deny ip 10.0.0.0 0.255.255.255 everything

  access-list 101 deny ip 172.16.0.0 0.15.255.255 all

  access-list 101 deny ip 192.168.0.0 0.0.255.255 everything

  access-list 101 deny ip 127.0.0.0 0.255.255.255 everything

  access-list 101 deny ip 255.255.255.255 host everything

  access-list 101 deny host ip 0.0.0.0 everything

  access-list 101 deny ip any any newspaper

  So as you can see, the DENY ANY ANY of the ACL would block return traffic wouldn't it? I thought that the ACL is applied FIRST? So I guess that by looking at this config when CBAC examines traffic OUT on the external interface, it can - then - create holes in the ACL to allow return traffic. Is this correct?

  And if so, why not simply allow the implicit DENY ALL; does deny ip any all appear explicitly in the ACL?

  I read through the guide 12-4 of the site of Cisco security configuration and do not answer this question.

  Thanks in advance

  :-(

  Your assumption is quite right, THAT CBAC is open a hole in the ACL to allow the return of return traffic.

  Regarding the ip to refuse a whole at the end of the access list, it's a line of best practice added to the access list, if you look at the line, you will notice that there is a keyword of log at the end of the line, so this is to log traffic refused a syslog server for example for you to review traffic later and analyze only in case you get attacked or sth like that.

  You can remove this line if you think it's unnecessary, but as I said to you that it is a good practice when it comes to the access lists.

  Regrads,

  Shadi'

• ASA 5520 8.0 (4) port depending on the ACLs vpn works not

  Hi all

  I have a problem with an ASA (5520 8.0 (4)) for lack of working with a port based acl for remote clients. I have a simple acl from a single line to split traffic, if I allowed the tunnel IP works fine, if I lock it up to TCP 3389 rdp will not work. I don't see anything in the logs and debug output, I did have a problem with a similar configuration (5510 8.0 (4) and I'm at a loss to explain it.)

  Everyone knows about this problem before? I have nat exclusions etc and as I said, the tunnel only works if the acl permits all IP traffic between client and server.

  THX in advance

  Split-tunnel list cannot IP, if you want to restrict which ports are are sent via the tunnel vpn for your clients vpn, you need to use VPN filters under Group Policy:

  http://www.Cisco.com/en/us/products/HW/vpndevc/ps2030/products_configuration_example09186a00808c9a87.shtml

• Capture packets for VPN traffic

  Hi team,

  Please help me to set the ACL and capture for remote access VPN traffic.

  To see the amount of traffic flows from this IP Source address.

  Source: Remote VPN IP (syringe) 10.10.10.10 access

  Destination: any

  That's what I've done does not

  extended VPN permit tcp host 10.10.10.10 access list all

  interface captures CAP_VPN VPN access to OUTSIDE gross-list data type

  Hello

  If you have configured capture with this access list, you filter all TCP traffic, so you will not be able to see the UDP or ICMP traffic too, I would recommend using the ACL, although only with intellectual property:

  list of allowed extended VPN ip host 10.10.10.10 access everything

  Capture interface outside access, VPN CAP_VPN-list

  Then with:

  See the capture of CAP_VPN

  You will be able to see the packet capture on the SAA, you can export the capture of a sniffer of packages as follows:

    https:// /capture//pcap capname--> CAP

  For more details of capture you can find it on this link

  Let me know if you could get the information that you were trying to achieve.

  Please Don t forget to rate and score as correct the helpful post!

  David Castro,

  Kind regards

• Force traffic into the tunnel?

  No IPSEC applied anywhere yet.

  If you have 2 routers configured back to back with the physical interfaces tunnel interfaces - which way will be the traffic travels above?

  Answer - It will follow the path of the routing table that I guess. OSPF or static or other routes.

  Series enough.

  Now add one IPSEC.

  OSPF fails as IPSEC does not support multicast.

  Series enough.

  Now, add IPSEC and GRE to the mix. Apply card crypto both physical and tunnel interfaces.

  Included here is the common ACL associated with free WILL. That is: -.

  access-list 100 permit will host [address physical source] [address physical destination]

  It's the ACL that is supposed to define what traffic is 'interesting' and which must be encrypted.

  We will repeat the question: what should be the traffic?

  I guess it's the same answer. Refer to the routing table.

  But that traffic is encrypted? Answer - ONLY traffic destined to the IP tunnel interface.

  If you ping from physics to physics, it will be clear.

  Question - do you need to force ALL traffic to the bottom of the tunnel interface in the order so he could match the ACL and therefore get encrypted?

  How do accomplish us this?

  Discussion and debate would be greatly appreciated.

  He

  Only traffic with the source/destination of the tunnel interfaces - you just encapsulate & encrypt what happens / leaves the tunnel. If you have two sites connected through a VPN IPSEC, 'interesting' traffic for VPN is the source/destination on tunnel interfaces you need to LAN traffic in the tunnel interfaces. If you have either the static routes, or run you a dynamic routing such as OSPF or EIGRP Protocol.

  You may have a default route pointing to the firewall, a routing protocol dynamic running - so that all "internal" traffic will take place on the tunnel = encrypted vpn to a remote site, while all the 'internet' traffic routes to the firewall and leaves normally.

  HTH