wolstech

Sort of. They use a botnet (hence the first D, "distributed", in DDoS), so the connections come from random IPs making a conventional firewall useless. We do already restrict too many connections from an IP during these attacks, which helps, but they just bring more/different bots instead. The firewall uses quite a bit of resources to detect and refuse these connections too. A hardware firewall appliance would be more efficient here. The actual attack method varies. One method (was used on Johnny) entails wasting server resources by opening a ton of connections and just leaving them open all day without closing them. This causes the server to leave Apache processes open waiting for the content of their request that never comes. The connections do eventually time out, but the attacker just reopens the connections when that happens. This means decreasing the max connection time actually increases load (process for timed out connection closing, and new process for replacement connection starting), making it useless as a mitigation. The second is request flooding. In that method, they just send requests for a targeted website over and over again as fast as possible, which results in the server using its resources to fulfill these requests over and over again, leaving it little time for legitimate requests to be processed. Consider that a typical request involves: Apache receiving the request and finding the file, then launching PHP. PHP then runs the script in the file, which often asks MySQL for data. PHP then sits there in memory waiting for that data, then when it gets it, uses that data, finishes its script and returns a webpage to Apache to send out. Doesn't seem to bad when you're handling a few hundred at a time, but when you want to suddenly do 1 million of them concurrently, it becomes an issue...the server gets backlogged, and/or runs out of memory and crashes. This also often manifest as invalid requests or junk packets with no or useless data being sent...these aim to clog up the network as opposed to waste the CPU's time. This is what I believe was happening on Tommy. The result is the same: legitimate requests cannot get through and the websites on the server get slow or go down.

Done. You should now be able to log in and your website should be working again.

All Johnny accounts are intentionally disabled due to maintenance. Please see https://www.helionet.org/index/topic/33812-johnny-maintenance/

Your account was archived because you haven't logged in for quite a while. We have a limited amount of space on our servers, and occasionally we have to remove the unused accounts to make space for new users. To prevent your account from becoming archived again please remember to log in at https://www.heliohost.org/login/ at least once every 30 days. Unarchiving...

The account calbet has been merged with zavyerr, and the email address has been updated.

The other username is already taken by what appears to be an older account of yours (it's from December 2016 and has the same profile picture). If that's yours, please post from that account to confirm you own it and I'll merge everything together into one.

Invite sent.

Invite sent.

You have to unpack the backup and manually restore everything anyway. You can't upload the backup and have the server automatically restore it. The major change will be your database users and database names, because the main account's username is different.

They don't care about us They just get upset because they aren't allowed to phish here.

It counted. The 2FA is just incompatible with our login tracking system. Not sure whether Krydos can fix that or not...

There is no local network. All of our equipment faces the internet directly, a lot of things just so happen to have consecutive IPs because we bought the IPs as a group. Every single IP we have is publicly routable.

Have you tried this? I need to know if this works or not. If it does, 2FA is to blame. If it does not, our website is just broken.

That account cannot be unsuspended because it was involved in a hacking attempt. Normally I'd send you an invite, but we can't create new accounts right now because of this issue: https://www.helionet.org/index/topic/33857-home1-unavailable-on-tommy/ Once that's fixed, I can send you an invite for a new account.

It's caused by this: https://www.helionet.org/index/topic/33857-home1-unavailable-on-tommy/ When that issue gets fixed, this will be too. Everyone with an account created after mid-April is likely seeing this, which is basically everyone who had to deal with AnonymousFox, and all the new users since that time.

You weren't blocked when you made your request so I couldn't unblock you.

@sagnik: Nope. The /home1 volume (which contains his home folder) isn't mounted for some reason. He wouldn't even be able to get to an htaccess file because as far as the server is concerned, his home folder is missing. Most users with an account created on or after April 19th 2018 probably have an account with their home folder on /home1...the /home1 was the added space from our NAS purchase. It probably dropped offline due to the DDoS traffic or the null routing yesterday and just needs to be remounted. The bad news is I don't know how to do that, which is why we're waiting for Krydos...

It counted that time. Try logging in using the https://heliohost.org/login/ page now, leaving 2FA disabled. If it works, the 2FA is incompatible with our system.

Didn't count...which did you use? https://heliohost.org/login/ or https://tommy.heliohost.org:2083/ ? Did the main cPanel page you ended up at end with .html or .phpcp? Also, can you remove the 2FA from your account and log in again?

Yes

All of that is caused by the DDoS. Specifically, the attack caused /home1 to unmount (it's a network volume, so most likely the traffic and subsequent null routing caused the NAS to disappear from under it and the server dropped the volume). Krydos needs to determine if that's the case and remount it. That issue is open over here: https://www.helionet.org/index/topic/33857-home1-unavailable-on-tommy/ While that's broken, any account whose home folder is on /home1 is effectively useless. In addition, it's impossible to create a new account on Tommy since all new accounts currently go on /home1.

It's the anonymousfox hack that many others were impacted by. I can't fix it at the moment though since /home1 isn't working and your invite will just fail if I send it. Once that issue is fixed, you'll receive an invite for a new account.

I can't check because your login date is set to the future and the script will never move it backwards. Let me set it back a few days... EDIT: Go ahead and log in again now. Leave your 2FA on. I moved your date to 7/30, and it should move to today if its working. Let me know when you're done and I'll check it.

The Johnny attack we believe was done as retaliation for ruining a phisher's opportunity to mass-phish on a brand new TLD. It started right after a week or two that involved banning 150+ very similar paypal phishing sites that kept being registered on the new .ooo TLD. We were getting 10+ new ones per day and I was banning them within hours of them being set up. We have no motive for Tommy at the moment, though it could be retaliation for the very quick cleanup of AnonymousFox. We thought initially that it was the same attacker as Johnny, just moving targets after Johnny went out for maintenance, but the actual type of attack is different, so that's unlikely. In addition, the Tommy attack subsided, whereas Johnny's was nearly continuous for 3 weeks and ended with the server being put out for maintenance... My last post on the first page of this topic is a good read: https://www.helionet.org/index/topic/33824-tommy-server-down/ (note that this was written during the attack, the Tommy attack has since subsided)

I figured this out...it's related to /home1 being unavailable. /home1 is the home folders stored on our NAS. I picked several sites, and all of them kept on /home1/<username> are affected. Krydos needs to fix it.