Jump to content

Security 101: Secure Connections


regid

Recommended Posts

Thanks for the response!

 

I'll take a look at Sophos Home, as well as Webroot. Any reason why this is recommended?

 

Why is connect better? Does it obscure the public IP address somehow? Or is it simply because the user won't know the domain name?

 

I'm familiar with Unifi hardware, but I'm still confused how Unifi hardware runs "behind" pfSense. @@Tur0k mentioned he has this config as well. How do you load a Unifi router with pfSense?

I run a unifi usg at my wan edge. Behind this I have sophos utm (or pfsense in your case). Mainly only doing packet inspection and some geo IP blocking and black listing.

 

Wan traffic coming in first goes through cloud flare protecting my IP and giving some ddos protection and image hosting.

 

 

 

 

Sent from my ELE-L29 using Tapatalk

Link to comment
Share on other sites

fizzyade

It depends what verification method you use. You cant really automate DNS verification with let's encrypt.

 

Sent from my ELE-L29 using Tapatalk

Huh?  

 

I have loads of devices that automatically update their LetsEncrypt certificates without any interaction, it's a doddle, just host your DNS with a acme.sh supported provider use DNS verification, I use this very same configuration to automate the renewal of certificates on applications that don't have support for LetsEncrypt built it.

Link to comment
Share on other sites

fizzyade

Thanks for the response!

 

I'll take a look at Sophos Home, as well as Webroot. Any reason why this is recommended? 

 

Why is connect better? Does it obscure the public IP address somehow? Or is it simply because the user won't know the domain name?

 

I'm familiar with Unifi hardware, but I'm still confused how Unifi hardware runs "behind" pfSense. @@Tur0k mentioned he has this config as well. How do you load a Unifi router with pfSense?

 

You don't, you run the USG Gateway software on it, it's pretty underwhelming in terms of functionality and power. I've got an unused USG 4 Pro sitting in my rack.  The interesting stuff like IPS/IDS can't be run on it properly if you have a fast internet connection as it maxes out on the 4 at 300 (give or take a bit, maybe 400) with that feature enabled.  It's a fairly basic product which is missing a lot of functionality from the GUI that can be configured via a json file, so once you start getting limited with the GUI be prepared to delve into the world of json!  The integration into the Controller is nice though, it's due a hardware refresh (they have the UDM now which seems to overlap other products), if it could push 1G through IPS/IDS and was priced reasonably then it'd probably be a good choice for a lot of folks.

 

I switched to using a NUC running Untangle, the moment I installed Untangle to test it I was so impressed.  It's like $50 a year for a personal license of it and well worth it.

 

