Kategorie: Server

Alles rund ums Konfigurieren von Server

ExpireDate von Zertifikat überwachen.

Raptor 2101Leave a comment

Wer, wie ich, eine eigene (private) CA betreibt, wird irgendwann mal überrascht feststellen, dass auch das Root-Zertifikat ausläuft. Standardmäßig nach 4 Jahren. Wenn plötzlich der Radius keine Clients mehr ins Netz lässt, wenn jede interne HTTPS-Verbindung auf Warnung läuft und man sich plötzlich wieder mit Notfall-Passwörtern anmelden muss, weiß man, dass man vergessen hat, sein Root-Zertifikat rechtzeitig zu erneuern.

Was bei einzelnen Clients noch mit vertretbaren Aufwand zu beheben ist, nervt beim Zwangs erneuern der CA doch ziemlich, besonders wenn man gerade etwas anderes vor hatte.

Für diesen Zweck hab ich mir ein kleines Script gebastelt, das via Munin alle Cert-Restlaufzeiten ermittelt und rechtzeitig Alarm schlägt.

wie immer unter GPL hier zu beziehen: Check Expire Date

OpenVPN – TLS-Server-Check bestehen

Raptor 21011 Comment

OpenVPN liefert gleich eine ganze BuildChain mit um sich Zertifikate zu generieren und zu signieren. Leider hat man meist schon eine Infrastruktur (CA) im Feld mit der man seine Zertifikate signiert und verteilt. Bei mir habe ich das immer über das in Ubuntu mitgelieferte CA.pl Skript gemacht und die so erzeugten Zertifikate funktionieren gerade nicht in OpenVPN. Es kann zwar eine Verbindung aufgebaut werden aber ein TLS-Server-Check schlägt fehl. Um gültige Zertifikate zu erzeugen muss man folgendes machen.

