Ufw log fills up with [BLOCK] messages from node-red http gets

brandock · 29 May 2020 16:12

I have node-red running on a Raspberry Pi, and on another Raspberry Pi I run emonCMS, ufw, and my apache2 reverse proxy server.

Some of my nod-red flows request the feed data from emonCMS. Like this one:

[{"id":"a7ce24a2.0a2908","type":"http response","z":"287b3bb9.8d15b4","name":"","statusCode":"","headers":{},"x":810,"y":560,"wires":[]},{"id":"50fb6fe2.f9488","type":"http request","z":"287b3bb9.8d15b4","name":"Get Solar","method":"GET","ret":"obj","paytoqs":false,"url":"http://192.168.1.40/emoncms/feed/value.json?id=88085&apikey=xxxxxxxxxxxxxxx","tls":"","persist":false,"proxy":"","authType":"","x":320,"y":560,"wires":[["482a840e.3db4fc"]]},{"id":"f7063400.6f0358","type":"http in","z":"287b3bb9.8d15b4","name":"","url":"/solar","method":"get","upload":false,"swaggerDoc":"","x":140,"y":560,"wires":[["50fb6fe2.f9488"]]},{"id":"403ae3d0.4f9cec","type":"inject","z":"287b3bb9.8d15b4","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":140,"y":620,"wires":[["50fb6fe2.f9488"]]},{"id":"ed2af74.cd73b08","type":"debug","z":"287b3bb9.8d15b4","name":"","active":false,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":750,"y":640,"wires":[]},{"id":"482a840e.3db4fc","type":"function","z":"287b3bb9.8d15b4","name":"","func":"value = Number(msg.payload);\nif (value < 30) value=0;\nvar solar = \n {\n \"title\": \"Solar\",\n \"value\":value,\n \"subtitle\":\"\"\n }\n\n\nmsg.payload = [solar]\nreturn msg;","outputs":1,"noerr":0,"x":530,"y":560,"wires":[["7ef8d070.82b7f"]]},{"id":"7ef8d070.82b7f","type":"json","z":"287b3bb9.8d15b4","name":"","property":"payload","action":"","pretty":false,"x":670,"y":560,"wires":[["ed2af74.cd73b08","a7ce24a2.0a2908"]]}]

When these requests go over to the emonCMS server, the ufw.log fills up with [BLOCK] messages. Interestingly enough, the requests still go through, get responses, and the flow works. But emonCMS struggles with the log volume and /var/log quickly gets 100% full, which causes various other problems.

Here is what I've tried:

Edit /etc/rsyslog.d/20-ufw.conf and remove the comment character before the &stop
added a specific “allow” rule for traffic coming from 192.168.1.80, the IP of my node-red server

This hasn’t slowed down the logging a bit. I am suspicious that this is because the inbound hits from node-red all have different, seemingly random destination ports.

This is what I see in the log:

pi@emonpi:~$ tail -f /var/log/ufw.log
May 29 08:43:02 emonpi kernel: [39258.075608] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=54308 WINDOW=0 RES=0x00 RST URGP=0 
May 29 08:43:32 emonpi kernel: [39288.157728] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=53602 WINDOW=0 RES=0x00 RST URGP=0 
May 29 08:43:41 emonpi kernel: [39297.116653] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=54502 WINDOW=0 RES=0x00 RST URGP=0 
May 29 08:44:02 emonpi kernel: [39318.237702] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=54502 WINDOW=0 RES=0x00 RST URGP=0 
May 29 08:44:31 emonpi kernel: [39347.034810] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=53426 WINDOW=0 RES=0x00 RST URGP=0 
May 29 08:45:05 emonpi kernel: [39380.492002] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=54112 WINDOW=0 RES=0x00 RST URGP=0 
May 29 08:45:05 emonpi kernel: [39380.702926] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=54112 WINDOW=0 RES=0x00 RST URGP=0 
May 29 08:45:35 emonpi kernel: [39410.732790] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=55624 WINDOW=0 RES=0x00 RST URGP=0 
May 29 08:45:42 emonpi kernel: [39417.677312] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=55624 WINDOW=0 RES=0x00 RST URGP=0 
May 29 08:46:03 emonpi kernel: [39438.562653] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=55624 WINDOW=0 RES=0x00 RST URGP=0 
May 29 08:46:33 emonpi kernel: [39468.636009] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=55822 WINDOW=0 RES=0x00 RST URGP=0 
May 29 08:47:05 emonpi kernel: [39500.991027] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=55064 WINDOW=0 RES=0x00 RST URGP=0 
May 29 08:47:05 emonpi kernel: [39501.202692] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=55064 WINDOW=0 RES=0x00 RST URGP=0 
May 29 08:47:35 emonpi kernel: [39531.122554] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=51778 WINDOW=0 RES=0x00 RST URGP=0 
May 29 08:47:42 emonpi kernel: [39538.078087] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=51778 WINDOW=0 RES=0x00 RST URGP=0 
May 29 08:48:01 emonpi kernel: [39556.318311] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=55064 WINDOW=0 RES=0x00 RST URGP=0 
May 29 08:48:20 emonpi kernel: [39576.159361] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=55404 WINDOW=0 RES=0x00 RST URGP=0 
May 29 08:48:43 emonpi kernel: [39598.317332] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=54862 WINDOW=0 RES=0x00 RST URGP=0 
May 29 08:49:03 emonpi kernel: [39619.200628] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=56130 WINDOW=0 RES=0x00 RST URGP=0 
May 29 08:49:31 emonpi kernel: [39647.197381] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=54862 WINDOW=0 RES=0x00 RST URGP=0

TotallyInformation · 29 May 2020 16:29

I assume that you have done sudo ufw allow 1880?

Unless you want to allow access from the Internet, you should really of course use

sudo ufw allow from 192.168.1.0/24 to any port 1880

brandock · 29 May 2020 16:47

This might be my lack of understanding of ufw, but wouldn't "udo ufw allow from 192.168.1.0/24 to any port 1880" open port 1880 as a destination port for inbound traffic? If you look at the [BLOCK] messages I'm getting, 1880 is the source port. The ports I would need to have open in ufw appear to be a myriad of somewhat random-looking ports like 55064, 56130, etc.

So what I've tried is "sudo ufw allow from 192.168.1.80" in the hope that this would ignore the port and just allow the traffic from this trusted server on my network. But it didn't work that way.

The source port of 1880 makes sense to me, because node-red is sending the http requests, but the destination ports I don't understand, and that is what brought me here.

TotallyInformation · 29 May 2020 17:04

I'm a little rusty on UFW myself.

I thought that is what you were trying to do? If not, my bad.

Normally, the default would be block everything in, let everything out. So you build out from there, allowing access inbound to specific services from as specific a location as possible.

Lets take a step back. Which IP address is which and in what direction are you actually trying to make a request?

.40 is emonpi (so running emon) and .80 is running Node-RED? And UFW is running on which device - .40?

If so, the request should be coming from the .80 and .40 should simply be responding which, unless you've made other changes to UFW, it would be able to do anyway.

The output shows that the request is coming from .80 and arriving at .40 on eth0 as expected.

I got the ports wrong though because, as you say, the request comes from port 1880 but arrives at a dynamic set of ports. So you are correct that you should open port range 50000-60000 or just allow any request from .80

By the looks of it, UFW is blocking repeated requests on different ports until it finds one that it likes - that's why you do get the data, but it is taking longer than expected (though probably still too fast to notice) because it is having to try multiple ports.

Is there a way to fix the port on emon?

brandock · 29 May 2020 18:06

Correct. .40 is emonpi running emonCMS, .80 is Node-RED. And yes, UFW is on .40.

I have full control of the ports on the emonPi, in the sense that it is my personal Raspberry Pi, but maybe I just haven't made the right changes. Here is the current state of ufw, with all the various things I've been trying. Any suggestions?

To                         Action      From
--                         ------      ----
80/tcp                     ALLOW IN    Anywhere                  
443/tcp                    ALLOW IN    Anywhere                  
22/tcp                     ALLOW IN    Anywhere                  
1883/tcp                   ALLOW IN    Anywhere                  
1880/tcp                   ALLOW IN    Anywhere                  
Anywhere                   ALLOW IN    192.168.1.80              
1880                       ALLOW IN    192.168.1.0/24            
80/tcp (v6)                ALLOW IN    Anywhere (v6)             
443/tcp (v6)               ALLOW IN    Anywhere (v6)             
22/tcp (v6)                ALLOW IN    Anywhere (v6)             
1883/tcp (v6)              ALLOW IN    Anywhere (v6)             
1880/tcp (v6)              ALLOW IN    Anywhere (v6)

TotallyInformation · 29 May 2020 19:51

Are there any blocks at all?

Somewhat as an aside, personally I would restrict IPv6 alltogether unless you really need it. I would also remove the 1880, 1883 (MQTT) and 22 (SSH) entries. If you really want to allow remote SSH from the Internet, you should move it to a different port >1024, that stops lots of automated attacks.

brandock · 30 May 2020 16:10

It is pretty wide open right now, as I try to get the logging to be less verbose and figure out why the [BLOCK] is happening. In reality, my .40 machine sits behind my router, which only forwards ports 80 and 443, and sometimes I open a different port > 1024 to forward to 22 if I need it. I am not an expert, but it makes me wonder if ufw is really needed on .40 because of this. Thoughts on that?

TotallyInformation · 30 May 2020 16:42

Well, it does give an extra layer of security but as long as you trust your router's configuration and firewall and you are only exposing 443 and a non-standard port for SSH there is probably little risk. I would turn off port 80 though if you can.

As you may have seen me say elsewhere, you can further strengthen your on-site security by only allowing incoming TLS secured connections from Cloudflare, using Cloudflare as an external proxy. This is much stronger because anyone (more likely anything) probing your router external IP address will get nothing back even on your open port.

What version of Rasbian are you using by the way? I think that Buster has replaced IPTABLES with something else hasn't it? Certainly Debian Buster has replaced IPTABLES with nftables. NFTABLES is supposed to be a lot easier to work with and you probably don't really need UFW to help.

https://wiki.debian.org/nftables

https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables

Paul-Reed · 30 May 2020 18:10

That's how my system is configured. I have a script which auto updates UFW with the IP addresses used by Cloudflare, if OP is interested - GitHub - Paul-Reed/cloudflare-ufw: Script to update UFW with Cloudflare IPs

brandock · 31 May 2020 13:58

Thanks, Paul and TotallyInormation! I'm interested in going the Cloudflare route. I have some questions about what this would look like:

Where would my fleet of Raspberry Pis site in my home network if I were to use Cloudflare as my reverse proxy? Right now they are all behind my Apple router's firewall, with ports 443 and (for now at least) 80 forwarding to .40, which is my reverse proxy, as described above. Would I now put them all outside my router's firewall, and use ufw to block all traffic not inbound from the Cloudflare reverse proxy? It seems like if I added Cloudflare to my current configuration my traffic would be going through two reverse proxies, mine and Cloudflare's.

TotallyInformation · 1 June 2020 22:41

You can keep everything pretty much the same. The first step is to ensure that you have a public domain name that you can use at least part of and to reassign the DNS servers to Cloudflare.

Then you create a sub-domain (which could be www. if you want) and make the IP address point to the IP address for your home WAN, the one assigned by the ISP. Then configure whatever security you want in Cloudflare including using their own generic cert instead of your own.

Once you've made sure that works, then you can change your home router to ban access to ports 80/443 except from the Cloudflare servers.

Now everyone has to come in via the Cloudflare proxy and cannot come direct to your home IP address.

Once you are sure everything is working, you can choose whether you also keep your local reverse proxy depending on what you are doing. You probably won't need it though.

Better to control that at the edge firewall, that way you know for sure that nothing can get into your network.

That is correct while that adds some overhead, it lets you use your local proxy to terminate the TLS between Cloudflare and your network, something that you really want. In addition, you can choose whether you want to use Cloudflare or your local proxy to provide any logins. The free Cloudflare logins are limited to, I think, 5 user id's.

[Internet cloud] -> Cloudflare Proxy (+ DNS, Cert) -> Home Router/Firewall -> *Pi's

Here is some of the stuff that you get from Cloudflare for free - this mainly from my blog:

system · 31 July 2020 22:41

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
[ANNOUNCE] node-red-contrib-http-logger: version 3.0.0 beta Share Your Nodes	0	286	17 November 2022
Http request keeps requesting, kills Node-RED server General	5	759	16 May 2020
Node-red http request and led connection General node-red-dashboard	9	376	9 January 2023
Node red is not giving http response General	3	801	5 November 2019
Econnrefused 109.169.55.159:80 General	5	231	11 July 2022

Ufw log fills up with [BLOCK] messages from node-red http gets

Related Topics