cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1670
Views
0
Helpful
8
Replies

ASA5520

laptev.valery
Level 1
Level 1

8.0(4)

asdm615

VPN plus lisens

Access-list inside-in checks only connections going from inside to dmz or to outside interfaces.

Abd do not work for trafic going from outside ot dmz.

for example from host located in inside:

only 1 rule in acl located on inside int.

permit host 10.1.1.1 209.1.1.200 3389

telnet 209.1.1.200 4899

refused by remoute host or unreacheble.

telnet 209.1.1.200 3389

open...

-----------------------------------

that is ok.

-=also static NAT rule from inside to outside=-

-=10.1.1.1 to 209.1.1.1                                  =-

but from host located in outside

telnet 209.1.1.1 3389

open...

telnet 209.1.1.1 4899

open...

------------------------------------

that is not ok! becouse ther is no access rule which permits that session from outside to inside.

i see matches only to access list on outside interface.

to close seesions to inside what can i do?

exept changing access list permit ip any any on outside interface?

ive read this:

1. A TCP SYN packet arrives at the PIX Firewall to establish a new connection.

2. The PIX Firewall checks the access control list (ACL) database to determine if the connection is permitted.

3. The PIX Firewall creates a new entry in the connection database (XLATE and CONN tables).

4. The PIX Firewall checks the Inspections database to determine if the connection requires application-level inspection.

5. After the application inspection function completes any required operations for the packet, the PIX Firewall forwards the packet to the destination system.

6. The destination system responds to the initial request.

7. The PIX Firewall receives the reply packet, looks up the connection in the connection database, and forwards the packet because it belongs to an established session.

from: http://www.cisco.com/en/US/docs/security/pix/pix62/configuration/guide/fixup.html

is that means that if packet permited on 1 acl it will be permited on all othaer acl's???

1 Accepted Solution

Accepted Solutions

Valery,

I think you are missing the "statefull-ness" part of a firewall. When you have an ACL applied to an interface and one is initiating a connection behind that interface, if the ACL allows it then a connection is created. Return traffic for that connection that is coming from the outside will not be checked against the outside interface ACL because we have existing connections for it already.

Now if you want to block outside people from coming to your inside (connections initiated from the outside) you NEED an ACL on the outside. Inside ACLs do not apply to the inbound (outside initiated) connections. So to block outsiders from going to port 3389 you need to block them on the outside interface. I would suggest a "deny" for traffic destined to the internal hosts on the ports you want to block, above your permit any any if you don't want to block more than that.

Rate helpful posts.

PK

View solution in original post

8 Replies 8

Panos Kampanakis
Cisco Employee
Cisco Employee

I am not completely sure about what do you mean but I will try to explain briefly.

If a packet matches a permit in an interface ACL as it hits an interface it creates a connection and subsequent packets that follow that connection will be allowed through. So when  a packet matches a permit or a deny in an ACL line the rest of the ACL below it will not be checked.

Does that answer your question?

PK

thank you for reply*

no, that does not answer my question(sory)

I understand how 1 Acl work.

but how does it work if 2 ACL on 2 different interfaces?

I need to protect my inside from outside and dmz, dmz2, dmz3 ... I would like to put ACL on inside interface.

because if i put it on outside interface, i will need extra ACL on each dmz, that will increase complexity of administrating network

my problem is that ACL on inside interface(in) does not work for connections from outside....

may be there are some special check box to fix it..

Perhaps you would like to do an access-list out of the interface.

So what you do is create the access-list you want then apply it to the egress interface in the outgoing direction, like this.

access-list inside_access_out deny tcp any any eq smtp

access-list inside_access_out permit ip any any

Then apply with the OUT keyword

access-group inside_access_out out interface  inside

Now nobody can send traffic directed to SMTP to my inside network?

Is this what you were looking for?

I am still not following why an ACL will not work.

First let me clarify, an ACL applied on an interface applies to all not existing connection packets/initial connection packets that his the interface. If they are an existing conn packets the ACL does not apply.

If you want to limit inside to outside and dmz then you can do it with an inside ACL. You know what the dmz subnet is. So you allow what you need on the inside for traffic that is destined to the dmz and you allow whast you need for the rest (to outside).

Does it make sense now?

PK

to pkampana: I have allready done this:

If you want to limit inside to outside and dmz then you can do it with an inside ACL. You know what the dmz subnet is. So you allow what you need on the inside for traffic that is destined to the dmz and you allow whast you need for the rest (to outside).

on inside interface access-list to in.