in der /etc/ssl(openssl.cnf muss man eine neue Sektion anlegen. Am besten mit dem Namen „Server“ oder „OpenVPNHost“

[ server ]
basicConstraints=CA:FALSE
nsCertType          = server
nsComment           = "Some comment"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
extendedKeyUsage=serverAuth
keyUsage = digitalSignature, keyEncipherment

anschließend muss man das certifiacte wie folgt erzeugen:

openssl req -days 365 -nodes -new -keyout newkey.pem -out newreq.pem -extensions server -config /etc/ssl/openssl.cnf
openssl ca -days 1095 -extensions server -in newreq.pem -policy policy_anything -out newcert.pem

Das so erzeugte Zertifikat besteht auch einen TLS-Server-Check

EdgeMax Router und die eigene DHCP-Server Config

Raptor 21012 Comments

Wer einen EdgeMax Router im Einsatz hat, kann über die Configschnittstelle seinen DHCP Server aufsetzten. Wer aber einen bestehenden DHCP Server migrieren will, wird blöde, alles über dieses Interface einzuhacken. Es geht auch einfacher. Die bestehende dhcpd.conf unter /config ablegen. Man kass es prinzipjell überall hinlegen, aber dort überlebt die Datei ein Firmware-Upgrade.

 

Anschließend die Datei /etc/init.d/dhcpd anpassen und von der automatisch generierten auf die /config/dhcpd.conf umbiegen. Wenn man im Configmenu den DHCP-Server abgeschaltet hat (kein Eintrag unter services) muss man nun noch den DHCP-Server beim Start mit starten lassen:

update-rc.d dhcpd default

Schon hat man seinen selbst-konfigurierten DHCP Server am Start.

Zertifikatseigenschaften von FreeRadius prüfen lassen

Raptor 21012 Comments

Ich hab seit einiger Zeit einen FreeRadius-Server um mein WLAN abzusichern und mein VPN Zugang zu regeln. Das System war so konfiguriert, dass der Client ein Zertifikat vorzeigt, einen Tunnel aufbaut und dann via EAP/PAP autorisiert wird. Das Gruppenmanagement übernahm dabei LDAP und die das Passwort wurde via Kerberos geprüft. Alles in allem sehr flexibel aber auch sehr komplex. Vor allem der LDAP Server störte mich doch extrem. Zum einen ist der so ganz anders zu konfigurieren und zu verwalten, als alle anderen Dienst ein meiner Landschaft, zum anderen hab ich ihn nie so richtig verstanden. Kurz der musste weg. Ich wollte aber weiterhin die Option haben, eine Nutzer via VPN auf Subnets „Zugang“ zu lassen aber vom Heimnetz „Sicher“ fern zu halten. Insofern man den aktuellen FreeRadius einsetzt bietet dieser eine sehr elegante Möglichkeit an, dass auf Zertifikatsbasis zu lösen.

Der Grundgedanke: Insofern man der CA wirklich vertraut bzw. die CA selber stellt, kann man davon ausgehen, dass ein Client nur das Zertifikat hat, dass er haben darf. Verlust und Diebstahl wird über eine aktuelle „Revocation Liste“ gelöst. Vertraut man der CA, kann man somit die Zugangsinformationen ins Zertifikat hinterlegen. Zum Beispiel kann man das OU (OrganisationUnit) oder gar das CN Feld nutzen. In meinem Fall, hab ich mich auf das CN Feld bzw den ganzen Zertifikats-Pfad verlassen. Meine Netz ist in verschiedene Bereiche getrennt: Sicher, Gesichert, Offen (Radius entfällt). Alle Clients haben schon jetzt Zertifikate die wie folgt aussehen: hostname.sicher.ca oder bekannter.gesichert.ca. Ich musste den Radius nur noch dazu bekommen, dass ein Client der in das „Sichere“ Netz will auch ein „sicher.ca“-Zertifakt vorweißt.

Umsetzung: Was man vorher braucht, ist ein Radius der TLS beherrscht. Das wird hier beschrieben: Ubuntusers:Wiki – FreeRadius. Läuft der TLS Modus stehen nun eine Reihe von Variablen innerhalb der FreeRadius-Configuraiton zur Verfügung. Eine komplette Liste konnte ich nicht auftreiben aber laut einigen Mailinglisten sind die folgenden Variablen wohl verfügbar:

  • TLS-Cert-Serial
  • TLS-Cert-Expiration
  • TLS-Cert-Issuer
  • TLS-Cert-Subject
  • TLS-Client-Cert-Serial
  • TLS-Client-Cert-Expiration
  • TLS-Client-Cert-Issuer
  • TLS-Client-Cert-Subject

Interessant ist die TLS-Client-Cert-Subject – Variable. Diese stellt das Subject via String zur verfügung. Jetzt muss man nur noch mittels RegExp seine gewünschte Prüfung durchführen. Dass kann dann so aussehen.

authenticate {
  Auth-Type eap {
    eap 
    if ( Huntgroup-Name == 'sicher' && "%{TLS-Client-Cert-Subject}" =~ /\/CN=.*\.sicher\.ca\// ) { 
      ok 
    }
    else {
      reject
    }
  }
}

Die „Huntgroup“ ist eine Eigenschaft die durch beliebige Regeln vorher gesetzt wird. In meinem Fall sieht die Regel so aus:

atlantic   NAS-IP-Address == 10.11.1.2, NAS-Identifier == "sicheres-lan"

Was folgt ist folgende Prüfung. Wenn eine TLS-Verbindung über einen Zugangspunkt mit der IP 10.11.1.2 und NAS-ID (vorher vereinbart) „sicheres-lan“ ankommt muss das CLientZertifikat auf „*.sicher.ca“ ausgestellt sein. Alles andere wird abgeleht. Mann kann da noch weitere else-Zweige einbauen. Aber das Prinzip bleibt das gleiche.

Servergespeicherte Profile mit unison

Raptor 2101Leave a comment

Da CSync leider nicht meine Erwartungen erfüllt hat bzw. nicht im Ubuntu-Repository versorgt wird musste ich mich vor ein Weile nach Alternativen umschauen.

Dabei bin ich auf Unison gestoßen. Installiert man es auf Client und Server kann man via ssh sehr schnell große Datenmengen in beide Richtungen abgleichen. Man kann sogar eine Konfliktlösungsstrategie angeben, falls es sowohl auf Server als auch Clients zu Änderungen kam.
Mittels Exclude-List kann man gezielt steuern was übertragen werden soll. Sogar via Regex.

Beispielconfig:

root = /home/myuser
root = ssh://myuser@myserver.local//path/to/storage
batch = true

ignore = Path .unison
ignore = Path .kdevduchain
ignore = Path .kde*/cache-*
ignore = Path .kde*/socket-*
ignore = Path .kde*/tmp-*
ignore = Path .kde/share/apps/amarok/albumcovers
ignore = Path .kde/share/apps/nepomuk
ignore = Path .kde/share/apps/akregator/Archive


ignore = Regex [^\.].* # alle Dateien die nicht mir . beginnen werden ignoriert.

Das ganze kann man ohne Probleme über ein Skript beim Start oder Login automatisieren:

/usr/bin/unison sync_homedir -silent -prefer newer -times

Bleibt nur noch das Problem wie man den ssh-Daemon auf der Server-Seite dazu bekommt ohne weitere Passwortabfrage eine Verbindung zuzulassen. Da gibt es verschiedene Varianten wie z.b. das Public-Key-Verfahren (wobei der keyring automatisch aufgemacht werden muss) oder GSSAPI. Letztere ist relativ bequem einzusetzen, wenn man mal einen Kerberos eingerichtet hat. Dann muss man einfach folgende Konfiguration im SSH Daemon vornehmen.

# Kerberos options
KerberosAuthentication yes
KerberosGetAFSToken yes
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

Anschließend akzeptiert der SSH Daemon nach einem Neustart auch Kerberos Tickets anstatt ein Password abzufragen.

IPSec/L2TP VPN mit OpenWRT

Raptor 21014 Comments

Da ich mehrere Android Geräte in Benutzung habe die ich nicht „rooten“ darf und dennoch einen VPN Tunnel in mein Heimnetzwerk brauche, hatte ich das „Vergnügen“ mich mit IPSec/L2TP – Tunneln auseinander zu setzten. Android bietet native aktuell vier VPN-Varianten an: PPP, L2TP, IPSec/L2TP (PSK), IPSec/L2TP (Certificate)

PPTP fällt aus, da der Android-Client nur primitive Authentifizierungen anbietet, welche als leicht angreifbar gelten. L2TP ist nur ein Layer2-Tunnel-Protokoll um darüber wiederum ein PPP-Tunnel aufzubauen. Da L2TP selber nicht Verschlüsselt ist das ganze nur so sicher wie der PPP Tunnel. Bei welchem wieder nur primitive Authentifizierungen angeboten wird. Bleibt als letzte Alternative nur den L2TP-Tunnel via eines IPSec Tunnel zu sichern. Sowohl die PSK (PreSharedKey) als auch zertifikatsbasierte Lösung sollten hinreichend sicher sein.

Damit beginnt aber auch schon der Ärger.  IPSec-Gateways findet man nur in wenigen SOHO Geräten vorkonfiguriert (z.b. einigen Fritzboxen) und das aus gutem Grund. Das Zusammenspiel Clients, Netze, Netzanbieter und IPSec läuft nicht so reibungslos wie es sollte. Dazu gleich mehr.

OpenWRT bietet gleich mehrere IPSec und L2TP Dienste an. Ich hab mich für den StrongSwan4 – Daemon als IPSec Dienst entschieden. Da dieser auch IKEv2 anbietet, in der Hoffnung dass dies vom auf Android eingesetzten Racoon-Daemon auch mal genutzt wird.

Des weiteren komm der xl2tp-Daemon oder der standardmäßig installierte ppp-Daemon zum Einsatz.

Bevor man die Sache angeht sollte man folgendes beachten um sich viel Zeit und Ärger zu ersparen: Das fehleranfälligste an einem IPSec/L2TP-VPN ist der IPSec-Anteil. Man sollte diesen also getrennt testen. Als sinnvoll hat es sich gezeigt, den Zielrouter mal vom Netz ab zu klemmen, die Firewall abzuschalten und plain den xl2tp-Daemon im Zusammenspiel mit dem PPP-Daemon zu testen. Das ganze geht einfach von der Hand und ist robust und stressfrei.

Danach kann man den IPSec Tunnel via PSK hochziehen und im internen Netz testen. Anschließend kann man ggf noch Zertifikate zur Authorisierung nutzen. Erst wenn das alles im internen Netz klappt sollte man Versuchen von „Außen“ auf das VPN zuzugreifen. Es empfiehlt sich an dieser Stelle für die Mobilen Devices einen LogReader zu installieren. Für Android ist das die App aLogcat. Leider gibt der racoon-Daemon nur in die Logfiles aus warum er einen Tunnel wieder zu macht oder warum er erst gar keinen aufbauen will.

Wie eingangs erwähnt gibt es mehrere Stolpersteine. Es war mir z.b. nicht möglich eines meiner Geräte dazu zu bewegen, den IPSec Tunnel aufzubauen. Das lies sich aber zweifelsfrei auf das Netzsegment zurückführen. Eine SIM-Karte des gleichen Netzanbieters aus einem anderen Gerät (anderes Netzsegment) eingewechselt und schon konnte der Tunnel aufgebaut werden. Es scheint Probleme beim Zusammenspiel Racoon – open/strong-Swan zu geben wenn mehrfaches „NAT“ing zum Einsatz kommt.[1. Quelle: http://www.mail-archive.com/users@lists.strongswan.org/msg02787.html]

Diesen Widrigkeiten zum Trotz kann man das ganze relativ leicht auf OpenWRT oder Ubuntu wie folgt einrichten:

Man benötigt  als Pakete den PPP-Daemon, XL2TP-Daemon und StrongSwan.

Configuration – /etc/ppp/options.xl2tpd

#Das wird nur gebraucht für radius-anbindung
plugin radius.so 
radius-config-file /etc/ppp/radius.conf
avpair NAS-Identifier=l2tp-vpn 
avpair NAS-Port=1

auth
#ggf für testzwecke noauth
#für debugging dump

lock
noccp
novj
novjccomp
nopcomp
noaccomp

ms-dns DNS-Server-IP

refuse-chap
require-pap

Hinweis ich erzwinge das unsichere PAP weil der IPSec-Tunnel via Zertifikaten gesichert ist (sehr schwer zu brechen, eigene CA) und FreeRadius für alles andere Klartextpasswörter im Zugriff braucht. Das muss man ggf. an seine Anforderungen anpassen!

Configuration xl2tp – Achtung hier verwende ich keine Authentifizierung. Das überlasse ich IPSec und PPPd
/etc/xl2tpd/xl2tpd.conf

[global]
port = 1701
;auth file = /etc/xl2tpd/xl2tp-secrets
access control = no
ipsec saref = no ;wichtig SAREF funktioniert nicht mit StrongSwan
;folgende zielen für debuggin einkommentieren
;debug avp = yes
;debug network = yes
;debug packet = yes
;debug state = yes
;debug tunnel = yes

[lns default]
exclusive = yes
ip range = 10.0.100.5-10.0.100.50
hidden bit = no
local ip = 10.0.100.1
length bit = yes
refuse authentication = yes
name = IpSec-Tunnel
ppp debug = no
pppoptfile = /etc/ppp/options.xl2tpd

Nun zu IPSec

config setup
        strictcrlpolicy=no #Für ein kleines Setup wird keine RevokationList verwaltet...
        plutodebug=none
        nat_traversal=yes #anschalten wenn man mit NAT(ted) Clients rechnet.
        virtual_private=%v4:10.0.0.0/8,%v4:192.168.99.0/24,%v4:!192.168.100.0/24
        charonstart=no #noch brauchen wir kein IKEv2
        #protostack=netkey
conn NAT-Tunnel
    authby=rsasig #Authentisierung via Zertifikaten
    pfs=no
    compress=no
    rekey=no 
    keyingtries=3
    type=transport
    auto=add
    left=%defaultroute
    leftcert=mycert.pem
    leftid=@mydomain
    leftrsasigkey=%cert
    leftsendcert=always
    leftprotoport=17/1701
    right=%any
    rightsubnet=vhost:%no,%priv
    rightprotoport=17/%any 
    rightrsasigkey=%cert
    rightca=%same #Wichtig das sorgt dafür dass alle Zertifikate die von der gleichen CA unterschrieben wurden wie das LeftCert angenommen wurden.
    keyexchange=ikev1 #ikev2 ist Standard auf ikev1 downgraden, da Android mit ikev1 reinkommt.

Anschließend sollte man sich noch vor der Dummheit der Nutzer und Clients schützen. Wenn der Racoon unter Andoid die Verbindung abbricht, versucht es der L2TP-Daemon dennoch aufzubauen. Die Verbindungsverwaltung bemerkt das zwar und beendet die Verbindung sofort, dummerweise wurden schon die Authentisierungs-Daten im Klartext gesendet. (Nein auch MS-Chap-v2 zählt als Klartext). Ein Angreifer kann so gezielt (über NAT) ein kurzes Downgrade erzwingen, die Daten abgreifen und dann selber ohne IPSec einen L2TP-Tunnel aufbauen.
Um das zu verhindern muss man IPTables dazu bringen Verbindungen für Port 1701(L2TP) nur dann anzunehmen, wenn diese über IPSec reingekommen sind. Früher war das einfach, da gab es ein ipsec-Device, heute muss man über die mangle-Table rann. Das ganze sieht dann wie folgt aus 

iptables -A INPUT -p udp --dport 500 -j ACCEPT #IPSec kommt immer über port 500 rein
iptables -A INPUT -p esp             -j ACCEPT # Encapsulated Security Payload - IPSec Protokoll
iptables -A INPUT -p ah              -j ACCEPT #Authentication Header - IPSec Protokoll

iptables -t mangle -A PREROUTING -p esp -j MARK --set-mark 1 # Der eigendliche Paylod kommt über das ESP protokol, alle Pakete markieren.
iptables -A INPUT -m mark --mark 1 -p udp --dport 1701 -j ACCEPT #alle Pakete die markiert wurden und an 1701 gehen werden akzeptiert.

Mittels dieser Regel lehnt der Gateway alle L2TP Pakete ab, die nicht über IPSec gesichert wurden.

Linux Bandbreiten-Monitor/Traffic-Accounting

Raptor 2101Leave a comment

Wenn man unter Linux einen Rechner betreibt findet man einen Haufen an Möglichkeiten den Bandbreitenverbrauch zu ermitteln. Betreibt man hingegen einen Router und will nicht nur den eigenen Verbrauch, sondern den Transfer-Traffic aufgeschlüsselt nach gewissen Attributen, wird es dünn im Lösungsumfeld. Soll das ganze dann noch auf einem handelsüblichen SOHO-Router laufen, wird es richtig kniffelig.

Das erste Problem ist, dass man wissen muss nach,nach was man sucht. Unter „Bandbreiten-Monitor“ verstehen die meisten Lösungsvorschläge das Monitoring des eigenen Verbrauchs/Traffic oder nur das „Gesamtaufkommen“ an einem Interface. Kurzum: Werte die sich leicht ermitteln lassen. Das aufschlüsseln des Transfertraffics bezeichnet man häufig als IP-Accounting. Danach teilt sich das Feld in folgende Lösungen auf:

  • Promiscuous Mode Basiert: Hierbei wird ein Interface in den Promiscuous-Mode geschaltet und der komplette Netzwerktraffic mitgeschnitten. Die Lösungen unterscheiden sich dann darin, wo und wie die Daten ausgewertet werden. Im einfachsten Fall werden die Pakete vorverarbeitet und an eine Sammelstelle weiter geleitet. Bekannteste Vertreter sind NTop, NProbe und bandwidthd.
  • IPTables/NetFilter Basiert: Hierbei wird ausgenutzt, dass IPTables mit protokolliert wie viele Pakete/Bytes über eine Filter-Regel gelaufen sind. Dies kann man dann asyncron über Bash-Befehle auslesen.

Der Promiscuous Mode basierten Lösungen sind die allumfassenden Lösungen. Sie schneiden alles mit und können die detailliertesten Auswertungen bieten. Sie haben jedoch immer zwei massive Nachteile. Erstens ist die benötigte CPU-Leistung enorm. Selbst die schlanke NPrope schaffte bei einem 600MHz Prozessor nicht mal Ansatzweise den zu erwartenden Transfertraffic (100Mbit/s). Auch wird das Analyseziel stark belastet. Sowohl was die Bandbreite als auch die CPU-Last betrifft. Das ist für eine einfache Bandbreitenanalyse ein wenig übertrieben. Des weiteren ist es mehr als fraglich ob das ganze rechtlich überhaupt zulässig ist. Immerhin handelt es sich hierbei um eine DPI,  jeh nach Ausführung sogar mit ungesicherter Ausleitung.

Die IPTables -Variante hat den Vorteil, dass die Pakete sowieso durch IPTables verarbeitet werden müssen. Der Overhead für das zusätzliche Monitoring hält sich in Grenzen. Auf besagtem 600 MHz Prozessor war keine Leistungsabfall durch Zu- oder Abschalten der Filter-Regeln zu messen, noch gab es eine nennenswerte CPU-Last. Der Nachteil ist jedoch, dass man wissen muss was man Monitoren will. Wenn man nur wissen will, wie viel Traffic auf ein Netzsegment entfällt, ist das einfach umsetzbar. Will man jedoch wissen auf welchen Client im Netzsegment der Traffic aufgelaufen ist, wird es schwierig. Besonders wenn es sich um ein Netzsegment mit ständig wechselnden Clients handelt wird es nahezu unmöglich das mit IPTables alleine zu bewerkstelligen.

Abhilfe schafft ein die NFLog Schnittstelle und ein Daemon aus dem pmacct.net-Project. IPTables führt das Decoding und Vorfilterung durch und leitet das Paket dann an den uacctd weiter. Dieser filtert, aggregiert und verarbeitet die Daten oder leitet sie an ein Sammelstelle weiter.

Das Ganze ist denkbar einfach zu konfigurieren. Als erstes braucht es nur IPTables-Regeln die die interessanten Pakete ausleiten.

iptables -I FORWARD -d 192.168.0.0/16 -j NFLOG --nflog-nlgroup 1
iptables -I FORWARD -s 192.168.0.0/16 -j NFLOG --nflog-nlgroup 1

Durch diese Regeln werden alle Pakete die das 192.168-Netz betreffen an die ULog-Schnittstelle weitergeleitet. Die weiteren Parameter bewirken, dass immer gewartet wird bis sich 50 Pakete gesammelt haben und nur die ersten 48 Bytes weitergeleitet werden. Die Group-Angabe ist später für die Auswertung wichtig.

Der entsprechende uacctd ist wie folgt konfiguriert:

daemonize: true
pidfile: /var/run/uacctd.pid
syslog: daemon

uacctd_group : 1
plugins: memory[host_in], memory[host_out]

aggregate[host_in]: dst_host
aggregate[host_out]: src_host

aggregate_filter[host_in]: dst net 192.168.0.0/16
aggregate_filter[host_out]: src net 192.168.0.0/16

imt_path[host_in]: /tmp/pmacct_host_in.pipe
imt_path[host_out]: /tmp/pmacct_host_out.pipe

Durch diese Konfiguration werden zwei Endpunkte angelegt, jeweils einen für ein- und ausgehendem Traffic und nach internem Client aggregiert. Der Speicherverbrauch und die Prozessorlast ist in meinem Einsatzgebiet zu vernachlässigen (selten mehr als 20 Clients gleichzeitig) kann jedoch je nach Einsatzart stark ansteigen. Ob das ganze bei 10k Clients und „portgenauem“ Monitoring noch skaliert habe ich nicht ausprobiert.

Auswerten kann man das ganze wie folgt:

pmactt -s -p /tmp/pmacct_host_in.pipe

Mit der eigenen Wunsch-Skriptsprache kann man nun die wildesten Skriptes zum überwachen des Traffics basteln.
Hier mein Beispiel für einen Perl-Skript/Munin-Plugin: munin-bandwidth.perl

Samba/CIFS und Kerberos Authentifizierung

Raptor 2101Leave a comment

Nachdem ich NFS und Kerberos installiert hatte, wollte ich auch Samba/CIFS an Kerberos anbinden. Das gestaltete sich schwerer als erwartet.

Das Einrichten auf Serverseite gestaltete relativ reibungslos. Einfach dem Samba-Dienst entsprechend Konfigurieren.

security = ADS
realm = AQUA
kerberos method = system keytab
encrypt passwords = true

Im Kerberos hinterlegt man einen entsprechenden Principal und fügt ihn dem CIFS-Server hinzu.

sudo kadmin -p kerberosadmin/admin
addprinc -randkey cifs/server.fqdn
ktadd cifs/server.fqdn

Nach einem Neustart des Dienstes werden die User-Credentials von Samba gegenüber Kerberos Authentiziert.

Auf Client-Seite war dem ganzen nicht so leicht bei zu kommen. Als erstes muss ein Client-Key am Kerberos erzeugt werden und in der Client Keytab hinterlegt werden.

sudo kadmin -p kerberosadmin/admin
addprinc -randkey cifs/client.fqdn
ktadd cifs/client.fqdn

Anschließend mounted man den Share wie folgt:

mount -t cifs //server.fqnd/Share /mnt/cifs-share -o sec=krb5,uid=1001

Bis dahin hat mich das „nur wenige“ Stunden gekostet. Der Parameter „uid“ wird scheinbar gebraucht wenn Winbind nicht so will, wie es soll. Ich hab es ums verrecken nicht hinbekommen, dass der Winbind mehr schmeißt als nur Fehler.

Daneben war es mit nicht möglich den krb5i-Modus zu aktivieren, also Schutz gegen Veränderung der einzelnen Daten-Pakete. Zudem scheint CIFS/Samba nur beim Mount die Usercredentials zu überprüfen und die Verbindung dann an den User zu knüpfen. Wenn ein anderer User (root) auf den Share zugrifft, erfolgt das unter der UID des Users der den Mount aufgemacht hat.

ics dhcp hostname direktive wird ignoriert.

Raptor 2101Leave a comment

Ich hatte bei mir das Problem, dass bei aktiven DNS-Update durch den DHCP Server „illegale“ DNS-Namen in meine dynamische Zone eingetragen wurden. Irgendein Witzbold muss sich bei Google wohl gedacht haben, dass „android_{MAC}“ ein wunderbar einfacher Hostname ist und den ein User nie ändern will.

Dummerweise wird dieser von keinem DNS Server standardmäßig akzeptiert. Man muss zu mindestens das „Sperrverhalten“ abschalten. Ich entschied mich dafür im DHCP Server ein Hostname zu definieren. Der wurde aber geflissentlich ignoriert. Das Snippet das standardmäßig als „on-commit“ Hook hinterlegt ist greift auf „option host-name“ zu anstatt auf „config-option host-name“.

Ich hab es wie folgt angepasst und in meine dhcpd.conf eingefügt

on commit {
  option server.ddns-hostname =
        pick (config-option host-name,option fqdn.hostname, option host-name);
  option server.ddns-domainname = config-option domain-name;
  option server.ddns-rev-domainname = "in-addr.arpa.";
}

RSyslog und der komfortable Weg Logfiles zu lesen.

Raptor 2101Leave a comment

Seit geraumer Zeit hab ich eine Artikel aus dem CT Sonderheft vor mir hergeschoben. Nun hab ich es endlichgeschafft RSyslog Logs über MySQL durch LogAnalyzer analysieren zu lassen. Wer nur Bahnhof versteht, hier eine kleine Zusammenfassung: Worum geht es eigendlich? Ein laufendes LinuxSystem produziert ziehmlich zentral einen Haufen LogFIles. Diese geben meist den entschiedenden Anhaltspunkt wenn es darum geht rauszufinden, was passiert ist, warum etwas nicht funktioniert und so weiter. Das Problem bei der vielzahl an Logs ist, dass man sie schlecht durchsuchen kann. Wenn man einen Zeitstempel hat, kann man vieleicht noch gezielt Suchen, aber spätestens wenn es um die Frage geht: „wann wurde Datei XY gelöscht und von wem“ wirds ungemütlich, Liegt der fragliche Zeitpunkt noch in der Logrotation, wenn ja in welcher und überhaupt ist suchen über mehrere Dateien angesagt. Wie häufig wünschte ich mir bei sowas ein statement wie folgendes:

SELECT * FROM logevents WHERE message LIKE '%filename%"

Nunja genau das kann man mit RSyslog umsetzten. Sobald man das Packet „rsyslog-mysql“ installiert (es gibt noch eine PostGreSQL Backend) werden alle LogEintrage zusätzlich auch in einer (auf Wunsch automatisch angelegten) Datenbank abgelegt. Zusätzlich deshalb, weil es blöd ist, in die Datenbank zu schreiben, dass die Datenbank nicht da ist. Hat man einmal diese Komfortstatus erreicht, will man ihn gleich richtig Auskosten. Hier kommt LogAnalyzer ins Spiel.

LogAufkommen nach Severity
LogAufkommen nach Diensten

LogAnalyzer wiederum ist eine „kleine“ PHP-Anwendung die mehrere Quellen (darunter MySQL, PlaintextFile, etc) einlesen und auswerten kann. Diese können dann Aggregiert, komfortabel durchsucht und ausgewertet werden. Das macht einem das Leben im Zweifelsfall ziehmlcih einfach. Und gerade mit dem PlaintextFile kann man so ziehmlich jede Quelle in das System einbinden Link: http://loganalyzer.adiscon.com/downloads