Mixing
Dealing with spam scripts as a shared hosting operator, with users who host mail externally
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
3
down vote
favorite
Assume the following setup;
- A shared hosting server, sharing a single IP with many small websites.
- A subset of the set of websites is sending e-mails. Some of those e-mails may be to their own domain.
- Another subset of the set of websites is hosting their mail on another platform.
- A third subset who host is vulnerable to a remote code execution vunerability.
- In the Venn diagram for subsets (2), (3), (4), assume any part can be nonempty.
There are issues with spammers becoming more and more competent at circumventing the installed security measures. With full code execution access, a hacker can circumvent the usual Linux mailing stack and instead implement their own E-mail server, directly communicating via socket code to external mail servers and sending a massive amount of spam.
A server is a pretty powerful machine, so such free-roaming code can send significant enough amounts of spam to get on the radar of the Big Boys, such as Microsoft and Google. These companies have their own home-rolled obfuscated proprietary systems which tend to block based on IP. I know that this is a stupid thing to do: IP does not equal a unique machine. Obviously a small hosting provider can do little about these Big corporate policies, and you cannot ignore them either; lots of consumers (e.g. users of the websites on the platform) will have e-mail addresses on the platforms of the big providers.
There's also an element of secrecy involved; the big companies are actively trying to fight the spammer botnets, so they provide no or minimal further information about any blocking so the spammers can't use this information. By sending spam that's 'signatured' they may have identified the particular botnet and marked the hosting server as a suspected cybercriminal tool. It's not entirely unreasonable, because truthfully that's what the server is being used for at that point.
IPv4 address exhaustion means that non-shared hosting is just a non-option for these small websites. It's financially just not achievable.
Note; assume there will always be some vulnerable sites, that's an intrinsic weakness of a shared platform, not every customer will have their code equally secure.
Upon being hacked, the customer is of course notified. Standard procedure is to take the site offline and reinstate a clean version, requiring the developers to fix the security issues before that.
Still, there remains a pretty big problem; One tiny mistake for one out of many websites will effectively shut down the e-mail for the entire server, and getting everything back up again can take days by curing rather than preventing this kind of issue. As sites get older, more sites start using the same IP, and spammers get ever more competent, the situation will get worse and worse over time.
While I can think of some partial solutions, so far they've all been unable to keep the full feature set we're providing. For example, I've tried blocking outgoing traffic over the standard E-mail port (25) through the server's firewall for all users except root and a trusted e-mail user. This will fully prevent our spam problems, because this means the websites are required to use the standard stack, and it's simple to configure things like rate limiting and spam filters for outgoing mail on this standard stack.
The tiny amount of spam that can still get through would not put us on these secret ip-blocking lists.
This works for most of the websites; but not all. Subset (3) is throwing a wrench into the works if combined with (2). Let's illustrate:
Our host (IP = H) is supposed to send a message to a microsoft host (IP = M), through its mail server. Say we send from 'noreply@domain.com' to 'contact@domain.com'.
If this message is sent directly, everything works.
However, when sent via the mail server, it needs DNS records. But then it tries to send to localhost (H), this fails, because (H) does not have the mailbox 'contact', that should only exist on the microsoft host...
Furthermore, plain blocking everything like that may not work for all the websites; some may have their own built-in mail engine, although if with some fiddling we can overcome the problem above I'm not impartial to telling these people to fix their software to use the correct mail program.
I'm interested in opinions about smart(er) ways of going about this conundrum.
linux shared-hosting
asked 5 hours ago
aphid
1162
New contributor
aphid is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
3
down vote
favorite
Assume the following setup;
- A shared hosting server, sharing a single IP with many small websites.
- A subset of the set of websites is sending e-mails. Some of those e-mails may be to their own domain.
- Another subset of the set of websites is hosting their mail on another platform.
- A third subset who host is vulnerable to a remote code execution vunerability.
- In the Venn diagram for subsets (2), (3), (4), assume any part can be nonempty.
There are issues with spammers becoming more and more competent at circumventing the installed security measures. With full code execution access, a hacker can circumvent the usual Linux mailing stack and instead implement their own E-mail server, directly communicating via socket code to external mail servers and sending a massive amount of spam.
A server is a pretty powerful machine, so such free-roaming code can send significant enough amounts of spam to get on the radar of the Big Boys, such as Microsoft and Google. These companies have their own home-rolled obfuscated proprietary systems which tend to block based on IP. I know that this is a stupid thing to do: IP does not equal a unique machine. Obviously a small hosting provider can do little about these Big corporate policies, and you cannot ignore them either; lots of consumers (e.g. users of the websites on the platform) will have e-mail addresses on the platforms of the big providers.
There's also an element of secrecy involved; the big companies are actively trying to fight the spammer botnets, so they provide no or minimal further information about any blocking so the spammers can't use this information. By sending spam that's 'signatured' they may have identified the particular botnet and marked the hosting server as a suspected cybercriminal tool. It's not entirely unreasonable, because truthfully that's what the server is being used for at that point.
IPv4 address exhaustion means that non-shared hosting is just a non-option for these small websites. It's financially just not achievable.
Note; assume there will always be some vulnerable sites, that's an intrinsic weakness of a shared platform, not every customer will have their code equally secure.
Upon being hacked, the customer is of course notified. Standard procedure is to take the site offline and reinstate a clean version, requiring the developers to fix the security issues before that.
Still, there remains a pretty big problem; One tiny mistake for one out of many websites will effectively shut down the e-mail for the entire server, and getting everything back up again can take days by curing rather than preventing this kind of issue. As sites get older, more sites start using the same IP, and spammers get ever more competent, the situation will get worse and worse over time.
While I can think of some partial solutions, so far they've all been unable to keep the full feature set we're providing. For example, I've tried blocking outgoing traffic over the standard E-mail port (25) through the server's firewall for all users except root and a trusted e-mail user. This will fully prevent our spam problems, because this means the websites are required to use the standard stack, and it's simple to configure things like rate limiting and spam filters for outgoing mail on this standard stack.
The tiny amount of spam that can still get through would not put us on these secret ip-blocking lists.
This works for most of the websites; but not all. Subset (3) is throwing a wrench into the works if combined with (2). Let's illustrate:
Our host (IP = H) is supposed to send a message to a microsoft host (IP = M), through its mail server. Say we send from 'noreply@domain.com' to 'contact@domain.com'.
If this message is sent directly, everything works.
However, when sent via the mail server, it needs DNS records. But then it tries to send to localhost (H), this fails, because (H) does not have the mailbox 'contact', that should only exist on the microsoft host...
Furthermore, plain blocking everything like that may not work for all the websites; some may have their own built-in mail engine, although if with some fiddling we can overcome the problem above I'm not impartial to telling these people to fix their software to use the correct mail program.
I'm interested in opinions about smart(er) ways of going about this conundrum.
linux shared-hosting
asked 5 hours ago
aphid
1162
New contributor
aphid is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
3
down vote
favorite
up vote
3
down vote
favorite
Assume the following setup;
- A shared hosting server, sharing a single IP with many small websites.
- A subset of the set of websites is sending e-mails. Some of those e-mails may be to their own domain.
- Another subset of the set of websites is hosting their mail on another platform.
- A third subset who host is vulnerable to a remote code execution vunerability.
- In the Venn diagram for subsets (2), (3), (4), assume any part can be nonempty.
There are issues with spammers becoming more and more competent at circumventing the installed security measures. With full code execution access, a hacker can circumvent the usual Linux mailing stack and instead implement their own E-mail server, directly communicating via socket code to external mail servers and sending a massive amount of spam.
A server is a pretty powerful machine, so such free-roaming code can send significant enough amounts of spam to get on the radar of the Big Boys, such as Microsoft and Google. These companies have their own home-rolled obfuscated proprietary systems which tend to block based on IP. I know that this is a stupid thing to do: IP does not equal a unique machine. Obviously a small hosting provider can do little about these Big corporate policies, and you cannot ignore them either; lots of consumers (e.g. users of the websites on the platform) will have e-mail addresses on the platforms of the big providers.
There's also an element of secrecy involved; the big companies are actively trying to fight the spammer botnets, so they provide no or minimal further information about any blocking so the spammers can't use this information. By sending spam that's 'signatured' they may have identified the particular botnet and marked the hosting server as a suspected cybercriminal tool. It's not entirely unreasonable, because truthfully that's what the server is being used for at that point.
IPv4 address exhaustion means that non-shared hosting is just a non-option for these small websites. It's financially just not achievable.
Note; assume there will always be some vulnerable sites, that's an intrinsic weakness of a shared platform, not every customer will have their code equally secure.
Upon being hacked, the customer is of course notified. Standard procedure is to take the site offline and reinstate a clean version, requiring the developers to fix the security issues before that.
Still, there remains a pretty big problem; One tiny mistake for one out of many websites will effectively shut down the e-mail for the entire server, and getting everything back up again can take days by curing rather than preventing this kind of issue. As sites get older, more sites start using the same IP, and spammers get ever more competent, the situation will get worse and worse over time.
While I can think of some partial solutions, so far they've all been unable to keep the full feature set we're providing. For example, I've tried blocking outgoing traffic over the standard E-mail port (25) through the server's firewall for all users except root and a trusted e-mail user. This will fully prevent our spam problems, because this means the websites are required to use the standard stack, and it's simple to configure things like rate limiting and spam filters for outgoing mail on this standard stack.
The tiny amount of spam that can still get through would not put us on these secret ip-blocking lists.
This works for most of the websites; but not all. Subset (3) is throwing a wrench into the works if combined with (2). Let's illustrate:
Our host (IP = H) is supposed to send a message to a microsoft host (IP = M), through its mail server. Say we send from 'noreply@domain.com' to 'contact@domain.com'.
If this message is sent directly, everything works.
However, when sent via the mail server, it needs DNS records. But then it tries to send to localhost (H), this fails, because (H) does not have the mailbox 'contact', that should only exist on the microsoft host...
Furthermore, plain blocking everything like that may not work for all the websites; some may have their own built-in mail engine, although if with some fiddling we can overcome the problem above I'm not impartial to telling these people to fix their software to use the correct mail program.
I'm interested in opinions about smart(er) ways of going about this conundrum.
linux shared-hosting
asked 5 hours ago
aphid
1162
New contributor
aphid is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Assume the following setup;
- A shared hosting server, sharing a single IP with many small websites.
- A subset of the set of websites is sending e-mails. Some of those e-mails may be to their own domain.
- Another subset of the set of websites is hosting their mail on another platform.
- A third subset who host is vulnerable to a remote code execution vunerability.
- In the Venn diagram for subsets (2), (3), (4), assume any part can be nonempty.
There are issues with spammers becoming more and more competent at circumventing the installed security measures. With full code execution access, a hacker can circumvent the usual Linux mailing stack and instead implement their own E-mail server, directly communicating via socket code to external mail servers and sending a massive amount of spam.
A server is a pretty powerful machine, so such free-roaming code can send significant enough amounts of spam to get on the radar of the Big Boys, such as Microsoft and Google. These companies have their own home-rolled obfuscated proprietary systems which tend to block based on IP. I know that this is a stupid thing to do: IP does not equal a unique machine. Obviously a small hosting provider can do little about these Big corporate policies, and you cannot ignore them either; lots of consumers (e.g. users of the websites on the platform) will have e-mail addresses on the platforms of the big providers.
There's also an element of secrecy involved; the big companies are actively trying to fight the spammer botnets, so they provide no or minimal further information about any blocking so the spammers can't use this information. By sending spam that's 'signatured' they may have identified the particular botnet and marked the hosting server as a suspected cybercriminal tool. It's not entirely unreasonable, because truthfully that's what the server is being used for at that point.
IPv4 address exhaustion means that non-shared hosting is just a non-option for these small websites. It's financially just not achievable.
Note; assume there will always be some vulnerable sites, that's an intrinsic weakness of a shared platform, not every customer will have their code equally secure.
Upon being hacked, the customer is of course notified. Standard procedure is to take the site offline and reinstate a clean version, requiring the developers to fix the security issues before that.
Still, there remains a pretty big problem; One tiny mistake for one out of many websites will effectively shut down the e-mail for the entire server, and getting everything back up again can take days by curing rather than preventing this kind of issue. As sites get older, more sites start using the same IP, and spammers get ever more competent, the situation will get worse and worse over time.
While I can think of some partial solutions, so far they've all been unable to keep the full feature set we're providing. For example, I've tried blocking outgoing traffic over the standard E-mail port (25) through the server's firewall for all users except root and a trusted e-mail user. This will fully prevent our spam problems, because this means the websites are required to use the standard stack, and it's simple to configure things like rate limiting and spam filters for outgoing mail on this standard stack.
The tiny amount of spam that can still get through would not put us on these secret ip-blocking lists.
This works for most of the websites; but not all. Subset (3) is throwing a wrench into the works if combined with (2). Let's illustrate:
Our host (IP = H) is supposed to send a message to a microsoft host (IP = M), through its mail server. Say we send from 'noreply@domain.com' to 'contact@domain.com'.
If this message is sent directly, everything works.
However, when sent via the mail server, it needs DNS records. But then it tries to send to localhost (H), this fails, because (H) does not have the mailbox 'contact', that should only exist on the microsoft host...
Furthermore, plain blocking everything like that may not work for all the websites; some may have their own built-in mail engine, although if with some fiddling we can overcome the problem above I'm not impartial to telling these people to fix their software to use the correct mail program.
I'm interested in opinions about smart(er) ways of going about this conundrum.
linux shared-hosting
linux shared-hosting
asked 5 hours ago
aphid
1162
New contributor
aphid is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 5 hours ago
aphid
1162
New contributor
aphid is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 5 hours ago
aphid
1162
New contributor
aphid is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 5 hours ago
aphid
1162
asked 5 hours ago
aphid
1162
1162
New contributor
aphid is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
aphid is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
aphid is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
4
down vote
This is a long and complicated topic; but I will try to answer as concise as I can.
Basically, IMHO, you are mixing three kinds of problems here:
- Abuse of legitimate email sending facilities which your server provide.
- Execution of malicious code on your webserver which may send emails to any outside recipients on their own, i.e. without using the legitimate local facilities
- Proper configuration of DNS records
I will leave out the latter one as this would be way OT here and focus on the first two kinds of problems.
You are not saying anything about how many machines and IP addresses you got at hand in order to seperate things, but with reasonable resources, my advice from years of practice would be as a first line of defense:
Do not allow your webserver to sent email anywhere except to an SMTP relay server which you own and control and which is separate from the webserver for reasons of compromising. Put an external firewall to the web server machine which will prevent any IP connection originating from your webserver at port 25 except to your SMTP relay server. (Some people may tell you to prevent not only connections originating from your webserver at port 25 but at all possible ports as web servers should theoretically reply to requests and not start any requests themselves. Unfortunately, this will give your customers trouble if they for example run any CMS which wants to talk back to its extension repo, for example. I will leave this subject to a separate discussion.
In the connection between your web server and your SMTP relay server make sure you use some form of authentication. If necessary, create a user for each website on your SMTP relay server and require the webserver to authenticate to the SMTP relay server in order to send mails. This will make it extremely simple for you to switch off email sending for just one specific website.
On your SMTP relay server, implement reasonable techniques to prevent spam. Usually some combination of rate limiting and possibly content scanning (think Spamassassin) where you would just filter out very high scores should help.
One could imagine some scripting magic then when an emerging spam outbreak is detected on the SMTP relay server the user belonging to the sending website will be blocked automatically to prevent damage.
After all, keep a 2nd and 3rd SMTP relay server in cold standby with a different public IP address and if possible in a different ASN. Should your countermeasures fail and the IP address of your first SMTP relay server get "burned" you can immediately switch over to one of your "yet unknown" servers to ensure proper outbound email delivery.
Note: When implementing this, make sure you properly understand things like DKIM and SPF and set the proper records. Then that will work. If you need to switch off a server which made it onto some blocking lists (most of them not being that secret by the way) you will usually get de-listed after some time (think weeks, not hours) and that IP would be available again for some kind of round robin.
answered 2 hours ago
TorstenS
46816
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
This is a long and complicated topic; but I will try to answer as concise as I can.
Basically, IMHO, you are mixing three kinds of problems here:
- Abuse of legitimate email sending facilities which your server provide.
- Execution of malicious code on your webserver which may send emails to any outside recipients on their own, i.e. without using the legitimate local facilities
- Proper configuration of DNS records
I will leave out the latter one as this would be way OT here and focus on the first two kinds of problems.
You are not saying anything about how many machines and IP addresses you got at hand in order to seperate things, but with reasonable resources, my advice from years of practice would be as a first line of defense:
Do not allow your webserver to sent email anywhere except to an SMTP relay server which you own and control and which is separate from the webserver for reasons of compromising. Put an external firewall to the web server machine which will prevent any IP connection originating from your webserver at port 25 except to your SMTP relay server. (Some people may tell you to prevent not only connections originating from your webserver at port 25 but at all possible ports as web servers should theoretically reply to requests and not start any requests themselves. Unfortunately, this will give your customers trouble if they for example run any CMS which wants to talk back to its extension repo, for example. I will leave this subject to a separate discussion.
In the connection between your web server and your SMTP relay server make sure you use some form of authentication. If necessary, create a user for each website on your SMTP relay server and require the webserver to authenticate to the SMTP relay server in order to send mails. This will make it extremely simple for you to switch off email sending for just one specific website.
On your SMTP relay server, implement reasonable techniques to prevent spam. Usually some combination of rate limiting and possibly content scanning (think Spamassassin) where you would just filter out very high scores should help.
One could imagine some scripting magic then when an emerging spam outbreak is detected on the SMTP relay server the user belonging to the sending website will be blocked automatically to prevent damage.
After all, keep a 2nd and 3rd SMTP relay server in cold standby with a different public IP address and if possible in a different ASN. Should your countermeasures fail and the IP address of your first SMTP relay server get "burned" you can immediately switch over to one of your "yet unknown" servers to ensure proper outbound email delivery.
Note: When implementing this, make sure you properly understand things like DKIM and SPF and set the proper records. Then that will work. If you need to switch off a server which made it onto some blocking lists (most of them not being that secret by the way) you will usually get de-listed after some time (think weeks, not hours) and that IP would be available again for some kind of round robin.
answered 2 hours ago
TorstenS
46816
add a comment |Â
up vote
4
down vote
This is a long and complicated topic; but I will try to answer as concise as I can.
Basically, IMHO, you are mixing three kinds of problems here:
- Abuse of legitimate email sending facilities which your server provide.
- Execution of malicious code on your webserver which may send emails to any outside recipients on their own, i.e. without using the legitimate local facilities
- Proper configuration of DNS records
I will leave out the latter one as this would be way OT here and focus on the first two kinds of problems.
You are not saying anything about how many machines and IP addresses you got at hand in order to seperate things, but with reasonable resources, my advice from years of practice would be as a first line of defense:
Do not allow your webserver to sent email anywhere except to an SMTP relay server which you own and control and which is separate from the webserver for reasons of compromising. Put an external firewall to the web server machine which will prevent any IP connection originating from your webserver at port 25 except to your SMTP relay server. (Some people may tell you to prevent not only connections originating from your webserver at port 25 but at all possible ports as web servers should theoretically reply to requests and not start any requests themselves. Unfortunately, this will give your customers trouble if they for example run any CMS which wants to talk back to its extension repo, for example. I will leave this subject to a separate discussion.
In the connection between your web server and your SMTP relay server make sure you use some form of authentication. If necessary, create a user for each website on your SMTP relay server and require the webserver to authenticate to the SMTP relay server in order to send mails. This will make it extremely simple for you to switch off email sending for just one specific website.
On your SMTP relay server, implement reasonable techniques to prevent spam. Usually some combination of rate limiting and possibly content scanning (think Spamassassin) where you would just filter out very high scores should help.
One could imagine some scripting magic then when an emerging spam outbreak is detected on the SMTP relay server the user belonging to the sending website will be blocked automatically to prevent damage.
After all, keep a 2nd and 3rd SMTP relay server in cold standby with a different public IP address and if possible in a different ASN. Should your countermeasures fail and the IP address of your first SMTP relay server get "burned" you can immediately switch over to one of your "yet unknown" servers to ensure proper outbound email delivery.
Note: When implementing this, make sure you properly understand things like DKIM and SPF and set the proper records. Then that will work. If you need to switch off a server which made it onto some blocking lists (most of them not being that secret by the way) you will usually get de-listed after some time (think weeks, not hours) and that IP would be available again for some kind of round robin.
answered 2 hours ago
TorstenS
46816
add a comment |Â
up vote
4
down vote
up vote
4
down vote
This is a long and complicated topic; but I will try to answer as concise as I can.
Basically, IMHO, you are mixing three kinds of problems here:
- Abuse of legitimate email sending facilities which your server provide.
- Execution of malicious code on your webserver which may send emails to any outside recipients on their own, i.e. without using the legitimate local facilities
- Proper configuration of DNS records
I will leave out the latter one as this would be way OT here and focus on the first two kinds of problems.
You are not saying anything about how many machines and IP addresses you got at hand in order to seperate things, but with reasonable resources, my advice from years of practice would be as a first line of defense:
Do not allow your webserver to sent email anywhere except to an SMTP relay server which you own and control and which is separate from the webserver for reasons of compromising. Put an external firewall to the web server machine which will prevent any IP connection originating from your webserver at port 25 except to your SMTP relay server. (Some people may tell you to prevent not only connections originating from your webserver at port 25 but at all possible ports as web servers should theoretically reply to requests and not start any requests themselves. Unfortunately, this will give your customers trouble if they for example run any CMS which wants to talk back to its extension repo, for example. I will leave this subject to a separate discussion.
In the connection between your web server and your SMTP relay server make sure you use some form of authentication. If necessary, create a user for each website on your SMTP relay server and require the webserver to authenticate to the SMTP relay server in order to send mails. This will make it extremely simple for you to switch off email sending for just one specific website.
On your SMTP relay server, implement reasonable techniques to prevent spam. Usually some combination of rate limiting and possibly content scanning (think Spamassassin) where you would just filter out very high scores should help.
One could imagine some scripting magic then when an emerging spam outbreak is detected on the SMTP relay server the user belonging to the sending website will be blocked automatically to prevent damage.
After all, keep a 2nd and 3rd SMTP relay server in cold standby with a different public IP address and if possible in a different ASN. Should your countermeasures fail and the IP address of your first SMTP relay server get "burned" you can immediately switch over to one of your "yet unknown" servers to ensure proper outbound email delivery.
Note: When implementing this, make sure you properly understand things like DKIM and SPF and set the proper records. Then that will work. If you need to switch off a server which made it onto some blocking lists (most of them not being that secret by the way) you will usually get de-listed after some time (think weeks, not hours) and that IP would be available again for some kind of round robin.
answered 2 hours ago
TorstenS
46816
This is a long and complicated topic; but I will try to answer as concise as I can.
Basically, IMHO, you are mixing three kinds of problems here:
- Abuse of legitimate email sending facilities which your server provide.
- Execution of malicious code on your webserver which may send emails to any outside recipients on their own, i.e. without using the legitimate local facilities
- Proper configuration of DNS records
I will leave out the latter one as this would be way OT here and focus on the first two kinds of problems.
You are not saying anything about how many machines and IP addresses you got at hand in order to seperate things, but with reasonable resources, my advice from years of practice would be as a first line of defense:
Do not allow your webserver to sent email anywhere except to an SMTP relay server which you own and control and which is separate from the webserver for reasons of compromising. Put an external firewall to the web server machine which will prevent any IP connection originating from your webserver at port 25 except to your SMTP relay server. (Some people may tell you to prevent not only connections originating from your webserver at port 25 but at all possible ports as web servers should theoretically reply to requests and not start any requests themselves. Unfortunately, this will give your customers trouble if they for example run any CMS which wants to talk back to its extension repo, for example. I will leave this subject to a separate discussion.
In the connection between your web server and your SMTP relay server make sure you use some form of authentication. If necessary, create a user for each website on your SMTP relay server and require the webserver to authenticate to the SMTP relay server in order to send mails. This will make it extremely simple for you to switch off email sending for just one specific website.
On your SMTP relay server, implement reasonable techniques to prevent spam. Usually some combination of rate limiting and possibly content scanning (think Spamassassin) where you would just filter out very high scores should help.
One could imagine some scripting magic then when an emerging spam outbreak is detected on the SMTP relay server the user belonging to the sending website will be blocked automatically to prevent damage.
After all, keep a 2nd and 3rd SMTP relay server in cold standby with a different public IP address and if possible in a different ASN. Should your countermeasures fail and the IP address of your first SMTP relay server get "burned" you can immediately switch over to one of your "yet unknown" servers to ensure proper outbound email delivery.
Note: When implementing this, make sure you properly understand things like DKIM and SPF and set the proper records. Then that will work. If you need to switch off a server which made it onto some blocking lists (most of them not being that secret by the way) you will usually get de-listed after some time (think weeks, not hours) and that IP would be available again for some kind of round robin.
answered 2 hours ago
TorstenS
46816
answered 2 hours ago
TorstenS
46816
answered 2 hours ago
TorstenS
46816
answered 2 hours ago
TorstenS
46816
46816
add a comment |Â
add a comment |Â
aphid is a new contributor. Be nice, and check out our Code of Conduct.
aphid is a new contributor. Be nice, and check out our Code of Conduct.
aphid is a new contributor. Be nice, and check out our Code of Conduct.
aphid is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f195123%2fdealing-with-spam-scripts-as-a-shared-hosting-operator-with-users-who-host-mail%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
