---

You have all been very nice not to nag me about the sluggishness fo the site in the recent period. I posted a short message about this in the shoutbox but will make a more formal post now.

The sluggishness is partly due to frequent attampts to hack the site. There are attempts to run code on the site or to upload or install rogue scripts first. Hackers try to run non-existing scripts or abuse existing scripts to gain access to the server. Especially when they try to abuse existing scripts it can lead to a heavy load on the server when it tries to execute them as genuine queries. Compare it to asking the finance department for a copy of invoice 876-7656-B15 while it does not exist. The finance department has no reason to assume it does not exist and soon everyone is searching for the original, at the same time dropping their regular work. That is when you have to wait and wait and wait for the department to resume their ordinary duties. [In the past the site was similarly slow when searchbots tried to index the site from garbled links.]

I have looked through the server's access log of the last 24 hours and have indentified more than 20 attempts to hack the server. One of these was a very serious attempt, lasting almost three mintes, several others were shorter script that were run to test the server for vulnerabilities. All the relevant IP's were blacklisted. IOn addition to these more that 20 IP's there were more that 50 probes to see if the site ran on one or other version of wordpress (which it does not). Luckily these probes were limited to just one or two requests that were not satisfactorily answered and the probes stopped.

While wading through the log I stumbled accross some strange page requests which I assume for now have to to with attempts to spam the site. These requests used the same method as described above ('the copy of the non-existing invoice method') and I expect that those requests also slowed the site down quite frequently. The culprit's IP's were also blacklisted.

I will scan the log frequently now, especially when I notice the site is sluggish. Hopefully I can keep the inconvenience cause by these rogue visitors limited.

---

Hi Paul, thanks for the information.
I know these problems and I commiserate with you!

Greetings Eric

---

I've noticed the load at times. I often wonder if someone is trying to brute force accounts. i don't know which forum software is used and it shouldn't be discussed here. Usually, forum software is well-coded but often has vulnerabilities. Updating software is best to close known vulnerabilities. Server-side protection is of utmost importance including load-balancing.

I use randomly generated csrf tokens with all of my post data. I'm building a website which is nearly complete. I don't know why forum developers do not implement csrf more often. I use a main index file and all other requests are ignored. Too bad forum developers aren't keeping up with security designs.

---

Thanks for the information, Paul.
We all face such attempts, more or less sophisticated.
In my experience, looking at the logs is useful and necessary, in particular at the SQL error logs (which show how the attacker attempts to gain access).

---

Unfortunately many hacking attempts come from botnets and the next one will be from an IP address you have never seen.

---

I use csrf tokens with post forms but they require restrictive xss coding to work.
function code:


$salt = bin2hex(random_bytes(32));
$key = bin2hex(hash_hkdf('sha3-512', $secret, 0, $info."\0".$ttl, $salt));
$token = join('-', [$salt, $key, $ttl]);
return $token;


my original token lacked the joining method, which was corrected by a security expert.
the secret is stored as a session variable for reconstruction and validation of the token.
I also implement random names and values for form input controls including submit buttons.

rate limiting and load balancing is critical on the server.
a good host will do this automatically.

---

I just noticed something interesting while viewing the index page: error reporting is not disabled. Errors should only be visible when a site is in development. Disable the errors to avoid free tips for script kiddies. Now i wonder if remote file inclusion is disabled too :|