Tips from the Abuse Department: Part 2 - Responding to Abuse Reports

June 25, 2012

If you're a SoftLayer customer, you don't want to hear from the Abuse department. We know that. The unfortunate reality when it comes to hosting a server is that compromises can happen, mistakes can be made, and even the most scrupulous reseller can fall victim to a fraudulent sign-up or sly spammer. If someone reports abusive behavior originating from one of your servers on our network, it's important to be able to communicate effectively with the Abuse department and build a healthy working relationship.

Beyond our responsibility to enforce the law and our Acceptable Use Policy, the Abuse department is designed to be a valuable asset for our customers. We'll notify you of all valid complaints (and possibly highlight security vulnerabilities in the process), we'll assist you with blacklist removal, we can serve as a liaison between you and other providers if there are any problems, and if you operate an email-heavy platform or service, we can help you understand the steps you need to take to avoid activity that may be considered abuse.

At the end of the day, if the Abuse department can maintain a good rapport with our customers, both our jobs can be easier, so I thought this installment in the "Tips from the Abuse Department" series could focus on some best practices for corresponding with Abuse from a customer perspective.

Check Your Tickets

This is the easiest, most obvious recommendation I can give. You'd be surprised at how many service interruptions could be avoided if our customers were more proactive about keeping up with their open tickets. Our portal is a vital tool for your business, so make sure you are familiar with how to access and use it.

Keep Your Contact Information Current

Our ticket system will send notifications to the email address you have on file, so making sure this information is correct and current is absolutely crucial, especially if you aren't in the habit of checking the ticket system on a regular basis. You can even set a specific address for abuse notifications to be sent to, so make use of this option. The quicker you can respond to an abuse report, the quicker the complaint can be resolved, and by getting the complaint resolved quickly, you avoid any potential service interruption.

If we are unable to reach you by ticket, we may need to call you, so keep your current phone numbers on file as well.

Provide Frequent Updates

Stay in constant communication in the midst of responding to an abuse report, and adhere to the allotted timeline in the ticket. If we don't see updates that the abusive behavior is being addressed in the grace period we are able to offer, your server is at risk of disconnection. By keeping us posted about the action you're taking and the time you need to resolve the matter, we're able to be more flexible.

If a customer on your servers created a spamming script or a phishing account, taking immediate steps to mitigate the issue by suspending that customer is another great way to respond to the process while you're performing an investigation of how that activity was started. We'll still want a detailed resolution, but if the abuse is not actively ongoing we can work with you on deadlines.

Be Concise ... But Not Too Concise

One-word responses: bad. Page long responses: also not ideal. If given the option we would opt for the latter, but your goal should be to outline the cause and resolution of any reported abusive activity as clearly and succinctly as possible in order to ease communication and expedite closing of the ticket.

Responding to a ticket with, "Fixed," is not sufficient to for the Abuse department to consider the matter resolved, but we also don't need a dump of your entire log file. Before the Abuse team can close a ticket, we have to see details of how the complaint was resolved, so if you don't provide those details in your first response, you can bet we'll keep following up with you to get them. What details do we need?

Take a Comprehensive Approach

In addition to stopping the abusive activity we want to know:

  1. How/why the issue occurred
  2. What steps are being taken to prevent further issues of that nature

We understand that dealing with abuse issues can often feel like a game of Whack-A-Mole, but if you can show that you're digging a bit deeper and taking steps to avoid recurrence, that additional work is very much appreciated. Having the Abuse department consider you a proactive, ethical and responsible customer is a worthy goal.

Be Courteous

I'm ending on a similar note to my last blog post because it's just that important! We understand getting an abuse ticket is a hassle, but please remember that we're doing our best to protect our network, the Internet community and you.

Unplugging your server is a last resort for us, and we want to make sure everyone is on the same page to prevent us from getting to that last resort. In the unfortunate event that you do experience an abuse issue, please refer back to this blog — it just might save you some headaches and perhaps some unnecessary downtime.

-Jennifer

Comments

June 25th, 2012 at 6:09pm

