EN - Happy new year ...

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

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

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:
ip vrf zif
rd 1:1
route-target both 1:1

Interface config zum grt_host:
interface FastEthernet0/0
ip address 10.10.10.1 255.255.255.0
speed 100
full-duplex

Interface config zum vrf_host:
interface FastEthernet0/1
ip vrf forwarding zif
ip address 20.20.20.1 255.255.255.0
speed 100
full-duplex

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
interface Loopback111
ip address 111.111.111.111 255.255.255.255

interface Loopback222
ip address 222.222.222.222 255.255.255.255

Jetzt 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.222
Und 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.111

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:
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 0

Der 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 0

Die 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/0
vrf

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, Tunnel201



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

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:

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,


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