Lish console is displaying ongoing UFW logging. Why?
Hello! I'm running a Debian 10 shared instance with UFW currently blocking ports except SSH (22). When I log in through SSH (Putty) I have no issues. Great!
But, when I access via the Lish console, the command prompt is regularly (every few seconds) being written to with a partial UFW log entry. For example (snippet):
[864641.626097] [UFW BLOCK] IN=eth0 OUT= MAC=f2:3c:92:9c:bd:09:3a:e0:cc
This makes it hard to use Lish as the command line is being overwritten with this logging as I type.
Looking at the UFW log, it appears my server is getting requests to a blocked port. UFW is doing its job and rejecting these requests. But why is the UFW log getting written to the Lish command line, and how do I fix this? (I.e. How do I adjust things so the Lish command line is clean?)
Thanks!
4 Replies
Just an update: It seems that this has to do with syslog settings and what messages get written to the console. These can be suppressed by changing the default syslog log level: 'sudo dmesg -n 1' or by changing the IPTables logging level.
That said, when I cat the current syslog settings (prior to updating with dmesg) I get (cat /proc/sys/kernel/printk): 7 4 1 7
I get the same defaults when I SSH in through putty (with the same user), but I don't get the console messages there. If I update in Lish: sudo dmesg -n 1 , the messages do stop, but:
Why am I only seeing the messages to begin with in Lish and not via Putty even when the syslog settings are initially the same?
Also (vaguely related), should I be concerned that I am getting repeated requests on the closed port? I.e. Should I be doing anything more than letting UFW/IPtables block the requests?
P.S. Some links on the above syslog info:
https://superuser.com/questions/180441/iptables-log-actio-writes-to-stdout/180463#180463
http://blmrgnn.blogspot.com/2016/01/dmesg-printk-log-level.html
Thanks!
jtoscani
Linode Staff
There's an easy solution to this, and then there's a much more involved way of going about it.
The quick fix - you could simply run the following to disable printing messages to the console:
dmesg -D
If you wanted to reenable them, you have that option:
dmesg -E
The other fix - edit your /etc/sysctl.cfg to cease console messages after the next reboot. One of my colleagues provides some thorough instruction on how to do this in another Community post, linked here.
jtoscani
Linode Staff
Why am I only seeing the messages to begin with in Lish and not via Putty even when the syslog settings are initially the same?
You're not looking at the console when you're accessing your server via SSH through Putty; contrarily, LISH displays console messages.
Also (vaguely related), should I be concerned that I am getting repeated requests on the closed port? I.e. Should I be doing anything more than letting UFW/IPtables block the requests?
You could use a service like Cloudflare to mask your IP and place a buffer between your server and your web traffic. This would also help reduce the load on your server, as it will have less work to do if it's not constantly dealing with this unwanted traffic.
In addition, we highly recommend that all users take measures to secure their servers - especially by hardening SSH access and using a service like Fail2ban.
@cl-bos --
You write:
Also (vaguely related), should I be concerned that I am getting repeated requests on the closed port? I.e. Should I be doing anything more than letting UFW/IPtables block the requests?
A firewall doesn't stop a request to a closed port. It only allows you to control the OS's response to that request. The typical responses are:
- accept the request & process it normally;
- reject the request and do nothing (chuck the request packets into the bit bucket…leading to receipt of a timeout error by the sender); or
- reject the request and return an immediate error.
The firewall will generate a log message no matter which one of these you choose (I believe it takes special action to generate a log on the normal case). These are the messages you're seeing…
There are merits to both reject options. I generally choose do nothing for rejections as the return an immediate error option confirms the existence of a active IP address.
-- sw