I've had the opportunity the last month or so to submit a number of tickets about a server migration (prompted by one of my servers being discontinued by SL). My CCI was installed on an unstable node and it was taking nearly half an hour to reboot, and was often completely unresponsive. I recognize that it's impossible to diagnose issues that affect reboots without actually rebooting the machine - so I made an effort to ensure permission was given right away.

This month I've submitted several tickets and responses to tickets providing *exacting* detail, particularly giving permission to perform operations like reboots and server changes within the initial ticket and multiple responses, and yet my tickets were delayed for hours, sometimes *days* because even given permission, the SL staff repeatedly asked for permission to do something, pushing my ticket back in the queue until I could come in and repeat myself.

When timeliness is an issue (and it has been), wouldn't it be better if staff were to spend an extra few seconds reading the ticket responses to see if permission has been granted already? Maybe you should just add a couple fields to the tickets that enable the customer to indicate if they authorize activities such as reboots and changes, and if necessary, a time window to perform them. Delaying these migrations by only a few days is going to cost me an extra $300. Thanks. :(

I've been with SoftLayer almost 10 years now - and while every once in a while there's an issue, I know it will *always* be resolved. This month has been one of the worst, but it *has* been resolved and I'm not able to move forward. SL has always done well to prove to me they care, but this is an issue that needs addressed. When permission is already granted, DON'T waste valuable time by asking me again. And again. And again...

June 26th, 2012 at 7:33am

Hello!

I have a genuine question - what should the victim of spam do when they're trying very hard to do things properly (send a polite complaint, include all headers, etc), and Softlayer just isn't stopping the spam?

I’m still getting spam from Softlayer. It’s coming from the same Softlayer IP, pushing the same weird “training”, and I’ve complained to abuse@softlayer.com 5 times this month alone.

What am I doing wrong? Shouldn't someone at Softlayer care about enforcing your own anti-spam policy?

June 26th, 2012 at 9:32am

Thanks for staying on top of this, David. I just got an update indicating this matter is resolved, and I'll be responding to the complaint you sent to Abuse with further information.

Regards,
Jennifer Groves
Manager, Abuse Department
abuse@softlayer.com

June 28th, 2012 at 6:43pm

When you parse the http://x-arf.org Reports automatically, you can build a fine score and forwarding all Reports when the score is under 500 points each ip/customer.
If the score to high:

ssh -> 100 points
mail -> 20 points
rfi -> 100 points
reported-from: xxx@trusted.tld -> 300 points

and the customer has received two or 3 warnings, block the ip/customer or create a abuse-ticket to recheck the reports and block them manually.
https://www.blocklist.de/en/search.html?as=36351

The Network from softlayer.com has outside a poor reputation and a lot of admins blocked your complete ip-range.

June 29th, 2012 at 9:14am

Shawn, I'm sorry we didn't see your comment earlier ... I just sent it over to the senior manager of technical support, and his immediate response was that he also wished there was a checkbox a customer could select to authorize whatever action needs to be taken. We've had complaints about the flip-side of your request as well, though: A customer says "you have my permission to do whatever you need to do" at the beginning of a ticket, and because the ticket kept going for a tangential reason, a tech could scroll back and see that permission, take action, and the customer gets upset that the permission wasn't intended to be valid for longer than the immediate approval.

Chris is going to follow up with his team after looking into your account, and he might send you a note as well. If you incur an additional cost as a result of the delays, let me know (khazard@softlayer.com), and I'll see if I can work with billing and support to make that right.

June 29th, 2012 at 10:11am

Thanks for the comment, blocklist.

While the route those admins took in blocking SoftLayer IP ranges is certainly an effective option when screening out abusive behavior, it might be heavy handed and limiting when you consider the thousands of legitimate customers and millions of legitimate websites that also resolve to a softlayer.com reverse lookup. Like the old idiom suggests, they're "throwing out the baby with the bath water." We can't change how admins choose to run their networks, but we can do everything in our power to run our network as efficiently as possible.

Because we don’t actively monitor or censor any content on any of the 100,000+ servers in our data centers for privacy/security reasons, we rely on abuse reports submitted by users. The "scenario" section of the "Fighting SPAM and Abuse on a Global Network" blog provides some context into how/why that setup works.

