asa5505: access-list niet beschikbaar

[Picaroon]

Beste mensen,

Op een ASA5505 heb ik een port forward aangemaakt van outside -> inside vanwege een interne server die bereikbaar moet zijn op het Internet. Hij zit niet in de DMZ, vanwege de base license. Het betreft een statische nat met access rule. Voor de rest is het een factory default config waar een asdm wizard overheen is gegaan, waarbij PAT wordt gebruikt voor inside -> outside.
De relevante rules:

object network Webserver
host 192.168.1.5
nat (inside,outside) static interface service tcp www www

access-list outside_access_in permit tcp any object Webserver eq www
access-group outside_access_in in interface outside

De forward werkt prima, maar wanneer de access-list om wat voor reden dan ook op inactief gezet moet worden werkt de forward niet meer nadat deze weer actief is gemaakt. Traffic wordt dan gedenied door de implicit rule.

Ik gebruik ASA 8.3.2 en ASDM 6.3.3, maar heb de rules geconfigureerd onder CLI.

[ Voor 3% gewijzigd door Picaroon op 12-12-2010 13:35 ]

[DGTL_Magician]

Dat is toch zoals het bedoeld is?
Als je de Access List er per se tijdelijk af wil halen doe dan:

access-list outside_access_open permit ip any any
access-group outside_access_open in interface outside

[Picaroon]

OP aangepast: nadat de rule dus actief is gemaakt.

Waarom zou ik een "access-list outside_access_open permit ip any any" willen doen op de outside interface waarbij al het binnenkomend verkeer standaard geblockt wordt?

[ Voor 63% gewijzigd door Picaroon op 18-08-2010 15:21 ]

[Verwijderd]

Wat is nu je exacte probleem?

Je hebt een werkende situatie met een port-forward en een ACL welke het webverkeer van buiten naar je server toestaat. Jouw eigen regel "access-list outside_access_in permit tcp any object Webserver eq www" is prima. Je wilt webverkeer vanaf het internet naar jouw webserver openzetten, dus voor elk IP adres. Aangezien je de source poort van de pakketjes richting jouw webserver moeilijk kunt raden is "any" (waarmee je elk IP adres en source poort aangeeft) prima .

Het plaatje van de omgeging in het algemeen ontbreekt, maar het inregelen van een DMZ voor dit soort dingen is imo de way to go. Als je een 5505 met base licentie hebt moet je dan wel of upgraden of tevreden zijn met een kreupele DMZ...

[Picaroon]

@smiley: probleembeschrijving bovenstaande situatie is slechts een voorbeeld. In werkelijkheid gaat het om een gameserver waarvan de UDP port op bepaalde tijden in de asa open gezet dient te worden. Zodra de rule inactive wordt, is de server niet meer bereikbaar. Zodra de rule weer active wordt begint de ellende: de rule is in de asa actief, maar de forward weigert. Zelfs de packet trace in asdm (hoe bout die simulator ook is) ziet geen ENKELE access-list meer. 't Maakt niet uit om welke service of port het gaat.

Samenvatting: De timer, inactive en active mode van een access rule niet goed werken. De enige workaround is de ASA rebooten of de port open te laten staan.

Workaround: reboot ASA of port open laten staan

Vraag: hebben meer mensen dit probleem? Is dit een bug?

[Verwijderd]

8.3.2 is vrij recent, sinds 8.3.x moet de ASA voor normaal functioneren 512MB geheugen hebben. 5505's welke na februari dit jaar gemaakt zijn hebben standaard genoeg geheugen, mocht deze dat niet hebben kun je terug gaan naar versie 8.2.2 of upgraden. Mocht je terug gaan naar 8.2.2 zal je terug moeten in je ASDM software.

Zelf heb ik nog nooit gewerkt met de timer functionaliteit van een ASA, wat is er op tegen om die poort permanent open te zetten?

[ Voor 8% gewijzigd door Verwijderd op 18-08-2010 19:01 ]

[Picaroon]

@smiley: de asa5505 heeft geen 512mb nodig voor 8.3.x tenzij je UL of Sec. plus license wil draaien. Ik heb echter 512MB geheugen.

't Gaat me niet alleen om die poort, maar ook andere poorten die ik niet constant open wil laten staan naar een bak in de inside netwerk. Vervelend als je een duur stukje hardware/software koopt omwille de veiligheid, maar een simpele optie als inactive / active niet blijkt te werken en de ASA moet gereboot worden.... lijkt me niet echt de bedoeling toch?

[Verwijderd]

Hmm, je hebt inderdaad gelijk wat betreft de geheugenvereisten, de ASA die ik moest upgraden was er eentje met een security plus licentie. Ik heb hier nog wel een 5505 staan, wanneer je je gehele configuratie mijn kant op kan laten komen wil ik het hier wel gaan reproduceren?

[Picaroon]

Ok, relaxt dat je 'm ook even wil testen:

