Logiles auf anderen Server schreiben

[jlinker]

Hallo,
wie kann ich denn die Logfiles von z. B. dem Apache auf einen anderen Server schreiben. Ich hab hier irgendwo mal so was gelesen - ich glaube es war im Zusammenhang mit dem gehackten Server oder so und der Besitzer des Servers hatte dann die Logfiles auf nem anderen Server liegen.

Habt Ihr da Ideen?

[alexander newald]

Bei syslog per

*.* @remoteserverip

Wobei man sich da im klaren sein sollte, das das sehr viel Traffic produzieren kann.

Bei Apache müsste man das selber programmieren.

[jlinker]

Hi Alexander,

kannst Du mir das mit dem Syslog ein klein wenig genauer erklären - bitte :lol:

Und vielleicht "Admins" ist Webserver jetzt nicht mehr das richtige Forum.

[alexander newald]

Das syslog Programm (bzw. die beiden, einmal syslogd für die Meldungen der Benutzerprogramme und klogd für Kernel Meldungen) schreiben normalerweise Meldungen nach /var/log/<dateiname>. Welcher Dateiname für welche Meldungen genommen wird, kann man in /etc/syslog.conf einstellen.

Die Datei hat ein Format zB. von:

Code: Select all

kern.*			/var/log/kernel
*.emerg			/var/log/panic
auth.*;authpriv.*	/var/log/security

*.warning		-/var/log/warn
mail.*			-/var/log/mail
cron.*			-/var/log/cron

*.*			@192.168.1.123

Vorne bestimmt, welche Meldungen gemeint sind, hinten in welche Datei geschrieben wird. Wird der Datei ein - vorangestellt, wird nicht nach jedem Eintrag ein sync druchgeführt, also nicht das Schreiben der Daten auf die Platte erzwungen. Bei Logdateien, die häufig Einträge haben empfiehlt sich diese Vorgehensweise. Bei Logdateien, die Sicherheitskritische Informationen speichern nicht, da evtl. nach einem Serverabschturz dann nicht alle Daten in der Datei sind.

Gibt man statt der Datei ein @<ip> an, werden die Meldungen an den Server mit der angegeben IP geschickt, der die Meldungen dann weiterverarbeitet, als wären die Meldungen local entstanden.

[jlinker]

Soweit OK, aber das würde ja bedeuten, dass der empfangende Server die Meldungen akzeptieren muss. Tut er dies standardmäßig? und über welchen Port funktioniert die Kommunikation?

[alexander newald]

Nein, man muss beim Starten -r als Option mitgeben. Die Kommunikation läuft über Port 514 (UDP)

[jlinker]

Ich nehme an, du meinst beim Starten von syslogd - oder?

Entstehen dadurch Sicherheitslöcher, die man ausnutzen kann?
Habe ich als "hacker" denn dann nicht die Möglichkeit aus der Ferne die Syslog-Einträge zu korrigieren? Ich nehme mal an, dass man aus der Ferne nur Einträge anhängen kann.

[captaincrunch]

Sofern du remote-Looging in Betracht ziehst, schau dir besser syslog-ng an ( http://www.balabit.com/products/syslog_ng/ ).

[jlinker]

Dann muss ich wohl jetzt erstmal ein bisschen was zu syslog-ng lesen

Gibts ne vordefinierte .conf Datei für SUSE? Weil im Package hab ich nur Files für RedHat, HP und Solaris gefunden.

[jlinker]

Soweit alles OK, SUSE hat es im yast drinn.

Angenommen ich möchte einen Server so konfigurieren, dass er die lokalen und die externen Messages annimmt, dann würde ich die conf-Datei folgendermaßen ändern: Ist es soo ok?

source src { unix-dgram("/dev/log"); internal(); };
source net { udp(ip("xxx.xxx.xxx.xxx") port(514)); };

Um die internen in ne andere Datei zu schreiben, als die externen:
destination messages { file("/var/log/messages"); };
destination messagesextern {file("/var/log/messagesextern"); };
log { source(src); filter(f_messages); destination(messages); };
log { source(net); filter(f_messages); destination(messagesextern); };


Und wie bringe ich jetzt den anderen Server dazu, seine Meldungen per UDP514 an die gewünschte IP zu senden?

Danke schonmal :lol:

---------------------

Hat sich erledigt!! Es funktioniert! Danke für den Tipp mit syslog-ng

[petersen]

hi jlinker

am besten du tunnelst bzw. verschluesselst die verbindung auch noch z.b. via stunnel (stunnel.org)

auf dem logserver solltest du massnahmen treffen, dass der hier offene port nur meldung von deinen clients entgegen nimmt.
sonnst kann es dir passieren, das irgendwelche sozial veranlagten mitmenschen so nett sind und deine ansonsten so langweiligen logfiles mit sinnvollen eintraegen auffuellen.

gruss
petersen

[jlinker]

OK, also stunnel leuchtet mir ein, aber wie erreiche ich, dass der LogServer nur Verbindungen von einem bestimmten Server annimmt?

[floschi]

Hi!

Es gibt ein O'Reilly Buch zu dem Thema Scure Linux Servers und genau das Kapitel zum remote logging (syslog-ng per tunnel) gibt's auf deren Seiten als Probekapitel ;)

[petersen]

Hi

den nach aussen offenen port stellt dann stunnel zur verfügung. hier könnte man so konfigurieren, dass dieser nur verbindungen entgegenimmt die z.b. ein best. zertifikat vorweisen können.

Schemata
syslog-ng[127.0.0.1:514] -> [127.0.0.1:514]stunnel[$ipsrv:1724] - ... - [$ipsrv:1724]stunnel[127.0.0.1:514] -> [127.0.0.1:514]syslog-ng

