Kategorie-Archiv: linux

Linux Raid5 lahm

Ich hab bei mir ein dm-crypt auf nem Software Raid5 auf meinem Ubuntu 12.04LTS
laufen. (3*2TB im Raid 5)

Performance war mäßig ~30MB/s schreibend übers Netz (Kopie Windows -> Sambashare)

Also hab ich die CPU getauscht Celeron E1400 Dual Core (2Ghz) gegen nen
Core 2 Duo 8400 (mehr Cache, mehr FSB, 3Ghz)
Hat was gebracht jetzt kam ich auf 40MB/s :-/

Nach einigem Recherchieren die Einstellung der stripe_cache_size gefunden
Tuning mdadm
Speed up mdadm

Es verursacht angeblich keine Gefahr des Datenverlustes, braucht aber
Speicher:
StripeCache Size * 4kb*Anzahl Disks mit u.g. Einstellungen etwa 100MB

Ich habe 8192 gewählt und für meine md-Devices eingestellt:

root@seth:~# echo "8192" > /sys/block/md1/md/stripe_cache_size
root@seth:~# echo "8192" > /sys/block/md2/md/stripe_cache_size
root@seth:~# echo "8192" > /sys/block/md3/md/stripe_cache_size

Der Schreibspeed lag danach (die gleiche 4GB große Datei wie in den
Tests vorher auch) bei knapp über 85MB/s und damit nur knapp unter dem Speed
der Gigabit Verkablung.

Um es permanent zu machen wieder google bemüht:
Making stripe cache size permamnent

root@seth: cat /etc/udev/rules.d/60-md-stripecache.rules
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change",
TEST=="md/stripe_cache_size", ATTR{md/stripe_cache_size}="8192"

Angeblich muss/kann/soll man dann die initramfs rebuilden , das hab ich
gemacht:

"update-initramfs -u"

Nach nem Reboot stehen die 8192 drinnen und der Speed ist deutlich
besser als vorher.

User Authentifizierung gegen Radius – Fortinet

Früher oder später kommt man an den Punkt wo man seine User zentral Administrieren will. Und so z.B. seine Admin-User in einem Radiusserver hinterlegt.

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.

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.