from inside interface every single connection is filtered just fine, but if some one trying to connect from outside to inside, i have no hits to my access-list and all connection is permited. I see hits on the outside interface access-list which is permit ip any any. Is it fine that inside_in access list does not filter connections from outside to inside? or it is impossible to filter both out and in connections whiyh 1 access-list?

to August Ritchie:
now i will try to use inside_out access-list, but it seems to not filter connection from inside to outside.

my test config:

GUESS# sh run
: Saved
:
ASA Version 8.0(4)
!
hostname GUESS
enable password cisco encrypted
passwd cisco encrypted
names
name 10.255.0.2 routerX
name 10.1.7.73 LaptevValery
!
interface GigabitEthernet0/0
nameif outside
security-level 0
ip address 9.18.2.2 255.255.255.128
!
interface GigabitEthernet0/1
nameif inside
security-level 100
ip address 10.255.0.1 255.255.255.248
!
interface GigabitEthernet0/2
no nameif
no security-level
no ip address
!            
interface GigabitEthernet0/3
shutdown
no nameif
no security-level
no ip address
!
interface Management0/0
shutdown
no nameif
no security-level
no ip address
management-only
!
boot system disk0:/asa804-k8.bin
boot system disk0:/asa805-k8.bin
ftp mode passive
object-group network HTTP_Access
network-object LaptevValery 255.255.255.255
object-group protocol TCPUDP
protocol-object udp
protocol-object tcp
object-group service DM_INLINE_TCP_1 tcp
port-object eq ftp
access-list inside_access_in extended permit tcp any any eq 3389
access-list inside_access_in extended permit tcp any eq ftp any inactive
access-list inside_access_in extended permit tcp any gt 1023 any inactive
access-list inside_access_in extended permit ip any any inactive
access-list outside_access_in extended permit ip any any
access-list dmz_access_in extended permit tcp any object-group DM_INLINE_TCP_1 any
pager lines 24
mtu outside 1500
mtu inside 1500
no failover
icmp unreachable rate-limit 1 burst-size 1
asdm image disk0:/asdm-615.bin
no asdm history enable
arp timeout 14400
static (inside,outside) 9.18.2.73 LaptevValery netmask 255.255.255.255
static (inside,outside) 9.18.2.72 routerX netmask 255.255.255.255
access-group outside_access_in in interface outside
access-group inside_access_in in interface inside
route outside 0.0.0.0 0.0.0.0 9.18.2.1 1
route inside 10.0.0.0 255.0.0.0 RouterX 1
timeout xlate 3:00:00
timeout conn 1:00: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
dynamic-access-policy-record DfltAccessPolicy
http server enable
http LaptevValery 255.255.255.255 inside
http RouterX 255.255.255.255 inside
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
telnet LaptevValery 255.255.255.255 inside
telnet timeout 5
ssh timeout 5
console timeout 0
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
username cisco password cisco encrypted
!
class-map inspection_default
match default-inspection-traffic
!            
!
policy-map type inspect dns preset_dns_map
parameters
  message-length maximum 512
policy-map global_policy
class inspection_default
  inspect dns preset_dns_map
  inspect h323 h225
  inspect h323 ras
  inspect rsh
  inspect rtsp
  inspect esmtp
  inspect sqlnet
  inspect skinny 
  inspect sunrpc
  inspect xdmcp
  inspect sip 
  inspect netbios
  inspect tftp
  inspect ftp strict
  inspect http
!
service-policy global_policy global
prompt hostname context
Cryptochecksum:6e3bfe5e3a4083aa25847a7cc90e0147
: end
GUESS#

whith this config i can sucsesfuly conect whith radmin(4899) to 9.18.2.73 from 9.18.2.1 or 10.18.2.1

that is somthing that i really need to fix.

i have changed access-list from in to out, so now i can not access from outside to inside, but have no limits from inside(((

is that possible whith

access-group inside_access_in in interface inside

close target port 3389 in the inside network?

Valery,

I think you are missing the "statefull-ness" part of a firewall. When you have an ACL applied to an interface and one is initiating a connection behind that interface, if the ACL allows it then a connection is created. Return traffic for that connection that is coming from the outside will not be checked against the outside interface ACL because we have existing connections for it already.

Now if you want to block outside people from coming to your inside (connections initiated from the outside) you NEED an ACL on the outside. Inside ACLs do not apply to the inbound (outside initiated) connections. So to block outsiders from going to port 3389 you need to block them on the outside interface. I would suggest a "deny" for traffic destined to the internal hosts on the ports you want to block, above your permit any any if you don't want to block more than that.

Rate helpful posts.

PK

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: