Hi,
My router when setting up port forwarding 443 to 8123, asked if it was to handle just TCP or both TCP and UDP. I set it for both, presume the server needs UDP also ??
Thanks
Hi,
My router when setting up port forwarding 443 to 8123, asked if it was to handle just TCP or both TCP and UDP. I set it for both, presume the server needs UDP also ??
Thanks
And unless you have setup proper reverse proxy with SSL dont do that unless you like to be owned?
Also I donât think the front end uses UDP itâs all http or https traffic
Thanks for your comment âŚ
I was following this Youtube:
âHome Assistant Remote Access using DuckDNS and LetsEncryptâ:
⌠it suggests the configuration 443 > 8123 (looks like we have the same router interface).
I thought https would be coming in on 443, or is the above wrong, and it can simply be 8123 > 8123.
I note your comment, TCP only.
Looks like I need to learn how to setup reverse proxy with SSL, I see NGINX mentioned, will this do what I need ?
I see this guide:
Better donât do it as you can easily give access to the whole net to your home.
Start with nabu casa cloud and learn something about it if you are so passionate to use your own solution for remote access.
Eh. DuckDNS includes LetsEncrypt SSL certs. The ports do get scanned and intrusion attempts do occur but HA is good at rejecting them.
Using MFA and IPBan I had no concerns when I was using DuckDNS.
This is just FUD.
Set up properly DuckDNS is fine.
And yes, both UDP and TCP.
You only Need the reverse proxy if you want local http access.
It is not. I did set up remote access using cloudflare tunnel a few years ago and shut it down after 24 hours. Doesnât need any port forwarding on router.
OP in my opinion is just someone who is getting familiar with those things and I wouldnât recommend to no one to set up itâs own remote access unless he really know what is he doing.
This has nothing to do with your attempts to use Cloudflare.
Thousands of people happily use DuckDNS + LetsEncrypt quite safely. Sure you get the occasional warning message that someone was knocking at the door but HA did not let them in.
The tutorial they are following is fine and they seem to have a grasp on what is required. So again, please stop with the FUD.
You only need TCP for HA (and indeed for most web services - only with the arrival of QUIC and HTTP/3 has UDP been supported).
I was more worried about someone redirecting 443 in the clear. That was more important than clarification of how first. There wasnât any info on how. Was going to ask the plan later.
FUD LOL, not heard that phrase before, but yes - it can dent ones confidence, its got me questioning some things now.
I need to do some more studying.
Do I need to get my head around reverse proxies, which sure I can do âŚ
I have read this:
It suggests 443 > 8123 and using NGINX and to make some changes to the configuration.yaml
⌠I think this chaps setup is all about being able to put the proxy up front to deal with secure traffic, whilst also letting unsecure traffic within the LAN connect unencrypted to HAOS, if at all possible I am interested in it all being secure though (ie from inside and outside),
Is forwarding 443 > 8123, secure from the router to HAOS server (ie within my NW), without a reverse proxy.
I need to understand more about forwarding, ie, why do we port forward 443 > 8123, why not forward 8123 > 8123, is that not all going inside a secure https connection, or does https/443 invoke the SSL certificate requirement, in combination with domain DNS enquiries (which I have yet to look into), hence traffic from within the LAN using IPâs are currently insecure.
Which one, TCP only or TCP and UDP, I have two different answers above.
Can one assume, that out of the boxHOAS is a reasonably locked down version of Linux (Debian ?).
Only connections I am wanting to make at this point is with a Browser, and the Android App. All my devices are Zigbee, so no WiFi requirement.
I have two factor authentication setup,
I have Nmap scanned my network from outside, and apart from 3 other ports related to other devices, (I think all at the router), only 443 is detected.
I would still like to work out how to probe 443 a bit closer with nmap, or other pen testing tools.
The server has been running for a couple of weeks now, all seems fine, only had one uninvited visitor from China who knocked on the door once, I presume the logs will keep a note of all these attempts.
I didnât wrote that to dent you confidence. If you are confident to do it, well do it.
But if your are not then common sense will be not to do it.
As others people opinion goes, well everyone have opinion.
Iâll add my 2 centsâŚ
Regarding port 443, there is one scenario Iâll share and is probably a very narrow application, but⌠There is a way to setup Alexa whereby you can see your HA cameras on an Alexa device that has a display, but it requires that HA be accessible from the external world via 443.
Forwarding a port itself is neither secure nor insecure, itâs what you forward it to and how that is configured that determines that.
Forward it to a service running TLS/SSL*, with MFA, thatâs (probably) secure. No SSL and use admin
/password
as your login, thatâs horribly insecure. If the underlying app has a long list of exploitable vulnerabilities (HA doesnât, as far as Iâm aware) then neither option there is âsecureâ because the app isnât.
It makes no difference at all, ports are just numbers, like door numbers, they donât bring security (or a lack of).
No
You can (for this anyway) use any port you want, theyâre just numbers. Now, using a default or common port does make it more likely that port scanners will find you. Like having a front door makes it easier for door-to-door sales people to find your door. Having the door around the side doesnât stop most of them from finding it though, just like not using a default/common port wonât find most scanners from finding you. Moving the door/changing the port doesnât have any impact on security - at most it may change the amount of noise in your log.
Look up what protocol HTTP uses and youâll see it uses TCP - until the arrival of QUIC and HTTP/3 anyway. For the purposes of HA it doesnât (yet?) support QUIC or HTTP/3, so TCP is all you need.
Itâs a minimal BuildRoot based OS, so yes.
Then youâve got less to worry about, at least as long as you use SSL.
Thanks for all that info, very helpful.
Iâve seen some more nefarious attempts to login - from china, but theyâve all been waved away by HAOS.
I need to find out more about how duckdns addon and letsencrypt certificates work together, along with the whole authentication/challenge and validation process.
The important part of the secure certificate, the Private Key, I dont remember being given an option to back up the key separately - unless i missed something, is this held on the HAOS server somewhere and gets backed up with the general backup function ? Excuse the lame question.
Mostly they donât.
yourhost.example.com
to your current WAN IP. It does nothing else.yourhost.example.com
after you prove you have control of that domainYes, have you read the DuckDNS add-onâs docs? You can find those files in /ssl/
.
Those are separate from SSL etc and can be found here.