syslog sendet keine Daten an remote server

Abend,

ich würde gerne Meldungen per syslog an einen remote server schicken, aber leider sendet er nichts! Ich benutze OpenBSD v6.5

Habe in die /etc/syslog.conf den Eintrag *.* @192.168.1.1 gesetzt und mit /etc/rc.d/syslogd restart den Dienst neu gestartet.
Aber es fließen leider keine Daten mittels Kontrolle: tcpdump -nettti <Interface von 192.168.1.111> host 192.168.1.1

Was habe ich vergessen bzw. was mache ich falsch?
 
Also bei meinen Tests mit 2 OpenBSDs 6.7 APUs funktioniert es…
Code:
#    $OpenBSD: syslog.conf,v 1.20 2016/12/27 13:38:14 jca Exp $
#

*.* @192.168.1.1
*.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none    /var/log/messages
kern.debug;syslog,user.info                /var/log/messages
auth.info                        /var/log/authlog
authpriv.debug                        /var/log/secure
cron.info                        /var/cron/log
daemon.info                        /var/log/daemon
ftp.info                        /var/log/xferlog
lpr.debug                        /var/log/lpd-errs
mail.info                        /var/log/maillog

# Uncomment this line to send "important" messages to the system
# console: be aware that this could create lots of output.
#*.err;auth.notice;authpriv.none;kern.debug;mail.crit    /dev/console

# Uncomment this to have all messages of notice level and higher
# as well as all authentication messages sent to root.
#*.notice;auth.debug                    root

# Everyone gets emergency messages.
#*.emerg                            *

# Uncomment to log to a central host named "loghost".  You need to run
# syslogd with the -u option on the remote host if you are using this.
# (This is also required to log info from things like routers and
# ISDN-equipment).  If you run -u, you are vulnerable to syslog bombing,
# and should consider blocking external syslog packets.
#*.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none    @loghost
#auth,daemon,syslog,user.info;authpriv,kern.debug        @loghost

# Uncomment to log messages from doas(1) to its own log file.  Matches are done
# based on the program name.
# Program-specific logs:
#!doas
#*.*                            /var/log/doas

Ein tcpdump dürfte sich bei einem UDP Versand allerdings generell etwas schwer tun.

Ich hab es so getestet.
auf der Empfänger Kiste syslogd in rc.d gestoppt und händisch mit dem Parameter -u gestartet. Danach ein tail -f /var/log/messages ausgeführt und auf dem Sender syslogd neu gestartet (um eine message auszulösen)
 
Aber warum tut sich tcpdump damit so schwer. Ich hätte erwartet die Packet ausgehend zum RemoteServer zu sehen - da hätte ich ja lange suchen können!

Diese Verbindung ist ja unverschlüsselt - wie kann ich diese am besten schützen?
 
aber tcpdump erwartet halt TCP Pakete. UDP arbeitet ein wenig anders.

Innerhalb eines LAN's (wie du es tust) halte ich den Schutz per Verschlüsselung für unnötig. Will man das über das Internet versenden sollte man das ganze per tls oder durch ein vpn schützen
 
aber tcpdump erwartet halt TCP Pakete.
Hä? tcpdump kann IP-Pakete aller Art anzeigen. Egal ob TCP, UDP oder ICMP.

Will man das über das Internet versenden sollte man das ganze per tls oder durch ein vpn schützen
Wenn man Verbindungen schützen will, muss man sie verschlüsseln. Aha. Ganz tolle Antwort und an Nutzlosigkeit kaum zu übertreffen. :-)

Das Handbuch gibt den Tipp stunnel zu verwenden. Was für Deine Zwecke durchaus auch ne brauchbare Methode ist.
Die haben auch ne schicke Homepage: https://www.stunnel.org/
 
Nur noch so als Hinweis: FreeBSD Anleitungen sind oft nicht 1zu1 auf OpenBSD anwendbar.

Dass ich tcpdump mit telnet verwechselt habe kommt leider öfter vor… Asche auf mein Haupt.
Mit tcpdump -i <interface> host 192.168.1.1 and udp and port 514 bekam ich Ergebnisse
Und Andy hats jetzt wieder auf meiner Ignore Liste geschafft.
 
