[syslog-ng] Issues with SYSLOG-NG 2.0.10 and relaying via a SSH tunnel

Marc Andersen man at inspektsecurity.com
Wed Jan 7 14:57:57 CET 2009


I think this has something to do with a feature that has been removed from the Linux Kernel at one point or other. The source IP will now always be overwritten when using an ssh tunnel or stunnel (somebody correct me if I'm wrong).

However, I think I somewhere saw a kernel patch that can be applied (I even think I saw on the syslog-ng forums, otherwise google it). The patch will enable IP source spoof (for lack of a better word).

For now to get around this, chain your hostnames so with your setup you will get a host field that looks like this:
<HOST FIELD IN SYSLOG>/<SENDER>/<SENDER WHICH SHOULD BE MACHINE A's IP/DNS BUT IS 127.0.0.1>

cheers
/Marc


On 07/01/09 14.47, "Dean Thompson" <Dean.Thompson at dtdataservices.com> wrote:



Hi Everybody,

I was wondering whether somebody might be able to help me with a problem
which appears to have been discussed before but is still continuing to
be a problem for an environment that I am working within.  The issue
relates to one host forwarding SYSLOG messages to another host via a SSH
tunnel.

Scenario:
=========

<Device> --SYSLOG MESSAGE--> Machine A <--SSH Tunnel--> Machine B

Items to note include Machine B setting up a reverse SSH tunnel with
Machine A.  Machine A has a local port of 5514 that it uses to forward
syslog messages to which sents them to machine B.  This connectivity is
working without any problems.

The issue that I am currently experiencing is on Machine B when looking
at the logs delivered via Machine A.  It would appear that Machine B
thinks that all the logs are coming from the IP address of 127.0.0.1.  I
have checked the configuration of syslog-ng on machine A and machine B
and they look as if they are configured correctly.

Syslog-NG 2.0.10 on Machine A is configured as follows:
=======================================================

options {
     log_fifo_size(1000);
     long_hostnames(off);
     use_dns(no);
     use_fqdn(no);
     keep_hostname(yes);
     check_hostname(yes);
     log_msg_size(16384);
};

source s_network {
     udp(ip(0.0.0.0) port(514));
     tcp(ip(0.0.0.0) port(514) max_connections(1000));
};

destination d_syslogmgr { tcp("127.0.0.1" port(5514)); };

[...]


Syslog-NG 2.0.10 on Machine B is configured as follows:
=======================================================

options {
     log_fifo_size(1000);
     long_hostnames(off);
     use_dns(no);
     use_fqdn(no);
     keep_hostname(yes);
     check_hostname(yes);
     log_msg_size(16384);
};

[...]


Output that is being observed:
==============================

Jan  7 12:32:34 127.0.0.1 172.XX.YY.1 3317162: 3339552: Jan  7
12:37:09.608: %LINK-3-UPDOWN: Interface FastEthernet0/7, changed state
to up
Jan  7 12:32:34 127.0.0.1 172.XX.YY.1 3317163: 3339553: Jan  7
12:37:10.457: %LINK-3-UPDOWN: Interface FastEthernet0/7, changed state
to down
Jan  7 12:32:34 127.0.0.1 172.XX.YY.1 23:37:07 accept 172.XX.YY.242
 > >eth-s2p2c3 src: 192.168.17.48; dst: 192.168.19.167; proto: tcp; rule:
22; product: VPN-1 & FireWall-1; service: 9999; s_port: 3310;
Jan  7 12:32:34 127.0.0.1 172.XX.YY.1 23:37:07 accept 172.XX.YY.242
 > >eth-s2p4c1 src: XXX.YYY.235.195; dst: 192.168.108.1; proto: udp; rule:
5; product: VPN-1 & FireWall-1; service: 53; s_port: 5707;
Jan  7 12:32:34 127.0.0.1 172.XX.YY.1 23:37:07 accept 172.XX.YY.242
 > >eth-s2p4c1 src: XXX.YYY.235.197; dst: 192.168.108.1; proto: udp; rule:
5; product: VPN-1 & FireWall-1; service: 53; s_port: 11639;
Jan  7 12:32:34 127.0.0.1 172.XX.YY.1 23:37:08 accept 172.XX.YY.242
 > >eth-s2p4c1 src: XXX.YYY.235.196; dst: 192.168.108.1; proto: udp; rule:
5; product: VPN-1 & FireWall-1; service: 53; s_port: 1325;
Jan  7 12:32:34 127.0.0.1 172.XX.YY.1 8023816: Jan  7 23:37:09.028:
%SYS-CFC8-2-MMAP: mmap failed for size 24576 bytes Caller PC 0x72B12BCC
errno 12 : ios-base : (PID=20499, TID=23) :
-Traceback=(c6lc2-sp-4-dso-b.so+0x1F9AD0) ([19:0]+0x204790)
([19:0]+0x20CEDC) ([16:-2]np.+0x84BD4) ([21:0]+0x855B8)
([9:-3]1-dso-b+0x1FE904) ([9:-3]0-dso-bn+0xD354C) ([20:0]+0xD2658)
([20:0]+0xD29D0) ([9:-3]2-dso-b+0x4E4684) ([19:0]+0x4E465C)

Ideally, I would prefer that the 127.0.0.1 was actually the 172.XX.YY.1
IP address, but it appears that there is a re-write of IP addresses
going on.  I have placed a packet sniffer on the line and I can see that
the packet which is actually sent to MACHINE B is correct (including the
correct IP addresses).  To me it would appear that the issue is in the
processing of the message at MACHINE B, but the issue may lie elsewhere.

Is there anything obvious with the configurations which would be
contributing to this problem, or is my basic understanding of how
SYSLOG-NG works when  wanting to keep hostnames and IP addresses flawed ?

Regards,

Dean

______________________________________________________________________________
Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng
FAQ: http://www.campin.net/syslog-ng/faq.html


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.balabit.hu/pipermail/syslog-ng/attachments/20090107/b8bc14ac/attachment.htm 


More information about the syslog-ng mailing list