July 17th, 2012 at 7:48am

Hi Jennifer, Thank you for this blog, it's really informative. I have just logged a abuse report about one of the websites that you are hosting, and I look forward to hearing from your team.

Deirdre

August 28th, 2012 at 2:49pm

What is Softlayer's antispam policy on compromised Web sites, virus droppers, and spam sites hosted on servers belonging to The Planet?

It has been my experience that since you bought The Planet, abuse reports are entirely ignored. Even reports of security breaches on servers running in The Planet's IP space are ignored. Phish, spam redirectors, hacked WordPress sites...they all remain active on The Planet servers for weeks or even months, with repeated messages sent to abuse@theplanet.com going unanswered and the problems continuing.

Have you simply dropped the ball when it comes to responding to network abuse on ISPs you've bought, or is The Planet now your bulletproof spam hosting subsidiary?

August 28th, 2012 at 5:29pm

Hi Franklin,

Thanks for chiming in here. The social media team asked if you could forward any examples of complaints that haven't been addresses to twitter@softlayer.com when you posted the same concern on Twitter, and that's still going to be the best bet to getting your concern resolved. The Planet and SoftLayer merged in November 2010, and the SoftLayer abuse team (abuse@softlayer.com) investigates and takes action on all valid complaints on The Planet's legacy network as well as SoftLayer's network. In addition to this post (which speaks to the way SoftLayer customers should respond to abuse tickets) and the post we sent via Twitter (Fighting SPAM and Abuse on a Global Network), the first blog in this series (Reporting Abuse) could be helpful as well.

When you have an opportunity, we'd love to follow up on any abuse reports that you've submitted that haven't been addressed properly.

Thanks!

August 29th, 2012 at 10:12am

Hello softlayer

I'm one of the server owners there is very mad at softlayer abuse team, because I can see that IP's there have multiple abuse report's of lets just say ssh attacks are allowed to work and still attack people even when we are talking about there are 34 reports on that IP.

February 26th, 2013 at 8:48am

Hi Softlayer, I appreciate you addressing this topic with a blog post- I have posted an abuse report with your team from one of your hosted websites, this is the second time now, because of spam and I hope to hear back from someone soon.

February 27th, 2013 at 9:00am

Hi Jamie, In Jennifer's previous post about reporting abuse, she explains, "We work hard to investigate and resolve all complaints received however, due to volume, we typically do not respond to complaining parties." While you may not receive a response, that shouldn't suggest that we aren't taking action.

If the abusive activity persists, please feel free to forward the abuse report you submitted to abuse@softlayer.com to our social media team (twitter@softlayer.com), and we'll see if there's anything we can do to help.

February 27th, 2013 at 1:15pm

You'll forgive me if I remain unconvinced. My experience with Softlayer continues to be quite poor; it seems to me that Softlayer is still incredibly slow to act on phish sites, malware droppers, and actively exploited servers, often leaving them up for days or weeks after being notified of the problem.

For example, when the Web site datzwhatzup (dot) net was compromised, it was being used to spread the W32/ZeroAccess malware. A compromise of this type, like a phish page, should be a high priority. Yet the site remained infected and continued to spread the malware for more than a week(!) after Softlayer was notified of the problem.

To me, that is unconscionable. I realize that abuse teams are always understaffed because management sees the abuse teams as employees who cost money but don't generate revenue, but even so, to allow a serious security compromise that was actively being used to spread malware to remain on a server for a week or more is really, really bad. (By way of comparison, some of the best ISPs in the industry, such as Bluehost, will often take down phish sites and malware spreaders within an hour or two of being notified of the problem.)

It is also unfortunate that professional spam-for-hire outfits have taken up residence on Softlayer's network. For example, pushbuttonemailer (dot) com now lives on your network. This spam-for-hire site is advertised by means of link redirectors placed on other hacked sites. It plainly advertises spamming services and is spamming itself via a network of hacked sites, but has remained on Softlayer's network nonetheless, and in fact it seems like Softlayer is helping the spammer do listwashing.

March 1st, 2013 at 11:21am

