Hello,
→ REMOTE LOGS via UDP, ok.
→ REMOTE LOGS via TCP, not ok.
I saw that IPFIRE uses syslogd…but syslog doesn’t handle TCP.
Issue 1:
The interface offers TCP … how to make it work?
Issue 2:
UDP transits in text… it’s not very secure for firewall data.
TCP SSL or UDP SSL would be more suitable.
Why did you choose syslog?
Hallo @bidochon
IPFire is using sysklogd
The choice was made a very long time ago (~20 years ago).
The IPFire developers team is very small and very busy. Someone would need to volunteer to look at replacing sysklogd with a different version that enabled encryption.
This has been raised a few times on the forum in the past but unfortunately no one has volunteered to support coming up with the updates required to make it work and be backwards compatible for all existing users.
Always open and willing to have new volunteers join the team.
I checked the documentation of sysklogd, both the github page, the man page and even the tutorial advertised in the github documentation and I cannot see any mention of TCP layer control transport, only UDP. I think this could be a bug of the WUI.
EDIT, from what I can see, rsyslog and syslog-ng have an added layer to handle TCP transmission control style, but I think OP is correct, IPFire does not seems to support these newer implementation of the protocol.
Looking through the config.dat perl code for that WUI page the protocol is related to what the remote syslog server is able to use.
The logs are then sent to the remote server using a program syslogdctrl which has been compiled in c
https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/misc-progs/syslogdctrl.c;h=3ae6bf8888b049f60bd654e649ae7da28cf92852;hb=refs/heads/core175
In the above c code line 121 is for sending the data with TCP and line 126 for UDP.
I am not familiar enough with how syslogging occurs or with c code, to be able to explain anything further from that code.
@bonnietwin Great work digging trough the code. I pasted the C code to GPT 4 and asked if this code is able to send over TCP a syslog message to rsyslog or syslog-ng, and by its code analysis the answer is YES. Quote:
The provided code is a program that adjusts the system’s syslog configuration based on settings in IPFire’s config file at
/var/ipfire/logging/settings. It modifies the/etc/syslog.conffile accordingly and then sends a SIGHUP to the syslog daemon to make it re-read the configuration.
However, it assumes that the syslog daemon can interpret the “@@” syntax for indicating a TCP connection. This “@” and “@@” syntax is supported by modern syslog implementations such as rsyslog and syslog-ng. But as we discussed earlier, the traditional syslogd daemon doesn’t natively support TCP connections.
So, if you replace syslogd with a daemon that supports TCP (like rsyslog or syslog-ng), then this script would likely be compatible, as long as the new syslog daemon uses a similar syntax for its configuration files. You’ll need to confirm this with the specific documentation for whichever syslog daemon you choose to use.
Do remember to test any changes thoroughly on a non-production system first, as modifying system packages on IPFire can be risky and potentially cause system instability.
EDIT @bonnietwin I chenged my opinion, the C code is NOT handling the message, but it is only changing the configuration file of syslogd, which DOES NOT SUPPORT TCP. I think this is a bug of the wui.
Please if you find the time, review the chat log here. I would really like your opinion. I will keep it up for few days then I will delete it
Hi all,
TCP has been indeed accidentially integrated into the WUI since sysklogd does not handle TCP nor encryption.
There has been made some development towards a full implementation of Rsyslogd on IPFire after the “New Feature” in the WUI 
has been integrated → git.ipfire.org Git - people/ummeegge/ipfire-2.x.git/commit but this has never been merged but may also not that far away from a development finish if someone is interested ?!
I use since then Rsyslogd but as a kind of Addon →
# root @ ipfire-prime in ~ [15:43:18]
$ rsyslogd -v
rsyslogd 8.2208.0 (aka 2022.08) compiled with:
PLATFORM: x86_64-pc-linux-gnu
PLATFORM (lsb_release -d):
FEATURE_REGEXP: Yes
GSSAPI Kerberos 5 support: Yes
FEATURE_DEBUG (debug build, slow code): No
32bit Atomic operations supported: Yes
64bit Atomic operations supported: Yes
memory allocator: system default
Runtime Instrumentation (slow code): No
uuid support: Yes
systemd support: No
Config file: /etc/rsyslog.conf
PID file: /var/run/rsyslogd.pid
Number of Bits in RainerScript integers: 64
See https://www.rsyslog.com for more information.
which works good.
Best,
Erik
I have had a look through that chat log. My understanding of that is that TCP would not be able to be used as a protocol for the remote syslog.
IPFire is using sysklogd (note the k in the name) but it could also be that sysklogd also cannot use TCP.
I found a post in IPFire
https://community.ipfire.org/t/shipping-logs-to-logstash/4160/6
That says that sysklogd cannot support TCP or TLS so that would also be in line with what your chat output provided.
In that same IPFire forum thread there are more posts starting with
https://community.ipfire.org/t/shipping-logs-to-logstash/4160/28
that indicate that an alternative, rsyslog, was being looked at back in 2018 and there is the suggestion that the TCP protocol option in the remote logging was something added as a future option. Unfortunately that rsyslog (only TCP and not configured for TLS) work never got completed into a final patch set submission and no other volunteer has stepped forward to pick the work up.
I suspect that if a bug is raised on that protocol then what would happen is that the TCP option would be removed as most of the core developers are focussed on IPFire3.x or fixing security/privacy or basic function issues with IPFire2.x.
EDIT:
@ummeegge replied while I was typing my response out so his reply already covers most of what I have said.