In order to develop a cross-plateform syslog client, I am trying to do it without using the syslog syscall. I am developping this client in C++ and for now testing in Linux. The old syslog client that I am replacing was working perfectly fine with the syslog syscall.
For how, it simply doesn't work. The trace is not in /var/log/user.log like it should be, either anywhere else (greped). But I do receive it when I listen on the right port with netcat. Shouldn't the port 514 be already in use by the way ?
The trace is as it should be sent on UDP/514. I tried to stick the RFC 3164 but something is still obviously wrong.
Id really appreciate if someone could give me a hint to solve this.
Trace: severity: 2 (Critical); facility: 23 (Local Use 7) ==> priority: 186
sh$> sudo nc -ul localhost -p 514
<186>Oct 18 10:36:03 hostname test_trace: | 10:36:03.242995 | CRIT | xxx-MAIN[5473-000] | 00000 | 0008 : main : user_msg
Thank you !
I think I found the problem in my own question: Rsyslog (my syslog server) doesn't listen on UDP/514 correctly.
/etc/rsyslog.conf
$ModLoad imudp
$UDPServerAddress 0.0.0.0
$UDPServerRun 514
If someone has any idea of why it still doesn't listen on UDP/514, I'd be really thanksful cause I really don't see why.
Thank you again.
The syslog() call writes to /dev/log and the system logger reads this unix domain socket to pick up the message. UDP/514 is for network transmission.
So it is not clear what you want.
Related
I am configuring rsyslog on a Linux server and want to configure it with TLS secure transport, I follow many documentation including rsyslog official guide (https://www.rsyslog.com/doc/v8-stable/tutorials/tls.html), the thing is that I can see udp port listening, but tcp doesn't and not getting errors on configuration validation, so I am blind and not seeing why tcp port is not listening, I try low and high ports and nothing, I am attaching configuration file that I use last time and the configuration validation output, thanks for any help!
module(load="imuxsock")
module(
load="imtcp"
StreamDriver.Name="gtls"
StreamDriver.Mode="1"
StreamDriver.Authmode="anon"
)
input(type="imtcp" port="11514")
module(load="imudp")
input(type="imudp" port="1514")
global(
DefaultNetstreamDriver="gtls"
DefaultNetstreamDriverCAFile="/var/ossec/agentless/rsyslog/ca.pem"
DefaultNetstreamDriverCertFile="/var/ossec/agentless/rsyslog/server/cert.pem"
DefaultNetstreamDriverKeyFile="/var/ossec/agentless/rsyslog/server-key.pem"
)
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
$RepeatedMsgReduction on
$FileOwner syslog
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022
$PrivDropToUser syslog
$PrivDropToGroup syslog
$WorkDirectory /var/spool/rsyslog
$IncludeConfig /etc/rsyslog.d/*.conf
And validation:
# rsyslogd -N6
rsyslogd: version 8.16.0, config validation run (level 6), master config /etc/rsyslog.conf
rsyslogd: End of config validation run. Bye.
Netstat output:
# netstat -na |grep 514
udp 0 0 0.0.0.0:1514 0.0.0.0:*
udp6 0 0 :::1514 :::*
Thanks for the answers, the problem apparently was not in the rsyslog configuration, but in Wazuh, the software that was trying to receive the logs of the rsyslog, what I did was change the configuration of the ossec.conf of Wazuh and the open port, create another remote control, one with safe value and one with syslog value and it worked, thanks for all the support as always !!! Hugs and take care
Got strange stuff. Setup: VirtualBox + CentOs7 + python3.6 + scapy2.4.0
Got network with only 4-5 hosts active: gateway, CentOs in VirtualBos, PC on which VirtualBox running and something else.
Trying to do:
ans, unans = sr(IP(dst='10.10.10.1-100')/ICMP(), iface = 'enp0s3', retry=0, timeout=1)
Begin emission: ...
Received 1822 packets, got 99 answers, remaining 1 packets
ans
Results: TCP:0 UDP:0 ICMP:99 Other:0
unans
Unanswered: TCP:0 UDP:0 ICMP:1 Other:0
ans[x] - are legit ICMP Reply packets.
unans[0] - no ICMP reply from CentOs VM itself
So looks like everything is alive instead of 4-5 hosts which actually are alive
What could be the possible reason ?
You want to know the possible reason, but scapy is not giving you enough details. So use tcpdump:
$ sudo tcpdump -e -c 200 icmp
Send the probe packets while tcpdump is running, in order to view address and timing details. It is possible you are seeing lots of perfectly normal ICMPs, for example port unreachable, or network unreachable. Tcpdump will tell you exactly what went over the network interface.
My server setup is nginx directly connects to a node.js server (nginx and node.js are in the same node and nginx is forwarding request to node: 127.0.0.1:8000). The symptom is sometimes there are some 504 logs in nginx log. And node.js log doesn't show any sign of ever receiving the request.
I then enabled tcp log using iptables, which logs all tcp packets to port 8000. After checking the tcp log, it seems that nginx was trying to establish a tcp connection with node.js server, but it never succeeds. It just kept retrying sending SYN packets and then got timed out by nginx. Here's an example (tcp + nginx log):
13:44:44 sp:48103 dp:8000 SYN
13:44:45 sp:48103 dp:8000 SYN
13:44:47 sp:48103 dp:8000 SYN
13:44:51 sp:48103 dp:8000 SYN
13:44:59 sp:48103 dp:8000 SYN
13:45:15 sp:48103 dp:8000 SYN
13:45:44 nginx 504
During the period, the CPU load is pretty light, memory < 50%, incoming request is less than 50 per minute. And other requests were processed normally.
Server is Ubuntu 14.04.2 LTS
Any idea what's going on? Seems like an OS level issue? Thank you in advance.
Check whether something is actually running on TCP port 8000 on your loopback interface. Try some commands like:
lsof -P -n -i tcp:8000
fuser 8000/tcp
ss -4lnt
netstat -4lnt
These should give you some hints on whether something is listening at all. Or it may only be listening on a specific interface/address and not your loopback.
I wrote a minuscule script to test an SMTP connection with Net::SMTP:
#!/usr/bin/perl -w
use strict;
use Net::SMTP;
my $smtp = Net::SMTP->new( 'mypc', Port => 10025, Timeout => 30, Debug => 1 );
die "Couldn't connect to SMTP server" unless $smtp;
An SMTP server is running on mypc:10025 and dumps all I/O it does. When I execute the script from a Debian Linux machine (64bit, Perl v5.20.2), the SMTP server shows I/O activity and everything works as expected:
zb226#debian8:~$ ./net_smtp.pl
Net::SMTP>>> Net::SMTP(2.33)
Net::SMTP>>> Net::Cmd(2.30)
Net::SMTP>>> Exporter(5.71)
Net::SMTP>>> IO::Socket::INET(1.35)
Net::SMTP>>> IO::Socket(1.38)
Net::SMTP>>> IO::Handle(1.35)
Net::SMTP=GLOB(0x118adc0)<<< 220 Hi
Net::SMTP=GLOB(0x118adc0)>>> EHLO localhost.localdomain
Net::SMTP=GLOB(0x118adc0)<<< 250 OK
When I execute this on the Windows 8 machine (64bit, Strawberry Perl 5.22.0), no connection is established. I can see this by the total absence of I/O in the SMTP server. Net::SMTP does not connect. The script just dies, as is expected in this case:
C:\test>perl -w net_smtp.pl
Couldn't connect to SMTP server at net_smtp.pl line 5.
Observations:
Interestingly, the script dies after what feels like 3 seconds, not the 30 seconds I specified.
I can use telnet.exe to connect to the SMTP server and it shows I/O activity.
I have tried turning off the Windows firewall completely without any improvement.
I had an admin disable the corporate anti-virus software temporarily without any improvement.
Updating Strawberry Perl to the currently recommended 5.24.0.1 didn't help either.
I'm not sure what to try next.
Edit: Tried a small IO::Socket::INET script to verify perl can actually connect on this Windows PC:
#!/usr/bin/perl
use strict;
use IO::Socket::INET;
my #hosts = qw/ mypc:10025 /;
foreach my $host ( #hosts ) {
my $open = defined IO::Socket::INET->new(PeerAddr => $host, Timeout => 5) || 0;
printf "Probed %s -> %s \n", $host, $open ? 'ok' : 'NOK';
}
I see I/O in the SMTP server and it works as expected:
C:\test>perl -w io_socket.pl
Probed mypc:10025 -> ok
Based on the information from the other answer the underlying problem is, that
the hostname used resolves to both an IPv4 and IPv6 address,
the SMTP server is only listening at the IPv4 address or the IPv6 address is blocked by a firewall,
and a recent version of Net::SMTP is in use which contrary to older versions transparently supports IPv6 and IPv4.
Because if the IPv6 support and the commonly used preference for the newer IPv6 against IPv4 Net::SMTP will resolve the hostname and then try the IPv6 address - and fail to connect. Direct use of IO::Socket::INET instead works because it is doing only IPv4 (contrary to IO::Socket::IP used by Net::SMTP).
The reason it works on Linux and not on Windows is probably the different version of Perl: the new version of Net::SMTP with built-in IPv6 (and SSL) support ships only since Perl 5.22 as a CORE module, i.e. the Perl on Windows (5.22) has the version with IPv6 support while the Perl on Linux (5.20) does not.
There are several ways to fix the problem:
use the IPv4 address directly instead of the hostname
make the SMTP server listen on both IPv4 and IPv6
or specify the address family to use, i.e.
my $smtp = Net::SMTP->new( 'mypc', ..., Domain => AF_INET );
Following this discussion, I found that the problem is related to IPv6. Opening C:\strawberry\perl\lib\Net\SMTP.pm and changing the line...
our #ISA = ('Net::Cmd', $inet6_class || 'IO::Socket::INET');
...to...
our #ISA = ('Net::Cmd', 'IO::Socket::INET');
...makes the original script run:
C:\test>perl -w net_smtp.pl
Net::SMTP>>> Net::SMTP(3.08)
Net::SMTP>>> Net::Cmd(3.08)
Net::SMTP>>> Exporter(5.72)
Net::SMTP>>> IO::Socket::INET(1.35)
Net::SMTP>>> IO::Socket(1.38)
Net::SMTP>>> IO::Handle(1.36)
Net::SMTP=GLOB(0x58e8fc)<<< 220 Hi
Net::SMTP=GLOB(0x58e8fc)>>> EHLO localhost.localdomain
Net::SMTP=GLOB(0x58e8fc)<<< 250 OK
For now, I'm relieved because I can continue my work, but if anybody has further clues as to how to avoid this ugly patch, I'll happily accept an elaborated answer.
Edit: Correspondingly and without patching, disabling IPv6 does the trick as well.
I lunched a simulator program which developed on C++ in my Ubuntu 11 when i want kill this process from process list of Linux and want to run it again, i faced to this error:
Error initializing sockets: port=6000. Address already in use
I used lsof command to find PID of process:
saman#jack:~$ lsof -i:6000
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
rcssserve 8764 saman 3u IPv4 81762 0t0 UDP *:x11
after that i tried to kill PID of 8764. but still it has error.
How can i fix it?
I think the problem you are having is that the socket if it is not shutdown correctly then it is still reserved and waiting for a timeout to be closed by the kernel.
Try doing a netstat -nutap and see if there's a line like this:
tcp 0 0 AAA.AAA.AAA.AAA:6000 XXX.XXX.XXX.XXX:YYYY TIME_WAIT -
if that's the case you just have to wait until the kernel drops it (30 secs approx) until you can open the socket at 6000 without conflict
It would seem that port 6000 is used by the X windowing system (the GUI part of linux) and is probably just restarted when you kill the process... either you'll need run the simulation without X-windows running, or you tweak the code to use a different port..