Best ISPs like *Bluehost*? omfg you've got to be kidding. I have had several clients on Bluehost and FTP has always been a nightmare. Just last month I had to fix a new clients site who was hosting with Bluehost. The site was only 380mb but even with the site disabled it took 17 **hours** on my 100MB connection to download it.

As far as the other sites you discuss, it would make a world of difference if you actually said whether you'd reported them to the abuse dept. If not, then you're talking apples and oranges. More importantly, did you contact their actual provider (websitewelcome?). That ought to be included in your first step when reporting abuse.

March 1st, 2013 at 11:24am

This is great - your site is actually being hosted with websitewelcome, too, Franklin. Talk about the whole pot/kettle thing. I guess using the relationship you have with them already to help address the problem was lost on you?

March 5th, 2013 at 4:10pm

"Best ISPs like *Bluehost*? omfg you’ve got to be kidding. I have had several clients on Bluehost and FTP has always been a nightmare."

I'm talking about "best hosts" here in the context of hosts with the best response to spam and other issues, not with the best FTP. Bluehost consistently removes things like computer malware droppers and bank phish sites extremely quickly, typically within hours hours of an abuse complaint, rather than leaving them up for days or weeks.

"This is great – your site is actually being hosted with websitewelcome, too, Franklin. Talk about the whole pot/kettle thing."

Websitewelcome is Hostgator. I use them in part because of their prompt attention to spam, malware, and phish complaints; they established an excellent track record of responding to these issues quickly before I ever started hosting with them.

Again, the issue here as I see it is that Softlayer is dismally poor at securing their network and in taking action to shut down phish and malware sites when notified of them, often leaving such sites active for days or even weeks. I find that indefensible.

March 5th, 2013 at 5:29pm

Interesting point, Franklin. Based on your experience, how would you "secure" SoftLayer's network of self-managed servers and cloud instances? SoftLayer does not manage the content on our servers, and we have a team of representatives dedicated to investigating and taking action on abuse complaints when they are submitted.

In what way would you suggest we monitor the activity on a site that's hosted by a customer of a customer of one of our customers? When we receive a complaint, would you suggest we shut down our customer immediately if action isn't taken to stop the abusive behavior? If a reseller's shared hosting server houses a single spammer, would it be fair to the hundreds of other legitimate customers for us to disconnect the server when we get an abuse complaint about that single spammer? Or would you, as a customer of a hosting reseller, hope that we work with our customers (so that our customers can work with their customers) to get the abusive content removed?

As you'll note in several of the previous comments under this post, we're happy to help escalate concerns you feel have not been addressed in a timely manner. Just forward those abuse complaints to twitter@softlayer.com, and we'll look into them.

March 5th, 2013 at 6:29pm

"SoftLayer does not manage the content on our servers, and we have a team of representatives dedicated to investigating and taking action on abuse complaints when they are submitted."

I would expect the team of representatives to be quicker about dealing with abuse complaints, particularly with regard to phish and malware dropper sites. Leaving a bank phish or a ZeroAccess dropper active for days or weeks is bad policy. I don't know why you're so slow--whether it's a question of policy or procedure or simply understaffing--but when, say, a bank phish is active on your network for a week, you're potentially exposing many people to fraud. I'm sure the criminals responsible for these kinds of abuse appreciate it.

"In what way would you suggest we monitor the activity on a site that’s hosted by a customer of a customer of one of our customers?"

Not monitoring activity on such sites is one thing. Not responding to abuse complaints in a timely fashion is another. Other large hosting providers who deal with many layers of resellers and customers don't move so slowly, so it's possible.

Look, I know the kinds of volumes of email that abuse addresses get. I know the numbers of sites we're talking about. I know how hard (read: impossible) it is for end users to be educated to update their vulnerable copies of WordPress and Joomla. But if it takes weeks to respond to abuse complaints, something's wrong.

March 6th, 2013 at 10:15am

The concern is understandable. The challenge is that you're talking generally about the lack of abuse response (or delay in abuse response) based on specific example(s?) you've reported. If you can forward the examples to our social media team, we can escalate them to the abuse department managers to look into why those reports weren't handled quickly, and if we need to make changes to the way we prioritize or filter abuse messages, we're much better equipped to do so.

