R
Redpitt
Guest
Hi all!
I've verified that after upgrading to Plesk 8.4 (the issue is present in Plesk 8.6 too), the SMTP server acts as an open relay.
I'm using Plesk 8.4 and Plesk 8.6 on Centos 4.x operating system.
Plesk upgrades are made via the autoinstaller command-line utility downloaded from Parallels site.
Users are able to use the mail server with any valid BASE64 login header (containing valid or invalid credentials) or WITHOUT sending these headers at all (toggling off SMTP authentication on their mail user agents).
I've tried to reconfigure the mail service via the "Server -> Mail" section in the control panel with no success.
Moreover, I've tried to correct the problem by calling "mailmng" and "mchk" command-line utilities, but that didn't solve the problem.
It seems to me that there's no way out to solve the security issue through the control panel, so I've decided to publish here a workaround to secure your mail servers waiting for Parallels to identify the problem and study a solution for it.
1. change directory to "/etc/xinetd.d"
2. create a file named "smtp_ok"
copy the following content into that file:
service smtp
{
flags = REUSE NAMEINARGS
socket_type = stream
protocol = tcp
wait = no
user = qmaild
server = /usr/sbin/tcpd
env = SMTPAUTH=1 POPAUTH=1
server_args = /var/qmail/bin/tcp-env -R /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp_auth /var/qmail/bin/cmd5checkpw
}
3. save and close the file
4. create a file named smtps_ok
5. copy the following content into that file:
service smtps
{
flags = REUSE NAMEINARGS
socket_type = stream
protocol = tcp
wait = no
user = qmaild
server = /usr/sbin/tcpd
env = SMTPAUTH=1 POPAUTH=1
server_args = /var/qmail/bin/tcp-env -R /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp_auth /var/qmail/bin/cmd5checkpw
}
6. remove the following files: "smtp_psa", "smtps_psa", "submission.psa"
7. restart xinetd by typing "/etc/init.d/xinetd restart"
This fix should let you secure your MTA. Now we have to check that it remains secure... for this purpose I've created a shell script and put a new cronjob that runs each minute (you can increase this value, but I suggest it should be less than 5 minutes).
This is needed because the plesk admin user can modify mail settings via the control panel and recreate the security hole.
With this script we continuosly check if the control panel modify the SMTP and SMTPS services configuration and restore authentication, disabling unwanted message submission.
To create this script you have to:
1. change directory to "/root"
2. create a file named "check_xinetd.sh"
3. copy the following content into that file:
#!/bin/bash
USER=root
SHELL=/bin/bash
HOME=/root
export USER SHELL HOME
RELOAD=0
cd /etc/xinetd.d
if [ -f /etc/xinetd.d/smtp_psa ]; then
rm -f /etc/xinetd.d/smtp_psa
let RELOAD=1
fi;
if [ -f /etc/xinetd.d/smtps_psa ]; then
rm -f /etc/xinetd.d/smtps_psa
let RELOAD=1
fi;
if [ "$RELOAD" == "1" ]; then
/etc/init.d/xinetd reload
fi
exit 0
4. make the script executable by typing "chmod 0700 check_xinetd.sh"
5. run "crontab -e"
6. your preferred editor opens: just put the following line at the end of the crontab file
0-59 * * * * /root/check_xinetd.sh
7. save and close the editor... you should see the message "installing new crontab"...
Good work! Your server is now fully secured...
Feedbacks welcome!
Thanks for your attention.
Redpitt.
I've verified that after upgrading to Plesk 8.4 (the issue is present in Plesk 8.6 too), the SMTP server acts as an open relay.
I'm using Plesk 8.4 and Plesk 8.6 on Centos 4.x operating system.
Plesk upgrades are made via the autoinstaller command-line utility downloaded from Parallels site.
Users are able to use the mail server with any valid BASE64 login header (containing valid or invalid credentials) or WITHOUT sending these headers at all (toggling off SMTP authentication on their mail user agents).
I've tried to reconfigure the mail service via the "Server -> Mail" section in the control panel with no success.
Moreover, I've tried to correct the problem by calling "mailmng" and "mchk" command-line utilities, but that didn't solve the problem.
It seems to me that there's no way out to solve the security issue through the control panel, so I've decided to publish here a workaround to secure your mail servers waiting for Parallels to identify the problem and study a solution for it.
1. change directory to "/etc/xinetd.d"
2. create a file named "smtp_ok"
copy the following content into that file:
service smtp
{
flags = REUSE NAMEINARGS
socket_type = stream
protocol = tcp
wait = no
user = qmaild
server = /usr/sbin/tcpd
env = SMTPAUTH=1 POPAUTH=1
server_args = /var/qmail/bin/tcp-env -R /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp_auth /var/qmail/bin/cmd5checkpw
}
3. save and close the file
4. create a file named smtps_ok
5. copy the following content into that file:
service smtps
{
flags = REUSE NAMEINARGS
socket_type = stream
protocol = tcp
wait = no
user = qmaild
server = /usr/sbin/tcpd
env = SMTPAUTH=1 POPAUTH=1
server_args = /var/qmail/bin/tcp-env -R /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp_auth /var/qmail/bin/cmd5checkpw
}
6. remove the following files: "smtp_psa", "smtps_psa", "submission.psa"
7. restart xinetd by typing "/etc/init.d/xinetd restart"
This fix should let you secure your MTA. Now we have to check that it remains secure... for this purpose I've created a shell script and put a new cronjob that runs each minute (you can increase this value, but I suggest it should be less than 5 minutes).
This is needed because the plesk admin user can modify mail settings via the control panel and recreate the security hole.
With this script we continuosly check if the control panel modify the SMTP and SMTPS services configuration and restore authentication, disabling unwanted message submission.
To create this script you have to:
1. change directory to "/root"
2. create a file named "check_xinetd.sh"
3. copy the following content into that file:
#!/bin/bash
USER=root
SHELL=/bin/bash
HOME=/root
export USER SHELL HOME
RELOAD=0
cd /etc/xinetd.d
if [ -f /etc/xinetd.d/smtp_psa ]; then
rm -f /etc/xinetd.d/smtp_psa
let RELOAD=1
fi;
if [ -f /etc/xinetd.d/smtps_psa ]; then
rm -f /etc/xinetd.d/smtps_psa
let RELOAD=1
fi;
if [ "$RELOAD" == "1" ]; then
/etc/init.d/xinetd reload
fi
exit 0
4. make the script executable by typing "chmod 0700 check_xinetd.sh"
5. run "crontab -e"
6. your preferred editor opens: just put the following line at the end of the crontab file
0-59 * * * * /root/check_xinetd.sh
7. save and close the editor... you should see the message "installing new crontab"...
Good work! Your server is now fully secured...
Feedbacks welcome!
Thanks for your attention.
Redpitt.