Issues with SYSLOG-NG 2.0.10 and relaying via a SSH tunnel
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
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@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
Hi, [ cut ]
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)); };
[...]
Unfortunately you omitted the actual log section.
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); };
[...]
Again vital information is missing like the source definition and the log section(s) where the source gets used. [ cut ]
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.
Sniffing an ssh tunnel on the wire? You must have a cool sniffer. An strace of syslog-ng on machine B would help a lot to see what's going on actually. When keep_hostname is used then hostname "rewriting" should happen only when the log message doesn't contain a hostname or an IP address. My wild guess would be that you're using the HOST_FROM macro which gets replaced by 127.0.0.1. The HOST macro should contain the originating hostname/IP address. Regards, Sandor -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
participants (3)
-
Dean Thompson
-
Geller, Sandor (IT)
-
Marc Andersen