Also mit dem neuen tcpdump-Befehl bekomme ich keinen Output.

Habe noch mal mit netstat -na -f inet auf der BSD-Maschine geschaut und den nachfolgenden Output:

Bash:
Active Internet connections (including servers)
Proto   Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp ...
Active Internet connections (including servers)
Proto   Recv-Q Send-Q  Local Address          Foreign Address        (state)
...               
udp          0      0  *.514                  *.*                   
udp          0      0  *.*                    *.*

Aber müsste es nicht so in der Art aussehen:
udp x x 192.168.1.111.xxxxx 192.168.1.1.514
 
Nur noch so als Hinweis: FreeBSD Anleitungen sind oft nicht 1zu1 auf OpenBSD anwendbar.
Huch. Mein Fehler. Ich hab das doch glatt verwechselt und gar nicht mitbekommen, das es um OpenBSD und nicht um FreeBSD geht.

Dass ich tcpdump mit telnet verwechselt habe kommt leider öfter vor
tcpdump? Mit telnet???

Und Andy hats jetzt wieder auf meiner Ignore Liste geschafft.
Da ist jemand aber arg kritikunfähig. :-)
Dabei lag doch der Fehler auch bei mir und nicht nur bei ihm.
 
Zuletzt bearbeitet:
Nachdem es bei mir auch so ausschaut und er Daten überträgt würde ich sagen nein…
Aber man kann ja relativ einfach ausprobieren ob er grundsätzlich syslog Daten übertragen würde:
2 Terminals zur OpenBSD Maschine aufmachen, oder auf der OpenBSD Maschine tmux verwenden
Im einen Fenster tcpdump -i <interface> host 192.168.1.1 and udp and port 514 (<interface> natürlich durch das verwendete interface ersetzen bei OpenBSD ist es meist sowas wie em0 oder athn0 … bei mir wars tun0 weil ich es durch ein vpn gejagt habe) laufen lassen
Im anderen Fenster nc -u 192.168.1.1 514 (weiss gerade nicht ob nc (also netcat) in der Grundinstallation drin ist… bei Bedarf nachinstallieren) ausführen und dann einfach ein paar ascii Zeichen eingeben gefolgt von einem return.
Im Fenster mit tcpdump sollte dann eine Zeile wie
05:51:01.116696 192.168.1.111.4904 > 192.168.1.1.syslog: udp 5
rauskommen.
Dazu braucht syslog auf der anderen Seite nicht mal empfangsbereit zu sein.
Funktioniert das schon nicht … liegt's wahrscheinlich nicht, oder nicht nur an syslog
Funktioniert das, poste mal gesamte syslog.conf hier rein (bei den 3 punkten hier im reply editor kannst du das mit dem spoiler und code verwenden wie ich vor ein paar Posts) vielleicht ist *.* 192.168.1.1 nur an der falschen Stelle
Ausserdem bin ich mir nicht sicher ob ich nicht statt /etc/rc.d/syslogd restart mal kill -HUP `cat /var/run/syslog.pid` wie auf einer IBM Knowledge Center Seite vorgeschlagen verwendet habe.
 
Habe es nach deiner Anleitung mit nc gemacht und bekomme beim TCPDUMP nur dieses eine LOG:
Code:
tcpdump: listening on em1, link-type EN10MB
10:18:19.792173 SYSTEMNAME.syslog > 192.168.1.1.syslog: udp 131

Habe auch schon mal mit kill ... neugestartet aber kein Unterschied!

Hier meine syslog.conf:
Code:
#       $OpenBSD: syslog.conf,v 1.18 2015/07/17 21:45:52 ajacoutot Exp $
#

*.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none /var/log/messages
kern.debug;syslog,user.info                             /var/log/messages
auth.info                                               /var/log/authlog
authpriv.debug                                          /var/log/secure
cron.info                                               /var/cron/log
daemon.info                                             /var/log/daemon
ftp.info                                                /var/log/xferlog
lpr.debug                                               /var/log/lpd-errs
mail.info                                               /var/log/maillog
#uucp.info                                              /var/log/uucp

