Problem inbound Verkehr

[pete.db 10]

Hallo zusammen,

da mein letzter Post anscheinend etwas unklar ausgedrückt war, versuche ich hier noch mal eine andere Problembeschreibung, diesmal mit Config im Gepäck.

 

Ich muss an meiner ASA5510 Sec+ einem Server in der DMZ Zugriff aiuf einen Server im internen Netz geben.

Mit der beiliegenden Config läuft Verkehr von der dmz in das interne Netz nur wenn ich ACL (CRYPTOACL) vom nat0-Statement am internen Netz (nat (intern) 0 access-list CRYPTOACL) um folgendes erweitere:

 

ACL*1 access-list CRYPTOACL permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0

 

Erst dann läuft überhaupt irgendwelcher Verkehr von der DMZ in das interne Netz.

Wenn ich das weglasse, egal wo ich statics und acls setze, läuft nichts von der dmz nach intern.

 

Die erste Frage wäre also, wieso muss ich das hier platzieren und geht das auch anders? Das nat 0 -Statement ist doch eigentlich nur für das VPN.

 

Wenn ich den o.g. Eintrag setze, ist allerdings jeglicher Verkehr von der dmz in das interne Netz freigegeben.

Daher habe ich die unten folgende ACL auf "in interface dmz gebunden".

 

ACL*2 access-list DMZ permit ip host 192.168.2.10 host 192.168.1.25

 

Damit habe ich den verkehr von der dmz in das interne Netz soweit eingeschränkt, dass nur der dmz-Server 192.168.2.10 auf den internen Server 192.-168.1.25 zugreifen kann.

Jedoch kann dann kein Server in der dmz mehr ins Internet.

Das funktioniert nur wenn ich die acl um folgendes erweitere:

 

ACL*3 access-list DMZ permit ip any any

 

...was ja mal nicht wirklich Sicherheit verspricht.

 

Meine Fragen wären:

 

1: Wieso läuft der Verkehr zwischen dmz und internem Netz nur wenn ich das ACL*1 setze? Das nat 0 -Statement ist doch eigentlich nur für das VPN

2: Wenn ich das machen muss, wieso haben meine dmz Server nach der ACL*2 keinen Zugriff mehr auf das Internet und wie kann ich das beheben ohne ACL*3 zu setzen?

3: Mache ich in der config mit den nat-statements oder Bindungen der ACLs generell irgendwas verkehrt?

 

Danke euch schon mal...

 

Verzweiflung@pete.de

 

PS:192.168.1.0/24 -> internes Netz

192.168.2.0/24 -> dmz

192.168.110.0/24 -> über VPN verbundes internes netz am anderen Standort

config-forum.TXT

[pete.db 10]

Hmm,

scheint wohl irgendwie auch nicht einleuchtender zu sein als mein erster Post :(

 

Könnt ihr mir alternativ verraten wie ihr die Kommunikation zwischen den interfaces regelt?

 

Ich habe ein extern, ein intern und eine dmz.

nat von intern nach extern, von intern in die dmz und von der dmz nach extern.

dann statics von extern nach intern, von extern in die dmz und von der dmz nach intern...

[mr._oiso 10]

Hi Pete,

 

also, ...........

Einmal funktioniert es mit Deiner ACL*1, weil Du Dich noch nicht

entschieden hast, ob Du das Packet von 192.168.2.10 nun

routen oder natten willst.

Im Grunde kann die ASA das Packet routen, aber das tut sie eben nur,

wenn Du es in die NAT (Ausnahme) : nat (dmz) 0 access-list CRYPTOACL

über die ACL CRYPTOACL mit aufnimmst !

Deshalb funktioniert es so wie geschildert.

 

Die Frage 2 und 3 lässt sich schnell erklären.

 

Am Ende einer jeden ACL steht, auch wenn die ASA es nicht anzeigt:

 

"access-list DMZ extended deny ip any any"

 

Daher kann bei ausschließlich diesem Eintrag:

 

host 192.168.2.10 host 192.168.1.25 anschließend auch nur noch

2.10 mit 1.25 reden !

 

Na und "permit ip any any" (recht hast Du) Sicher ist das sicherlich nicht !

 

Mein Vorschlag im nächsten Post

 

Greez Mr. Oiso

–

Hi Pete,

 

da ich nicht weiss, was der Server 192.168.2.10 in der DMZ macht.

hier ein allg. Vorschlag:

 

no access-list CRYPTOACL extended permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0

 

static (intern,dmz) 192.168.2.x 192.168.1.x netmask 255.255.255.255

 

Lass die beiden Server über einen statischen NAT Eintrag miteinander kommunizieren. Damit umgehst Du die NAT 0 (Ausnahme).

Für x wähle jeweils eine frei Adresse aus dem internen und dem dmz Netz.

Wenn Du z.B. einen SMTP Proxy hier in der DMZ betreibst ginge auch:

 

static (intern,dmz) tcp 192.168.2.x smtp 192.168.1.x smtp netmask 255.255.255.255

 

Statt dem hier:

access-list DMZ extended permit ip host 192.168.2.10 host 192.168.1.25

access-list DMZ extended permit ip any any

 

Solltest Du die ACL schon genauer definieren:

z.B.:

 

access-list DMZ extended tcp host 192.168.2.10 any eq smtp

access-list DMZ extended tcp host 192.168.2.10 any eq www

access-list DMZ extended udp host 192.168.2.10 any eq domain

access-list DMZ extended udp host 192.168.2.10 any eq ntp

access-list DMZ extended tcp host 192.168.2.? (andere Server)

access-list DMZ extended udp host 192.168.2.? (andere Server)

oder wenn z.B. 192.168.2.10 ein Terminal Server inkl. Webzugriff für die Remote Side ist

access-list DMZ extended tcp host 192.168.2.10 eq 3389 192.168.110.0 255.0.0.0

access-list DMZ extended tcp host 192.168.2.10 eq www 192.168.110.0 255.0.0.0

access-list DMZ extended icmp host 192.168.2.10 host 192.168.1.25

 

ICMP in jedem fall erst einmal um zu sehen ob es funktioniert

 

 

Nice Weekend

 

Greez from Mr. Oiso

–

Hi again,

 

Tips:

 

Du kannst den static auch weglassen und nur die ACL DMZ einrichten,

musst dann aber

access-list CRYPTOACL extended permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0

 

stehen lassen.

Der Übersicht wegen mache ich es auf jeden Fall so, damit ich mir nicht bei einer Config ähnliche Gedanken mache.

 

Und, ich würde die nat 0 an DMZ und intern über getrennte ACL's definieren !

 

Ciao

 

Mr. Oiso

[pete.db 10]

Hallo Mr. Oizo,

bin momentan noch im Urlaub, daher die lange Reaktionszeit ;).

Jedenfalls erstmal vielen Dank für deinen Post und deine Mühe...ich werde es in der nächsten Woche gleich mal ausprobieren und dann berichten.

 

Danke dir...

Pete