UDM SE/Nginx: Do I have a security issue?

I replaced my pfSense CE/HA-Proxy setup with a UDM SE and a PI5 running Nginx.

I have a couple of services exposed on port 443, which is forward to Nginx on the PI5. The PI5 sits on the UDM’s Default network.

I have enabled Intrusion Prevention (Block and Notify) on Default network of the UDM SE and I not see a number of warnings notifications in the Security Detections section of the UDM SE’s System Log. It’s stuff from different countries/external IPs with signatures like “ET DROP Dshield block…”, “ET CINS Active Threat…” etc.

It appears that UDM SE’s WAN connections are bing probed on port 443 and that the UDM SE’s Intrusion Prevention is working. However, it still makes me wonder if I have configured things correctly and whether I am now less secure than I was with pfSense CE and its Internal HA-Proxy?

How secure is Ngnix and is there anything I should do to harden Ngnix?

Should Nginx sit on a different subnet?

Do I need to also forward port 80 to Nginx in order for this to update my Let’s Encrypt certificate?

I know that I could just hide my stuff behind a VPN (e.g. Wireguard) but my workplace blocks everything apart from 80 and 443.

P.S. I configured Nginx in a docker container according to Toms video.

Br.

JASE-DK

There is a lot to unpack on this. To keep this simple I will list the things I would do.

  1. Put nginx in a DMZ. So yes get it off your main network.
  2. Your IDS is not able to see the encrypted traffic so it’s not doing much good there. Not hurting anything keeping it in though.
  3. I would block all other countries inbound to you WAN. Maybe go a step further and use fail2ban or Crowdsec with bouncers on nginx
  4. On your nginx configs make sure to use high security cipher suites and only use TLS 1.2 and 1.3. Also create a dhparam cert.

I’d say that is a start. Someone might chime in with other suggestions.

1 Like

There are not any known vulnerabilities in Nginx but make sure you have a process to keep it up to date in case there are. Fail2Ban is good but there are also more advanced tools such as https://www.crowdsec.net/ that can help block known malicious actors.

2 Likes

@xMAXIMUSx has provided useful advice already.

I just want to say that it it perfectly normal that you see a NIDS reporting hits from these CTI feeds if you eneble the NIDS for the traffic incoming from the Internet.

While Crowdsec, fail2ban, and GeoIP filtering have been mentioned you could also use the same feeds the NIDS is using (or more of them) to block dubious incoming traffic. Any of these countermeasures are useful, none will protect you against a zero day vulnerability in the software exposed to the internet. Hence you put that machine on a DMZ network.

Whatever you do, you can turn off the NIDS alerts for the incoming N-S traffic, they are of zero help. However, you want to enable NIDS alerts for outgoing N-S traffic and for internal E-W traffic and tune them to your normal traffic mix. That lets you see when something new (and possibly malicious) has been intruduced to you network.

Color me crazy, but I don’t open ports. I would rather use a Cloudflare tunnel

Yes, a Cloudflare tunnel is the way to go. I deleted my port forward and created a Cloudflare tunnel.

Thanks all for the advise.

I did mine with an slightly different approach using HAProxy in pfsense. I am using wildcard domain for DNS and Let’s Encrypt SSL certs, i.e. *.yourdomain.com. Then I’ve setup a special URL such as nextcloud-jde23.yourdomain.com with exact host matching in HAProxy so it will only allow access with that exact URL. Rest gets dumped to my NoAccess backend that will hold the connection for a few mins and then drop them without sending a response. I’ve put this on my NoAccess backend:

Put this under custom action:
http-request silent-drop

This works pretty well and only thing I see in the HAProxy logs would be exploit / ping attempts. Since this NoAccess backend is not running anything other than dropping the connection with no response they can try all they want and nothing will respond back. Eventually they give up and move on.

I also use Fail2Ban as a fallback in case they figured out the exact URL.

Cloudflare tunnel is perfectly fine. I rather keep everything behind my firewall without external connection. This also makes VPN unnecessary.