Cisco PIX Routingprobleme

[Mr.Floppy33]

Aloah,

ich habe für Lernzwecke eine PIX nach Hause bekommen und habe da nun so meine kleinen Problemchen mit...

Auf dem Bild ist erkennbar wie sie in etwa aufgestellt ist.
Ich habe also ein ganz normales lokales Netz (192.168.0.0/24), welches ich für die PIX als "Internet" ansehe. Das Netz 192.168.1.0 soll also das sein, wo die geschützten Arbeitsplätze drin stehen sollen.
Die Interfaces der PIX (Outside 192.168.0.251 und Inside 192.168.1.1) sind von den entsprechenden Rechnern anpingbar.

Zu Testzwecken will ich nun erst einmal den Zustand erreichen, dass von dem Notebook aus auf das Internet zugegriffen werden kann, z.B. Surfen, also DNS und HTTP sollten funktionieren.

Die Konfiguration der PIX sieht folgender Maßen aus:


PIX Version 5.3(2)
nameif ethernet0 outside security0
nameif ethernet1 inside security100
access-list ifout permit tcp any any
access-list ifout permit udp any any
ip address outside 192.168.0.251 255.255.255.0
ip address inside 192.168.1.1 255.255.255.0
route outside 0.0.0.0 0.0.0.0 192.168.0.1 1


Die Gruppe ifout wurde so erstellt:

access-group ifout in interface inside


Die Routen sehen derzeit so aus:

# show route
outside 0.0.0.0 0.0.0.0 192.168.0.1 1 OTHER static
outside 192.168.0.0 255.255.255.0 192.168.0.251 1 CONNECT static
inside 192.168.1.0 255.255.255.0 192.168.1.1 1 CONNECT static



So, und jetzt hört mein Verständnis auch schon auf. Ich gehe mal davon aus, dass an den Routen etwas nicht in Ordnung ist. Ich erlaube ja schließlich alles(!) auf UDP und TCP, daher sollten doch nun eigentlich auch DNS-Anfragen von dem Notebook weitergeleitet werden (sofern die Routen stimmen), oder?


Kann mir jemand sagen, woran es (bei meinem Wissen) scheitert oder gar die richtigen Routing-Befehle sagen? :]

[Mr.Floppy33]

Kann das sein, dass ich da was missverstanden habe und ich nicht von inside nach outside routen kann, sondern nur von inside nach DMZ und von DMZ nach outside?


Eigentlich hatte ich nämlich den Aufbau einer DMZ zu Hause noch nicht sonderlich geplant ;)


Kann mir denn niemand etwas dazu sein? :wein:

[Apoll]

Die routen sollten stimmen. Die access-lists kannst Du eigentlich auch rausnehmen, da per default eine "allow all"-Policy für alle Interfaces gilt, wenn ich mich recht erinner.

Kriegst Du von der PIX einen ICMP-Fehler zurück, wenn Du den Rechner im anderen Netz pingst? Ansonsten würd ich mal aus der Befehlsreferenz der PIX ein paar debug-Kommandos raussuchen ;)

[Mr.Floppy33]

Hi,


von der PIX aus kann ich Rechner in der Umgebung anpingen und umgekehrt auch.



Ähm, mal eine ganz dumme Frage: MUSS ich Natting oder Patting benutzen, um z.B. vom Notebook aus surfen zu können oder sollte das auch *so* schon gehen? Hach, da tun sich gerade richtige Abgründe auf ;)

[Apoll]

Ähm, mal eine ganz dumme Frage: MUSS ich Natting oder Patting benutzen, um z.B. vom Notebook aus surfen zu können oder sollte das auch *so* schon gehen? Hach, da tun sich gerade richtige Abgründe auf ;)
Stimmt, in deiner Konfiguration ist NAT/PAT notwendig. Wenn beispielsweise Client A (192.168.1.2) Client B (192.168.0.2) pingt, dann kriegt Client B einen ICMP echo request mit einer Source-Adresse aus einem anderen - ihm unbekannten - Netz. Du könntest ja mal Wireshark anwerfen und das nachprüfen. Jedenfalls weiß Client B dann nicht, dass er das Antwortpaket Richtung PIX schicken sollte.

Wenn du NAT/PAT auf der PIX aktivierst, sollte das funktionieren. Ich garantiere allerdings für nichts mehr, ist schließlich schon spät ;)

[Mr.Floppy33]

Ach, nachts kommen doch eigentlich die besten Antworten :]


Hmmm, aber das ist ja das Problem, dass wenn ich so nun etwas mache, nichts geroutet wird. Ich kann so von 192.168.1.2 nicht 192.168.0.2 anpingen. Oder ist es das, was du meinst: 192.168.0.2 erhält das Paket zwar, aber kann nicht drauf antworten, weil es nur zur PIX geht...? Hmm, das könnte ich in der Tat mal nachprüfen ;-)