Konfig-Tipps (ohne Gewähr - nicht getestet :roll: )
-Client-
syslog-ng: destination loghost {tcp("127.0.0.1" port(514));};
stunnel: stunnel -c -p /usr/local/ssl/certs/stunnel.pem -d 127.0.0.1:514 -r $ipsvr:1724

-Server-
syslog-ng: source remote {tcp(ip("127.0.0.1") port(514) keep-alive(yes));};
stunnel: stunnel -p /usr/local/ssl/certs/stunnel.pem -a /usr/local/ssl/certs -v 3 -d 1724 -r 127.0.0.1:514


ps: wichtig ist evtl. auch noch, dass du auf allen servern eine referenzzeit nutzt (z.b.via ntp)

Gruss
Petersen

[jlinker]

OK ok,

Zeitabgleich läuft sowieso bereits. Muss mich jetzt erstmal um das Stunnel kümmern.

[petersen]

welche version nutzt du denn von stunnel?

3.x oder 4.x? :?:

[jlinker]

die 4.x - und er akzeptiert die Parameter -d , etc. irgendwie nicht

[petersen]

ja, der syntax hat sich geaendert.

am besten du vergleichst mal

http://www.stunnel.org/faq/stunnel-3.xx.html (Punkt 4)
mit
http://www.stunnel.org/faq/stunnel.html#options

oder du nimmst abstand von oben geposteten Konfig-Tipps und liest dich mal komplett in die materie ein. ist im übrigen auch ganz interessant und auch für andere sachen evtl. mal nützlich.

gruss
petersen

[jlinker]

Also es funktioniert jetzt soweit. Wenn ichs richtig gesehen habe,dann benötigt stunnel 4.x eine conf-Datei.

Wenn ich jetzt Daten beliebig zwischen beiden Rechnern austauschen möchte, dann benötige ich auf jedem Server 2 Instanzen von stunnel, oder? Weil ich ja die Client=yes Option mit angeben muss, oder :?:

[petersen]

im prinzip schon - fuer ein remote-logging brauchst du aber keine "bidirektionale" verbindung.

stunnel in seiner art als ssl-"wrapper" ist hier evtl. nicht so gut geeignet.

was moechtest du denn genau austauschen?

[jlinker]

Es geht halt immer noch um die Logfiles. Ich habe 2 Server und hatte überlegt, ob es Sinn macht die Logfiles des einen jeweils auf den anderen Server zu schreiben.

Im Ã?brigen: stunnel läuft jetzt soweit - nur hab ich noch nicht rausgefunden, wie ich das mit dem Client-Zertifikat hinbekomme. Also Server darf nur Connections mit bestimmtem Client-Zertifikat erlauben.

Vielleicht ist auch stunnel überhaupt nicht das richtige Tool. Ich möchte halt vermeiden, dass mir jemand von außen die Logfiles vollschreibt. Ich hatte schon an iptables oder ähnliches gedacht. Allerdings fand ich dann die stunnel-Lösung über Verschlüsselung viel besser :lol:

Noch ne Frage: Irgendwie bekomme ich stunnel nur mit root-Rechten zum Laufen. Es sollte aber doch auch mit nem anderen User funktionieren, oder?

Danke
Jürgen

[petersen]

dann wuerde ich wohl auch zwei instanzen von stunnel nehmen. halt einmal von a->b und eben einmal von b->a

zu der verifizierung anhand von zertifikaten kann ich nur zu version 3.x was vermelden:

-v level

verify peer certificate
level 1 - verify peer certificate if present
level 2 - verify peer certificate
level 3 - verify peer with locally installed certificate
default - no verify

wenn deine clients statische ips haben, kannst du sicher mit filtern arbeiten um hier ein "einlasskontrolle" zu realisieren - denk aber z.b. an ip-spoofing :?

ich habe stunnel auch noch als root laufen (shame on me :oops: ) - aber es sollte auch unter einem anderen benutzer laufen, wenn du die stunnel-rechte entprechend anpasst.

[jlinker]

OK, Instanzen also so wie vermutet. Welche Rechte muss ich denn anpassen? Weil stunnel ja auch die openssl-lib benötigt, oder?? Dann müsste ich die ja auch mit entsprechenden Rechten zur Verfügung stellen :?:

Kannst du mit die Beschreibungen hinter den Leveln mal übersetzen. Ich bin zwar recht gut in Englisch, aber der Sinn der dahinter steckt, den hab ich noch nicht kapiert :?

[petersen]

Stunnel has 3 methods for checking certificates, which are controlled by the '-v' option:

Don't Verify Certificates

If no -v # argument is given, then stunnel will ignore any certificates offered and will allow all connections.

-v 1
Verify the certificate, if present.

If no certificate is presented by the remote end, accept the connection.
If a certificate is presented, then
If the certificate valid, it will log which certificate is being used, and continue the connection.
If the certificate is invalid, it will drop the connection.

-v 2
Require and verify certificates
Stunnel will require and verify certificates for every SSL connection. If no certificate or an invalid certificate is presented, then it will drop the connection.

-v 3
Require and verify certificates against locally installed certificates.
Stunnel will look in the directory /usr/local/ssl/certs/trusted (or whatever you specify with the -a parameter) for appropriate certificates.

ich lege dir die lektüre der faq auf stunnel.org nochmal ans herz .. es lohnt sich - glaub's mir

[jlinker]

Oh, das steht da auch drinn :oops: Hab ich wohl überlesen, weil ich mir auf Deinen Hinweis hin die Seiten inkl. FAQ bereits angesehen habe. Nur deshalb habe ich überhaupt Stunnel 4.x zum Laufen bekommen.

Danke für Deine Hilfe :lol: