Linux

Syslog-ng ist ein gebräuchlicher Syslog-Server auf der Linux- und Unix-Plattform. Dieses Programm implementiert das syslog-Protokoll und bietet einige Erweiterungen, die bekannte Schwachstellen des Protokolles beheben sollen. Syslog-ng ist eine quelloffene Softwarelösung. Quelle: Wikipedia

Im Gegensatz zum alten syslog bietet syslog-ng mehr Funktionen (z. B. tcp-Verbindungen) und ist flexibler zu konfigurieren. Es existiert auch eine kommerzielle Variante.

Die Konfiguration von syslog-ng ist relativ gut in der Datei /etc/syslog-ng/syslog-ng.conf erklärt.

Die allgemeine Syntax ist nach dem Schema

NAME {
        # Kommentare
        EINSTELLUNG(PARAMETER);
};

Jede Zeile und jeder Block (geschweifte Klammerm) wird also mit einem Semikolon abgeschlossen

Grundsätzlich sind vier Arten von Einstellungen zu machen

Optionen (options
Quellen (source)
Filter (filter)
Ziele (destination)

Optionen (options) wirken global.

options {
        # the number of lines buffered before written to file
        # you might want to increase this if your disk isn't catching with
        # all the log messages you get or if you want less disk activity
        # (say on a laptop)
        # (default is 0)
        #sync(0);
};

Quellen (source): Hier wird die Quellen von Protokolldaten angegeben.

Allgemeine Syntax:

source NAME {
 Einstellung
};

Als Quellen werden

Pipes
```
unix-stream("/dev/log");
```

Dateien (files)

file("/proc/kmsg" log_prefix("kernel: "));

Netzwerkquellen über

UDP
```
udp( ip(127.0.0.1) port(514) )
```
(für alte syslogs) oder

TCP unterstützt.

source NAME {tcp(ip("127.0.0.1")
 port(514));
 };

Letzteres wird bei einer Konfiguration als Log-Host (siehe unten) wichtig.

Die vorgegebene Quelle s_all sieht so aus:

source s_all {
        # message generated by Syslog-NG
        internal();
        # standard Linux log source (this is the default place for the syslog()
        # function to send logs to)
        unix-stream("/dev/log");
        # messages from the kernel
        file("/proc/kmsg" log_prefix("kernel: "));
        # use the following line if you want to receive remote UDP logging messages
        # (this is equivalent to the "-r" syslogd flag)
        # udp();
};

facility(facility1,facility2,…): Lass alle Messages durch, die dieser Facility entsprechen.
level(prio1, prio2,…) (oder synonym priority()): Lass alle Messages durch, die der angegebenen Priorität/Level entsprechen.
program(regexp): Alle Meldungen, die vom Programm kommen, worauf regexp passt, werden durchgelassen. Hierbei ist regexp ein regulärer Ausdruck. Hat man Leerzeichen (whitespaces) im Programmnamen, sollte man den Ausdruck zwischen doppelte Anführungsstriche setzen.
host(regexp): Filterung nach Host, woher die Message kommt, ebenfalls regulärer Ausdruck. Eine einfache Filterung wäre nach dem Hostnamen, z. B. so: host(myhost). Genau genommen müsste man host(„^myhost$“) schreiben.
match(regexp): Dies lässt nur Meldungen durch, wo die eigentliche Message auf dieses Muster passt. Dies ist ein sehr leistungsfähiger Mechanismus, lassen sich doch so ganz gezielt Meldungen herausfischen. Es gibt fast nichts, was man nicht mit regulären Ausdrücken erschlagen könnte.
filter(filter_name): Um kompliziertere Filterregeln zu erstellen, kann man mehrere Filter zu einem neuen Filterkonstrukt zusammenfügen. Hiermit kann man also andere Filter in einem neuen Filter aufrufen. Damit kann man verschachtelte Filterkonstrukte erstellen. Es ist oft auch für die Lesbarkeit besser, zuerst mehrere Teilfilter zu definieren, die man dann in einer weiteren Filterregel zusammenfügt.

Quelle: Selflinux (Lizenz: GNU FDL)

Ziele (destinations): Die eigentlichen Logdateien bzw. entfernte Rechner.

destination d_syslog { file("/var/log/DATEI.log" owner("root") group("adm") perm (0640)); };

Anstatt Dateien können auch andere Ziele (z. B. über tcp) angegeben werden:

destination loghost {tcp("IP" port(514));};

Als Ziel ist auch eine Datenbank (siehe sqlsyslogd usw.) möglich.

Es gibt die Möglichkeit ein Ausgabeformat mit template() festzulegen. Dies und mehr wird in der Selflinux-Dokumentation zum destination Objekt beschrieben.

Auf einem Loghost eine eine Sortierung nach Hosts usw. sehr nützlich. Beispiel:

destination std { 
	file("/var/log/HOSTS/$HOST/$YEAR/$MONTH/$DAY/$FACILITY_$HOST_$YEAR_$MONTH_$DAY" 
		owner(root) group(root) perm(0600) dir_perm(0700) create_dirs(yes)
	); 
};

Ein minimales Beispiel für die facility local0:

destination df_local0 { file("/var/log/local0.log"); };
filter f_local0 { facility(local0); };
log {
        source(s_all);
        filter(f_local0);
        destination(df_local0);
};

syslog-ng auf Client und Server installieren
auf dem Client in der Datei /etc/syslog-ng/syslog-ng.conf:
```
destination loghost {tcp("192.168.0.1" port(30514));};

log {
        source(s_all);
        destination(loghost);
};
```
Als IP des Servers 192.168.0.1 und als Port wird 30514 angenommen, die Werte sollten angepasst werden. Wenn Meldungen über fehlgeschlagene Logins (faciliy: auth, authpriv) nicht im Protokoll enthalten sein sollen, fügt man zwischen source und destination noch folgenden Zeile an:
```
filter(f_syslog);
```

auf dem Server in der Datei /etc/syslog-ng/syslog-ng.conf:

source s_remote {
  tcp(ip("192.168.0.1")
  port(30514)
  max-connections(1));
  };

destination d_remote_syslogs {
  file("/var/log/loghosts/syslogs.log");
  };

# syslog von den Clients
log {
 source(s_remote);
 filter (f_syslog);
 destination(d_remote_syslogs);
 };

# auth,authpriv von den Clients

destination d_remote_auths {
  file("/var/log/loghosts/auths.log");
  };

log {
 source(s_remote);
 filter (f_auth);
 destination(d_remote_auths);
 };

Als IP des Servers 192.168.0.1 und als Port wird 30514 angenommen, die Werte sollten angepasst werden. Ebenso die Pfade der Protokolldateien (/var/log/loghosts/auths.log und /var/log/loghosts/syslogs.log). Falls oben auth und authpriv herausgefiltet hat, ist der Abschnitt ab „# auth,authpriv von den Clients“ natürlich nicht mehr nötig. Ggf. sollten die Optionen angepasst werden:

options {
  long_hostnames(off);
  sync(0); # Anzahl der Zeilen bevor auf die Festplatte geschrieben wird
  keep_hostname(yes); # Hostnamen beibehalten?
  chain_hostnames(no); #  "chained hostname"-Format?
  };

Die Filter f_auth und f_syslog sind in der Konfiguration bereits standardmäßig vordefiniert und brauchen daher nicht mehr angegeben zu werden. Der Vollständigkeit halber dennoch:

# all messages from the auth and authpriv facilities
filter f_auth { facility(auth, authpriv); };

# all messages except from the auth and authpriv facilities
filter f_syslog { not facility(auth, authpriv); };

unfertig. Allgemeine Konfigurationsbeispiele siehe Seite von stunnel4.

syslog-ng und stunnel4 installieren

Zertfikate Server und alle Clients erzeugen (Dateinamen anpassen!):

openssl req -new -x509 -nodes -days 1095 -out loghost-server.pem -keyout loghost-server.pem

openssl req -new -x509 -nodes -days 1095 -out client1.pem -keyout client1.pem

Die Zertifikate der Clients in einer einzelnen Datei sammeln und abspeichern:
```
cat *-client.pem > all-clients.pem
nano all-clients.pem 
```
Dabei sollen —–BEGIN CERTIFICATE—– und —–END CERTIFICATE—– gelöscht werden.
nach /etc/stunnel kopieren
die Client-Zertifikate auf die entsprechenden Rechner verteilen
stunnel auf dem Server und auf dem Client konfigurieren:
1. Server:
2. Client:

Konfiguration von Syslog-ng:

Server: Am Ende der Konfigurationsdatei /etc/syslog-ng/syslog-ng.conf anfügen

destination loghost {tcp("78.47.94.237" port(50515));};
# destination stunnel {tcp("127.0.0.1" port(514));};
#                   
# log {source(src); destination(loghost);}
#
# *.*;auth,authpriv.none          -/var/log/syslog
log {
        source(s_all);
        # filter(f_syslog); # 
        destination(loghost);
};

Client:

options { long_hostnames(off);
 sync(0);};
source src {unix-stream("/dev/log");
 pipe("/proc/kmsg");
 internal();};
destination dest {file("/var/log/messages");};
destination stunnel {tcp("127.0.0.1" port(514));};

log {source(src); destination(dest);};
log {source(src); destination(stunnel);};

Wenn man an der Konfigurations schraubt muss man aufpassen, dass nach Konfigurationsfehlern am Ende auch syslog-ng wieder läuft. Ein normales

/etc/init.d/syslog-ng reload

gibt nämlich bei Debian Etch keinen Muks von sich wenn syslog-ng nicht läuft.

Einen Patch dafür und wie man ihn anwendet hab ich als Beispiel hinterlegt. Wenn man weiter anpasst kann man syslog-ng auch gleich starten lassen.

Syslog-ng

Links

Konfiguration

Optionen (options)

Quellen (source)

Filter (filter)

Ziele (destination)

minimales Beispiel

LogHost mit syslog-ng

unverschlüsselt

verschlüssel mit stunnel

Fehlerbehandlung