#!/bin/sh
egrep -a -v '^[[:space:]]*#' $1 | egrep -a '[[:print:]]'

Funktioniert und nimmt 70kB Konfigurationsdateien den Schrecken.

Bei Alcatel Der einfache Adminzugang für einen Switch ist schnell erledigt, wie es mit Routern oder Firewalls aussieht behandle ich später (wenn ich dazu komme).

Bei Alcatel ist das ganze ein bisschen komplexer, die Userberechtigungen handlet man über Bitmasken ab, so kann man z.B. FTP zulassen, aber ssh verbieten. oder lesend per ssh erlauben, aber nicht per Telnet.

Hier lassen wir im Beispiel lesenden Zugriff nur per ssh zu.
Der schreibende Zugriff (aluadmin) darf überall drauf zugreifen.

Im Radiusserver hinterlegt man die entsprechenden User/Rückgabe Werte in /etc/freeradius/users:

"aluadmin" Cleartext-Password:= "aluadmin"
        Xylan-Asa-Access = all,
        Xylan-Acce-Priv-F-W1 = 0xffffffff,
        Xylan-Acce-Priv-F-W2 = 0xffffffff,
"aluread" Cleartext-Password:= "aluread"
        Xylan-Asa-Access = all,
        Xylan-Acce-Priv-F-R2 =  0xffffffff,
        Xylan-Acce-Priv-F-R1 =  0xffffffff,
        Xylan-Acce-Priv-F-W1 =  0x00000002,
        Xylan-Acce-Priv-F-W2 =  0x00000000,

Für den lesenden Zugriff ist komischerweise auch “schreibend” auf ssh nötig.
Dies braucht man damit show Kommandos abgeschickt werden können.

Der schreibende Zugriff auf die einzelnen Abschnitte der Konfiguration muss separat freigeschaltet werden.
Die Bitmasken sind kann man sich über

show aaa priv hexa

anzeigen lassen.

->show aaa priv hexa
file            = 0x00000001 0x00000000,
ssh             = 0x00000002 0x00000000,
scp             = 0x00000004 0x00000000,
telnet          = 0x00000008 0x00000000,
ntp             = 0x00000010 0x00000000,
dshell          = 0x00000020 0x00000000,
debug           = 0x00000040 0x00000000,
..
[snip]

De folgende Nutzer hat read-only Zugriff nur auf „vlan“. Es ist dem Benutzer nicht möglich z.B. „show ip interface“ einzugeben.

"vlanread" Cleartext-Password:= "vlanread"
        Xylan-Asa-Access = "all",
        Xylan-Acce-Priv-F-R1 = 0x10000000,
        Xylan-Acce-Priv-F-R2 = 0x00000000,
        Xylan-Acce-Priv-F-W1 = 0x00000002,
        Xylan-Acce-Priv-F-W2 = 0x00000000

Ein Dokumentation von Alcatel findet man z.B.
in diesem PDF auf Seite 8

Die Konfigurationen auf dem Switch sind in wenigen Zeilen erledigt (der Radiusserver muss vom Switch aus erreichbar sein -> IP Adressen Routing etc. muss stimmen ..)

!Falls Radiusserver tot ist es praktisch noch einen lokalen Account haben
user localadmin password Rettemich read-write all
! aaa aktivieren, primär radius fallback auf local
aaa radius-server "RadiusServer" host 172.16.1.32 key 12345678
aaa authentication telnet "RadiusServer" "local"
aaa authentication ssh "RadiusServer" local
aaa authentication console "RadiusServer" local

Man kann natürlich auch mit

aaa authentication default RadiusServer local

alles abfrühstücken

Das sollte es gewesen sein.

Liegt es nahe das auch auf andere Geräte auszuweiten.

Cisco ist da auch ein Kandidat. Der einfache Adminzugang für einen Switch ist schnell erledigt, wie es mit Routern oder Firewalls aussieht behandle ich später (wenn ich dazu komme).

Im Radiusserver hinterlegt man die entsprechenden User/Rückgabe Werte in /etc/freeradius/users:

# nicht im Privilege Modus, enable noetig
"iosread" Cleartext-Password := "iosread"
        Service-Type = NAS-Prompt-User
# priv 15
"iosadmin" Cleartext-Password := "iosadmin"
        Service-Type = NAS-Prompt-User,
        cisco-avpair = "shell:priv-lvl=15"

Alternativ geht auch folgendes:

"catosadmin" Cleartext-Password := "catosadmin"
        Service-Type = Administrative-User

Das ist wenn ich mich recht erinnere für CatOS devices auch zwingend notwendig -funktioniert bei IOS praktischerweise auch.

Die Konfigurationen auf dem Switch sind in wenigen Zeilen erlegt:

!Falls Radiusserver tot ist einen lokalen Account haben
username localadmin privilege 15 secret Rettemich

