DDOS BOT activity

[Yahalimu]

Nope, doesn't work on present version.. Excellent.

[ecartz]

I thought we had CSRF ?
Maybe it's on the admin side only.

CSRF is on all POST forms admin or catalog. It started on catalog and was added to admin more recently.

The problem might be that buy_now is a GET request.

Also, I don't think that GETs allow multiple buy_now events from the same URL by default. That may be something that Ian enabled for his shop at some point. Or maybe something in 1.0.5.0 -- my memories of what changed since then are getting hazy. Looking, this shouldn't have worked since actions were introduced in their own directory, which was well before 1.0.5.0.

[MyGamesShop]

From reading stuff off the internet I have deduced, this does not make me any kind of expert.

Good-luck, This is a SYN attack. There is little to nothing you can do.
I have banned 100s of thousands of IP addresses to find the controllers. I am now down to maybe 50 block bans per day not thousands as before, taken 6 months, 3hrs everyday. The last now probably part of the headless botnet.

As I'm in Australia it was easier for me as as I don't sell overseas. In the final stages I was inundated with Ukraine/Russian IP's to ban then all went very quiet. (Not pointing the finger here)
You can easily tell the SYN ones they only click once mostly hitting a valid product or sort order, (this is so you cant tell them from shoppers).
Entry time and last click is the sames even tho online time shows 10's of minutes. (But don't ban these ip's as they probably are from a spoofed valid customer range) You need to check manually.. easy if its from a country you don't sell to, a flag would help see below.

As the IP is spoofed, you just helped DDos'd the faked IP (Poor Brazil). There was no real person to send back that ACK.

But likely there would be a monitoring site IP's to see if your still up periodically. If you start banning you will suffer a bigger flood, making it seem worthless, as if it wont end.

Pay attention to the ones that have been on the site for over an hour, use who-is and CIDR to IPv4 website to calculate blocks, disable IP6 if you have that option.

Maybe phoenix developers could add a daily TRUNCATE at chosen hour to clear the SESSION table overnight to help, for those who choose to use it.

Also maybe add a lazy add country [Flag] image on the who's online page for us.

The cloud-flare solution will add a bit more overhead to your site processing instead of just returning a few ACK bytes.
Seeing 1000's of invalid customers is hard to ignore tho, and being used to ddos with the ACK feels dirty.
The cloud-flare solution does not make the problem go away it just hides it from your view.

I find with one of my suppliers website who uses cloud-flare to be very annoying (But a great advert for cloud-flare, again feeling dirty?). But you need to weight this against block banning your actual customers.....

This is a limitation of TCP and unlikely to ever change.

https://cybersecuritynews.com/syn-attack/
https://www.cloudflare.com/learning/ddo ... os-attack/
https://gbhackers.com/l7-ddos-botnet/

As I host my own stuff I will be adding a OPNsense firewall that has
Anti DDOS DDoS protection using SYN cookies and GeoIP Blocking.
This like Phoenix is Open-source at its best.

[ecartz]

Maybe phoenix developers could add a daily TRUNCATE at chosen hour to clear the SESSION table overnight to help, for those who choose to use it.

That particular solution would require configuration on the host outside the CE Phoenix Cart application. Typically either cron or some kind of equivalent for the database software.

It's worth noting that there is already code to remove older sessions in the application. If it is not working, you may want to check three PHP settings:

session.gc_maxlifetime = 1800
session.gc_probability = 1
session.gc_divisor = 100

I put what I believe are the default values there. That would remove every session older than half an hour with a 1% chance every time a session is started. If you want to keep sessions longer, increase maxlifetime. You can make this run more frequently by increasing probability or decreasing divisor. Less frequently by increasing the divisor (probability cannot be less than 1). None of those values should be 0 in the actual configuration.

[frankl]

I read this thread earlier today, then checked my sessions table.

Over 4 million records in the session table in one month! It was massive, nearly 4GB. Looks like my server setup wasn't letting Phoenix core delete sessions.

Attached is a small hook to delete sessions older than 1 week old from the database. DO NOT USE IT BEFORE RUNNING THE INDEX CREATION BELOW ON YOUR DATABASE or you will run in to all sorts of hell

Code: Select all

ALTER TABLE sessions ADD KEY idx_expiry (expiry)

Session Expiry.zip

What the hook does is run this query on every page load.

Code: Select all

DELETE FROM sessions WHERE expiry < UNIX_TIMESTAMP(NOW() - INTERVAL 7 DAY)

You may want to run the query directly on your database during downtime for the first time.

[MyGamesShop]

Thankyou Frankl, ecartz I will update my php config as advised if its not looking like that already.

Just for fun.. here is my screenshot today: Can you find the suspect?

[MyGamesShop]

Just letting you know the PHP settings cured the large session db issue.
With the added benefit... of automatically logging me out after inactivity.

This should be in the Phoenix documentation in set-up, which I probably missed somewhere.
Bots still there, but this issue for me is solved.

Thanks

[ArtcoInc]

frankl

How can this query be modified to run on an older site that does not have hooks?

TIA!

Malcolm

[burt]

v1.0.3.0 has hooks. Just not to the degree of modern versions of Phoenix.

You'd need to change the query to a `tep_db_query`
and probably just put it into an admin side hook

I haven't tested but this is the general idea.

This might as well just run when you're in admin

Code: Select all

hook_admin_index_session_expiry {
  public function listen_injectSiteEnd() {
   tep_db_query("DELETE FROM sessions WHERE expiry < UNIX_TIMESTAMP(NOW() - INTERVAL 7 DAY)");
  }
} 

and obviously save the file into the appropriate place, based on that first line of code;
/includes/hooks/admin/index/session_expiry.php

If that does not work, change `index` to `siteWide` in both the code and the file location.

[MyGamesShop]

https://perishablepress.com/ultimate-ai ... via-apache
Instant fix! I can see no downside.

You will need to edit this a bit for Phoenix to access some Admin areas like Images and Database etc.
https://perishablepress.com/8g-firewall/#download