rsyslog message weiterleitung

This is a German-language forum for those that prefer this language. For broader audience (and quicker replies) post to the English forums if you feel comfortable enough with that.

Dies ist ein deutschsprachiges rsyslog Forum. Hier gibt es keine weitere Unterteilung wie in den Englischen Foren. Wer sich bei Deutsch wohler fühlt, der Poste hier. Man bedanke aber, das Antworten hier ob der geringeren Teilnehmerzahl länger dauern können.

Google Ads


rsyslog message weiterleitung

Postby olemka » Thu Jul 22, 2010 1:13 pm

Hallo,

ich habe eine Testumgebung installiert, die syslog messages via TCP/TLS von den Cients zum zentralen Syslog Server weiterleitet.
Das funktioniert soweit einwandfrei.
Auf dem zentralen Syslog Server ist eine Evenlog Analyzer SW (Manageengine) installiert, die allerdings kein TLS versteht und auf UDP
port 514 hört.
Wenn ich nun die Messages an port 514 via rsyslog weiterleite, dann steht in den Nachrichten nicht mehr die originale Absenderadresse,
sondern die des zentralen Syslog Servers. Somit kann der Eventloganalyzer die Nachrichten nur zum eigenen Server zuordnen.
Schalte ich den EventlogAnalzer ab und nehme stattdessen den normalen syslog, steht auch die "verdrehte" Absenderadresse in den NAchrichten.

Message Flow:

Client rsyslog --TLS TCP--> (zentraler rsyslog --interne weiterleitung auf UDP 514-> Eveloganalyzer)


Client Rsyslog config:

###################################
# if you experience problems, check
# http://www.rsyslog.com/troubleshoot for assistance

# rsyslog v3: load input modules
# If you do not load inputs, nothing happens!
# You may need to set the module load path if modules are not found.

$ModLoad immark # provides --MARK-- message capability
$ModLoad imuxsock # provides support for local system logging (e.g. via logger command)
$ModLoad imklog # kernel logging (formerly provided by rklogd)

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.* /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none -/var/log/messages

# The authpriv file has restricted access.
authpriv.* /var/log/secure

# Log all the mail messages in one place.
mail.* -/var/log/maillog


# Log cron stuff
cron.* -/var/log/cron

# Everybody gets emergency messages
*.emerg *

# Save news errors of level crit and higher in a special file.
uucp,news.crit -/var/log/spooler

# Save boot messages also to boot.log
local7.* /var/log/boot.log

# make gtls driver the default
$DefaultNetstreamDriver gtls

# certificate files
$DefaultNetstreamDriverCAFile /home/balzer/TLS/ca.pem
$DefaultNetstreamDriverCertFile /home/balzer/TLS/piggy-cert.pem
$DefaultNetstreamDriverKeyFile /home/balzer/TLS/piggy-key.pem

$ActionSendStreamDriverAuthMode x509/name
$ActionSendStreamDriverPermittedPeer kermit
$ActionSendStreamDriverMode 1 # run driver in TLS-only mode
*.* @@kermit:10514 # forward everything to remote server
#######################################

Server rsyslog conf

#######################################
# Log all kernel messages to the console.
# Logging much else clutters up the screen.

$ModLoad immark # provides --MARK-- message capability
$ModLoad imuxsock # provides support for local system logging (e.g. via logger command)
$ModLoad imklog # kernel logging (formerly provided by rklogd)

$ModLoad imuxsock # local messages
$ModLoad imtcp # TCP listener

# make gtls driver the default
$DefaultNetstreamDriver gtls

# certificate files
$DefaultNetstreamDriverCAFile /home/balzer/TLS/ca.pem
$DefaultNetstreamDriverCertFile /home/balzer/TLS/kermit-cert.pem
$DefaultNetstreamDriverKeyFile /home/balzer/TLS/kermit-key.pem

$InputTCPServerStreamDriverAuthMode x509/name
$InputTCPServerStreamDriverPermittedPeer piggy
$InputTCPServerStreamDriverMode 1 # run driver in TLS-only mode
$InputTCPServerRun 10514 # start up listener at port 10514





#kern.* /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none /var/log/messages

# The authpriv file has restricted access.
authpriv.* /var/log/secure

# Log all the mail messages in one place.
mail.* -/var/log/maillog


# Log cron stuff
cron.* /var/log/cron

# Everybody gets emergency messages
*.emerg *

# Save news errors of level crit and higher in a special file.
uucp,news.crit /var/log/spooler

# Save boot messages also to boot.log
local7.* /var/log/boot.log

*.* @192.168.208.134 #Weiterleitung zum EventlogAnalyzer
######################################################


Kann jemand helfen, die originalabsenderadresse bei weiterleiten beizubehalten ?


VG und danke o.
Last edited by olemka on Thu Jul 22, 2010 1:21 pm, edited 1 time in total.
olemka
Avarage
 
Posts: 10
Joined: Thu Jul 22, 2010 12:56 pm

Urgent Question?

  • Pulling out your Hair?
  • Wasting Time and Money?
  • Deadline Approaching?

Re: rsyslog message weiterleitung

Postby rgerhards » Thu Jul 22, 2010 1:19 pm

Diese Aussage verstehe ich womöglich nicht richtig:

olemka wrote:Schalte ich den EventlogAnalzer ab und nehme stattdessen den normalen syslog, steht auch die "verdrehte" Absenderadresse in den NAchrichten.


Ist gemeint, dass dann der "richtige" Host drin steht?

