tri125
By:
tri125

UFW spamming block messages

March 30, 2017 459 views
Applications Firewall Debian

Hello, I've been noticing that systemd-journal has been slowly but steadily eating up RAM (14.55% 2 days ago, 17.27% yesterday, and 18.23% today). When I looked in the logs, I found many breaks in attempts but also a constant stream of these messages:

kernel: [UFW BLOCK] IN=eth0 OUT= MAC=04:01:3b:5c:8a:01:4c:96:14:a4:ab:f0:08:00 SRC=104.236.189.176 DST=162.243.241.41 LEN=40 TOS=0x00 PREC=0x00 TTL=244 ID=54321 PROTO=TCP SPT=58773 DPT=6379 WINDOW=65535 RES=0x00 SYN URGP=0

kernel: [UFW BLOCK] IN=eth0 OUT= MAC=04:01:3b:5c:8a:01:4c:96:14:a4:af:f0:08:00 SRC=171.224.207.81 DST=162.243.241.41 LEN=44 TOS=0x00 PREC=0x00 TTL=51 ID=13232 PROTO=TCP SPT=45620 DPT=23 WINDOW=40732 RES=0x00 SYN URGP=0

kernel: [UFW BLOCK] IN=eth0 OUT= MAC=04:01:3b:5c:8a:01:4c:96:14:a4:ab:f0:08:00 SRC=107.6.116.106 DST=162.243.241.41 LEN=40 TOS=0x00 PREC=0x00 TTL=243 ID=5786 PROTO=TCP SPT=55207 DPT=3389 WINDOW=1024 RES=0x00 SYN URGP=0

kernel: [UFW BLOCK] IN=eth0 OUT= MAC=04:01:3b:5c:8a:01:4c:96:14:a4:ab:f0:08:00 SRC=111.132.227.100 DST=162.243.241.41 LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=13331 DF PROTO=TCP SPT=32958 DPT=23 WINDOW=5840 RES=0x00 SYN URGP=0

kernel: [UFW BLOCK] IN=eth0 OUT= MAC=04:01:3b:5c:8a:01:4c:96:14:a4:ab:f0:08:00 SRC=111.132.227.100 DST=162.243.241.41 LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=13332 DF PROTO=TCP SPT=32958 DPT=23 WINDOW=5840 RES=0x00 SYN

When I'm using the control panel from digitalocean, I actually see all of these messages being printed out right off the terminal, that doesn't seems normal.

I'm not sure what these are and what to do of them.

My ufw is configured to allow http, ssh, https. Logging set to low, default to deny incoming traffic and to allow outgoing traffic.

2 Answers

@tri125

That's the reason we use firewalls :-). If it's showing block messages, that's normal. That means that a connection attempt was blocked.

SRC = The IP that attempted to connect.

DST = The IP of your server.

PROTO = The protocol used by the attempted connection.

DPT = The destination port, or port they were trying to connect to.

A firewall, like most software, is going to use resources. It's a trade off, though you're going to use far fewer resources than you would if you were allowing the connection attempts to be made without a firewall installed.

With a firewall installed and blocking, as you have it setup, those attempting to connect are blocked before they can even attempt to authenticate.

When connected to Console from the DigitalOcean control panel, seeing those messages is also normal. If you use Terminal (MacOS) or PuTTy (Windows) and connect over SSH, you won't see them as you do in the Console as Console handles things a little different.

As long as you are seeing the blocks, you shouldn't have anything to worry about. Your IP is public, attempts to login are going to occur. Add to that the fact that someone else may have had the same IP you have before you had it, and it could be a matter of mistaken attempted access (i.e. someone didn't update their configuration).

Firewalls will use up resources though, but that comes with having a publicly accessible server.

  • Thank you for the explanation. However, the firewall isn't consuming the ram, systemd-journal does.

    I'm more worried about the ram consumption being out of control than someone trying to login without my keys ;)

    systemd-journal is the process with the highest ram consumption on the droplets, it's skyrocketing. I can't imagine what will happen when the server actually have some load.

    Do you know how I can mitigate this beside turning off loging?

    • @tri125

      The amount of RAM occupied is generally pretty consistent with the number of processes being managed. With a 4% shift coming to out to ~20MB on a 512MB, and a multiple of that as you scale up in RAM size (1GB, 2GB, etc), I'm not sure I'd consider that to be abnormal, though it is very well possible that it's a memory leak.

      That being said, there's a difference between memory used and memory mapped. To get the actual usage, get the pid of the process and run:

      sudo pmap -d pid
      

      Where pid is the process ID of systemd-journald. You'll see a huge listing, and at the very bottom, something that looks like this:

      mapped: 32288K    writeable/private: 576K    shared: 5068K
      

      In my case, ~32MB is mapped, but that doesn't mean that's how much systemd-journald is actually using right now -- it's more so what it could use right now. That same number could be pulled from top looking at the VIRT column.

      What you really need to look at is the RES column. In my case, this is a new Droplet, so the usage isn't much different than it would be for any new Droplet without anything on it, but the RES column shows just 3.5MB.

      You can disable logging if you prefer to do so, though in such a case, I don't see much to worry about unless it's physically using a good chunk of RAM. I have seen cases where users report 2-4GB of RAM usage, in such a case, I'd say it is a memory leak and you'd need to use strace and report it.

      • @tri125

        A a general note, if you're not using snapd, you can disable that to free up a little bit of RAM. It has nothing to do with systemd as it relates to your case, though it is a service that automatically runs on Ubuntu, consumes RAM, and really doesn't help in on most servers unless you physically install something using it.

        systemctl stop snapd
        
        systemctl disable snapd
        

        I mention this mainly because of RAM savings.

Have another answer? Share your knowledge.