Hello,
My question is already somewhat available here, but i cannot seem to reply to the thread.
Anyhow, what i want to do is to simply change the SSL-port to something other then 443, it seems that running it on 443 is getting a VERY high amount of bots, scripts and hackers trying to SQLi/bruteforce/whatnot.
If this isn't doable, do you have any recommendations as to how i can secure my environment just a bit? Would i be needed to drop all incoming traffic aimed towards the webserver apart from specified allowed hosts? This isn't really optimal.
Article Comments
Any reason this cannot be changed? Seems like a pretty simple fix which would save people quiet a lot of trouble.
And, Linux probes? Still nothing after a few years?
Jul, 2012 - Permalink
It may seem like a 'pretty simple fix', but technically it's not. So it's on the wishlist but not set for a certain version or ETA. Sorry. The same applies for Linux Probes.
Jul, 2012 - Permalink
Too bad i guess. I really really like PRTG and all that comes with it, but these small issues are stuff that really puts me off. I've read the KB and all, and there are threads dating back 4-5 years asking for Linux Probes and still the same answer, In my personal opinion that either shows that you do not listen to your customers, or that you simply do not care.
Great product, apart from these flaws.
Jul, 2012 - Permalink
We do care and we do listen to our customers and users. But sometimes, things are not a pretty simple fix, nor are there as many people asking for it as one might think, and in fact a lot of users may have asked for other features. And then there is always a decision we have to make, what to "do" with the limited human resources we have so that most users have to biggest benefit in terms of new features, improvements and the occasional fix.
Jul, 2012 - Permalink
Makes very much sense indeed, however, i still maintain the stance that you should perhaps look into linux-probes. This would make this product even better, and actually pose a pretty big blow to the other alternatives out there.
These two issues are the main ones, everything else is top-notch really. Perhaps the users asking for Linux probes might not be that many, but that could potentially be due to them running a simple search, and seeing that there are no ETA's or anything even as of now, years later. Perhaps this is where you potentially loose a few clients that for whatever reasons cannot run the Windows based alternative. These clients could potentially later end up choosing another solution due to this issue, at least with the smaller packages á 100 monitors.
Or am i completely wrong?
Jul, 2012 - Permalink
We are looking into such requests, and with Linux Probes we do that "every now and then", so we evaluate such "major" points a bit more thoroughly, please be assured. But choices have to be made, and very often those are compromises, as explained above.
Jul, 2012 - Permalink
Completely understood.
Looking forward to hearing news about the ability to change SSL-port and Linux probes in the near future then ;)
Have a great day.
Jul, 2012 - Permalink
If you are afraid of exposing port 443 to the internet, how about doing a port forward on your hardware firewall?
Expose an exotic port on your firewall and have it routed to 443 on your PRTG machine.
From within your internal network you would still be able to access your PRTG server directly on port 443, but the outside world can only access in on port xxxx
Regards,
Jul, 2012 - Permalink
Unfortunately i do not have any hardware firewall put in place for this, however this is still doable indeed.
Jul, 2012 - Permalink
This article applies to PRTG Network Monitor 12.3.4 or later
Custom SSL Port Now Available
As of version 12.3.4 [Stable] a custom SSL port for the PRTG web server can now be defined.
Quote from the version history:
Improved [Core]: PRTG web server can now run on https (SSL) on a user specific port (other than 443)
Dec, 2012 - Permalink
Hello,
I'm very sorry but PRTG can only use HTTPS (SSL) on port 443. This can't be changed.
best regards.
Jul, 2012 - Permalink