Startup-config
: Saved
: Written by enable_15 at 21:19:05.039 UTC Wed Aug 18 2010
!
ASA Version 8.3(2)
!
hostname ASA5505
enable password ******************** encrypted
passwd ******************* encrypted
names
!
interface Vlan1
nameif inside
security-level 100
ip address 192.168.1.1 255.255.255.0
!
interface Vlan2
nameif outside
security-level 0
ip address dhcp setroute
!
interface Ethernet0/0
switchport access vlan 2
!
interface Ethernet0/1
!
interface Ethernet0/2
!
interface Ethernet0/3
!
interface Ethernet0/4
!
interface Ethernet0/5
!
interface Ethernet0/6
!
interface Ethernet0/7
!
ftp mode passive
object network obj_any
subnet 0.0.0.0 0.0.0.0
object network mw2server
host 192.168.1.5
object service mw2
service udp destination eq 28960
object network testserver2
host 192.168.1.5
object service test
service tcp destination eq 27
access-list outside_access_in extended permit object mw2 any object mw2server log debugging inactive
access-list outside_access_in extended permit object test any object testserver2 log debugging
pager lines 24
logging enable
logging asdm debugging
mtu inside 1500
mtu outside 1500
icmp unreachable rate-limit 1 burst-size 1
no asdm history enable
arp timeout 14400
!
object network obj_any
nat (inside,outside) dynamic interface
object network mw2server
nat (inside,outside) static interface service udp 28960 28960
object network testserver2
nat (inside,outside) static interface service tcp 27 27
access-group outside_access_in in interface outside
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
timeout tcp-proxy-reassembly 0:01:00
dynamic-access-policy-record DfltAccessPolicy
http server enable
http 192.168.1.0 255.255.255.0 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 timeout 5
ssh timeout 5
console timeout 0
dhcpd auto_config outside
!
dhcpd address 192.168.1.10-192.168.1.41 inside
dhcpd auto_config outside interface inside
dhcpd enable inside
!

threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
webvpn
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum client auto
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
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 ip-options
!
service-policy global_policy global
prompt hostname context
Cryptochecksum:***********************
: end

Ik wil wel wat jpg's toevoegen, maar moet een URL opgeven... lukt nu niet. Wanneer de testserver2 rule wordt uitgezet en daarna weer aan, ziet de ASA hem niet meer.

Volgens mij zit 't hem in de objecten die de rule aanroept waarmee de asa in de war raakt. Wanneer ik dezelfde rule zonder objecten gebruik (dus de inhoud daarvan rechtstreeks in de access rule) lijkt het wel te werken, maar moet ik echter nog goed uitttesten.

[DukeBox]

Ik kwam vergelijkbare problemen tegen, daarom ben ik ook terug gegaan naar 8.2. Ik vermoed dat het te maken heeft met de switch naar object based acls. Geheugen is het in iedergeval niet, ik heb er 1GB in zitten.
Wat is er overigens 'kreupel' aan de DMZ bij de base license ? Ben nog niet ergens tegenaangelopen.

[Verwijderd]

Dukebox, je kunt bij een 5505 met een base licentie wel drie vlans definiëren al zal je bij een van de drie aanmoeten geven naar welke interface verkeer niet geforward mag worden. Zie ook onderstaande config.

code:

interface Vlan1
 description *** LAN ***
 nameif INSIDE
 security-level 100
 ip address 192.168.1.254 255.255.255.0
!
interface Vlan2
 description *** WAN ***
 nameif OUTSIDE
 security-level 0
 ip address 10.0.0.1 255.255.255.0
!
interface Vlan3
 description *** DMZ ***
 no forward interface Vlan1
 nameif DMZ
 security-level 50
 ip address 172.16.1.254 255.255.255.0
!
interface Ethernet0/0
 description *** LAN ***
!
interface Ethernet0/1
 description *** WAN ***
 switchport access vlan 2
!
interface Ethernet0/2
 description *** DMZ ***
 switchport access vlan 3

Daarnaast zijn objectgeoriënteerde ACL's niet nieuw, wat wel nieuw is, is het NAT stuk waar je nu gebruik moet maken van objecten. Moet er wel bij zeggen dat ik nog niet heel veel gestoeid heb met de 8.3.x software, dus ben benieuwd

[ Voor 5% gewijzigd door Verwijderd op 19-08-2010 00:11 ]

[DukeBox]

Maar dat is toch de eigenschap van een DMZ ? Dus ik begrijp niet wat daar kreupel aan is.

[Verwijderd]

Normaal zou je een DMZ van zowel het LAN als van het WAN moeten kunnen bereiken, dat is op deze manier niet mogelijk. Je geeft namelijk niet voor niets aan dat je LAN security-level 100, DMZ 50 en WAN 0 heeft. Hoger is "meer" trusted en mag dan ook verbinding maken met de apparaten in het DMZ (zolang de ACL dit toestaat), echter is dat met de base licentie dus niet mogelijk.