# Uncomment this line to send "important" messages to the system
# console: be aware that this could create lots of output.
#*.err;auth.notice;authpriv.none;kern.debug;mail.crit   /dev/console

# Uncomment this to have all messages of notice level and higher
# as well as all authentication messages sent to root.
#*.notice;auth.debug                                    root

# Everyone gets emergency messages.
*.emerg                                                 *

# Uncomment to log to a central host named "loghost".  You need to run
# syslogd with the -u option on the remote host if you are using this.
# (This is also required to log info from things like routers and
# ISDN-equipment).  If you run -u, you are vulnerable to syslog bombing,
# and should consider blocking external syslog packets.
#*.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none        @loghost
#auth,daemon,syslog,user.info;authpriv,kern.debug               @loghost

*.*                                                             @192.168.1.1

# Uncomment to log messages from doas(1) to its own log file.  Matches are done
# based on the program name.
# Program-specific logs:
#!doas
#*.*                                                    /var/log/doas
 
Das mit dem tcpdump sieht doch schonmal garnicht so schlecht aus… die Zahl am Schluss sind afaik die verschickten Byte. .syslog gibt den udp port 514 an. (wobei es etwas komisch ist, wenn du nc verwendest, dass beim ersten .syslog in der Zeile dieser Port verwendet wird, anyway)
Vielleicht liegt es wirklich an der Position von *.* @192.168.1.1. Wie man an meinem spoiler Beispiel sieht, ist es in meinem Testaufbau den ich gestern gemacht habe, vor allen anderen Regeln.
Als Referenz hab ich das Beispiel von IBM genommen:
https://www.ibm.com/support/knowled...m.ibm.dsm.doc/t_DSM_guide_OpenBSD_syslog.html
 
Lustig. Kaum hat man was gesagt, kommen auch brauchbare Antworten.
Also doch kritikfähig. :-)
Daumen hoch!
 
tcpdump? Mit telnet???
Ich bin kein Netzwerk Spezialist… wenn ich trotzdem mal bei einem Kunden etwas z.B. auf ner pfSense testen oder fixen muss, kommen tools wie tcpdump und telnet ins Spiel (ist mir in den letzten 7 Jahren 3x passiert, kein einziges mal hatte ich das Attribut udp benötigt). Eines dieser beiden Tools kann kein UDP.
 
Habe jetzt meinen Syslog-Eintrag in die dritte Zeile geschrieben und dann tcpdump gemacht:
Wenn ich jetzt den Dienst mit kill neu starte kommt genau die eine Zeile einmal.
Code:
TESTSYSTEM: ~ # tcpdump -i em1 host 192.168.1.1 and udp and port 514
tcpdump: listening on bge3, link-type EN10MB
13:37:18.829320 TESTSYSTEM.syslog > 192.168.1.1.syslog: udp 41
Was stimmt den mit meinem Syslog nicht - Normaleweise müsste es ein Flut an Daten sein!?
 
@Andy_m4
der Ton macht die Musik… Eine Aussage das man tls oder ein vpn verwenden solle als
"an Nutzlosigkeit kaum zu übertreffen" zu bezeichnen
dann aber eine Art auf TLS basierendes VPN drunter hängt (wobei syslog selbst tls unterstützt)
Ist halt etwas, dass mich extremst nervt.
 
Ich bin kein Netzwerk Spezialist… wenn ich trotzdem mal bei einem Kunden etwas z.B. auf ner pfSense testen oder fixen muss, kommen tools wie tcpdump und telnet ins Spiel (ist mir in den letzten 7 Jahren 3x passiert, kein einziges mal hatte ich das Attribut udp benötigt).
Ja. Ich verstehe. So kann man z.B. auch Webserver testen:
telnet www.myserver.de 80 GET /
usw. :-)
Dabei geht es darum, Prozess A lauscht auf nem TCP/IP-Socket und man will mit dem reden.
tcpdump ist eher: Prozess A spricht via IP mit Prozess B und mal will die belauschen.

