Facebook
Twitter
-
If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
CentOS2Alma discussion
How to change default FTP port in Plesk 12.5.30?
- Thread starter Alan_SP
- Start date
jamin
Basic Pleskian
Hi Alan_SP . Here is Odin KB article on How to Change Default Port, it is not recommended. http://kb.odin.com/en/138
I would imagine its as easy as modifying the Port in /etc/proftpd.conf and then restarting xinetd service - and of course allowing the ports through any firewalls if you have any.
U
UFHH01
Guest
Places to change the standart FTP - ports are ( with Plesk, ProFTPD ):
/etc/proftpd.conf
Code:
...
# Port 21 is the standard FTP port.
Port 21
.../etc/services
Code:
...
ftp-data 20/tcp
ftp 21/tcp
fsp 21/udp fspd
...This is for changing Plesk port (8443), not FTP port.
Solution for changing FTP port is the one that @UFHH01 mentions, but previously I changed FTP port that way and had problems with backup when using FTP repository, backup didn't worked because different FTP port.
That's the reason why I asked about changing FTP port for Plesk, so Plesk is aware of change and that backup also works with changed default port.
Last edited:
U
UFHH01
Guest
Hi Alan_SP,
you still may experience issues and problems when changing your default FTP - port. As you already noticed, communications from Plesk - related services with other FTP - servers are based on the "standart" port. Odin might implement the additional FTP - port - settings in the future, but actually there is no such setting.
you still may experience issues and problems when changing your default FTP - port. As you already noticed, communications from Plesk - related services with other FTP - servers are based on the "standart" port. Odin might implement the additional FTP - port - settings in the future, but actually there is no such setting.
Thanks, so now I know that there's no right way to change default FTP port in Plesk and that changing Plesk port impacts severely backup if using FTP repository.
As a suggestion, please add a way so Plesk can be aware of changes in default FTP port. It's interesting that Plesk now can use FTP repository that uses different FTP port (OK, I'm not sure, it was long time when I tried that), you just use standard directive ftp.someserver.com:XFTPport (XFTPport is none standard FTP port).
As a suggestion, please add a way so Plesk can be aware of changes in default FTP port. It's interesting that Plesk now can use FTP repository that uses different FTP port (OK, I'm not sure, it was long time when I tried that), you just use standard directive ftp.someserver.com:XFTPport (XFTPport is none standard FTP port).
if you are using a ftp repository for your backup in plesk then it should be a remote server - which those would use FTP on the standard port right? (Note you can also use Dropbox as your destination instead so you don't have to do this at all with your own servers). Changing the port on your server would really only affect inbound FTP requests - so unless you are using FTP backup to your local server it shouldnt really affect plesk right - or am I missing something?
U
UFHH01
Guest
Hi Amin Taheri,
Correct, but please be aware that some hosting provider offer as well FTP - backup solutions, which are included in their server - hosting - package. These additional ( remote ) FTP - servers are only accessible from the main - IP of your rented server and are much more secure than a dropbox, or any other remote server. There are no internal affects on your server at all, when you change your standart FTP - port = correct as well.
Well, I can't tell how it is now (still didn't tried it), but with older versions of Plesk (v10), for some reason changing default FTP port messed with backing up to FTP repository. Backup didn't worked. Don't know why.
But I think that I could use FTP repository with non standard FTP port successfully. So it seems that for some reason Plesk needs FTP port to be default one.
But I think that I could use FTP repository with non standard FTP port successfully. So it seems that for some reason Plesk needs FTP port to be default one.
The point I was trying to make was that DropBox allows you to host quite a lot of space for virtually free (1TB for $10/mo) , and there is a plesk extension which allows you to do the backups and restores from there already - meaning no need to setup anything else, or maintain several servers, or pay for additional hosting plans, etc. I would also argue that since DropBox is preparing for an IPO they are probably way more secure than most hosting companies out there. But all of this is likely off topic to the issue ALan_SP posted.
To get back on track: another option could be to specify the port as part of the hostname if you are not asked for it separately - for example - ftp.example.com:8021 - I seem to recall this working well in the older versions.
However if you have tried all of that and think you have found a bug please forward it off to the Odin team for review.
To get back on track: another option could be to specify the port as part of the hostname if you are not asked for it separately - for example - ftp.example.com:8021 - I seem to recall this working well in the older versions.
However if you have tried all of that and think you have found a bug please forward it off to the Odin team for review.
Where I set up this?
@Alan_SP,
Yes, you can. The same principle applies as when having the passive ports opened up at the remote server, i.e. the server on which the FTP repository resides.
Not really, any FTP Port can be configured to be used by ftp processes.
In theory, a custom ftp port can be used by any ftp process.
UFHH01 already gave you the right directions to change a port, in your case on the remote FTP server OR the source FTP server.
However, in practice, you might encounter (read: you are destined) to encounter issues with the ftp process, handling the backup of data to a remote FTP server.
A elaborate work-around is present, but there is no need to present that in your specific case.
In essence, you want a different ftp port on the remote FTP server, am I correct?
If that is the case, just consider to use the passive port configuration on the remote server, allowing you to specify a RANGE of custom ftp ports, used for ftp backup processes.
Sure, the origin server is using the standard ftp ports, but that is not really something to be bothered about and/or that should not be an issue.
How to create the passive ports? Simply create a custom config file in the directory /etc/proftpd.d/, with the contents being one line: PassivePorts <RangeStart> <RangeEnd>.
Just fill in your preferred range by defining the RangeStart and RangeEnd variables, that is all.
Note that proftpd does not have to be restarted, the addition of the custom config file becomes effective immediately.
This approach is certain to work, whilst still having the ability to choose the ftp ports used on the remote server.
In short, yes you can to
Finally, note that the above "work-around" is not confined to "passive ports": any port range will do, the only point is that TLS connections are used.
For instance, port range 3400 to 3500 will do just as fine as port range 1024 1096, proftpd is not really bothered about that (choose the range carefully though).
However, all the above is not really the solution, it merely is a work-around.
The desire exists to define a custom ftp port, without losing the ability to perform backups to a ftp repository.
I can recall this particular issue to exist for more than 4 years now and 3 or more years ago, Odin Team suggested that they were working on it. Are they? IgorG, can you tell us?
I had a "test solution" working in a simple development server, that has been discarded years ago.
Maybe Odin Team can reinvestigate the issue (and I will have an attempt to remember the solution I found).
Regards....
Yes, you can. The same principle applies as when having the passive ports opened up at the remote server, i.e. the server on which the FTP repository resides.
Not really, any FTP Port can be configured to be used by ftp processes.
In theory, a custom ftp port can be used by any ftp process.
UFHH01 already gave you the right directions to change a port, in your case on the remote FTP server OR the source FTP server.
However, in practice, you might encounter (read: you are destined) to encounter issues with the ftp process, handling the backup of data to a remote FTP server.
A elaborate work-around is present, but there is no need to present that in your specific case.
In essence, you want a different ftp port on the remote FTP server, am I correct?
If that is the case, just consider to use the passive port configuration on the remote server, allowing you to specify a RANGE of custom ftp ports, used for ftp backup processes.
Sure, the origin server is using the standard ftp ports, but that is not really something to be bothered about and/or that should not be an issue.
How to create the passive ports? Simply create a custom config file in the directory /etc/proftpd.d/, with the contents being one line: PassivePorts <RangeStart> <RangeEnd>.
Just fill in your preferred range by defining the RangeStart and RangeEnd variables, that is all.
Note that proftpd does not have to be restarted, the addition of the custom config file becomes effective immediately.
This approach is certain to work, whilst still having the ability to choose the ftp ports used on the remote server.
In short, yes you can to
Finally, note that the above "work-around" is not confined to "passive ports": any port range will do, the only point is that TLS connections are used.
For instance, port range 3400 to 3500 will do just as fine as port range 1024 1096, proftpd is not really bothered about that (choose the range carefully though).
However, all the above is not really the solution, it merely is a work-around.
The desire exists to define a custom ftp port, without losing the ability to perform backups to a ftp repository.
I can recall this particular issue to exist for more than 4 years now and 3 or more years ago, Odin Team suggested that they were working on it. Are they? IgorG, can you tell us?
I had a "test solution" working in a simple development server, that has been discarded years ago.
Maybe Odin Team can reinvestigate the issue (and I will have an attempt to remember the solution I found).
Regards....
@Alan_SP
If I am not mistaken, the "test solution" consisted of creating a custom config file in the directory /etc/proftpd.d/ on the relevant server, with the lines:
<VirtualHost "0.0.0.0">
Port "custom port"
# "... relevant other config lines"
</VirtualHost>
and replace the IP address and the custom port, as set in /etc/proftpd.conf and /etc/services.
At least, something similar, but then again, it was a long long time ago (and the passive port work-around was more suitable).
Note that I did create a "bottom up" test solution: every standard config was kept (in order to allow for painless upgrades of proftpd and to have a ftp solution ready, whenever the custom port should fail) AND another custom virtualhost was created for the usage of the custom port (requires some specific configuration and that is more easy this way).
Also note that the standard port (21) was effectively rendered useless by a full firewall block (easy to change, if the custom port should fail).
Regards......
If I am not mistaken, the "test solution" consisted of creating a custom config file in the directory /etc/proftpd.d/ on the relevant server, with the lines:
<VirtualHost "0.0.0.0">
Port "custom port"
# "... relevant other config lines"
</VirtualHost>
and replace the IP address and the custom port, as set in /etc/proftpd.conf and /etc/services.
At least, something similar, but then again, it was a long long time ago (and the passive port work-around was more suitable).
Note that I did create a "bottom up" test solution: every standard config was kept (in order to allow for painless upgrades of proftpd and to have a ftp solution ready, whenever the custom port should fail) AND another custom virtualhost was created for the usage of the custom port (requires some specific configuration and that is more easy this way).
Also note that the standard port (21) was effectively rendered useless by a full firewall block (easy to change, if the custom port should fail).
Regards......
jamin
Basic Pleskian
Sorry Alan_SP, I must have had a long day I miss read post, for some reason my brain said default Plesk Port and missed FTP bit, my bad. I could have answered that one. ;(
No, I want to change FTP port on main server, because it gets attacked a lot. I know that changing FTP port doesn't make server absolutely secure, but it at least removes mails from those who attacks servers with scripts.
I mentioned that thing with backup as I tested this before and noticed I had problems with backup and I had to revert my changed FTP port to default one. So I wander for a way to do it and having Plesk continue to work as it should (backup wise). Now I know that it is still unresolved. Hope the solution would be found out...
@Alan_SP,
If the desire to change the FTP port on the main (or origin) server (only) results from attacks, then you should consider the following.
In general, it is not that efficient to change the FTP port in that case, since it actually does not handle the root cause of the problem: vulnerability to attacks.
In essence, the vulnerability to attacks (on any port) can reduced to an absolute minimum by using a combination (!) of
a) passive port configuration of FTP and require passive FTP by default,
b) proper firewall rules (for instance, when backing up to a remote FTP repository, only allow the IPs for the remote FTP server to access the standard and/or passive FTP ports),
c) use of fail2ban (configuring a proper jail and filter, with a maximum re-attempt of 2, should do the trick)
d) use of Nginx (as a sort of blocking mechanism, in the sense that only specific requests should be forwarded to FTP server)
and so on.
In most cases, using Fail2Ban will result a drastic decrease in vulnerability to attacks.
However, one should also consider to use the other measures proposed, since distributed attacks can make Fail2Ban ineffective.
Note that the measures proposed will at least keep your backup processes working properly.
Finally, you stated
and with respect to that, I must admit that this would be an amazing feature, but also an almost unreachable feature.
After all, in the processes of backups to a remote FTP repository, two FTP servers are normally "negotiating" on the standard FTP port(s), implying that the remote FTP server has to "know" that the origin FTP server is using non-standard FTP ports (note: multiple ports), which is rather difficult to configure or even impossible with common proftpd packages.
I know for fact that some custom code compilation in proftpd can make this possible, but the endresult is not and will never be stable.
A more reliable approach is the use of the "VirtualHost method", but then again, this is also quite cumbersome (to configure and test).
In short and in conclusion, the most easy method of reducing FTP (and other) attacks can be found in the usage of other tools, such as firewalls, Fail2Ban etc.
Regards.....
If the desire to change the FTP port on the main (or origin) server (only) results from attacks, then you should consider the following.
In general, it is not that efficient to change the FTP port in that case, since it actually does not handle the root cause of the problem: vulnerability to attacks.
In essence, the vulnerability to attacks (on any port) can reduced to an absolute minimum by using a combination (!) of
a) passive port configuration of FTP and require passive FTP by default,
b) proper firewall rules (for instance, when backing up to a remote FTP repository, only allow the IPs for the remote FTP server to access the standard and/or passive FTP ports),
c) use of fail2ban (configuring a proper jail and filter, with a maximum re-attempt of 2, should do the trick)
d) use of Nginx (as a sort of blocking mechanism, in the sense that only specific requests should be forwarded to FTP server)
and so on.
In most cases, using Fail2Ban will result a drastic decrease in vulnerability to attacks.
However, one should also consider to use the other measures proposed, since distributed attacks can make Fail2Ban ineffective.
Note that the measures proposed will at least keep your backup processes working properly.
Finally, you stated
and with respect to that, I must admit that this would be an amazing feature, but also an almost unreachable feature.
After all, in the processes of backups to a remote FTP repository, two FTP servers are normally "negotiating" on the standard FTP port(s), implying that the remote FTP server has to "know" that the origin FTP server is using non-standard FTP ports (note: multiple ports), which is rather difficult to configure or even impossible with common proftpd packages.
I know for fact that some custom code compilation in proftpd can make this possible, but the endresult is not and will never be stable.
A more reliable approach is the use of the "VirtualHost method", but then again, this is also quite cumbersome (to configure and test).
In short and in conclusion, the most easy method of reducing FTP (and other) attacks can be found in the usage of other tools, such as firewalls, Fail2Ban etc.
Regards.....
Similar threads