Wat je dan krijgt is bijv. een webserver in het DMZ welke niet te benaderen is vanaf het LAN. Een ander scenario waarbij een webserver in het DMZ voor authenticatie gebruik wil maken van een DC in het LAN is op deze manier ook onmogelijk. Oftewel; kreupel...

[Picaroon]

't Wordt onmogelijk gemaakt, maar wil niet zeggen dat het ook zo is. Er is een manier om dit probleem te omzeilen met een VM bak... zal binnenkort eens vragen hoe hij dat precies heeft gedaan.

[Verwijderd]

Picaroon, je zou de server een interface in zowel het LAN als in het DMZ kunnen geven, dan kan de machine namelijk alsnog bij het LAN zonder tussenkomst van de ASA. Maar of dat nou een mooie oplossing is...

[DukeBox]

Verwijderd schreef op donderdag 19 augustus 2010 @ 01:11:
Wat je dan krijgt is bijv. een webserver in het DMZ welke niet te benaderen is vanaf het LAN. Een ander scenario waarbij een webserver in het DMZ voor authenticatie gebruik wil maken van een DC in het LAN is op deze manier ook onmogelijk. Oftewel; kreupel...

Vreemd, ben daar nog niet tegenaan gelopen. Mijn server is zowel extern te banaderen via NAT naar DMZ als intern naar DMZ. Maar ik heb inderdaad geen communicatie nodig van DMZ naar intern.

[Picaroon]

@dukebox: maar je hebt dus wel een trafficflow terug van de DMZ naar intern op het moment dat je een connectie opbouwt met een DMZ server?

[Verwijderd]

DukeBox; ik ben benieuwd hoe je dat gerealiseerd hebt . Je zal namelijk bijvoorbeeld niet eens kunnen pingen met een machine van het LAN naar de DMZ. Je ICMP request zal wel aankomen bij de machine in het DMZ maar zijn reply zal niet geforward worden door de ASA naar het LAN.

Weet je zeker dat het hier een 5505 met base licentie betreft en dat je "no forward interface <<inside vlan>>" hebt moeten configureren?

[ Voor 20% gewijzigd door Verwijderd op 20-08-2010 00:01 ]

[DukeBox]

Ja, heel zeker.. was wel van plan een + licentie te kopen, maar nog niet gedaan.

[MrFX]

DukeBox schreef op vrijdag 20 augustus 2010 @ 00:35:
Ja, heel zeker.. was wel van plan een + licentie te kopen, maar nog niet gedaan.

herinner me nog een topic op vmug mogelijk was dit wat je bedoelde

http://www.vmug.nl/module...opic&t=4714&highlight=asa

[Picaroon]

Ik heb het topic doorgelezen, maar er wordt niet expliciet gesproken over verkeer dat wel toegestaan is van dmz -> inside.

Wat ik me dan afvraag: zodra vanuit inside een verbinding wordt geïnitialiseerd, wordt er dan verkeer teruggestuurd ondanks de beperking?

[MrFX]

Picaroon schreef op vrijdag 20 augustus 2010 @ 11:11:
Ik heb het topic doorgelezen, maar er wordt niet expliciet gesproken over verkeer dat wel toegestaan is van dmz -> inside.

Wat ik me dan afvraag: zodra vanuit inside een verbinding wordt geïnitialiseerd, wordt er dan verkeer teruggestuurd ondanks de beperking?

Ik zat net de handleiding (Cisco ASA 5500 Series Configuration Guide using the CLI Software Version 8.3)door te pluizen en deze geeft aan dat het device het inkomende packet ontvangt (volgens access lists, filters, AAA). Vervolgens neemt de asa waar of er een sessie is opgebouwd om hem vervolgens te forwarden naar de inside zone.

[Picaroon]

En een forward naar de inside interface mag dus niet vanaf de dmz vanwege de restrictie (er van uitgaande dat je deze instelt op de dmz interface). Maar blijkbaar werkt dat wel bij eenmaal opgebouwde connecties van uit de inside interface... tnx!

[ Voor 25% gewijzigd door Picaroon op 20-08-2010 16:00 ]

[Verwijderd]

MrFX, vreemd. Ik heb het namelijk gisteravond getest met twee laptops met daarop een netwerksniffer en toen het volgende geconstateerd;

Verwijderd schreef op donderdag 19 augustus 2010 @ 23:59:
Je zal namelijk bijvoorbeeld niet eens kunnen pingen met een machine van het LAN naar de DMZ. Je ICMP request zal wel aankomen bij de machine in het DMZ maar zijn reply zal niet geforward worden door de ASA naar het LAN.

In de logging wordt ook aangeven dat het door de "no forward" geen doorgang krijgt, ongeacht of de sessie vanaf het DMZ of vanaf het LAN geïnitieerd wordt.

[ Voor 4% gewijzigd door Verwijderd op 20-08-2010 18:35 ]

[Picaroon]

Zo heb ik de beperking ook geïnterpreteerd.

OT
@smiley: heb je mijn config nog getest?

[Picaroon]

Probleem is opgelost sinds er ASDM v6.3.4 op staat. Blijkbaar een bugje.