der Ton macht die Musik
Ich will jetzt nicht kleinlich sein, aber Du hast mit dem "Ton" quasi vorgelegt indem Du eine halbgarre und lieblose Antwort gegeben hast. Eine Antwort der Kategorie "Dann lässt man es lieber bleiben".
Und sowas verstehe ich immer nicht. Wenn die Leute SICHTBAR kein Bock auf ne Antwort haben, dann sollen sie es bleiben lassen statt unbrauchbare Antworten zu geben und sogar noch Unsinn zu verbreiten.

Ist auch ansich kein Problem. Jeder kann ja auch mal ein schlechten Tag haben. Aber hey: Dann steh dazu und spiel nicht noch die beleidigte Leberwurst wenn jemand dazu was sagt.
 
Was stimmt den mit meinem Syslog nicht - Normaleweise müsste es ein Flut an Daten sein!?
Nicht unbedingt es sei denn du schaltest sowas wie eine debug Modus ein
Die letzten 4 Einträge meiner übertragenen /var/log/messages
Sahen vor 10 Minuten wie folgt aus
Code:
Apr 30 19:15:38 puffy1 syslogd[28544]: start
Apr 30 20:00:01 puffy1 syslogd[28544]: restart
May  1 05:00:01 puffy1 syslogd[28544]: restart
May  1 10:42:34 puffy1 syslogd[59422]: start

Du solltest halt jetzt mal deine Log Dateien von OpenBSD mit den empfangenen Logeinträgen vergleichen…
Bei 2 OpenBSD Systemen steht dann halt z.B. in /var/log/messages auf der empfangenden Maschine
Statt "puffy1" die IP Adresse (vielleicht aber auch der Name falls DNS funktioniert) des Senders drin

Edit: wahrscheinlich würde ein Log von pf auch Daten on mass produzieren… ich hatte mal von einer pfSense solche Logs an meine splunk Instanz übertragen was meine 10 GB/Tag Lizenz innerhalb von ein paar Stunden aufgebraucht hatte
 
Zuletzt bearbeitet:
Es läuft pflog mit einer stündlich Produktion von ca. 4000 Einträgen - deshalb wundert mich ja warum keine "Flut" an Daten kommt.

/var/log/messages muss ich noch prüfen
 
Habe jetzt mal drei Stunden tcpdump laufen lassen und auf dem remote server geschaut. Sind so ca. 300 Einträge vorhanden.
In /var/log/messages sind ganze 3 Einträge - er sendet also schon einmal deutlich mehr!
Es geht also - ich vermute ich war zu ungeduldig, da ich erwartet hatte er schickt auf pflog-Daten.

Wie schaffe ich jetzt, dass er die pflog0 Einträge per syslog schickt?
 
In der Datenbank taucht lieder nur die IP der TESTMASCHINE auf.

WIe schaffe ich es, dass er den Hostnamen mit sendet?
 
Habe ich gemacht...muss ich irgendwetwas neu laden???

Zu dem Schicken der pflogs habe ich hier eine Lösung:

Code:
#Add to /etc/rc.local:
pflogd -f /dev/null
nohup tcpdump -l -q -n -e -ttt -i pflog0 | logger -t pf -p local0.info &

#and add to /etc/syslog.conf:
local0.info @loghost

Spricht gegen diese Lösung irgendetwas dagegen
 
Habe ich gemacht...muss ich irgendwetwas neu laden???

Hatte erst nach der änderung der /etc/hosts syslogd gestarte, als ich das getestet habe. Ein restart von syslogd kann imho nicht schaden

Zu dem Schicken der pflogs habe ich hier eine Lösung:

Code:
#Add to /etc/rc.local:
pflogd -f /dev/null
nohup tcpdump -l -q -n -e -ttt -i pflog0 | logger -t pf -p local0.info &

#and add to /etc/syslog.conf:
local0.info @loghost

Spricht gegen diese Lösung irgendetwas dagegen

So bzw. so ähnlich (weil er den schritt in die rc.local nicht beschrieben hat oder ich das nicht gesehen habe bisher) wurde es von Peter N.M. Hansteen zumindest im "Book of pf" beschrieben.
 
Zurück
Oben