Deny traffic by vrf - acl?

Hello,
I have a service provider network with multiple public vrfs and some private vpns also.  We liked the design of this it seemed to keep the public routing completely separate from the core routing.  However it seems there is an awkward do to shut, as if we set a public addressed sub-interface for a customer ssh access is available.  We want to keep ssh access around out network, so have filtered out who can access using acl on the vty, say to 10.x.x.x
However we also have some private vpns, so I could quite easily set 10.x.x.x addressing which would allow people to attempt ssh access.
So basically, what is the best way to completely drop all telnet/ssh access to sub-interfaces on a per vrf basis, i.e. if you are in this vrf, regardless of IP, you cannot ever see telnet/ssh ports filtered/closed or otherwise?
Many thanks
Nicholas

Hello,
Many thanks for the reply.  Unfortunately this will restrict telnet through the interface - we want to allow our customers to use any application through our router.  So we can do:
10 deny tcp any 10.x.x.x eq telnet
20 permit ip any any
And apply this to the interface.  However if we give a customer a couple of private vpn to route between, we need a sub-interface which could overlap with this address, so be of security interest, and also presumably is open to spoofing.
What I am looking for, if it exists, is to completely disable telnet/ssh services on an interface, not necessarily by ip access list.
Many thanks
nicholas

Similar Messages

  • Denying telnet traffic from VRF interfaces on the router

    Hi,
    We are currently trying to accomplish incomming telnet traffic from an VRF interface to be denied by the router(7613--IOS:12.2(18)SXF4). In the line vty , we have associated an access-class specifying the block should be allowed for inbound telnet connection to the router. This is working good but it also allows the incomming telnet from an VRF interface having the same block as the global table block which is configured for allowing the incomming telnet connection. We don't want to allow any telnet connection from the vrf interface , even though it matches the permit block in the access-list
    Kindly note that, we have not specified vrf-also command on the access-class.
    Please let us a way to accomplish the above requirement .
    Thanking You
    Regards
    Anantha Subramanian Natarajan

    Hi,
    Thanks for the suggestion.
    I think, I haven't made my requirement clear. We would not like applying access-list to the VRF interfaces to acheive this requirement bcos, then we may have to bind to all the VRF interfaces(I mean customer interfaces),we acting as service provider. We are looking the way by applying access-class binded to line vty ,which is common to all the telnet traffic.
    Kindly let us know,if you have some suggestions on the same
    Regards
    Anantha Subramanian Natarajan

  • Howto control/filter traffic between VRF-(lite) using route leaking?

    Hi,
    does anybody know how I can control/filter the traffic between two vrf when I use route leaking or also normal route target export/import connections, maybe with an acl, in the following scenarios?
    Scenario 1:
    I use a normal MPLS network with several PE routers (maybe ASR series) which connect to the CE routers via OSPF. Two VPNs are configured on the PE routers and I want one of PE routers to allow/route traffic between these VPNs but especially traffic on tcp port 80 and no other ports. I'm only aware of bindung acls to logical or physical interfaces but I don't know how to do this here.
    Scenario 2:
    Same as scenario 1 but not the PE router will connect the VPN but a separate router-on-a -tick (e.g. 4900M) which is connected to one of the PE routers should do this job with vrf-lite and route leaking (address-family ipv4 vrf ...). Also here I want only to allow tcp port 80 between the vpns
    Kind Regards,
    Thorsten

    Thanks.
    That's what I was assuming. In my experience this solution does not scale with increasing number of vpn and inter vpn traffic via route target.
    Is it correct that there is only one common acl per vpn where all rules for the communication to all other vpns are configured? Doesn't this acl become too complex and too error-prone to administrate in a real network environment? Further on in my understanding this acl has to be configured per vpn on all pe routers which have interfaces to ce routers for that vpn.
    Does cisco offer software for managing this?

  • ACE and selection of traffic based on ACL

    Hi Folks,
    I have noticed on the ACE it is possible to select traffic to hit a chosen farm based on an ACL. On further look into the ACE ACL, i was not able to determine whether the ACL can match IP DSCP value, like you can on the IOS side.
    Can someone please confirm if its possible to have an ACE ACL matching a specific DSCP value in the packet.
    Best Regards
    Alan

    Alan,
    unfortunately this is not possible.
    Gilles.

  • UDP traffic not hitting ACL when logged

    2821 ISR
    I've got a DAPE ACL I'm trying to build. One of the entries that caused a lot of problems was permitting NTP (UDP 123). I had an entry like this on an ACL:
    permit udp <my.src.lan.ip> 0.0.0.255 host <our.external.NTP.server> log
    This line did not get any hits, and NTP updates were failing on our Windows clients. (the final line is a deny ip any any)
    I changed this line to read:
    permit udp <my.src.lan.ip> 0.0.0.255 host <our.external.NTP.server>
    Note that the only difference is that I'm not logging this line.
    Once change, I saw hits on this line, and NTP updates on our Windows clients suddenly started going through and working.
    Is this normal behavior? I can't see why logged ACL entries would make them fail to get picked up and let through.

    Hello.
    I believe the entry is not interface ACL, but NAT ACL.
    "log" keyword is not supported inside NAT ACLs, that is why you observed connectivity issue.

  • Denying traffic for unknown routers/WAPS

    I support several SG200-26p Small Business switches.  As our networking has grown more complex, I'm now starting to venture beyond basic configurations.
    With the 200 series switches, is it possible to deny service / turn off a port if an unknown WAP, Switch or additional router is detected on the SG200?
    Thanks!

    Hello [email protected],
    Here is a link to the admin guide:  http://www.cisco.com/c/dam/en/us/td/docs/switches/lan/csbss/sf20x_sg20x/administration_guide/78-21139.pdf
    On page 262 in the beginning of configuration of port security.
    Here is some of the information you may be interested in:
    Port Security has four modes:
    • Classic Lock—All learned MAC addresses on the port are locked, and the
    port does not learn any new MAC addresses. The learned addresses are
    not subject to aging or re-learning.
    • Limited Dynamic Lock—The device learns MAC addresses up to the
    configured limit of allowed addresses. After the limit is reached, the device
    does not learn additional addresses. In this mode, the addresses are
    subject to aging and re-learning.
    • Secure Permanent—Keeps the current dynamic MAC addresses
    associated with the port and learns up to the maximum number of
    addresses allowed on the port (set by Max No. of Addresses Allowed).
    Relearning and aging are disabled. 
    • Secure Delete on Reset—Deletes the current dynamic MAC addresses
    associated with the port after reset. New MAC addresses can be learned
    as Delete-On-Reset ones up to the maximum addresses allowed on the
    port. Relearning and aging are disabled. 
    Hope this helps,
    Michael D.
    If this post is helpful please rate or mark as correct.

  • No ACL deny logs for Traffic not matched by Static Object NATs and ACL. Need Help.

    I start noticing that I do not see any denied traffic coming in on my ACL.  To better explain, lets say I have this config.
    ### Sample Config ###
    object network webserver
    host 192.168.1.50
    nat (dmz, outside) static X.X.X.X service tcp www www
    access-list inbound extended permit ip any4 object webserver eq www
    If I generate a traffic from the outside let's say a traffic that is trying to access X.X.X.X via TCP Port 8080 which obviously does not have any NAT entry to it going to my DMZ, I don't see the ACL denies it anymore but instead comes back with a Drop Reason: (nat-no-xlate-to-pat-pool) . On the packet trace I got this. (Below) it seems that does not even hit the ACL as there is no xlate found for it, at least to what the drop reason says.
    Phase: 1
    Type: CAPTURE
    Subtype:
    Result: ALLOW
    Config:
    Additional Information:
    MAC Access list
    Phase: 2
    Type: ACCESS-LIST
    Subtype:
    Result: ALLOW
    Config:
    Implicit Rule
    Additional Information:
    MAC Access list
    Phase: 3
    Type: ROUTE-LOOKUP
    Subtype: input
    Result: ALLOW
    Config:
    Additional Information:
    in   0.0.0.0         0.0.0.0         Outside
    Result:
    input-interface: Outside
    input-status: up
    input-line-status: up
    output-interface: Outside
    output-status: up
    output-line-status: up
    Action: drop
    Drop-reason: (nat-no-xlate-to-pat-pool) Connection to PAT address without pre-existing xlate
    Before, using a regular Static PAT on ASA Versions 8.2(5) below, I could get the deny logs (ASA-4-106023). Generally, I use these logs, and are quite important for us specially during auditing.
    My question is how can I generate logs for these type of dropped traffic on the ASA 9.1 Version? 
    Any comments/suggestions are gladly appreciated :)
    Regards,
    John

    I believe, but am not 100% sure, that the reason you are not seeing the ACL drop but a no NAT matched is because of the changes from 8.2 to 8.3 in the order of how things are done.  In 8.3 and later you need to secify the real IP address when allowing packets in, and this is because NAT happens before the ACL is matched.  So since there is no match on the NAT the packet is dropped then and there, never reaching the stage where ACLs are checked.
    As to seeing drops in the ACL log...You might want to try adding an ACL that matches the NATed IP...but I don't think you will have much success with that either.  My guess is that there is no way around this...at least no way I know of.
    Please remember to select a correct answer and rate helpful posts

  • ACL do you define all traffic?

    Is it best practice to create an ACL on each interface that specificies what traffic is allowed and everything is denied?
    I've got a couple of interface on my ASA that someone has put in a rule that says allow any to any. I would assume that would not be a good idea.

    Hi,
    I personally prefer to only allow traffic from the actual source network that are located behind the interface instead of specifying the source as "any" in the ACL statement.
    I also tend to add a "deny ip any any" statement at the end of the interface ACL (even though it already contains Implicit Deny). This is because this will let me actually see the hitcount of denied traffic on that interface while the Implicit Deny counter cannot be seen.
    Naturally if you have the "ip verify reverse-path " configured for your LAN/DMZ interface then that will already make sure that traffic is not allowed from source addresses/networks that according to ASA routing table are NOT located behind the source interface.
    - Jouni

  • Denying all traffic on the inside unless specified

    Hi Is there a way to configure my asa5505 to dent all traffic on the inside so i can specify what ip or host  can access specific protocol or ports via access list? im thinking mabe i ned to set the inside security level to 0 also and then specify any ideas.

    Hi,
    Well it is pretty simple,
    You will have to use ACL and simply only allow the traffic you need to allow. Since the ACL automatically denies any traffic that isnt specifically permitted you dont really need any deny statements even.
    You cant make specific rules with the "security-level" alone and using an interface ACL basically makes the "security-level" useless for the most part.
    As soon as you configure an ACL like this for example
    access-list INSIDE-IN permit tcp any host 1.1.1.1 eq 80
    access-group INSIDE-IN in interface inside
    It will mean that only traffic that is allowed is TCP/80 traffic to destination IP address 1.1.1.1. All other traffic will be blocked because of the Implicit Deny in every ACL. It wont show in the CLI configuration. Naturally if you want you can always add the deny rule to the ACL to see the hitcount of traffic that has not matched the previous rules
    access-list INSIDE-IN permit tcp any host 1.1.1.1 eq 80
    access-list INSIDE-IN deny ip any any
    access-group INSIDE-IN in interface inside
    You will have to make sure that you dont block any essential services your users might need like usually HTTP, HTTPS, DNS for example. It really depends on what you are trying to achieve.
    - Jouni

  • ACL access denied exception

    Hello Everyone,
    I am trying to log into an application which uses ACL (ldap auth) for user say "xxx", while entering the username and password I see the following error in the log file in Sun one webserver 6.0, solaris 8 platform (I have changed the host IP and folder informations, rest remains the same)
    [NSACL4340] ACL_GetAttribute: All attribute getters declined for attr "cert"
    [23/Dec/2008:11:54:50] security (16450): for host 111.111.111.11 trying to GET /servlet/ActionServlet, acl-state reports: access of /yy/abcWebserver6.0/https-test/tester/servlet/ActionServlet denied because evaluation of ACL uri=/servlet/ActionServlet directive 2 failed
    [23/Dec/2008:13:12:35] security (16450):
    [NSACL4340] ACL_GetAttribute: All attribute getters declined for attr "cert"
    [23/Dec/2008:13:12:35] security (16450): for host 111.111.111.11 trying to GET /servlet/ActionServlet, acl-state reports: access of /yy/abc/Webserver6.0/https-test/tester/servlet/ActionServlet denied because evaluation of ACL uri=/servlet/ActionServlet directive 2 failed
    Please let me know if any information is required, I can provide.
    Thanks in advance.

    can you send your *.acl files?
    [NSACL4340] ACL_GetAttribute: All attribute getters declined for attr "cert"do u have cert in those ACL files? Have you stored certificates in LDAP ? If you want normal (basic auth) user name password authentication, you do not need those.

  • ISE Airespace ACL WLC problem

    Hello,
    i've configured ISE and WLC to use guestportal with CWA but there is a problem with CoA -- it doesn't want to apply airespace alc after auth at guestportal.
    1. At authC page i've configured a wireless MAB to continue if user not found and to use a Internal users as a identity store.
    2. At authZ page i've configured a WEBAUTH as a default rule with the following:
    Access Type = ACCESS_ACCEPT
    cisco-av-pair = url-redirect-acl=ACL-WEBAUTH-REDIRECT
    cisco-av-pair = url-redirect=https://ip:port/guestportal/gateway?sessionId=SessionIdValue&action=cwa
    3. I've also configured this ACL at WLC to permit
    permit dns and icmp any-any
    permit any-to-ise-8443
    permit ise-to-any
    This part works fine because i able to redirect to guestportal and use my guest login&pw to authorize myself. The guest account was previously generated through sponsor portal and it's working too.
    4. At authC page i've use a wireless dot1x to use Internal users
    5. At authZ page i've use a "if internal users:Guest then GUEST permission" rule
    6. GUEST rule looks like the following:
    Access Type = ACCESS_ACCEPT
    Airespace-ACL-Name = GUEST_INTERNET_ONLY
    7. This ACL is configured on the WLC permitting any except private networks (ISE is also permitted)
    After guest portal auth i see a success message and i able to ping internet but i have no web access to it. It looks like CoA and Airespace acl are don't working and i keep using my ACL-WEBAUTH-REDIRECT access-list and i see a strange error messages in the WLC logs:
    *apfReceiveTask: Nov 12 17:32:27.317: %ACL-3-ENTRY_DONOT_EXIST: acl.c:369 Unable to find an ACL by name "".
    I swear my ACL name spelling is correct and both ACL-WEBAUTH-REDIRECT and GUEST_INTERNET_ONLY are on the WLC with their counters growing!
    I don't have a point what issue it could be...
    Any ideas?
    P.S. see attach for Live authentication log

    Thank you guys for your responses, it's working now!
    The first problem was there:
    Changing IPv4 ACL 'none' (ACL ID 255) ===> 'GUEST_INTERNET_ONLY' (ACL ID 5)
    There are only 3 ACLs on my WLC so ALC ID 5 is kinda suspicious -- after WLC reload it becames ACL ID 1 but the problem was unresolved.
    After that i changed my authZ matching rule to use another authZ profile:
    Access Type = ACCESS_ACCEPT
    Airespace-ACL-Name = PERMIT_ALL_TRAFFIC
    cisco-av-pair = Airespace:Airespace-ACL-Name
    Then i created ACL PERMIT_ALL_TRAFFIC on my WLC with one ACE "permit any any". I also denied access to my private networks at ASA where guest vlan's gateway resides.
    I think the problem was in WLC's GUEST_INTERNET_ONLY ACEs which denied traffic to my private networks.
    Thanks for the help!

  • Acl in class-map

    Hi
    i'm a little unsure of how using ACL's works within a class map.
    I want to allow access to a web server 1.1.1.1 and deny all othetraffic coming from the outside zone to the inside zone, so i have created an acl with a
    permit http to 1.1.1.1 and a deny ip any any statement and applied it to the class map.
    when i apply this to the policy map i can either inspect, drop or pass the traffic.
    what i don't understand is how this works with the ACL permit or deny statements or the implicit deny functionality of the ACL.
    for example if I apply the pass action to this class-map/ACL how does it handle the deny ip any any statement in the ACL?
    If i am passing the traffic in the policy, does it still deny any deny statements in the ACL?
    ​​also what about multiple class maps in a policy map, wouldn't a deny statement in the first acl stop further processing in the policy map
    hope this makes sense..
    thanks for any help

    When using ACLs in a class map, a permit entry causes the ACL condition to match and a deny entry does not. So, for your ACL "permit tcp any host 1.1.1.1 eq www", any HTTP traffic to 1.1.1.1 on 80/tcp will be matched by the class map and the implicit "deny ip any any" will not be matched. There is no action implied by the ACL when used this way, only a match or no match.
    ip access-list extended ACL_HTTP
    permit tcp any host 1.1.1.1 eq www
    class-map type inspect match-any CM_HTTP
    match access-group name ACL_HTTP
    In order to actually deny the traffic, you have to specify a drop in the policy map.
    policy-map PM_HTTP
    class CM_HTTP
    inspect
    class class-default
    drop
    To illustrate the point a bit further, let's say you were going to allow HTTP and HTTPS with two ACLs and did it like this:
    ip access-list extended ACL_HTTP
    permit tcp any host 1.1.1.1 eq www
    ip access-list extended ACL_HTTPS
    permit tcp any host 1.1.1.1 eq 443
    class-map type inspect match-any CM_HTTP
    match access-group name ACL_HTTP
    match access-group name ACL_HTTPS
    policy-map PM_HTTP
    class CM_HTTP
    inspect
    class class-default
    drop
    In the above case, HTTP traffic to 1.1.1.1 is a hit on ACL_HTTP's permit statement, is matched by the class map and is inspected by the policy map. HTTPS traffic to 1.1.1.1 is a hit on ACL_HTTPS's permit statement, is likewise matched by the class map and is inspected by the policy map. The implicit deny statements (and any other deny statements you may add) only ensure that the packet doesn't match that element of the class map and doesn't prevent it from being matched against another.

  • ASA5520 ACL established connections problem

    Hello,
         I have one ASA5520 with version 8.4(3), and a few ACL rules defined. One ACL is permit traffic from one interface(EXT_SERVICE) to another interface(DMZ_SERVICE), if i change that rule to deny traffic, all new connections that match the rule is denied, but no the established connectios. ¿Why the established connections can pass the deny rule? ¿How I can change that? I need create a ACL with deny type and stop all comunications that is running and match the deny rule.
    Thanks for help!!
    Running-config of my ASA5520:
    ciscoasa# show run
    : Saved
    ASA Version 8.4(3)
    hostname ciscoasa
    enable password 8ay2wjIyt7RRXU24 encrypted passwd 2wFQnbNIdI.2KYtU encrypted names !
    interface GigabitEthernet0/0
    description TRUNK 0A 1/2
    channel-group 1 mode active
    no nameif
    no security-level
    no ip address
    interface GigabitEthernet0/1
    description TRUNK 0A 2/2
    channel-group 1 mode active
    no nameif
    no security-level
    no ip address
    interface GigabitEthernet0/2
    description TRUNK 1A 1/2
    channel-group 1 mode active
    no nameif
    no security-level
    no ip address
    interface GigabitEthernet0/1
    description TRUNK 0A 2/2
    channel-group 1 mode active
    no nameif
    no security-level
    no ip address
    interface GigabitEthernet0/2
    description TRUNK 1A 1/2
    channel-group 2 mode active
    no nameif
    no security-level
    no ip address
    interface GigabitEthernet0/3
    description TRUNK 1A 2/2
    channel-group 2 mode active
    no nameif
    no security-level
    no ip address
    interface Management0/0
    nameif management-ha
    security-level 100
    ip address 192.168.199.223 255.255.255.0 !
    interface Port-channel1
    nameif TRUNK_0A
    security-level 0
    no ip address
    interface Port-channel1.21
    vlan 21
    nameif DMZ_EXPLO
    security-level 70
    ip address 192.168.21.223 255.255.255.0 !
    interface Port-channel1.31
    vlan 31
    nameif EXT_EXPLO
    security-level 0
    ip address 192.168.3.223 255.255.255.0 !
    interface Port-channel2
    nameif TRUNK_1A
    security-level 0
    no ip address
    interface Port-channel2.11
    vlan 11
    nameif INTERNA
    security-level 90
    ip address 192.168.11.223 255.255.255.0 !
    interface Port-channel2.22
    vlan 22
    nameif DMZ_SERVICE
    security-level 70
    ip address 192.168.22.223 255.255.255.0 !
    interface Port-channel2.32
    vlan 32
    nameif EXT_SERVICE
    security-level 0
    ip address 192.168.1.151 255.255.255.0 !
    boot system disk0:/asa843-k8.bin
    ftp mode passive
    clock timezone CEST 1
    clock summer-time CEDT recurring last Sun Mar 2:00 last Sun Oct 3:00 object network GW-SERVICE  host 192.168.1.200  description Xircom access-list DMZ_SERVICE_access_out extended permit ip any any inactive access-list DMZ_SERVICE_access_out extended deny ip any any access-list DMZ_SERVICE_access_in extended permit ip any any inactive access-list DMZ_SERVICE_access_in extended deny ip any any access-list EXT_SERVICE_access_in extended permit ip any any inactive access-list EXT_SERVICE_access_in extended deny ip any any access-list EXT_SERVICE_access_out extended permit ip any any inactive access-list EXT_SERVICE_access_out extended deny ip any any access-list global_mpc extended permit ip any any access-list default standard deny any pager lines 24 logging enable logging asdm informational mtu management-ha 1500 mtu TRUNK_0A 1500 mtu DMZ_EXPLO 1500 mtu EXT_EXPLO 1500 mtu TRUNK_1A 1500 mtu INTERNA 1500 mtu DMZ_SERVICE 1500 mtu EXT_SERVICE 1500 no failover icmp unreachable rate-limit 1 burst-size 1 asdm image disk0:/asdm-647.bin no asdm history enable arp timeout 14400 access-group DMZ_SERVICE_access_in in interface DMZ_SERVICE access-group DMZ_SERVICE_access_out out interface DMZ_SERVICE access-group EXT_SERVICE_access_in in interface EXT_SERVICE access-group EXT_SERVICE_access_out out interface EXT_SERVICE route EXT_SERVICE 0.0.0.0 0.0.0.0 192.168.1.200 1 timeout xlate 3:00:00 timeout pat-xlate 0:00:30 timeout conn 0:05:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02 timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00 timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00 timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute timeout tcp-proxy-reassembly 0:01:00 timeout floating-conn 0:00:00 dynamic-access-policy-record DfltAccessPolicy user-identity default-domain LOCAL http server enable http 192.168.1.0 255.255.255.0 EXT_SERVICE no snmp-server location no snmp-server contact snmp-server enable traps snmp authentication linkup linkdown coldstart telnet timeout 5 ssh timeout 5 console timeout 0 threat-detection basic-threat threat-detection statistics access-list no threat-detection statistics tcp-intercept ntp server 84.88.69.32 source EXT_SERVICE prefer ntp server 130.206.3.166 source EXT_SERVICE prefer ntp server 93.92.239.129 source EXT_SERVICE ntp server 212.36.75.245 source EXT_SERVICE
    webvpn      
    class-map global-class
    match access-list global_mpc
    match default-inspection-traffic
    policy-map type inspect dns preset_dns_map  parameters
      message-length maximum client auto
      message-length maximum 512
    policy-map type inspect im im
    parameters
    match protocol msn-im yahoo-im
      drop-connection log
    policy-map type inspect ipv6 ipv6
    parameters
    match header routing-type range 0 255
    policy-map global-policy
    class global-class
      inspect ctiqbe
      inspect dcerpc
      inspect dns
      inspect esmtp
      inspect ftp
      inspect h323 h225
      inspect h323 ras
      inspect http
      inspect icmp
      inspect icmp error
      inspect ils
      inspect ip-options
      inspect ipsec-pass-thru
      inspect mgcp
      inspect netbios
      inspect pptp
      inspect rsh
      inspect rtsp
      inspect sip
      inspect skinny
      inspect snmp
      inspect sqlnet
      inspect sunrpc
      inspect tftp
      inspect waas
      inspect xdmcp
    class class-default
      inspect ftp
    service-policy global-policy global
    prompt hostname context
    no call-home reporting anonymous
    Cryptochecksum:23a90a41872bc184caa246b8848b4183
    : end
    ciscoasa#

    Ok Pavel,
         I am try to do that you said, but it doesn't work as I spected, sorry for my error and please if you know a document to explain me how do that better than I was do please let me it and I will try
    I have these rules:
    access-list DMZ_SERVICE_access_out extended permit tcp any any eq ssh
    access-list DMZ_SERVICE_access_out extended deny ip any any
    access-list DMZ_SERVICE_access_in extended permit tcp any any eq ssh
    access-list DMZ_SERVICE_access_in extended deny ip any any
    access-list EXT_SERVICE_access_in extended permit tcp any any eq ssh
    access-list EXT_SERVICE_access_in extended deny ip any any
    access-list EXT_SERVICE_access_out extended permit tcp any any eq ssh
    access-list EXT_SERVICE_access_out extended deny ip any any
    access-list global_mpc extended permit ip any any
    access-list default standard deny any
    Ok, Now I'm simulating a hacker that connect over ssh to one host in DMZ_SERVICE network, connect to that host over ssh, and while the ssh connection is running I write this to the ASA:
    access-list EXT_SERVICE_access_in line 1 extended permit tcp any any eq ssh  inactive
    access-list DMZ_SERVICE_access_in line 1 extended permit tcp any any eq ssh  inactive
    access-list DMZ_SERVICE_access_out line 1 extended permit tcp any any eq ssh  inactive
    access-list EXT_SERVICE_access_out line 1 extended permit tcp any any eq ssh  inactive
    The ssh connection is still alive
    Sorry if I wasn't understand your advice. Please coud you explain me the method of cut the stablished malicious established connections?
    I see that if I define a 'Service Police Rule' the ping(icmp traffic) is blocked with the ACL change to deny.
          class-map global-class1
            match default-inspection-traffic
          policy-map global-policy
            class global-class1
              inspect icmp
    ¿Perhaps is the this the way?

  • Guest Traffic Segregation without using Anchor Controller

    Hi
    I need help in calrifiing , is there any other option avaialble to segregate the guest traffic from CORP on internal WLC itself without using anchor controller ?

    Well really can't tell you or else it would be a book. You either have use ACL's on your layer 3 to deny traffic from your guest subnet to your internal. Nothing has to change on the WLC. If you want to connect one port of the WLC to the DMZ, then disable LAG on the WLC and use port one as primary for the internal traffic which includes management and another port in the WLC as primary for the guest.
    Sent from Cisco Technical Support iPhone App

  • Network Admission Control & ACL,s

    In doc
    http://www.cisco.com/en/US/customer/products/ps6350/products_configuration_guide_chapter09186a00804dfa81.html
    with regard to the interface ACL it says
    access-list access-list-number {permit | deny} protocol source destination
    Example:
    Router (config)# access-list 105 permit udp any any
    or
    Router (config)# access-list 105 permit ip host 192.168.0.2 any
    or
    Router (config)# access-list 105 deny ip any any
    Normally "access-list 105 deny ip any any"
    would block everything. Is NAC clever enough to allow EAPoUDP traffic through this ACL. If so what is the point of the previous 2 examples, if not what is the point of blocking everything

    I believe it should be as below:
    Router (config)# access-list 105 permit udp any any
    or
    Router (config)# access-list 105 permit ip host 192.168.0.2 any
    and
    Router (config)# access-list 105 deny ip any any

Maybe you are looking for