! aaa aktivieren, primär radius fallback auf local
aaa new-model
aaa authentication login default group radius local
aaa authorization exec default group radius local

!Radiusserver:
radius-server host 172.16.1.32 auth-port 1812 acct-port 1813 key 12345678

Damit kann sich ein catosadmin oder iosadmin im priviledge Modus anmelden, ein iosread kommt in den unpriveligierten modus, darf ein paar “show” Befehle. Für weitere Untaten muss er erst in den enable Modus.

Für Fortigates sind die Eintragungen einfach:
Im Radiusserver hinterlegt man nur das für Fortigate gültige admin-profil (hier in /etc/freeradius/users):

"fortiadmin" Cleartext-Password:= "fortiadmin"
        User-Service-Type = Login-User,
        Fortinet-Access-Profile = super_admin
"fortiread" Cleartext-Password:= "fortiread"
        User-Service-Type = Login-User,
        Fortinet-Access-Profile = read_only

Jetzt muss man der Fortigate Konfigurationen vornehmen
Als erstes legen wir ein “read_only” Profile an und eins was garnichts darf (“noaccess”), das ist für gültige User, die keine Fortigate VSAs haben.

config system accprofile
    edit "read_only"
        set admingrp read
        set authgrp read
        set endpoint-control-grp read
        set fwgrp read
        set loggrp read
        unset menu-file
        set mntgrp read
        set netgrp read
        set routegrp read
        set sysgrp read
        set updategrp read
        set utmgrp custom
        set vpngrp read
            config utmgrp-permission
                set antivirus read
                set application-control read
                set data-loss-prevention read
                set ips read
                set spamfilter read
                set webfilter read
            end
    next
    edit "noaccess"
        unset menu-file
    next
end

Wir konfigurieren einen Radiusserver (172.16.1.32) mit PSK 12345678

config user radius
    edit "freeradius"
        set all-usergroup enable
        set auth-type chap
        set nas-ip 172.16.1.2
        set secret 12345678
        set server "172.16.1.32"
    next
end

Dann legen wir eine User Gruppe an die den Server abfragt:

config user group
    edit "radadmin"
    set member "freeradius"
    next
end

Und ordnen nun eine “Wildcardadmingruppe” dieser Usergroup zu. Diese heißt hier “wildcard”

config system admin
    edit "wildcard"
        set remote-auth enable
        set accprofile "noaccess"
        set vdom "root"
        set wildcard enable
        set remote-group "radadmin"
        set radius-accprofile-override enable
        set radius-vdom-override enable
    next
end

Jeder user (“wildcard enable”) wird gegen Radius geprüft hat aber standardmäßig “noaccess” als accprofile. Das verhindert das ein beliebiger gültiger Radiususer irgendwas auf der Fortigate darf.

Dieses accprofil kann (und muss) dann vom Radius überschrieben werden. Ebenso könnte man die vdom auf die ein User Zugriff hat spezifizieren. – Das wird hier aber nicht gemacht.

Lokale User werden lokal an der Fortigate verifiziert, alle anderen dank Wildcard im Radius nachgeschlagen.

Will man einen v2 user zum lesen und einen v3 user zum schreibenden Zugriff haben ist folgendes nötig:


aaa authentication snmp local
user snmpv2user password 111222333 read-only all no auth
user snmpv3user password abcd1234 md5+des read-write all
snmp community map "public" user "snmpv2user" on
snmp security authentication set


- Zum authentifizieren nutzen wir die lokale Datenbank.
- Der User “snmpv2user” angelegt und darf dank no auth auch snmp.
- Die SNMP community “public” wird auf den user gemappt. Dank “no auth” darf dieser snmp machen, fehlt das geht es nicht.
- Der User “snmpv3user” darf dank “md5+des” snmpv3 machen und nutzt auch die Privacy Extension -> Verschlüsselt.
- Mit “snmp security authentication set” sagt man snmpv1/2c ist mit “get” erlaubt für “set” braucht man mindestens v3 gesigned.

Kontrolle:
>show snmp community map
Community mode : enabled
status community string user name
--------+--------------------------------+--------------------------------
enabled public snmpv2user
>show user
[..]
User name = snmpv3user,
Password expiration = None,
Password allow to be modified date = None,
Account lockout = None,
Password bad attempts = 0,
Read Only for domains = None,
Read/Write for domains = All ,
Snmp allowed = YES,
Snmp authentication = MD5,
Snmp encryption = DES,
Console-Only = Disabled
User name = snmpv2user,
Password expiration = None,
Password allow to be modified date = None,
Account lockout = None,
Password bad attempts = 0,
Read Only for domains = None,
Read/Write for domains = All ,
Snmp allowed = YES,
Snmp authentication = NONE,
Snmp encryption = NONE,
Console-Only = Disabled


Mit dem SNMP Tester von Paessler kann man schön überprüfen, ob man mit v2c/public oder dem v3 User reinkommt.

