Syslog over TCP

[jdrizzle]

Has anyone been successful in implementing syslog over TCP with a fortigate? I know it uses RFC 3195 standard. I have tried syslog-ng and rsyslog but neither have been able to successfully receive logs. This is a mandate to migrate away from syslog over UDP. FortiAnalyzer is not an option. UDP is not an option. Any assistance with this topic would be greatly appreciated. Thanks in advance.

[Jeff_FTNT]

Try Winsyslog (http://www.winsyslog.com/en/) Linux Rsyslog is works too. If you use FortiAnalyzer, you may use Encryption method.

[emnoc]

The ng-syslog also works for unix. Just set the ng-syslog to use tcp by defining it under your sources.

[jdrizzle]

Thanks for the replies so far. FortiAnalyzer is not an option. I will have to research winsyslog. I am trying to get rsyslog to work with the im3195 module but it is not working as of yet. syslog-ng (what you referred to as ng-syslog) does not support RFC 3195 format for syslog over TCP. I have that from their developers. RFC 3195 by many is considered dead. We have other devices logging syslog over TCP fine. It is only an issue with our fortigates as they only support this legacy RFC 3195 format. I actually believe this is more of a Fortinet issue than anything.

[jdrizzle]

From winsyslog site: WinSyslog is an enhanced syslog server for windows remotely accessible via a browser with the included web application compliant to RFC 3164, RFC 3195 and RFC 5424 backed by practical experience since 1996 highly performing reliable robust easy to use reasonably priced highly scalable from the home environment to the needs of multi-national companies free for trouble-shooting in home environments (see edition comparison for limitations) Looks promising.

[Istvan_Takacs_FTNT]

Would be good to know what exactly the issue is with your syslog-ng configuration. I successfully implemented it on our network with logrotate, etc. to dump everything into separate files, the logs coming from the different devices. You can turn on TCP logging by using the ' reliable' option, but that won' t help if your syslog-ng is not correctly configured. Anyway, FGT successfully can deliver logs to any syslog targets, I' d suggest to run tcpdump on your syslog-ng host to troubleshoot the issue on that end.

[emnoc]

The RFC 3195 might be dead, but it' s the standard that' s well published. Another few options are Kiwi & mysyslogd, not a big fan of it ( former ), but the both supports syslog over tcp, not 100% sure if they are RFC3195 compliant tho. My hunch is , they are not but it' s worth looking into.

[jdrizzle]

Thanks everyone you replied. This has been a learning experience for sure. Istvan, I don' t think syslog-ng supports RFC3195. That was from individuals that represented them on their forum. I installed and configured winsyslog and it is working with the fortigates using RFC3195. I am now redesigning our syslog server environment from rhel to winOS to use winsyslog. winsyslog also supports UDP and normal TCP syslog delivery as well. Other options include native log file management, forwarding, filtering, writing syslog to the win eventlog, to name a few. Thanks everyone.

[wernfried]

Obviously syslog-ng does not support RFC3195, see Any plans to support RFC 3195?

Also in rsyslog the support seems to very poor:

RSyslog - Features

support forRFC 3195 as a sender - this is currently unlikely to happen, because there is no real demand for it. Any work on RFC 3195 has been suspend until we see some real interest in it.  It is probably much better to use TCP-based syslog, which is interoperable with a large number of applications. You may also read my blog post on the future of liblogging, which contains interesting information about the future of RFC 3195 in rsyslog.

im3195: RFC3195 Input Module

Caveats/Known Bugs

Due to no demand at all for RFC3195, we have converted rfc3195d to this input module, but we have NOT conducted any testing. Also, the module does not yet properly handle the recovery case. If someone intends to put this module into production, good testing should be conducted. It also is a good idea to notify the rsyslog project that you intend to use it in production. In this case, we’ll probably give the module another cleanup. We don’t do this now because so far it looks just like a big waste of time.

 

Not really convincing.

Best Regards