I have a mixture of UniFi and Mikrotik switches (All UniFi AP's), the mikrotiks are used for the 10G network.

Link to comment
Share on other sites

Guest asrequested

I have a pfsense router and a USG Pro 4. I use both. USG behind the pfsense. The USG doesn't NAT. On pfsense I run Snort and Torguard (openVPN) interfaces. The USGs IPS is good, but it has a weak processor and can't handle the load above 250Mb/s. Running Snort on pfsense replaces the use of the USG IPS.

Link to comment
Share on other sites

fizzyade

I have a pfsense router and a USG Pro 4. I use both. USG behind the pfsense. The USG doesn't NAT. On pfsense I run Snort and Torguard (openVPN) interfaces. The USGs IPS is good, but it has a weak processor and can't handle the load above 250Mb/s. Running Snort on pfsense replaces the use of the USG IPS.

 

Yeah, didn't fancy the short lived USG XG?  :lol:

Link to comment
Share on other sites

shocker

Quick question

 

I have a reverse proxy successfully configured with subdomain.domain.tld port 443 and on Emby network I have:

 

External domain: subdomain.domain.tld

WAN and LAN ports, default

Secure connection mode: Handled by remote proxy

No additional certificates added on network part, only on nginx.

 

Now when I'm connecting with Emby Connect in my profile I have the server ip address not the reverse proxy domain, and the traffic from the app is not going via reverse proxy.

 

Any idea why?

Link to comment
Share on other sites

darkassassin07

It depends what verification method you use. You cant really automate DNS verification with let's encrypt.

 

Sent from my ELE-L29 using Tapatalk

This depends very much on what features your dns provider has.

I use a free cloudflare account infront of my server which allows me to update dns records via cloudflares api. I then have a script that runs these two commands every two months refreshing my cert with acme.sh + letsencrypt:

/home/pi/.acme.sh/acme.sh --issue -d mydomain.com -d *.mydomain.com --force --dns dns_cf >> /home/pi/logs/cert.log
/home/pi/.acme.sh/acme.sh  --install-cert -d mydomain.com --key-file /home/pi/SSL/key.key --fullchain-file /home/pi/SSL/cert.pem --reloadcmd "sudo nginx -s reload" >> /home/pi/logs/cert.log
Edited by darkassassin07
Link to comment
Share on other sites

fizzyade

Quick question

 

I have a reverse proxy successfully configured with subdomain.domain.tld port 443 and on Emby network I have:

 

External domain: subdomain.domain.tld

WAN and LAN ports, default

Secure connection mode: Handled by remote proxy

No additional certificates added on network part, only on nginx.

 

Now when I'm connecting with Emby Connect in my profile I have the server ip address not the reverse proxy domain, and the traffic from the app is not going via reverse proxy.

 

Any idea why?

In advanced settings in the server make sure that the external domain is set to your TLD.

 

You need to set the connection address to the top level domain, you will then either need to enable hairpin NAT on your router so you can connect to the external IP from inside the network, if you can’t do that then you’ll need to set up split dns, either by adding records for your TLD on your router or by running a DNS server inside your network which resolves hosts inside the network to their local IP and forwards all other requests onto a different DNS server.

 

 

 

Have you got a port forward on 8192 going to 8192 on the server? If so, change it to forward port 8192 to 443 on your reverse proxy.

Link to comment
Share on other sites

shocker

In advanced settings in the server make sure that the external domain is set to your TLD.

 

You need to set the connection address to the top level domain, you will then either need to enable hairpin NAT on your router so you can connect to the external IP from inside the network, if you can’t do that then you’ll need to set up split dns, either by adding records for your TLD on your router or by running a DNS server inside your network which resolves hosts inside the network to their local IP and forwards all other requests onto a different DNS server.

 

 

 

Have you got a port forward on 8192 going to 8192 on the server? If so, change it to forward port 8192 to 443 on your reverse proxy.

 

I think you misunderstood the issue.

I don't have any connectivity issue and my ip's are public ip's there is no nat, no port forwarding.

My question is why when the pairing is done via emby connect the traffic is not sent via the reverse proxy and it's sent directly via ip:port of the Emby server.

Link to comment
Share on other sites

darkassassin07

WAN and LAN ports, default

So both the local and public ports for http are 8096, and https 8920?

 

'Public https port number' should be set to 443, while the local https port should stay as 8920.

 

The dashboard of your server should say:

In-home (lan) access:

Http://<embyserverip>:8096

Remote (WAN) access:

Https://subdomain.domain.tld:443

 

If the In-Home address is accessible externally, emby connect may try to connect to that before attempting the external address.

If that's the case you could try setting up your firewall on the emby server to only allow the nginx server to connect to it and no other devices.

Link to comment
Share on other sites

shocker

So both the local and public ports for http are 8096, and https 8920?

 

'Public https port number' should be set to 443, while the local https port should stay as 8920.

 

The dashboard of your server should say:

In-home (lan) access:

Http://<embyserverip>:8096

Remote (WAN) access:

Https://subdomain.domain.tld:443

 

If the In-Home address is accessible externally, emby connect may try to connect to that before attempting the external address.

If that's the case you could try setting up your firewall on the emby server to only allow the nginx server to connect to it and no other devices.

Sorry, yes the https is exactly as you described and http is ip:8096

 

The in-home is accessed externally, I think that might be the case.

I can block the port on my network firewall, in this case if I block 8096 Emby will fallback to the wan?

Link to comment
Share on other sites

darkassassin07

I believe so yes. Assuming your domain name is accessible both at home and externally, you shouldn't have any issues preventing everything but nginx from connecting to emby on 8096

 

/edit by that I mean, the remote address in the dashboard is accessible from home/away

Edited by darkassassin07
Link to comment
Share on other sites

shocker

I believe so yes. Assuming your domain name is accessible both at home and externally, you shouldn't have any issues preventing everything but nginx from connecting to emby on 8096

 

/edit by that I mean, the remote address in the dashboard is accessible from home/away

Yes the domain is fully accessible remotely.

Thank you for those information’s I’ll give it a try and come back with a feedback!

Link to comment
Share on other sites

fizzyade

This depends very much on what features your dns provider has.

I use a free cloudflare account infront of my server which allows me to update dns records via cloudflares api. I then have a script that runs these two commands every two months refreshing my cert with acme.sh + letsencrypt:

/home/pi/.acme.sh/acme.sh --issue -d mydomain.com -d *.mydomain.com --force --dns dns_cf >> /home/pi/logs/cert.log
/home/pi/.acme.sh/acme.sh  --install-cert -d mydomain.com --key-file /home/pi/SSL/key.key --fullchain-file /home/pi/SSL/cert.pem --reloadcmd "sudo nginx -s reload" >> /home/pi/logs/cert.log

 

 

slightly curious why you only run the script every 2 months, acme.sh will only request a new cert if it’s within the window for renewal on LetsEncrypt, otherwise it will just ignore the update request.

 

I have a cronjob which runs my cert script every 24 hours and also has an entry for startup, covers all bases should the machine be down when the job was due to run.

 

I guess whatever works for you is the perfect solution!

 

I'm currently trying to get acme-dns working with caddy, I have a VPS spun up to act as the name server for the records, but haven't managed to get a domain to validate yet. 

Link to comment
Share on other sites

darkassassin07

I didn't know acme.sh would exit if a renewal isn't necessary. I just figured if the cert is valid for 3 months, renewing every 2 months is a good balance between regular renewals and not spamming LEs servers for no good reason.

  • Like 1
Link to comment
Share on other sites

fizzyade

I didn't know acme.sh would exit if a renewal isn't necessary. I just figured if the cert is valid for 3 months, renewing every 2 months is a good balance between regular renewals and not spamming LEs servers for no good reason.

They’ve thought of that! iIt won’t connect to the LetsEncrypt servers if the renewal isn’t due.

 

It’s a really cool shell script.

 

I actually have quite a few machines on the network requesting certs, a mixture of Caddy servers and other servers where acme.sh is easy to deploy, can really recommend caddy and it’s well worth taking a look at, I run 2 caddy servers, one which is only internally accessible on the network and the other which is externally accessible, means I don’t need the DNS records for my internal server to be on Cloudflare.

 

I actually learned that acme.sh has some other features which I could use to simplify some of my usage cases from your post, going to investigate and see if I can clean up a few little bits here and there.

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...