It's good to have an open dialogue about the most efficient ways to handle abuse, but it's difficult to continue the conversation when the primary concerns seem to be based on the sweeping generalization that SoftLayer abuse is slow in general because SoftLayer abuse was slow on specific occasions. To a certain extent, that position is based on confirmation bias.

March 6th, 2013 at 3:20pm

That's a fair point. The fact that some complaints are not acted on quickly doesn't mean that all complaints are, or that they always will be.

I am particularly sensitive to malware and phish issues because too often it seems to me that large service providers are so apathetic, understaffed, or both that they end up complicit in criminal behavior. The worst example of that I've ever encountered is a company called iPower Web. A few years ago, I discovered that a large number of sites hosted on their servers had been compromised through a gaping hole in their homebrewed Web control panel, and were being used to spread the W32/Zlob malware. Not only did they fail to take action against hacked sites, and leave the malware droppers in place, it took about sixteen months(!) for them to fix the security vulnerability...by which point more than 200,000 sites on their servers(!!) had been hacked and recruited to spread malware.

I'm not saying that Softlayer is anywhere near as bad, of course. That's simply an example of the sort of intractability and indifference I deal with almost every day, and I tend to be particularly upset by service providers who allow malware and phish sites to linger on their servers for extended periods of time. I don't think that iPower was actually acting with malice, but past a certain point any sufficiently advanced incompetence is indistinguishable from malice. Either way, it still benefits organized crime to the detriment of people who use the Internet.

I'm glad to see that you're willing to escalate problems like this, and that you seem to be proactive about dealing with this kind of abuse on your network.

Leave a Reply

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <pre>, <blockcode>, <bash>, <c>, <cpp>, <drupal5>, <drupal6>, <java>, <javascript>, <php>, <python>, <ruby>. The supported tag styles are: <foo>, [foo].
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
CAPTCHA
To prove you're a person (not a spam script), type the security word shown in the picture.
Image CAPTCHA
Enter the characters shown in the image.

Comments

June 25th, 2012 at 6:09pm

I've had the opportunity the last month or so to submit a number of tickets about a server migration (prompted by one of my servers being discontinued by SL). My CCI was installed on an unstable node and it was taking nearly half an hour to reboot, and was often completely unresponsive. I recognize that it's impossible to diagnose issues that affect reboots without actually rebooting the machine - so I made an effort to ensure permission was given right away.

This month I've submitted several tickets and responses to tickets providing *exacting* detail, particularly giving permission to perform operations like reboots and server changes within the initial ticket and multiple responses, and yet my tickets were delayed for hours, sometimes *days* because even given permission, the SL staff repeatedly asked for permission to do something, pushing my ticket back in the queue until I could come in and repeat myself.

When timeliness is an issue (and it has been), wouldn't it be better if staff were to spend an extra few seconds reading the ticket responses to see if permission has been granted already? Maybe you should just add a couple fields to the tickets that enable the customer to indicate if they authorize activities such as reboots and changes, and if necessary, a time window to perform them. Delaying these migrations by only a few days is going to cost me an extra $300. Thanks. :(

I've been with SoftLayer almost 10 years now - and while every once in a while there's an issue, I know it will *always* be resolved. This month has been one of the worst, but it *has* been resolved and I'm not able to move forward. SL has always done well to prove to me they care, but this is an issue that needs addressed. When permission is already granted, DON'T waste valuable time by asking me again. And again. And again...

June 26th, 2012 at 7:33am

Hello!

I have a genuine question - what should the victim of spam do when they're trying very hard to do things properly (send a polite complaint, include all headers, etc), and Softlayer just isn't stopping the spam?

I’m still getting spam from Softlayer. It’s coming from the same Softlayer IP, pushing the same weird “training”, and I’ve complained to abuse@softlayer.com 5 times this month alone.

What am I doing wrong? Shouldn't someone at Softlayer care about enforcing your own anti-spam policy?

June 26th, 2012 at 9:32am

Thanks for staying on top of this, David. I just got an update indicating this matter is resolved, and I'll be responding to the complaint you sent to Abuse with further information.