Zumindest im Paessler muss man wenn der user mit md5+des angelegt ist sowohl bei v3 Password und v3 encryption key das user Passwort angeben, nur eins reicht nicht.

Dank hierfür geht an Klaus Peras, der hat viel davon schon gewußt.

Im OmniVista macht man zur Nutzung für auto discovery folgendes
Discovery ->Ping Sweep -> Next
[New] SNMP Setup
Hier einen Namen angeben auf dem zweiten Reiter SNMPv3 angeben und auf dem letzten Reiter den Usernamen “Auth Method = MD5″ und Auth/Priv Password angeben.
Auf der nächsten Seite (Next) macht man eine Range und wählt das grade angelegte Setup.
Fertig.
Unter ->Toplogy -> Switches sollten die Geräte dann vorhanden sein.

lanpower 1 start

Ansehen kann man sich das ganz so:


show lanpower 1
Port Maximum(mW) Actual Used(mW) Status Priority On/Off
----+-----------+---------------+-----------+---------+------
1 15400 0 Powered Off Low ON
2 15400 0 Powered Off Low ON
3 15400 0 Powered Off Low ON
4 15400 0 Powered Off Low ON
5 15400 3000 Powered On Low ON
6 15400 0 Powered Off Low ON
7 15400 0 Powered Off Low ON
8 15400 0 Powered Off Low ON
9 15400 0 Powered Off Low ON
10 15400 0 Powered Off Low ON
11 15400 0 Powered Off Low ON
..

format flash:

Danach das image laden:

rommon 12 > IP_ADDRESS=172.16.0.194
rommon 13 > IP_SUBNET_MASK=255.255.255.0
rommon 14 > DEFAULT_GATEWAY=172.16.0.1
rommon 16 > TFTP_SERVER=172.16.0.176
rommon 17 > TFTP_FILE=c870-IOS.bin
rommon 18 > tftpdnld

Danach einfach mit
“boot”
das Image laden .

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.

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.

Auf einen aktuellen Firmwarestand kommen sie nach dem provisionieren – Sind sie mit dem Controller verbunden, bekommen sie das AOS vom Controller.L
eider wird nach einem reset wieder ein altes AOS geladen.

Um auch nach einem Reset das aktuelle AOS benutzen zu können muss man die backup-partition der RAPs flashen, das geht mittels des Befehls
(OAW-4504) #apflash ip-addr 192.168.234.20 backup-partition

Mit show ap image version sieht man die vorhandene Version und auch ob das upgrade noch andauert:

(OAW-4504) #show ap image version
AP Image Versions On Controller
-------------------------------
AOS-W version 5.0.3.0 for OAW-AP6x_7x (p4build@cyprus) (gcc version 3.4.3) #26207 Tue Nov 30 09:13:58 PST 2010
Access Points Image Version
---------------------------
[snip]
192.168.234.20 AOS-W version 5.0.3.0 for OAW-AP6x_7x (p4build@cyprus) (gcc version 3.4.3) #26207 Tue Nov 30 09:13:58 PST 2010 AOS-W version 5.0.3.0 for OAW-AP6x_7x (p4build@cyprus) (gcc version 3.4.3) #26207 Tue Nov 30 09:13:58 PST 2010 3.3.2.11-rn-3.0.1(p4build@trinidad.arubanetworks.com)#21263 Wed May 6 22:30:18 PDT 2009 Yes 1 0 0 0 In Progress (3 secs)


Nach dem Upgrade steht statt In Progress dann Completed und der RAP bootet die neue Version.

192.168.234.20 AOS-W version 5.0.3.0 for OAW-AP6x_7x (p4build@cyprus) (gcc version 3.4.3) #26207 Tue Nov 30 09:13:58 PST 2010 AOS-W version 5.0.3.0 for OAW-AP6x_7x (p4build@cyprus) (gcc version 3.4.3) #26207 Tue Nov 30 09:13:58 PST 2010 3.3.2.11-rn-3.0.1(p4build@trinidad.arubanetworks.com)#21263 Wed May 6 22:30:18 PDT 2009 Yes 1 0 0 0 Completed (65 secs)


Diese wird auch in der backup-partition angezeigt:
192.168.234.10 AOS-W version 5.0.3.0 for OAW-AP6x_7x (p4build@cyprus) (gcc version 3.4.3) #26207 Tue Nov 30 09:13:58 PST 2010 AOS-W version 5.0.3.0 for OAW-AP6x_7x (p4build@cyprus) (gcc version 3.4.3) #26207 Tue Nov 30 09:13:58 PST 2010 AOS-W version 5.0.3.0 for OAW-AP6x_7x (p4build@cyprus) (gcc version 3.4.3) #26207 Tue Nov 30 09:13:58 PST 2010 Yes 3 0 0 0 Done