Wie auch immer: das Problem dürfte sein, dass der EventlogAnalyzer einfach "dumm" die Senderadresse des UDP-Pakets nimmt. Das ist zwar oft nützlich, weil man sich damit die Mühe sparen kann, die verschiedenen Message-Formate zu erkennen (was manchmal auch einfach nicht möglich ist). Allerdings: bei diesem einfachen Ansatz ist Relaying, wie hier wohl zu sehen, nicht mehr untersützt.

Abhilfe gibt es in neuen rsyslog releases der Verson 5. Dort kann man die UDP Absenderadresse fälschen (spoofing), und rsyslog tut dann so, als sei der Absender das ursprüngliche System. Damit das klappt, müssen natürlich auch alle beteiligten Firewalls (inkl der lokalen auf dem Relay-Host!) mitspielen. Dann kann man das aber recht einfach mit dem Modul omudpspoof machen:

http://www.rsyslog.com/doc/omudpspoof.html

Rainer
rgerhards
Site Admin
 
Posts: 3806
Joined: Thu Feb 13, 2003 11:57 am

Re: rsyslog message weiterleitung

Postby olemka » Thu Jul 22, 2010 1:37 pm

Hallo Rainer,

danke der Antwort.

Ich wollte sagen das der syslog (anstatt des Eventloganalyzer) auch die "verdrehten" Nachrichten empfängt und damit unterstreichen, das es wohl am rsyslog,
der die Nachrichten weiterleitet.

VG o--
olemka
Avarage
 
Posts: 10
Joined: Thu Jul 22, 2010 12:56 pm

Re: rsyslog message weiterleitung

Postby rgerhards » Thu Jul 22, 2010 1:49 pm

ich verstehe ehrlich gesagt nicht, was "verdreht" meint. Vielleicht wäre es sinnvoll, einen tcpdump von den jeweiligen Systemen auf der Transitstrecke anzugeben.
rgerhards
Site Admin
 
Posts: 3806
Joined: Thu Feb 13, 2003 11:57 am

Re: rsyslog message weiterleitung

Postby olemka » Thu Jul 22, 2010 2:00 pm

Hallo Gerhard,

verdreht heiß in diesem Fall:
Ich erwarte die Adresse vom Client ,
es steht dort aber die des zentralen Servers am Ende der Kette.

VG O..
olemka
Avarage
 
Posts: 10
Joined: Thu Jul 22, 2010 12:56 pm

Re: rsyslog message weiterleitung

Postby olemka » Thu Jul 22, 2010 3:44 pm

Hallo,

das ist die Original Nachricht, die von rsyslog auf dem zentralen Server empfangen wird.

2010-07-22T16:33:33+02:00 piggy sshd[26170]: Connection closed by 192.168.208.134


So sieht die weitergeleitete Nachricht an den localhost (127.0.0.1) im Eventlog Analyzer ( oder auch im syslog aus).

Jul 22 16:33:33 127.0.0.1 piggy sshd[26170]: Connection closed by 192.168.208.134.

Die 127.0.0.1 wird als source IP interpretiert und "piggy" rutscht ins Nachrichtenfeld.

Vg O.
olemka
Avarage
 
Posts: 10
Joined: Thu Jul 22, 2010 12:56 pm

Re: rsyslog message weiterleitung

Postby olemka » Fri Jul 23, 2010 12:44 pm

Hallo,

nach einigem Probieren kann ich jetz die Nachrichten inter nweiterleiten,
ohne das sie Source Adresse verändert wird.

$template spoofaddr,"%fromhost-ip%"
$template spooftemplate,"%rawmsg%"
$ActionOMUDPSpoofSourceNameTemplate spoofaddr
$ActionOMUDPSpoofTargetHost kermit
$ActionOMUDPSpoofSourcePortStart 514
$ActionOMUDPSpoofSourcePortEnd 514
*.* : omudpspoof:;spooftemplate


VG
olemka
Avarage
 
Posts: 10
Joined: Thu Jul 22, 2010 12:56 pm

Re: rsyslog message weiterleitung

Postby thomas » Mon Oct 18, 2010 9:54 am

Hallo,

ich habe ein Problem mit dem spoofing bei der Version 5.5.7.

Es werden von verschiedenen Servern syslog messages via rsyslog auf einen zentralen Server geleitet der wiederum leitet die messages via rsyslog an ein OpenNMS (Ziel-System). Auf diesem zentralen Server Server wird das Spoofing gemacht.
Das Spoofing und weiterleiten der syslog messages aller Server über den zentralen Server (192.168.41.70) zum Ziel-System (192.168.40.60 OpenNMS) funktioniert hervorragend.

Außer: syslog messages von dem zentralen Server selbst. Diese haben als Source IP Adresse immer 127.0.0.1. Sie sollen aber die IP Adresse des zentralen Servers selbst (192.168.41.70) haben. Scheinbar werden IP Packete mit Source IP 127.0.0.1 gar nicht zum Ziel-System weitergeleitet.

Wie kann ich syslog messages die lokal auf dem zentralen Server generiert werden mit der richtigen IP Adresse des zentralen Servers zum Ziel-System weiterleiten ?

Der entsprechende part der rsyslog.conf sieht so aus:

$ModLoad omudpspoof
$template spoofaddr,"%fromhost-ip%"
$template spooftemplate,"%rawmsg%"
$ActionUDPSpoofSourceNameTemplate spoofaddr
$ActionUDPSpoofTargetHost 192.168.40.60
$ActionUDPSpoofSourcePortStart 514
$ActionUDPSpoofSourcePortEnd 514
*.* :omudpspoof:;spooftemplate

Viele Grüße
Thomas
thomas
New
 
Posts: 1
Joined: Wed Oct 06, 2010 6:11 am

Google Ads



Return to Deutsches rsyslog Forum

Who is online

Users browsing this forum: No registered users and 0 guests

cron