Schlagwort-Archiv: cisco

Alcatel Routed Port

Bei vielen Cisco Switchen kann man einen Port als Routed Port machen.

Die Konfiguration ist dann

Interface FastEthernet0/1
no switchport
ip address 192.168.10.1 255.255.255.0

Der Vorteil in einem solchen Routed Port ist, das es keine L2 Protokolle wie z.B. Spanning Tree o.ä. gibt die einem dazwischen funken können.

Seit einem Maintanance Release der 6.4.4 gibt es das ganze auch bei Alcatel 6400/6850/6850E und 9000E Switchen.

Die Konfiguration ist dann:

ip interface RTR1 address 192.168.1.2/24 rtr-port 1/1 rtr-vlan 3

Soll der Port getaggt sein geht das auch:

ip interface "RTR1" address 192.168.2.1 mask 255.255.255.0 rtr-port 1/2 rtr-vlan 4 type tagged

Zur Kontrolle:

show vlan
Vlan type: std => Standard Vlan
Vlan type: rtr => Router Vlan, reserved for rtr-port IP Interface
                              stree                       mble   src        
 vlan  type  admin   oper   1x1   flat   auth   ip   ipx   tag   lrn   name 
-----+------+------+------+------+------+----+-----+-----+-----+-----+---------------------
   1    std   on     on     on    on     off   off   NA   off     on   VLAN 1                          
   2    std   on    off     on    on     off   off   NA   off     on   VLAN 2                          
   3    rtr   on    off    off   off     off    on   NA   off     on   Router VLAN: 3                  
   4    rtr   on    off    off   off     off    on   NA   off     on   Router VLAN: 4                  
  10    std   on     on     on    on     off   off   NA   off     on   vlan10           

bzw:


-> show ip interface 
Total 3 interfaces
        Name            IP Address     Subnet Mask   Status Forward  Device
--------------------+---------------+---------------+------+-------+----------------------------------------------------
Loopback             127.0.0.1       255.0.0.0           UP      NO Loopback
RTR1                 192.168.2.1     255.255.255.0     DOWN      NO Rtr-Port 1/2 vlan 3 UNTAGGED
RTR2                 192.168.10.2    255.255.255.0     DOWN      NO Rtr-Port 1/1 vlan 4 TAGGED

Auf einem 6450/6250 geht das imho noch nicht ebenso wenig wie auf einem 6900 und OS10k.

Konfiguration freeradius für dot1x Teil 2

