Howdy, Stranger!

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

Advertise on LowEndTalk.com
Spam Attack
New on LowEndTalk? Please read our 'Community Rules' by clicking on it in the right menu!

Spam Attack

randvegetarandvegeta Member, Provider

We use Blesta on our VPSBit Billing System and we're getting a crazy SPAM attack of some sort.

Thousands of tickets, all with gibberish 'Subjects' and the content / body is all the same.

"Muchas gracias. ?Como puedo iniciar sesion?"

Unfortunately I can't make heads or tails of the Blesta ticket system and there are many limitations. The ticket system does not have/user captchas. Also, no IP logging for anonymously opened tickets. Our system is also apparantly now sending out spam as result as Blesta is sending out confirmation emails to all those newly opened tickets.

Managed to insert an IP logger to see if all these tickets were being opened by the same IP or group of IPs. Unfortunately it looks like each ticket is opened by a new IP. Each IP appears to be a public TOR exit node.

Anyone have any idea what the heck this SPAM crap is and how to block it?

Comments

  • Block the IP? Captcha? etc...

  • randvegetarandvegeta Member, Provider

    @Neoon said:
    Block the IP? Captcha? etc...

    The IP is different every time.

    I do not see any support for Captcha in the Blest ticket system.

  • @randvegeta said:

    @Neoon said:
    Block the IP? Captcha? etc...

    The IP is different every time.

    I do not see any support for Captcha in the Blest ticket system.

    Any pattern you could block? like same User Agent, method how this is going to be posted?

  • randvegetarandvegeta Member, Provider

    @Neoon said:

    @randvegeta said:

    @Neoon said:
    Block the IP? Captcha? etc...

    The IP is different every time.

    I do not see any support for Captcha in the Blest ticket system.

    Any pattern you could block? like same User Agent, method how this is going to be posted?

    I can easily write a piece of code that queries the database for known markers (content is always the same) and just auto delete. But that doesn't stop blesta from actually processing the ticket in the 1st place and sending off that confirmation e-mail. If I knew which PHP files were responsible for all these things, I could hard code some filters or other rules. But I cant really make heads or tales of the whole system. Seems very crazy to me.

  • @randvegeta said:

    @Neoon said:

    @randvegeta said:

    @Neoon said:
    Block the IP? Captcha? etc...

    The IP is different every time.

    I do not see any support for Captcha in the Blest ticket system.

    Any pattern you could block? like same User Agent, method how this is going to be posted?

    I can easily write a piece of code that queries the database for known markers (content is always the same) and just auto delete. But that doesn't stop blesta from actually processing the ticket in the 1st place and sending off that confirmation e-mail. If I knew which PHP files were responsible for all these things, I could hard code some filters or other rules. But I cant really make heads or tales of the whole system. Seems very crazy to me.

    Eh, blocking it at webserver level? You think way to complicated.

  • randvegetarandvegeta Member, Provider

    @Neoon said:

    @randvegeta said:

    @Neoon said:

    @randvegeta said:

    @Neoon said:
    Block the IP? Captcha? etc...

    The IP is different every time.

    I do not see any support for Captcha in the Blest ticket system.

    Any pattern you could block? like same User Agent, method how this is going to be posted?

    I can easily write a piece of code that queries the database for known markers (content is always the same) and just auto delete. But that doesn't stop blesta from actually processing the ticket in the 1st place and sending off that confirmation e-mail. If I knew which PHP files were responsible for all these things, I could hard code some filters or other rules. But I cant really make heads or tales of the whole system. Seems very crazy to me.

    Eh, blocking it at webserver level? You think way to complicated.

    What do you mean? What markers would you look for?

  • @randvegeta said:

    @Neoon said:

    @randvegeta said:

    @Neoon said:

    @randvegeta said:

    @Neoon said:
    Block the IP? Captcha? etc...

    The IP is different every time.

    I do not see any support for Captcha in the Blest ticket system.

    Any pattern you could block? like same User Agent, method how this is going to be posted?

    I can easily write a piece of code that queries the database for known markers (content is always the same) and just auto delete. But that doesn't stop blesta from actually processing the ticket in the 1st place and sending off that confirmation e-mail. If I knew which PHP files were responsible for all these things, I could hard code some filters or other rules. But I cant really make heads or tales of the whole system. Seems very crazy to me.

    Eh, blocking it at webserver level? You think way to complicated.

    What do you mean? What markers would you look for?

    As I explained, anything unique from this attack.
    Like User Agent, any pattern you can block with the webserver.

  • randvegetarandvegeta Member, Provider

    @Neoon said:

    @randvegeta said:

    @Neoon said:

    @randvegeta said:

    @Neoon said:

    @randvegeta said:

    @Neoon said:
    Block the IP? Captcha? etc...

    The IP is different every time.

    I do not see any support for Captcha in the Blest ticket system.

    Any pattern you could block? like same User Agent, method how this is going to be posted?

    I can easily write a piece of code that queries the database for known markers (content is always the same) and just auto delete. But that doesn't stop blesta from actually processing the ticket in the 1st place and sending off that confirmation e-mail. If I knew which PHP files were responsible for all these things, I could hard code some filters or other rules. But I cant really make heads or tales of the whole system. Seems very crazy to me.

    Eh, blocking it at webserver level? You think way to complicated.

    What do you mean? What markers would you look for?

    As I explained, anything unique from this attack.
    Like User Agent, any pattern you can block with the webserver.

    The only I think I'm tracking at the moment is the IP. I can track the user agent... but I need to make sure legitimate traffic also doesnt get filtered. Need to think what else I can use to identify the user, from connection alone. It's easier if I could just use the content they submit, but by the time they submit, it's already been processed by Blesta.

  • jarjar Provider

    Disable those auto replies asap. Most important is to mitigate the damage it can do to your domain rep.

    Thanked by 2Falzo randvegeta
  • First, disable the response e-mail in the ticket system until you have this resolved -- this will remove at least 70% of the motivation of this attack, as generally the intent is both to cause you annoyance and get your outbound IPs blocked by e-mail services to cause additional hardship for you. Once you have that disabled, then you probably want to investigate the logs for the system and see if there are any common user agents or something in the logs that you can sort the users by, if you are using nginx in front you should be able to use those markers to create a map where you can use an if statement to evaluate the selected 'marker' as you referred to, usually the user agent is a good one.

    That is of course assuming they are doing this through the web site, there really wouldn't be any good way to stop this if they are just sending you large amounts of e-mails which are entered as tickets.

    my 2 cents.

    Cheers!

    Thanked by 1Falzo

    Have an Allwinner H3 device? Check out H3Droid! | Lichee Pi Zero - The 6$ SBC | #SYSarm - Get It! | Armbian | Atomic Pi Mirror
    22+ Years IT Experience in Linux/Windows Hosting, Administration and Development Services

  • seriesnseriesn Member, Top Provider

    Put it behind cloudflare and enable under attack mode. That usually presents everyone with an initial captcha. Should help till you figure out what's going on.

    Thanked by 1lentro
  • NyrNyr Member

    As an immediate fix, you can easily ban every Tor exit node at the webserver or network level:
    https://www.dan.me.uk/torlist/?exit

    After that, can't you implement a captcha?

    Thanked by 1PUSHR_Victor
  • PUSHR_VictorPUSHR_Victor Member, Provider

    ^ This.

  • NeoonNeoon Member
    edited November 19

    Yea good idea, to check what kind of IP's, so you know if its TOR or something else.
    In case its just TOR IP's block the exit's.

  • SplitIceSplitIce Member, Provider
    edited November 19

    @randvegeta If you need a quick solution we offer a target for a layer 7 rule that adds a captcha after form submission (designed for anti spam)

    Just a suply a rule matching the form submission recevier and set the target to anti spam (example exists in KB).

    We have used it ourselves for ticket spam.

    X4B - DDoS Protection: Affordable Anycast DDoS mitigation with PoPs in the Europe, Asia, North and South America.
    Latest Offer: Brazil Launch 2020 Offer
  • pphillipspphillips Member, Host Rep

    @randvegeta said: The ticket system does not have/user captchas.

    The ticket system in Blesta allows CAPTCHA's for non-authenticated clients as of version 4.12. This impacts web based tickets, and obviously has no affect on imported email tickets. If it's related to emails, you should filter your email before sending it through to Blesta.

    Thanked by 1randvegeta

    Paul from Blesta.

  • randvegetarandvegeta Member, Provider

    Soa> @pphillips said:

    @randvegeta said: The ticket system does not have/user captchas.

    The ticket system in Blesta allows CAPTCHA's for non-authenticated clients as of version 4.12. This impacts web based tickets, and obviously has no affect on imported email tickets. If it's related to emails, you should filter your email before sending it through to Blesta.

    Its not email imported.

    Perhaps you can direct me to the file where I can insert a bit of code to read the 'body' of the ticket so I can check if it matches some known spam text, and just ignore it instead of actually opening a ticket?

  • stefemanstefeman Member
    edited November 20

    Put behind cloudflare and make a cloudflare firewall rule for country code and choose "Tor".

    Or just add this rule to cloudflare to block tor.

    block
    (ip.geoip.country eq "T1")
    
  • @stefeman said:
    Put behind cloudflare

    Thanked by 1brueggus
  • CSF.blocklists --> TOR

    Long live LowEndInfo.com

  • randvegetarandvegeta Member, Provider

    In case anyone is interested, the user agent appears to be different every time, but each time, appears as any other legitimate browser. So filtering by agent is not really possible.

    However, I was able to find other means to easily detect the junk traffic, and have now seem to be blocking it with 100% effectiveness so far. We'll see how it goes.

  • @randvegeta said:
    In case anyone is interested, the user agent appears to be different every time, but each time, appears as any other legitimate browser. So filtering by agent is not really possible.

    However, I was able to find other means to easily detect the junk traffic, and have now seem to be blocking it with 100% effectiveness so far. We'll see how it goes.

    Well, I'm too late, but curious if you could rename the url in case that was hardcoded into the attack and then they'd get 404's but anyone who followed your website would correctly find the new url?

  • randvegetarandvegeta Member, Provider

    @TimboJones said:

    @randvegeta said:
    In case anyone is interested, the user agent appears to be different every time, but each time, appears as any other legitimate browser. So filtering by agent is not really possible.

    However, I was able to find other means to easily detect the junk traffic, and have now seem to be blocking it with 100% effectiveness so far. We'll see how it goes.

    Well, I'm too late, but curious if you could rename the url in case that was hardcoded into the attack and then they'd get 404's but anyone who followed your website would correctly find the new url?

    Theoretically this could be possible. Just delete the ticket department and create a new 1.

    Thanked by 1TimboJones
Sign In or Register to comment.