Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


abuse report is dead ?
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

abuse report is dead ?

Well its not a big deal, but recently i'm receiving many bruteforce attack for smtp and other ports attack from reputable provider such as digital ocean, hetzner. Its annoying for my log server, especially if they do repeatly and i report to the provider but seems i don't receive any reply. Do you have same situations ? or any suggestion ? Thanks.

«1

Comments

  • jarjar Patron Provider, Top Host, Veteran
    edited October 2019

    Large providers receive as many as thousands of reports like this per hour thanks to people who configure fail2ban to report every failed login in an email, and it makes it very difficult (if not impossible) for them to hire enough humans to reply to every one of them. They very likely do use your complaints in some fashion, but understand that brute force is a lower priority over copyright complaints, CP, spam, etc.

    Keep sending your complaints, but change your expectations of hearing back. Abuse on the internet is simply too high for there to be enough trained humans to talk about each occurrence. Humans can't compete on a 1:1 ratio with the automation that is being used to execute the attacks at any reasonable scale.

  • Yeah you are right, but at least they know if one of their customer is abusing their services especially with behaviour create, attack and destroy some container. Can't expect too much lol.

    Thanked by 1jar
  • jarjar Patron Provider, Top Host, Veteran
    edited October 2019

    @logaritse said:
    Yeah you are right, but at least they know if one of their customer is abusing their services especially with behaviour create, attack and destroy some container. Can't expect too much lol.

    Yeah to give you some insight: The larger providers don't just have more IP space and therefore more compromised servers, they're also more highly targeted by extremely skilled individuals with malicious intent. You might see the same trend and think "Well that's the same customer, why don't they just terminate them?" But on the other side it may look more like 16,000 customers each with their own seemingly legitimate identity with different addresses, credit cards, sign-up dates, and matching residential IP addresses to go with each identity (thanks IoT devices!).

    Many people with malicious intent are extremely skilled, highly automated, and only predictable for short periods of time between identifying their patterns and them changing their patterns. Running a legitimately large service provider is not just equivalent to running a smaller one at greater scale. You'd think it would just scale in a linear fashion with number of users, but instead it skyrockets in very unique and hard to track ways when you reach a certain size. Meanwhile, you've got these thousands of fail2ban emails coming in every hour and you're trying to track these trends and patterns for larger issues while also handling regular abuse complaints.

    I would often have people furious with me because "I've reported this spam email to you 10 times now, why won't you just terminate the client?" I'd have to tell them "I have. In my eyes I've terminated 10 clients that had no clear relation to each other until you reported them to me." After so many reports I'd catch the pattern and preemptively kill the accounts for a week. Then they'd change their pattern. I'd build scripts to find them, devoted my life to hunting them for weeks at a time.

    Helping with abuse @ DO was an interesting time that nothing else prepared me for, and the scale of it couldn't have been assumed based on any prior experience. Let's just say that team deserves unlimited beer.

  • How to see who tried to log in my VPS? Ubuntu 18.04

  • loeloe Member
    edited October 2019

    @Jar likely said the truth.

    tl;dr: yes, abuse report is dead

  • I contend that there's a lack of willingness on provider's part to do anything about it.
    Analogous to a catalytic convertor, the source of the issue isn't being tackled. There's plenty of 'talk' with regards to DDoS mitigation for incoming packets but sod all done to stop activity from internal sources.

  • @RedSox take a look at /var/log/auth.log - for example:

    sudo grep "Failed password" /var/log/auth.log
    

    @AlwaysSkint said:
    Analogous to a catalytic convertor, the source of the issue isn't being tackled.

    I am as intrigued as I am ignorant specifically with regards to the finer points of the metaphorical catalytic converter ... that is to say, I don't quite understand the analogy? (Just curious what you mean about root cause.)

    Thanked by 1RedSox
  • AlwaysSkintAlwaysSkint Member
    edited October 2019

    @uptime
    The twisted idea to add a cat. to reduce exhaust emissions (notwithstanding the radioactivity/disposal) would be much better addressed by more efficient combustion. Tackle the problem at source, not by adding a sticky plaster to the fault.

    There has to be some mechanism that picks up on these broadcast network packets and blocks them at source. CSF manages to scan syslog to see incoming packets, surely a similar approach can be taken on packets traversing routers/bridges et al. Does voxility, for example not just interrogate incoming packets for abusive activity - apply similar to internal networks.

    Thanked by 1uptime
  • Working at security dept of some provider and could tell it's quite difficult to react to all the abuse reports, especially those auto generated, which we just bulk delete and even blacklist some senders. Can precisely confirm a jar's point.

    Thanked by 1jar
  • JordJord Moderator, Host Rep

    I sent an abuse email to OVH once, It's been 2 years and I'm still waiting for a reply. I will tweet Oles soon to make sure someone replies to me.

  • Abuse reports are overused by automated messages. This IP was reported by fail2ban - so what? Secure your vps instead of expecting someone will kill client because of single report.

    Thanked by 1legalstuff
  • AlwaysSkintAlwaysSkint Member
    edited October 2019

    Looks as though I'm at a polar opposite to some of these comments. Nothing unusual .:-/
    Many provider's ToS categorically state no scanning/malicious activity etc. but do little/nothing to prevent/monitor/ban the practice. Automation: little human interaction required.

  • uptimeuptime Member
    edited October 2019

    Automated abuse reports as a potential DDoS vector?

    Discuss.

    Thanked by 2jar legalstuff
  • jarjar Patron Provider, Top Host, Veteran
    edited October 2019

    AlwaysSkint said: There has to be some mechanism that picks up on these broadcast network packets and blocks them at source

    At the provider level this is dangerous on at least three levels. First it requires such physical overhead at scale that it could damage your chance at being competitive, and if you don't have customers then you don't need it anyway (and the company not doing it gets the customers, thus circular and solving nothing). Second, inspecting packets of all outbound traffic for all customers would receive the most incredible pushback from customers and possibly even media outlets and government, if the provider is of reasonable size. Third, you'd need to continually have humans inspecting the traffic (violating privacy) to adjust the systems to the new trends, as bad actors don't simply throw their hands up and say "good game" but instead they adjust or create new botnets that solve the problem of being filtered.

    It's a lot easier to theorize than it is to implement. Customer privacy is a thing. All of that seems like a lot to go through just because someone else is afraid their server might get brute forced (which they can and should protect against).

    Thanked by 2legalstuff ralph
  • AlwaysSkintAlwaysSkint Member
    edited October 2019

    @jar You're not telling me that incoming packets aren't inspected (excluding at the content level) already by (nearly) all providers? That's how a firewall works; SPI. Apply the same to internal and outbound packets, using existing hardware/software.

    [On the subject of privacy.. I block my ISP TalkTalk from my servers, after discovering they (TT) scan my VPSes after I visit them through ssh or a web client. That's me using OpenDNS rather than the ISP DNS and so-called Child Protection turned off. No packet inspection? Aye, right.]

  • jarjar Patron Provider, Top Host, Veteran
    edited October 2019

    AlwaysSkint said: You're not telling me that incoming packets aren't inspected (excluding at the content level) already by (nearly) all providers? That's how a firewall works; SPI. Apply the same to internal and outbound packets, using existing hardware/software.

    Correct, this requires a hardware overhead that would have to be passed on to customers. Passing on such a high cost to customers for the sole purpose of having their privacy violated would result in all of the customers going to a company that didn't do that, which means that it solves nothing.

    No provider is logging your packets (if for no other reason than it would cost them too much money), and no one is staring at a monitor watching them like a scene from the matrix ;)

    A shared router running at the capacity of any large provider cannot handle the excessive overhead of logging everyone's packets.

    Thanked by 1AMXRT
  • AMXRTAMXRT Member
    edited October 2019

    @AlwaysSkint, aren't you, by any chance, affiliated with a Russian government?

    Thanked by 1AlwaysSkint
  • AlwaysSkintAlwaysSkint Member
    edited October 2019

    I wasn't suggesting to use wireshark (or similar) to visually inspect packet content. Packet type, Port and source/destination is enough, as per current firewall rules. This doesn't go into the realms of privacy.

  • jarjar Patron Provider, Top Host, Veteran
    edited October 2019

    AlwaysSkint said: I wasn't suggesting to use wireshark (or similar) to visually inspect packet content. Packet type, Port and source/destination is enough, as per current firewall rules.

    Then how would you catch the trends to stop them? Just block all outbound traffic? Ok, let's theorize on this:

    Option 1: One provider blocks outbound traffic on port 22 to prevent SSH brute force attacks from leaving their network.

    Result: Customers go to a company that doesn't do this, because it's unreasonable and punishes everyone. Now the attacks come from that provider, will they pass their customers to the next to satisfy this, or call you crazy and not do it?

    Option 2: All providers block outbound traffic on port 22 to prevent SSH brute force attacks from leaving their network.

    Result: Default OpenSSH port changed from 22 by all major distros.

    If you're talking about more conditional configurations, then you're again asking for the router to act as a filter with rule sets that have to be identified by receiving complaints, having humans inspect the packets, and then create rules which take physical resources to manage. After enough of those have been created due to continual workarounds by bad actors, your router can no longer handle it and you now need an additional system in each rack that has the sole purpose of managing the filters. Oh, and oops you've broken 16 different use cases that were important to 1600 customers and now you need to hire a team to receive those complaints and review them for potential whitelisting. Now you've increased the cost of tenancy in that rack. Keep doing it long enough and your customers go to someone who isn't constantly causing problems for their traffic by heavy handed filters, isn't charging them an increased cost for something that they don't feel is a problem, or hasn't outsourced their support team to the lowest bidder to pay for it. Now, you've just shut down one ISP and everyone moved to the next one that isn't doing this, so you've solved nothing.

    Welcome to the internet. It's a dirty place.

  • @logaritse said:
    Well its not a big deal, but recently i'm receiving many bruteforce attack for smtp and other ports attack from reputable provider such as digital ocean, hetzner. Its annoying for my log server, especially if they do repeatly and i report to the provider but seems i don't receive any reply. Do you have same situations ? or any suggestion ? Thanks.

    I report to those providers daily. Hetzner did forward (at least some of) my reports to their customers who sometimes gave me a CC when replying to Hetzner. I don't know about how Digital Ocean handles my reports, but I do receive lots of port scans from their IPs (993 yesterday).
    After reporting like this for years, I know I won't receive any reply most of the time. Providers are busy. I just want to let them know what happened in their network. It's their call to do something (or nothing) about it.

  • AlwaysSkintAlwaysSkint Member
    edited October 2019

    psuedo-code:

    If TCP out = port 22 and packets > 10/s then REJECT
    If dest = ..*.255 and source !gateway then REJECT

    Some provider's block outbound email by default - just saying.
    I've made all my points; take it as you see fit.
    /end

  • @AlwaysSkint said:
    If TCP out = port 22 and packets > 10/s then REJECT

    wouldn't this block outgoing scp ?

    Thanked by 3jar AMXRT FlamesRunner
  • jarjar Patron Provider, Top Host, Veteran
    edited October 2019

    @uptime said:

    @AlwaysSkint said:
    If TCP out = port 22 and packets > 10/s then REJECT

    wouldn't this block outgoing scp ?

    Now you’re hiring a support team to answer why people can’t rsync lol

    It’s so easy to theorize about all this stuff from the perspective of never having dealt with it. That’s not an insult to anyone, I get it. I’ve been there. I never imagined why people don’t do these things until I found myself dealing with things at large scale. So now I share what I learned.

    Thanked by 3uptime AMXRT ralph
  • AlwaysSkintAlwaysSkint Member
    edited October 2019

    @uptime said:

    @AlwaysSkint said:
    If TCP out = port 22 and packets > 10/s then REJECT

    wouldn't this block outgoing scp ?

    If the idiot is still using port 22 for scp, then well deserved. ;)
    //end

  • AMXRTAMXRT Member
    edited October 2019

    There's a lot of controversy here...

  • uptimeuptime Member
    edited October 2019

    @AlwaysSkint said:
    If the idiot is still using port 22 for scp, then well deserved. ;)
    //end

    Um ... if you could please explain to me - even as if I were perhaps some kind of idiot :trollface: - what's wrong with using port 22 ? It is a standard port after all - and I don't always have the option to change it. Am I missing something obvious here, or what ...?

  • nc

    Thanked by 1uptime
  • uptimeuptime Member
    edited October 2019

    @AlwaysSkint said:
    nc

    cancel, chargeback, review ... next.

    Thanked by 1angstrom
  • @AlwaysSkint said:
    nc

    You lost that one. Better luck next time

  • AlwaysSkintAlwaysSkint Member
    edited October 2019

    @angstrom said:
    You lost that one. Better luck next time

    Nah, just couldn't be assed stating the f'kin obvious, even if uptime was just being the Devil's Advocate. Got other things to do today

    Thanked by 1uptime
Sign In or Register to comment.