Weiter gehts.
Ich möchte dot1x Authentifizierung am Switchport machen. Man braucht dazu ein Zertifikat, damit EAP-TLS funktioniert, das baut man dank entsprechender Tools von freeradius ganz einfach:
Man löscht die Links und den ganzen kram aus /etc/certs und kopiert die Tools:
rm /etc/freeradius/certs/*
cp /usr/share/docs/freeradius/examples/certs/* /etc/freeradius/certs

Dann passt man die Dateienn server.cnf und ca.cnf an.
in ca.cnf:
[ CA_default ]
default_days = 3660
[ req ]
input_password = meinpass
output_password = meinpass
[certificate_authority]
countryName = DE
stateOrProvinceName = radius@jan
localityName = daheim
organizationName = Radius-Teste
emailAddress = me@example.com
commonName = "Radiustest"

Damit gilt das Zertifikat 10 Jahre. Das Password muss man auch in der /etc/freeradius/eap.conf bei private_key_password angeben
(per default steht es dort auf „Whatever“), damit der Schlüssel nachher geladen werden kann.

In die server.cnf übernimmt man Laufzeit und die Daten aus der Ceritificate authority.

mit
make all
baut man seine Zeritifkate

Wichtig: ca.der auf memory stick o.ä. kopieren, das ist unser Stammzertifikat und das brauchen wir auf den Clients, damit diese nachher eine TLS Tunnel aufbauen können.

Um die Konfig erstmal nicht mehr anpassen zu müssen machen wir noch eine Änderung die es später erlauben wird VLANs für User zurückzugeben. Dafür setzten wir in
/etc/freeradius/eap.conf
Die in ttls und peap ändern wir den Parameter von „no“ auf „yes“
use_tunneled_reply = yes

Damit sollte die Konfiguration von Freeradius fertig sein.

Jetzt spielt man das Zertifikat im Computer ein, bei XP durch Doppelklick, bei Windows 7 muß man händisch den „Vertrauenswürdigen Zertifikatsspeicher“ wählen.

Wie man den Cisocswitch aktiviert und Windows einstellt kommt im nächsten Artikel.

FreeRadius Server unter Linux für User-Authentication & dot.1X

Wer viel mit Netzwerkgeräten arbeitet stößt früher oder später zwangsläufig auf das problem User authentifizieren zu wollen. In einem Netzwerk mit 50 Switchen ist es nicht zielführend lokale User auf jedem Switch einzutragen.
Passwortänderung? Na klar auf 50 Switchen ist man dann beschäftigt.
Oder man will Netzwerkauthentifizierung nach 802.1X – Der User darf erst nach Eingabe seines Usernamen/Passworts ans Netzwerk. Grade in größeren Firmen ist das Problem der unbewachten LAN Dose öfter Thema.
Ein anderer Anwendungsbereich sind WLANs. PreShared Keys kennt und nutzt mittlerweile fast jeder – nur was machen wenn man dieses ändern will? Jedem User das neue Passwort nennen? Ein Alptraum, geheim zu halten ist so ein PSK auch eher schwer. Hier gibt es die Lösung in Form von WPA2-Enterprise, wo ein Radius Server die User Authentifizierung übernimmt, es also keine gemeinsamen Shared Secrets mehr gibt.

Für all sowas benötigt man einen Radiusserver, den man unter Linux auch als freie Version bekommt.
Ich will hier die notwendigen Konfigurationen für Freeradius unter Ubuntu 10.04 beschreiben.
installieren:
aptitude install freeradius

Man sagt welcher Client sich anmelden darf (z.B. Switch, APs etc) und hat dafür ein Shared Secret definiert, mit dem die Radius Connection verschlüsselt ist. Es handelt sich hier um Netzwerkgeräte, nicht um ein Shared Secret, was der Endwanwender je zu Gesicht bekommt.

Den Client definiert man in
/etc/freeradius/clients.conf
client 172.16.10.100/32 {
secret = MeinPasswort
shortname = Cisco ASA
}

alternativ kann man auch ganze Netze (z.B. mit AP Adressen oder Switchen mit dem gleichen Passwort freigeben:
client 172.16.11.0/24 {
secret = MeineSwitche
shortname = Meine Switche sind in dem Netz
}

User und Passwörter brauchen wir auch, die legt man in der
/etc/freeradius/users an
"jan" Cleartext-Password := "jankanns"
"test" Cleartext-Password := "test123"

Dann der Radius Server neu starten und das reicht zumindest schonmal um User an eine ASA zu anzumelden.

Die Einstellungen an der ASA:

Configuration > Device Management > Users/AAA > AAA Server Groups

Dort eine Radius Servergruppe Anlegen und im unteren Fenster die IP hinzufügen.
Richtiges Interface wähen, die Ports sind 1812 und 1813 das Shared Secret für diesen Client (in diesem Fall „asapass“) gehört in „Server Secret Key“.
Das „Common Password“ Feld bleibt frei.
Mit dem „Test“ Button kann man die Authentication testen

Auf der CLI testet man mit
root@server:~# radtest test test123 127.0.0.1 1812 testing123
Sending Access-Request of id 158 to 127.0.0.1 port 1812
User-Name = "test"
User-Password = "test123"
NAS-IP-Address = 127.0.1.1
NAS-Port = 1812
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=158, length=20

Wenn man Debug Ausgaben haben will startet man Radius mit dem Parameter X:

/etc/init.d/freeradius stop
freeradius -X

Und schon ergiessen sich viele Meter Debugausgaben.

Ich teste jetzt mit verschiedenen Switchen und versuche es auch mal mit WLAN und EAP-TLS und schreibe dann ein Update-Artikel.

Ein Fragezeichen auf der Cisco CLI eingeben

Manchmal muss man auf der Cisco CLI ein Fragezeichen eingeben, z.B. wenn man DHCP Options angeben will wo auf eine Webseite verwiesen wird und dort Parameter übergeben werden:
x.y.z/website.php?option=username

Auf der CLI bringt Cisco gleich die Kontext Hilfe. Will man das verhindern weil man halt wirklich ein „?“ braucht muss man vor dem Fragezeichen ein mal STRG+V benutzen.

Nicht cisco GBICs/SFPs

Cisco will das man nur seine eigenen GBICs benutzt. Bei manchen 3rd Party SFPs gibt es dann Fehler:
%PHY-4-UNSUPPORTED_TRANSCEIVER: Unsupported transceiver found in Gi1/0/1
%GBIC_SECURITY_CRYPT-4-VN_DATA_CRC_ERROR: GBIC in port gi 1/0/1 has bad crc

Mittels der undokumentierten Befehle
service unsupported-transciever
no errdisable detect cause gbic-invalid

kann man sein Glück trotzdem versuchen.
Das klappt nicht auf allen Plattformen und leider nicht mit allen GBICs/SFPs, aber ein Versuch sollte es wert sein.

Cisco ASA für den Zugriff mit SSH konfigurieren

Will man die ASA per SSH administrieren, muss man erst an ein paar Schräubchen drehen:
Wie auf einem Router ein Key Pärchen erzeugen und braucht natürlich auch einen User und SSH muß diesen User zum authentifizieren benutzen:

Auf der CLI einen user anlegen:

username admin password MeinTollesPasswort privilege 15

Authentifizierung local erfolgen lassen

aaa authentication http console LOCAL
aaa authentication ssh console LOCAL

RSA Schlüssel erzeugen:

crypto key generate rsa

management Access freigeben Hier erlaube ssh von 192.168.1.0/24 auf dem Management Interface:

ssh 192.168.1.0 255.255.255.0 management

ASDM
Im ASDM ist es etwas versteckter und umständlicher.

User anlegen:
Configuration > Device Management > Users/AAA > User Accounts --> Add
Usernamen, Passwort, Privilege Level eintragen

Authentifizierung mit lokalen Usern für ASDM und SSH
Configuration > Device Management > Users/AAA > AAA Access > Authentication
–> HTTP/ASDM und SSH ankreuzen

RSA Schlüssel anlegen:
Configuration > Device Management > Certificate Management > Identity Certificates
–> Add –> Add New Identity Certificate und dann neben „Key Pair“ auf New klicken.

ManagementAccess freigeben:
Configuration > Device Management > Management Access > ASDM/HTTPS/Telnet/SSH
Hier mit Add für SSH und HTTPS/ASDM die entsprechenden Einträge machen

Dann sollte es auch mit dem adminsitrieren klappen.