Ansonsten hab ich grad die Nat-Befehle rausgesucht und ein großzügiges


global (outside) 1 192.168.0.220-192.168.0.230 netmask 255.255.255.0
nat (inside) 1 0.0.0.0 0.0.0.0 0 0

lässt nun den Clients im Netz 192.168.1.0 ALLES zu (ist dann ja auch so gewollt).

Ist das eine Situation, die man sicherheitstechnisch eher vermeiden sollte? Also allgemein zu natten...? Ich kann ja nun dennoch mit den Access-Listen alles mögliche verbieten bzw. ne kleine Whiteliste machen...?

Und thx, gell :]

[Apoll]

Oder ist es das, was du meinst: 192.168.0.2 erhält das Paket zwar, aber kann nicht drauf antworten, weil es nur zur PIX geht...? Hmm, das könnte ich in der Tat mal nachprüfen ;-)
Kann gut sein, dass 192.168.0.2 das Paket bekommt (ich schätze ja), aber er wird das Antwortpaket nichtmal zur PIX schicken, da er mit einer Adresse aus dem 192.168.1.0/24 Netz nichts anfangen kann (/edit: es sei denn, Du konfigurierst eine extra Route in den Client rein, was natürlich nur ein dirty-Hack wäre)


Ist das eine Situation, die man sicherheitstechnisch eher vermeiden sollte? Also allgemein zu natten...? Ich kann ja nun dennoch mit den Access-Listen alles mögliche verbieten bzw. ne kleine Whiteliste machen...?
Bin nicht sicher, ob ich Dich richtig verstanden habe. NAT alleine ist keine Sicherheitstechnologie (auch wenn es fälschlicherweise oft so gesehen wird). Um den Zugriff auf ein Netzwerk einzuschränken, wird Paketfiltering verwendet. Access-Lists gehen schonmal in Richtung Paketfiltering.


Und thx, gell :]
Kein Problem ;)

[Mr.Floppy33]

Ich meinte es auch eher so, dass NAT unsicherer wäre als FESTE Routen zu den Rechnern (statt zum ganzen Netz) zu verdrahten. Zu sagen, dass beispielsweise Port 22 TCP von Rechner A auf Rechner B (und wieder zurück) okay ist, hört sich für mein Empfinden restriktiver an als erstmal alles zu natten, um das dann wieder mit ACLs einzugrenzen.

Oder ist Natting auch im ich sag mal professionellen Einsatz Gang und Gäbe??

Ich habe von Routing und diesen Sachen halt keine Ahnung, darum hab ich ja ne PIX hier stehen^^




Das nächste der Gefühle wird dann jetzt sein eine DMZ zu realisieren mit einem Squid, dass die Clients dann erst über den Squid in der DMZ ins Internet können. Klingt sicherheitstechnisch schon okay, oder mach ich da grad nochn konzeptionellen Denkfehler?

[Apoll]

Ich meinte es auch eher so, dass NAT unsicherer wäre als FESTE Routen zu den Rechnern (statt zum ganzen Netz) zu verdrahten. Zu sagen, dass beispielsweise Port 22 TCP von Rechner A auf Rechner B (und wieder zurück) okay ist, hört sich für mein Empfinden restriktiver an als erstmal alles zu natten, um das dann wieder mit ACLs einzugrenzen.
Mir ist nicht ganz klar, was Du meinst. Der Gedanke hinter NAT (genau genommen eigentlich PAT) ist ja nur der, IP-Adressen zu sparen, indem ein ganzes Netzwerk hinter einer (oder einer Handvoll) IP-Adressen "verborgen" wird.


Oder ist Natting auch im ich sag mal professionellen Einsatz Gang und Gäbe??
Was meinst Du mit "professionellem Einsatz"? Firmennetzwerke? Ich würde mal behaupten, NAT trifft man praktisch überall auf die ein- oder andere Weise an.



Das nächste der Gefühle wird dann jetzt sein eine DMZ zu realisieren mit einem Squid, dass die Clients dann erst über den Squid in der DMZ ins Internet können. Klingt sicherheitstechnisch schon okay, oder mach ich da grad nochn konzeptionellen Denkfehler?
Denke nicht, das ist eigentlich ein häufiges Szenario.

[Mr.Floppy33]

Okay, ich denke mir wird jetzt einiges klarer. (Stimmt ja, NAT ist ja eigentlich dazu da Adressen zu sparen - darum macht man das ja^^)

Gut, dass ich gefragt habe und vielen Dank nochmal! :]