Does anyone have instructions/tips for installing syslog-ng on pfsense 2.0.1?

sdb1031

Hi,
I'd like to utilize syslog-ng on my pfsense 2.0.1 router in order to achieve encrypted transport of syslog messages to a remote log server. I was thinking of installing it with the following command (i have an amd64 proc):

pkg_add -r http://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8.3-release/sysutils/syslog-ng-3.3.4_1.tbz

and disabling the existing syslog daemon from starting at boot time.

I'm sure that there has to be some other steps that I've missed, such as how to configure the syslog-ng config file, etc.
Has anyone ever installed syslog-ng on pfsense? If so, any tips that can be shared?

laleger

I too would like to integrate syslog-ng with pfSense. I've been reading up on the development documents and don't mind building a package. Is there any additional interest in having a package for syslog-ng? Is anyone already working on a package? I certainly don't want to duplicate any effort. Thanks.

stephenw10

There have in the past been some posts about this with regard to local logging as opposed to encryption as the original poster asked about.
I would be interested in this if local long term logging is what you're hoping to achieve. It's the one thing I miss from my previous router OSes (IPCop, Smoothwall, etc). I am running embedded only though so it makes things a lot more complex.

Previous posts have been around simply installing syslog-ng locally and then pointing pfSense at it as though it was an external syslog server. This minimises changes in the pfSense base.
It would be nice to have the ability to search the logs from within the GUI. I believe there is a syslog-ng web front end that you could probably get code from.
You would probably need to have some functionality to control the log size.

See:
http://forum.pfsense.org/index.php/topic,26829.0.html
and
http://forum.pfsense.org/index.php/topic,7793.0.html

Steve

laleger

Thanks for the feedback. I've been familiarizing myself with the 3.x generation of syslog-ng and here are my thoughts on an initial package:

Use the latest version of syslog-ng 3.x supported by FreeBSD 8.3 (already confirmed that the latest package works without issues on 2.0.1). This should also make the migration to pfSense 2.1 easier.
Initial GUI would be something like:
=================================================
Tab 1 - General:
Listen on interfaces (Interface selection)
Listen on port (Input: default 514)
Default log file (Input: default /var/log/syslog-ng/incoming.log)
Rotate Frequency (Select: Hourly, Daily, Weekly, Monthly)
Compress (Checkbox)
Compression (Select: gzip, bzip)
Max Archives (Input)
Tab 2 - Log Processors: Field groups to manage syslog-ng “log” objects
Tab 3 - Sources: Field groups to manage syslog-ng “sources” objects
Tab 4 - Destinations: Field groups to manage syslog-ng “destinations” objects
Tab 5 - Filters: Field groups to manage syslog-ng “filters” objects
Tab 6 - Parsers: Field groups to manage syslog-ng “parsers” objects
Tab 7 - Rewrites: Field groups to manage syslog-ng “rewrites” objects
Tab 8 - Templates: Field groups to manage syslog-ng “templates” objects
=================================================
To support the log rotation, I would reintroduce the newsyslog utility into pfSense via the syslog-ng package. As new “destinations” objects are created/removed, the newsyslog.conf file will be updated accordingly so that those log files are rotated in accordance with the settings defined under the General tab.
Allow the existing circular syslog server to continue to handle the pfSense logs. Users who desire the pfSense logs to be sent to the syslog-ng server can do so via the remote syslog settings.
These are my initial thoughts but I feel this approach should allow a great deal of flexibility for other users interested in having a separate syslog server.

stephenw10

You are clearly more familiar with this than me! ;)

Personally I would be using this only for logging pfSense.
In the embedded install of pfSense the /var is a ram drive that's lost when you reboot. Clearly unsuitable for longterm logging. But as long as this is user selectable it's probably safer to force people to make a decision rather than potentially causing damage to solid state storage.

Steve