Happy new year to all our readers.
I hope that everyone had a good start into 2010 and that everyone had the chance to achieve the aims they set for 2009. I'm proud to say that I did :D, I managed short before X-mas to pass the last CCSP exams and I'm now officially a CCSP. The exams where quite hard and I took a boot camp in India just for the CCSP preparation, that helped me a lot in the IPS topics.
Now we have 2010 and the next big aim is CCIE Security by the end of the year. I'll keep you updated on my progress.
Cheers NWG
Sonntag, 3. Januar 2010
DE - Frohes neues ...
Frohes neues Jahr und so, sei allen Lesern hier vorab gewünscht.
Ich hoffe ein jeder ist gut in das neue Jahr rein gekommen und konnte am Ende von 2009 sagen er hat alle selbst gesteckten Ziele für sich erfüllt. Ich zumindest konnte das behaupten. Kurz vor Weihnachten hab ich die letzten Tests abgelegt und darf mich nun ganz offiziell CCSP nennen. Ich hab dafür extra noch ein Bootcamp in Indien mitgemacht, was mir gerade im Bereich IPS sehr geholfen hat.
Jetzt kommt das nächste große Ziel bis zum Ende 2010 CCIE Security. Ich werde euch auf dem laufenden halten.
Cheers NWG
Ich hoffe ein jeder ist gut in das neue Jahr rein gekommen und konnte am Ende von 2009 sagen er hat alle selbst gesteckten Ziele für sich erfüllt. Ich zumindest konnte das behaupten. Kurz vor Weihnachten hab ich die letzten Tests abgelegt und darf mich nun ganz offiziell CCSP nennen. Ich hab dafür extra noch ein Bootcamp in Indien mitgemacht, was mir gerade im Bereich IPS sehr geholfen hat.
Jetzt kommt das nächste große Ziel bis zum Ende 2010 CCIE Security. Ich werde euch auf dem laufenden halten.
Cheers NWG
Montag, 14. Dezember 2009
DE - dynamisches Routeleanking oder "Inter VRF routing"
Dynamisches Route Leaking oder Routing Protokolle fürs Routing zwischen der globales Routingtabelle (GRT) und VRFs
Hallo zusammen,
das letzte mal gab es ein Beispiel, wie man statisch das Routing zwischen 2 VRFs einrichtet und dachte, daß es doch garnicht so schwer sein kann, dies auch dynamisch zu realisieren ... das war reichlich naiv ;)
Nach massig herumprobieren und mit dem Rat von ein paar anderen habe ich ein kleines Lab zusammengebaut, wo Routen zwischen der GRT und einem VRF dynamisch ausgetauscht werden.
Soweit ich es sagen kann, gibt es keine Möglichkeit Routen auf normalem Wege zu redistributen, wenn ein Routingprozess der globale ist. Wenn man es dennoch versucht, bekommt man eine kryptische Fehlermeldung wie diese:
VRF -> GRT [code]%OSPF process 1 is attached to Default-IP-Routing-Table[/code]
GRT -> VRF [code]OSPF process 22 already exists and is attached to Default-IP-Routing-Table[/code]
Dies müssen wir einfach "austricksen" und dafür brauchen wir einige Tunnelinterfaces und ein paar Loopbacks
So sieht mein Netzplan aus:
Der globale Client und der VRF_Client werden wieder durch missbrauchte Router dargestellt, die lediglich eine IP haben und eine Default Router auf das ausgehende Interface+Next Hop IP.
grt_host
[code]interface FastEthernet0/0
ip address 10.10.10.10 255.255.255.0
ip route 0.0.0.0 0.0.0.0 10.10.10.1 FastEthernet0/0[/code]
vrf_host
[code]interface FastEthernet0/1
ip address 20.20.20.20 255.255.255.0
ip route 0.0.0.0 0.0.0.0 20.20.20.1 FastEthernet0/1[/code]
Nun brauchen wir ein paar Grundkonfigurationen für den VRF Router:
ein vrf erstellen:
Interface config zum grt_host:
Interface config zum vrf_host:
Das alles ist kein Hexenwerk ... bis jetzt ;)
Das erste was wir uns überlegen müssen: wie tricksen wir die Grenzen des Designs aus?
Die erste Zutat sind "Tunnel-Interfaces", die andere sind "Loopbacks".
Unterm Strich brauchen wir:
ein Tunnel-Interface pro VRF,
ein Tunnel-Interface für die GRT
ein Loopback pro VRF und
ein Loopback für die GRT.
Wenn wir mehrere VRFs mit der GRT verknüpfen wollen, brauchen wir entsprechend der obigen Liste das gleiche nochmal pro zusätlichem VRF.
Beide Loopbacks werden in der GRT gelassen:
VRF Router
Jetzt brauchen wir die dazugehörigen Tunnel-Interfaces.
Das für die GRT:
Und das für das VRF:
Was macht dieses Konstrukt? Wir zeigen mit dem dem Tunnel 201 auf die Loopback in der GRT, mit der Quelle in der GRT und packen das ganze dann ins VRF. Hört sich nicht nur komisch an, es ist komisch (und "fühlt sich komisch an), ABER es funktioniert ;)
Jetzt haben wir schicke Netzwerke, zwischen denen wir ein Routingprozess wie zB OSPF laufen lassen können.
Der globale Routingprozess:
Der VRF Routingprozess:
Die Routing Tabelle schaut danach wiefolgt aus::
global
vrf
Und das wars auch schon!
Nun ist es möglich vom grt_host direkt den vrf_host zu pingen und umgekehrt.
Bei Fragen nutzt einfach die Kommentarfunktion
Bis dann,
Zif
Hallo zusammen,
das letzte mal gab es ein Beispiel, wie man statisch das Routing zwischen 2 VRFs einrichtet und dachte, daß es doch garnicht so schwer sein kann, dies auch dynamisch zu realisieren ... das war reichlich naiv ;)
Nach massig herumprobieren und mit dem Rat von ein paar anderen habe ich ein kleines Lab zusammengebaut, wo Routen zwischen der GRT und einem VRF dynamisch ausgetauscht werden.
Soweit ich es sagen kann, gibt es keine Möglichkeit Routen auf normalem Wege zu redistributen, wenn ein Routingprozess der globale ist. Wenn man es dennoch versucht, bekommt man eine kryptische Fehlermeldung wie diese:
VRF -> GRT [code]%OSPF process 1 is attached to Default-IP-Routing-Table[/code]
GRT -> VRF [code]OSPF process 22 already exists and is attached to Default-IP-Routing-Table[/code]
Dies müssen wir einfach "austricksen" und dafür brauchen wir einige Tunnelinterfaces und ein paar Loopbacks
So sieht mein Netzplan aus:
Der globale Client und der VRF_Client werden wieder durch missbrauchte Router dargestellt, die lediglich eine IP haben und eine Default Router auf das ausgehende Interface+Next Hop IP.
grt_host
[code]interface FastEthernet0/0
ip address 10.10.10.10 255.255.255.0
ip route 0.0.0.0 0.0.0.0 10.10.10.1 FastEthernet0/0[/code]
vrf_host
[code]interface FastEthernet0/1
ip address 20.20.20.20 255.255.255.0
ip route 0.0.0.0 0.0.0.0 20.20.20.1 FastEthernet0/1[/code]
Nun brauchen wir ein paar Grundkonfigurationen für den VRF Router:
ein vrf erstellen:
ip vrf zif
rd 1:1
route-target both 1:1Interface config zum grt_host:
interface FastEthernet0/0
ip address 10.10.10.1 255.255.255.0
speed 100
full-duplexInterface config zum vrf_host:
interface FastEthernet0/1
ip vrf forwarding zif
ip address 20.20.20.1 255.255.255.0
speed 100
full-duplexDas alles ist kein Hexenwerk ... bis jetzt ;)
Das erste was wir uns überlegen müssen: wie tricksen wir die Grenzen des Designs aus?
Die erste Zutat sind "Tunnel-Interfaces", die andere sind "Loopbacks".
Unterm Strich brauchen wir:
ein Tunnel-Interface pro VRF,
ein Tunnel-Interface für die GRT
ein Loopback pro VRF und
ein Loopback für die GRT.
Wenn wir mehrere VRFs mit der GRT verknüpfen wollen, brauchen wir entsprechend der obigen Liste das gleiche nochmal pro zusätlichem VRF.
Beide Loopbacks werden in der GRT gelassen:
VRF Router
interface Loopback111
ip address 111.111.111.111 255.255.255.255
interface Loopback222
ip address 222.222.222.222 255.255.255.255Jetzt brauchen wir die dazugehörigen Tunnel-Interfaces.
Das für die GRT:
interface Tunnel102
ip address 100.100.100.1 255.255.255.0
tunnel source 111.111.111.111
tunnel destination 222.222.222.222Und das für das VRF:
interface Tunnel201
ip vrf forwarding RED
ip address 100.100.100.2 255.255.255.0
tunnel source 222.222.222.222
tunnel destination 111.111.111.111Was macht dieses Konstrukt? Wir zeigen mit dem dem Tunnel 201 auf die Loopback in der GRT, mit der Quelle in der GRT und packen das ganze dann ins VRF. Hört sich nicht nur komisch an, es ist komisch (und "fühlt sich komisch an), ABER es funktioniert ;)
Jetzt haben wir schicke Netzwerke, zwischen denen wir ein Routingprozess wie zB OSPF laufen lassen können.
Der globale Routingprozess:
router ospf 1
router-id 10.10.10.10
log-adjacency-changes
network 100.100.100.1 0.0.0.0 area 0
network 10.10.10.0 0.0.0.255 area 0Der VRF Routingprozess:
router ospf 2 vrf zif
router-id 20.20.20.20
log-adjacency-changes
network 20.20.20.0 0.0.0.255 area 0
network 102.102.102.2 0.0.0.0 area 0Die Routing Tabelle schaut danach wiefolgt aus::
global
VRF_Router#sh ip route
[...snip...]
Gateway of last resort is not set
102.0.0.0/24 is subnetted, 1 subnets
C 102.102.102.0 is directly connected, Tunnel102
200.200.200.0/32 is subnetted, 1 subnets
C 200.200.200.200 is directly connected, Loopback200
100.0.0.0/32 is subnetted, 1 subnets
C 100.100.100.100 is directly connected, Loopback100
20.0.0.0/24 is subnetted, 1 subnets
O 20.20.20.0 [110/11112] via 102.102.102.2, 00:24:29, Tunnel102
10.0.0.0/24 is subnetted, 1 subnets
C 10.10.10.0 is directly connected, FastEthernet0/0vrf
Router#sh ip route vrf zif
Routing Table: zif
[...snip...]
Gateway of last resort is not set
102.0.0.0/24 is subnetted, 1 subnets
C 102.102.102.0 is directly connected, Tunnel201
20.0.0.0/24 is subnetted, 1 subnets
C 20.20.20.0 is directly connected, FastEthernet0/1
10.0.0.0/24 is subnetted, 1 subnets
O 10.10.10.0 [110/11112] via 102.102.102.1, 00:26:19, Tunnel201Und das wars auch schon!
Nun ist es möglich vom grt_host direkt den vrf_host zu pingen und umgekehrt.
Bei Fragen nutzt einfach die Kommentarfunktion
Bis dann,
Zif
Donnerstag, 26. November 2009
DE - IOS HTTP Server "hacking" Vorsorge
So nachdem ich heute 4 Firmen angerufen hab und denen mitgeteilt hab das die Konfiguration Murks ist, poste ich die ganze Geschichte auch noch in deutsch.
Vor kurzem bin ich über eine Suchmaschine gestolpert mit der man auch was finden kann. Dabei ging es aber nicht um den Inhalt der Webseite sondern mehr das drum herum. So war es möglich nach dem Webserver und deren Version zu suchen.
Gesagt getan auf meine suche nach Cisco IOS Webservern erhielt ich über 67.000 Treffer. Ouch,. mal ehrlich 67k wieso müssen die Webinterfaces haben und vor allem warum müssen die via Publik IP Verfügbar sein.
Als ich so durch die liste surfte stellt ich fest das einige nicht mit der 401 sondern mit einer 200 als HTTP Statuscode antworteten. Einen von den Routern angeklickt und schon hat sich gezeigt. Prima die Systeme arbeiten ganz ohne Authentifizierung.
Ich hab die Suchkriterien angepasst und von 67.000 Routern brauchen mehr als 1200 Kein Passwort sind also ungeschützt.
Da es über die Weboberfläche möglich ist ein show cdp neigbor abzusetzen zeigte sich das hinter den Routern noch andere Cisco Komponenten hängen. Ich hoffe das die nicht so lausig konfiguriert sind wie der Router.
Um sicher zu sein, gilt daher entweder eine Access Liste auf den Webserver binden:
oder noch besser:
cheers
NWG
Vor kurzem bin ich über eine Suchmaschine gestolpert mit der man auch was finden kann. Dabei ging es aber nicht um den Inhalt der Webseite sondern mehr das drum herum. So war es möglich nach dem Webserver und deren Version zu suchen.
Gesagt getan auf meine suche nach Cisco IOS Webservern erhielt ich über 67.000 Treffer. Ouch,. mal ehrlich 67k wieso müssen die Webinterfaces haben und vor allem warum müssen die via Publik IP Verfügbar sein.
Als ich so durch die liste surfte stellt ich fest das einige nicht mit der 401 sondern mit einer 200 als HTTP Statuscode antworteten. Einen von den Routern angeklickt und schon hat sich gezeigt. Prima die Systeme arbeiten ganz ohne Authentifizierung.
Ich hab die Suchkriterien angepasst und von 67.000 Routern brauchen mehr als 1200 Kein Passwort sind also ungeschützt.
Da es über die Weboberfläche möglich ist ein show cdp neigbor abzusetzen zeigte sich das hinter den Routern noch andere Cisco Komponenten hängen. Ich hoffe das die nicht so lausig konfiguriert sind wie der Router.
Um sicher zu sein, gilt daher entweder eine Access Liste auf den Webserver binden:
access-list 1 permit X.X.X.X ! x.x.x.x= your management network
ip http access-class 1
oder noch besser:
no ip http server
cheers
NWG
EN - IOS HTTP Server hacking prevention
OK I need to post this since this is really scary to me.
A few days ago I stumbled upon a quite cool search engine (no I will not post the URL) what was really interesting is that it did not search for the content of the website it was more interested in the server replies like Server Version HTTP status code.
Since Cisco routers and switches offer a web server for configuration I searched for Cisco IOS servers. The result was scary (it gets worse a bit later) more than 67.000 routers and switches operating the HTTP server are public available. Their may be reasons why routers should be available via HTTP from the Internet but 67000 router people you are kidding me.
I checked some of them and most look like real routers/ switches.
But while browsing the list I found a few routers responding with Cisco IOS Server AND HTTP 200 code. (most of the routers respond with 401 authorization required). I tried one of these and great I could log in and have a look at the configuration passwords etc.
I decided to redefine my search and the result was: from those 67.000 routers 1200 are not requiring authorization of any kind, great.
A quick show cdp neigh showed that most of them I've checked are connected to other Cisco devices. I hope that these devices aren't configured that poorly.
To get out of this list just bind an access list to you HTTP Server,
or even better do a
hope some of those guys owning these routers fix them (fast)
Cheers
NWG
A few days ago I stumbled upon a quite cool search engine (no I will not post the URL) what was really interesting is that it did not search for the content of the website it was more interested in the server replies like Server Version HTTP status code.
Since Cisco routers and switches offer a web server for configuration I searched for Cisco IOS servers. The result was scary (it gets worse a bit later) more than 67.000 routers and switches operating the HTTP server are public available. Their may be reasons why routers should be available via HTTP from the Internet but 67000 router people you are kidding me.
I checked some of them and most look like real routers/ switches.
But while browsing the list I found a few routers responding with Cisco IOS Server AND HTTP 200 code. (most of the routers respond with 401 authorization required). I tried one of these and great I could log in and have a look at the configuration passwords etc.
I decided to redefine my search and the result was: from those 67.000 routers 1200 are not requiring authorization of any kind, great.
A quick show cdp neigh showed that most of them I've checked are connected to other Cisco devices. I hope that these devices aren't configured that poorly.
To get out of this list just bind an access list to you HTTP Server,
access-list 1 permit X.X.X.X ! x.x.x.x= your management network
ip http access-class 1
or even better do a
no ip http server
hope some of those guys owning these routers fix them (fast)
Cheers
NWG
Samstag, 21. November 2009
DE - "Router on a Stick" oder "Inter VLAN routing" mit ASA 5505
Da ich eben beim durchschauen der Google Auswertung unserer Seite festgestellt hab das mehrere Abfragen bzgl. ASA 5505 und Router on-a-stick kamen will ich hier ein kurze Antwort posten.
Die Frage ob es überhaupt geht, ist mit einem klaren Ja und Nein zu beantworten. Die ASA 5505 bietet in der Basis Lizenz 3 Vlans an und enthält keine Trunk Option. Das bedeutet in der Basis Lizenz geht ein Router on-a-stick nicht, da ja on-a-stick bedeutet, rein und raus am selben physikalischen Interface.
Hat man die erweiterte (Plus) Lizenz gekauft, hat man mehr Vlans und kann auch Trunks bauen. Dies erfolgt dann ähnlich der Konfiguration von Trunk Ports auf einem Switch:
Anlegen der entsprechenden Vlan Interfaces
Aufbauen des „Sticks" Interfaces
Access-listen können wie gewohnt eingebunden werden und auch der Rest arbeitet genau wie erwartet. Am anderen Ende der Verbindung von Ethernet 0/0 sollte ein Switch dann den Trunk wieder aufteilen. Routing erfolg gemaess den richtlinien der ASA bzgl der Security-Level der einzelnen Vlans (vom hohen Level zum niedrigen ist default erlaubt, andersherum muss freigeschalten werden)
Vielleicht eine Anmerkung, die 5505 hat 8 Ports, daher ist eigentlich eine on-a-stick Konfiguration nur bedingt sinnvoll. Ich persönlich würde zumindest die WAN Seite von den Internen Ports trennen. Aber das ist nur meine Meinung.
Anmerkung 2, auf den anderen ASA 55x0 funktioniert das bauen von Router on-a-stick Konfigurationen fast genau wie bei einem Cisco Router.
Cheers NWG
Die Frage ob es überhaupt geht, ist mit einem klaren Ja und Nein zu beantworten. Die ASA 5505 bietet in der Basis Lizenz 3 Vlans an und enthält keine Trunk Option. Das bedeutet in der Basis Lizenz geht ein Router on-a-stick nicht, da ja on-a-stick bedeutet, rein und raus am selben physikalischen Interface.
Hat man die erweiterte (Plus) Lizenz gekauft, hat man mehr Vlans und kann auch Trunks bauen. Dies erfolgt dann ähnlich der Konfiguration von Trunk Ports auf einem Switch:
Anlegen der entsprechenden Vlan Interfaces
interface vlan 10
nameif IF_outside
security-level 0
ip address 172.20.2.1 255.255.255.0
no shutdown
interface vlan 20
nameif IF_Core
security-level 100
ip address 172.20.3.1 255.255.255.0
no shutdown
interface vlan 30
nameif IF_MGMT
security-level 99
ip address 172.20.4.1 255.255.255.0
no shutdown
interface vlan 30
nameif IF_Marketing
security-level 20
ip address 172.20.5.1 255.255.255.0
no shutdown
Aufbauen des „Sticks" Interfaces
interface ethernet 0/0
description ### Stick Interfaces ###
switchport mode trunk
switchport trunk allowed vlan 10,20,30
no shutdown
Access-listen können wie gewohnt eingebunden werden und auch der Rest arbeitet genau wie erwartet. Am anderen Ende der Verbindung von Ethernet 0/0 sollte ein Switch dann den Trunk wieder aufteilen. Routing erfolg gemaess den richtlinien der ASA bzgl der Security-Level der einzelnen Vlans (vom hohen Level zum niedrigen ist default erlaubt, andersherum muss freigeschalten werden)
Vielleicht eine Anmerkung, die 5505 hat 8 Ports, daher ist eigentlich eine on-a-stick Konfiguration nur bedingt sinnvoll. Ich persönlich würde zumindest die WAN Seite von den Internen Ports trennen. Aber das ist nur meine Meinung.
Anmerkung 2, auf den anderen ASA 55x0 funktioniert das bauen von Router on-a-stick Konfigurationen fast genau wie bei einem Cisco Router.
Cheers NWG
Abonnieren
Posts (Atom)
Feeds
Posts
Alle Kommentare