Regards,
Jennifer Groves
Manager, Abuse Department
abuse@softlayer.com

June 28th, 2012 at 6:43pm

When you parse the http://x-arf.org Reports automatically, you can build a fine score and forwarding all Reports when the score is under 500 points each ip/customer.
If the score to high:

ssh -> 100 points
mail -> 20 points
rfi -> 100 points
reported-from: xxx@trusted.tld -> 300 points

and the customer has received two or 3 warnings, block the ip/customer or create a abuse-ticket to recheck the reports and block them manually.
https://www.blocklist.de/en/search.html?as=36351

The Network from softlayer.com has outside a poor reputation and a lot of admins blocked your complete ip-range.

June 29th, 2012 at 9:14am

Shawn, I'm sorry we didn't see your comment earlier ... I just sent it over to the senior manager of technical support, and his immediate response was that he also wished there was a checkbox a customer could select to authorize whatever action needs to be taken. We've had complaints about the flip-side of your request as well, though: A customer says "you have my permission to do whatever you need to do" at the beginning of a ticket, and because the ticket kept going for a tangential reason, a tech could scroll back and see that permission, take action, and the customer gets upset that the permission wasn't intended to be valid for longer than the immediate approval.

Chris is going to follow up with his team after looking into your account, and he might send you a note as well. If you incur an additional cost as a result of the delays, let me know (khazard@softlayer.com), and I'll see if I can work with billing and support to make that right.

June 29th, 2012 at 10:11am

Thanks for the comment, blocklist.

While the route those admins took in blocking SoftLayer IP ranges is certainly an effective option when screening out abusive behavior, it might be heavy handed and limiting when you consider the thousands of legitimate customers and millions of legitimate websites that also resolve to a softlayer.com reverse lookup. Like the old idiom suggests, they're "throwing out the baby with the bath water." We can't change how admins choose to run their networks, but we can do everything in our power to run our network as efficiently as possible.

Because we don’t actively monitor or censor any content on any of the 100,000+ servers in our data centers for privacy/security reasons, we rely on abuse reports submitted by users. The "scenario" section of the "Fighting SPAM and Abuse on a Global Network" blog provides some context into how/why that setup works.

July 17th, 2012 at 7:48am

Hi Jennifer, Thank you for this blog, it's really informative. I have just logged a abuse report about one of the websites that you are hosting, and I look forward to hearing from your team.

Deirdre

August 28th, 2012 at 2:49pm

What is Softlayer's antispam policy on compromised Web sites, virus droppers, and spam sites hosted on servers belonging to The Planet?

It has been my experience that since you bought The Planet, abuse reports are entirely ignored. Even reports of security breaches on servers running in The Planet's IP space are ignored. Phish, spam redirectors, hacked WordPress sites...they all remain active on The Planet servers for weeks or even months, with repeated messages sent to abuse@theplanet.com going unanswered and the problems continuing.

Have you simply dropped the ball when it comes to responding to network abuse on ISPs you've bought, or is The Planet now your bulletproof spam hosting subsidiary?

August 28th, 2012 at 5:29pm

Hi Franklin,

Thanks for chiming in here. The social media team asked if you could forward any examples of complaints that haven't been addresses to twitter@softlayer.com when you posted the same concern on Twitter, and that's still going to be the best bet to getting your concern resolved. The Planet and SoftLayer merged in November 2010, and the SoftLayer abuse team (abuse@softlayer.com) investigates and takes action on all valid complaints on The Planet's legacy network as well as SoftLayer's network. In addition to this post (which speaks to the way SoftLayer customers should respond to abuse tickets) and the post we sent via Twitter (Fighting SPAM and Abuse on a Global Network), the first blog in this series (Reporting Abuse) could be helpful as well.

When you have an opportunity, we'd love to follow up on any abuse reports that you've submitted that haven't been addressed properly.

Thanks!

August 29th, 2012 at 10:12am

Hello softlayer

I'm one of the server owners there is very mad at softlayer abuse team, because I can see that IP's there have multiple abuse report's of lets just say ssh attacks are allowed to work and still attack people even when we are talking about there are 34 reports on that IP.

February 26th, 2013 at 8:48am

