[Feature request] Open HestiaCP port based on an Admin's subdomain.DynDNS IP Address for 100% security

Following concept helps HestiaCP 100% security and ZERO chance of hacking!

I have used VestaCP for many years after it was dead. That script was vulnerable. At the time when many users were reporting that their VestaCP was getting hacked, I did not look in my servers, if they were hacked. I did not need to.

For this, I have configured DynDNS. The IP of that DynDNS domain gets entered by CSF. If that fails, I have a background cron running to check if the oldIP and newIP are changed.

HestiaCP does not have tight integration of CSF. Then it requires a small script to check with cron, if the subdomain.dyndns has changed. If yes, it will add in the iptables.

The idea is very simple. Script would be very easy to develop. All users would benefit very much.

What the hell does an DynDNS protect so far I know it is nothing more than a CNAME for an ip. If I hack a server I probably want the server kept online so I can do bad things with it.

So far there 4 methods to gain access to a server:

  1. Via the website / Wordpress or any other website that is written wrong (Often caused by bad plugins/and so on)
  2. FTP / SSH Access to the server. Please use decent passwords and disable root and disable FTP if you don’t need them…
  3. Via Hestia it self. So far I know there are currently no know ways to gain access to the system…
  4. Any other system (Mysql, Dovecot and Exim) but so far there are no root escalation available for them…

Last few “Vulnerabilities” that where discovered where thing you allready needed to have admin permission to do so… Except the first one but it was only a bypass for the other “protections”


Hello Marcus,

Let me go through your misunderstanding one by one:

Nowhere in my message I have mentioned that the concept of subdomain.DynDNS will protect the entire server and all the ports. The list and methods of hacking a system, which you describe above, is then not relevant because the solution triggers only on ONE SPECIFIC PORT BOUND TO ONE SPECIFIC IP ADDRESS!

The concept of subdomain.DynDNS has nothing to do with DynDNS.com. The abbreviation simply means that it is a dynamic ip address. Because you assumed that it correlates to services offered by a company, you mention about the CNAME. CNAME has nothing to do with the idea of binding a port with an ip address.

If I configure - with my concept - each port opened by any service, for e.g. 80, 443, 993, 995, 3306, etc. and bind these services to one dynamic ip address (subdomain.DynDNS), then a possibility to hack that service becomes null, unless the kernel is hacked. For a hacker with a different ip address, the kernel declares that secured port to be closed.

In fact, I use dovecot, sshd, webmin, hestia, vsftp, etc. EXCLUSIVELY on specific ports opened to allow traffic to the router ip address (subdomain.DynDNS) that changes dynamically as well as the cluster servers. I myself can access my emails from my router ip address only. Outside, I can access using roundcube under a specific subdomain protected with .htaccess.

I rejected use of services offered by companies based under the jurisdiction of Patriot Act. I use provider within the European Union for binding services to that subdomain.DynDNS. Only necessary ports remain open for public.

Hestia has taken a lot of distance from VestaCP and has dramatically enriched security in it.

However, why should a sensitive port should remain accessible and open to by default, when this port could be bound to 123.456.123.456 (router dynamic ip address)? Due to binding ports to a specific ip address, there are advantages. Thereafter, ironing vulnerabilities besomes a small issue.

Not binding it and making it remain open to public invites hackers to theaten that port.

BTW, it strikes me: In above, I have used binding as terminology. This is - with reference to the discussion here technically wrong. What I mean is to filter traffic on that particular port with ipset/iptables.

In reality, I am binding services from within the conf of that service to my dynamic address using sed/cron. But my solution here above does not relate to that and hence the use of the term.

When iptables + fail2ban is installed by default only ports listed below should be open.

Marcus, you prove yourself that Hestia is still accessible to hackers @ port 8083 to Portscan will work, right? What will happens with DDOS? For any reason if the script fails or fail2ban service is not loaded, then trouble is preprogrammed. You also need to configure fail2ban and experience headaches too. Same is with other tools like modsecurity, etc.

My security infrastructure has:

BindingToService:8083 —> Filtering the traffic:8083 —> Resolve

For Hestia, I suggested an easier solution with DynDNS and iptables:

Filtering the traffic:8083 —> Resolve

OPEN:8083 —> 123.456.123.456 (Admin’s RouterIP with subdomain.DynDNS)
CLOSED:8083 —>

One simply need to add the DynDNS of Admin’s router into the iptables with cron and delete the old one. Thats it. It is an extremely charming solution. It adds an additional layer of security at the level of kernel on the top of iptables + fail2ban. After that you may have fail2ban on different ports like 80/443/993, etc. Hestia will not need or use it.

It has been 15 years I have not used any such tools like modsecurity or fail2ban. My servers are secured by kernel based on binding ports and filtering traffic in the simplest way. I do not care a damn on hackers or any vulnerable scripts. In fact, I used VestaCP after it was dead for years now and slept without fears.

If you are the only user it will work fine. It will not work if there are random users need access to the system

For my main servers i have enabled ipset

and General block list for a few blacklist so far.

A other option to improve security might using knock.d

Thanks Marcus for sharing and exchanging.

In my solution, ipset would be required because of dynamic update of the Admin’s IP. I must use it for dynamically updating tables.

If I understand, with ipset you could acquire some additional advantage of separating tables and efficiency. But in terms of adding a security layer, it will not help. It will not change the behaviour of ports <—> inbound traffic. it will only allow you to organize better, but not control better.

I have not enabled any of these features but I am always very interested in hardening the security and diminishing the attack surface.

A friend of mine always accesses his servers through one of them. All of his servers have only that server allowed to access via ssh and drop the rest of the connections.

I am not friends with dyndns solutions since I may want to access from my phone (tethering)

Port knocking is very interesting but as a system is a pain in the ass. You have to knock and then you have to remember to close. Under windows it is more complicated to generate a script to knock.

You can drop all connections not coming from that ipset:
-Other servers belonging to me
-My static IP
-My proxy/tunnel IP

1 Like

That is very true. You captured the limitation of this solution. I assume that Admins have modern routers that have feature DynDNS updating function. Most good routers have this. So one simply need to tie up with one of the providers to update the Admin’s IP regularly.

If an admin does not have this facility, then I am afraid one has to turn this feature off . This offers an option to choose additional security at the kernel level by filtering the traffic.

This is an area I will be working on next. I was looking into alternatives @Phone / @Server of capturing the IP of the smartphone and entering into my infrastructure. @Phone gave me a headache. A rough way would be a URL with php @Server to detect and enter the ip. I want to achieve this because one could secure roundcube, hestia, etc. with this.

If you find something I would be very glad to know about it.

Use fail2ban to whitelist your IP if you can successfully establish an IMAP connection or visit certain url or…

But this is a recipe for disaster since there are too many parts that can’t fail.

EDIT: We may also want to enable 2fa for SSH

1 Like

It is best not to open the port 8083 but to access that port through an SSH tunnel:

ssh -L 8885:localhost:8083 -N -f -l user server.name -i ~/.ssh/privatekey

Then access the panel at the address http://localhost:8885

1 Like

With above, you are opening the port 8885! With your suggestion, you mean to differentiate the method to establish a connection - not through SSL - but through a tunnel.
SSH tunnel helps to avoid MITM. So it is good. But the port remains open.

At the end, you say that that port should be bound to localhost, if that is the concept. In that case, to use the IP or another IP like 123.456.123.456 (Admin’s Router IP) is one and the same (technically). In both the cases, you ARE BINDING THE IP.

In my solution, there is no binding but filtering. In your suggestion, there is binding but no filtering. Thats difference.

I still believe that the filtering option in the panel could support Administrators, who have users (or no other users), that could get a DynDNS from their Routers. Then, they get added advantage from this security as an option.

On my server only the SSH 22 port is open, locally any port is valid.

1 Like

Aha. So you in fact did not mean to bind the IP.

Yes, then this is a feasible secure option for a single user/admin from home/office.

I, however, use a cluster. So I need to bind + filter the traffic. I mount the remote dir with ssh for faster resync, etc. For me, the tunnelling is not an option between two remote servers.

If someone is looking for a guide to make a server more secure, this guide could help:

Best regards


1 Like