Frage zu ACL

[Frittenbude 10]

Hallo zusammen,

 

ich beschäftige mich derzeit mit ACLs zur Absicherung eines LANs, das aus mehreren Subnetzen auf der Basis von VLANs besteht.

 

Das als Zitat markierte Problem ist gelöst!

 

Folgender beispielhafter Aufbau ist gegeben:

 

VLAN1: 192.168.1.0 / 24

VLAN2: 192.168.2.0 / 24

 

In VLAN1 befinden sich Clients, in VLAN2 befindet sich ein HTTP-Server.

 

Auf einem L3-Switch findet das Routing zwischen den VLANs statt. Dort sollen auch ACLs platziert werden, um die Kommunikation zwischen Netzen einzuschränken. Für das Beispiel des HTTP-Servers habe ich folgende ACLs:

 

access-list 116 permit tcp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 eq 80

access-list 116 permit ip 192.168.2.0 0.0.0.255 192.168.2.0 0.0.0.255

access-list 116 deny ip any any

 

access-list 136 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

access-list 136 permit ip 192.168.2.0 0.0.0.255 192.168.2.0 0.0.0.255

access-list 136 deny ip any any

 

Auf dem SVI (VLAN2) wird ACL 116 für IN und zusätzlich ACL 136 für OUT angewendet.

 

Die Kommunikation zwischen Clients aus dem VLAN1 auf den Server aus VLAN2 funktioniert jedoch nicht. Ich habe die Vermutung, dass es auf dem Rückweg des Paket vom Server zum Client liegt, da folgender Eintrag mehrere Matches erhielt:

 

access-list 136 deny ip any any

 

Übrigens habe ich die jeweils mittlere Regel der ACLs erstellt, da der Server den Router nicht erreichen konnte.

 

Kann mir jemand sagen, wo das Problem liegt?

 

 

Es ist doch richtig, dass beim Aufbau der HTTP-Verbindung vom Client aus für den Hinweg zur Server Port 80 benötigt wird und ein Antwortpaket vom Server an den Client irgendeiner beliebiger sein kann.

 

Für Hilfe wäre ich Euch dankbar.

 

Gruß,

Frittenbude

[honk81 10]

access-list 116 permit tcp 192.168.1.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 80

access-list 116 permit ip 192.168.2.0 0.0.0.255 192.168.2.0 0.0.0.255

kann es sein, dass du die source und destination nicht richtig setzt?

ich hätte das jetzt etwa so vermutet:

access-l 116 permit tcp 192.168.1.0 0.0.0.255 192.168.[b]2[/b].0 0.0.0.255 eq 80

damit sollte der Verkehr aus 192.168.1.0/24 nach 192.168.2.0/24 auf Port 80 erlaubt, und alles andere verboten sein.

 

Ich hoffe, dass passt so, bin aktuell auch noch dabei, mich intensiver mit ACLs zu befassen.

 

Gruß

[Frittenbude 10]

Oh, da habe ich mich in dem Fall hier nur vertippt. So wie Du es sagst, sollte es eigentlich heißen.

 

Ich korrigiere das eben in meinem Startpost.

 

Gruß,

Frittenbude

[Otaku19 33]

access-list 116 permit ip 192.168.2.0 0.0.0.255 192.168.2.0 0.0.0.255

 

das kann schon mal nicht sein, damit würdest du spoofing zulassen.

 

Was genau durch die "access-list 136 deny ip any any" gematcht wird sieht man ja leider nicht nur durch sh access-list. Könnten das also Pakete sein die nicht an 192.168.1.0/24 gehen ? Und die Aufrufe beim Webserver gehen evtl deshalb nicht weil evtl. auch DNS im VLAN 2 zu Hause ist, aber nicht in der ACl freigegeben wurde ?

[Frittenbude 10]

DNS lasse ich erstmal außen vor. Ich greife auf den Server vorerst per IP-Adresse zu.

 

Zu dem Eintrag:

access-list 116 permit ip 192.168.2.0 0.0.0.255 192.168.2.0 0.0.0.255

 

Also ohne diesen Eintrag kann ich vom Server z.B. keinen Ping auf die im gleichen Netz liegende Schnittstelle des L3-Switches absetzen.

 

Hier mal der Aufbau in visueller Form.

 

Die rote Verbindung soll eine Trunk-Verbindung darstellen.

Gruß,

Frittenbude

[onedread 10]

HI

 

wie siehts denn mit der switchportkonfiguratin aus? Und was haben die Clients für einen Gateway eingestellet?

 

geht der Ping ins VLAN2?

 

kannst du von VLAN2 ins VLAn1 pingen oder anderes?

 

Für was brauchst du einen Trunk zum Server?

[Frittenbude 10]

Ich habe meinen Fehler gefunden. Es lag daran, dass ich Incoming und Outgoing verwechselt habe.

 

Irgendwie hatte ich einen Dreher im Gehirn. ;-)

 

Folgende Config ist richtig:

 

access-list 116 permit tcp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 eq 80

access-list 116 deny ip any any

 

access-list 136 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

access-list 136 deny ip any any

 

ACL 116 wird auf OUT von Interface VLAN2 angewendet; entsprechend ACL 136 auf IN von Interface VLAN2.

 

Sorry, war einfach ein Denkfehler meinerseits.

 

Aber nochmal zur Problematik, dass ACLs nicht die Funktion einer Stateful Inspection haben:

Wie sorgt man dafür, dass für den Rückweg aus VLAN2 zu VLAN1 nicht alle Ports geöffnet werden müssen? Ein HTTP-Server antwortet ja bei einer Anfrage auf Port 80 mit einer zufälligen Portnummer.

 

Ich könnte ja nun garnicht folgenden Fall abdecken:

 

In VLAN1 steht HTTP-Server1, in VLAN2 HTTP-Server2.

Clients aus VLAN1 möchten auf HTTP-Server2 zugreifen und analog dazu Clients aus VLAN2 auf HTTP-Server1.

 

In dem Fall habe ich ja nichts gewonnen, wenn ich Port 80 für die Kommunikation aus VLAN1 in VLAN2 öffne und das gleiche für Port 80 aus VLAN2 in VLAN1 tue.

 

Wie handhabt man sowas?

 

Gruß,

Frittenbude

[Otaku19 33]

ich weiß nicht ob ein layer3 Switch inspection kann....man könnte reflective acls dafür verwenden, die sollten klappen.

[Frittenbude 10]

Die Reflective-Sache klingt gut. Kennst Du zufällig ein Tutorial, das einen in die Thematik einführt?

 

Ich würde mich da gerne schlauer machen.

 

EDIT:

Unter folgendem Link habe ich etwas gefunden:

http://www.firstdigest.com/2009/03/cisco-how-to-use-reflexive-access-list-and-why-they-are-useful/

Vielleicht ist es auch für den ein oder anderen interessant, der die gleiche Problematik hat wie ich.

 

Danke nochmals an alle für die schnelle Hilfe.

 

Gruß,

Frittenbude

[Otaku19 33]

hier:

Reflexive access lists - PacketLife.net