Hi Softlayer, I appreciate you addressing this topic with a blog post- I have posted an abuse report with your team from one of your hosted websites, this is the second time now, because of spam and I hope to hear back from someone soon.

February 27th, 2013 at 9:00am

Hi Jamie, In Jennifer's previous post about reporting abuse, she explains, "We work hard to investigate and resolve all complaints received however, due to volume, we typically do not respond to complaining parties." While you may not receive a response, that shouldn't suggest that we aren't taking action.

If the abusive activity persists, please feel free to forward the abuse report you submitted to abuse@softlayer.com to our social media team (twitter@softlayer.com), and we'll see if there's anything we can do to help.

February 27th, 2013 at 1:15pm

You'll forgive me if I remain unconvinced. My experience with Softlayer continues to be quite poor; it seems to me that Softlayer is still incredibly slow to act on phish sites, malware droppers, and actively exploited servers, often leaving them up for days or weeks after being notified of the problem.

For example, when the Web site datzwhatzup (dot) net was compromised, it was being used to spread the W32/ZeroAccess malware. A compromise of this type, like a phish page, should be a high priority. Yet the site remained infected and continued to spread the malware for more than a week(!) after Softlayer was notified of the problem.

To me, that is unconscionable. I realize that abuse teams are always understaffed because management sees the abuse teams as employees who cost money but don't generate revenue, but even so, to allow a serious security compromise that was actively being used to spread malware to remain on a server for a week or more is really, really bad. (By way of comparison, some of the best ISPs in the industry, such as Bluehost, will often take down phish sites and malware spreaders within an hour or two of being notified of the problem.)

It is also unfortunate that professional spam-for-hire outfits have taken up residence on Softlayer's network. For example, pushbuttonemailer (dot) com now lives on your network. This spam-for-hire site is advertised by means of link redirectors placed on other hacked sites. It plainly advertises spamming services and is spamming itself via a network of hacked sites, but has remained on Softlayer's network nonetheless, and in fact it seems like Softlayer is helping the spammer do listwashing.

March 1st, 2013 at 11:21am

Best ISPs like *Bluehost*? omfg you've got to be kidding. I have had several clients on Bluehost and FTP has always been a nightmare. Just last month I had to fix a new clients site who was hosting with Bluehost. The site was only 380mb but even with the site disabled it took 17 **hours** on my 100MB connection to download it.

As far as the other sites you discuss, it would make a world of difference if you actually said whether you'd reported them to the abuse dept. If not, then you're talking apples and oranges. More importantly, did you contact their actual provider (websitewelcome?). That ought to be included in your first step when reporting abuse.

March 1st, 2013 at 11:24am

This is great - your site is actually being hosted with websitewelcome, too, Franklin. Talk about the whole pot/kettle thing. I guess using the relationship you have with them already to help address the problem was lost on you?

March 5th, 2013 at 4:10pm

"Best ISPs like *Bluehost*? omfg you’ve got to be kidding. I have had several clients on Bluehost and FTP has always been a nightmare."

I'm talking about "best hosts" here in the context of hosts with the best response to spam and other issues, not with the best FTP. Bluehost consistently removes things like computer malware droppers and bank phish sites extremely quickly, typically within hours hours of an abuse complaint, rather than leaving them up for days or weeks.

"This is great – your site is actually being hosted with websitewelcome, too, Franklin. Talk about the whole pot/kettle thing."

Websitewelcome is Hostgator. I use them in part because of their prompt attention to spam, malware, and phish complaints; they established an excellent track record of responding to these issues quickly before I ever started hosting with them.

Again, the issue here as I see it is that Softlayer is dismally poor at securing their network and in taking action to shut down phish and malware sites when notified of them, often leaving such sites active for days or even weeks. I find that indefensible.

March 5th, 2013 at 5:29pm

Interesting point, Franklin. Based on your experience, how would you "secure" SoftLayer's network of self-managed servers and cloud instances? SoftLayer does not manage the content on our servers, and we have a team of representatives dedicated to investigating and taking action on abuse complaints when they are submitted.

In what way would you suggest we monitor the activity on a site that's hosted by a customer of a customer of one of our customers? When we receive a complaint, would you suggest we shut down our customer immediately if action isn't taken to stop the abusive behavior? If a reseller's shared hosting server houses a single spammer, would it be fair to the hundreds of other legitimate customers for us to disconnect the server when we get an abuse complaint about that single spammer? Or would you, as a customer of a hosting reseller, hope that we work with our customers (so that our customers can work with their customers) to get the abusive content removed?

As you'll note in several of the previous comments under this post, we're happy to help escalate concerns you feel have not been addressed in a timely manner. Just forward those abuse complaints to twitter@softlayer.com, and we'll look into them.

March 5th, 2013 at 6:29pm

"SoftLayer does not manage the content on our servers, and we have a team of representatives dedicated to investigating and taking action on abuse complaints when they are submitted."

I would expect the team of representatives to be quicker about dealing with abuse complaints, particularly with regard to phish and malware dropper sites. Leaving a bank phish or a ZeroAccess dropper active for days or weeks is bad policy. I don't know why you're so slow--whether it's a question of policy or procedure or simply understaffing--but when, say, a bank phish is active on your network for a week, you're potentially exposing many people to fraud. I'm sure the criminals responsible for these kinds of abuse appreciate it.

"In what way would you suggest we monitor the activity on a site that’s hosted by a customer of a customer of one of our customers?"

Not monitoring activity on such sites is one thing. Not responding to abuse complaints in a timely fashion is another. Other large hosting providers who deal with many layers of resellers and customers don't move so slowly, so it's possible.

Look, I know the kinds of volumes of email that abuse addresses get. I know the numbers of sites we're talking about. I know how hard (read: impossible) it is for end users to be educated to update their vulnerable copies of WordPress and Joomla. But if it takes weeks to respond to abuse complaints, something's wrong.

March 6th, 2013 at 10:15am

The concern is understandable. The challenge is that you're talking generally about the lack of abuse response (or delay in abuse response) based on specific example(s?) you've reported. If you can forward the examples to our social media team, we can escalate them to the abuse department managers to look into why those reports weren't handled quickly, and if we need to make changes to the way we prioritize or filter abuse messages, we're much better equipped to do so.

It's good to have an open dialogue about the most efficient ways to handle abuse, but it's difficult to continue the conversation when the primary concerns seem to be based on the sweeping generalization that SoftLayer abuse is slow in general because SoftLayer abuse was slow on specific occasions. To a certain extent, that position is based on confirmation bias.

March 6th, 2013 at 3:20pm

That's a fair point. The fact that some complaints are not acted on quickly doesn't mean that all complaints are, or that they always will be.

I am particularly sensitive to malware and phish issues because too often it seems to me that large service providers are so apathetic, understaffed, or both that they end up complicit in criminal behavior. The worst example of that I've ever encountered is a company called iPower Web. A few years ago, I discovered that a large number of sites hosted on their servers had been compromised through a gaping hole in their homebrewed Web control panel, and were being used to spread the W32/Zlob malware. Not only did they fail to take action against hacked sites, and leave the malware droppers in place, it took about sixteen months(!) for them to fix the security vulnerability...by which point more than 200,000 sites on their servers(!!) had been hacked and recruited to spread malware.

I'm not saying that Softlayer is anywhere near as bad, of course. That's simply an example of the sort of intractability and indifference I deal with almost every day, and I tend to be particularly upset by service providers who allow malware and phish sites to linger on their servers for extended periods of time. I don't think that iPower was actually acting with malice, but past a certain point any sufficiently advanced incompetence is indistinguishable from malice. Either way, it still benefits organized crime to the detriment of people who use the Internet.

I'm glad to see that you're willing to escalate problems like this, and that you seem to be proactive about dealing with this kind of abuse on your network.

Leave a Reply

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <pre>, <blockcode>, <bash>, <c>, <cpp>, <drupal5>, <drupal6>, <java>, <javascript>, <php>, <python>, <ruby>. The supported tag styles are: <foo>, [foo].
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
CAPTCHA
To prove you're a person (not a spam script), type the security word shown in the picture.
Image CAPTCHA
Enter the characters shown in the image.