That's not gonna happen to you? :DDDDDDD
While managing more than 300 websites, I get various emergencies from time to time. Sometimes they are quite heated, but often it is a complete triviality. If, like me, you have been tempted by programming in the past, and you also know that programming is a pain, you will surely agree with me.
When a web application becomes popular, it becomes a tempting target for hackers. Their motivation is usually not to bring down the entire website, quite the opposite. In fact, hackers want you, as the server administrator, to be completely unaware of them. A good hacker waits for months, watching the web server and getting the most valuable thing - your data.
To protect your users, it's imperative to encrypt all data and have multiple layers of protection. For passwords, use one of the slow functions such as Bcrypt + salt, Argon2, PBKDF2, or Scrypt. Michal Špaček has already written about security rating, and I thank him for adding to the article. As a site owner, you must insist on proper password hashing when discussing with a programmer. Otherwise, you are going to cry, just like many people before you who also deluded themselves that it didn't concern them.
I've noticed that when a web server reaches a certain threshold of traffic (in the Czech Republic, it's about 50+ visitors per day), it starts to get a series of attacks directed at it out of nowhere. To make it not easy, the attacker always has an advantage, because he can choose which part of the infrastructure to start attacking and you - as the owner of the web server - have to recognize it in time, defend yourself and be better prepared for it next time.
How many attacks have been directed at you in the last month, for example? Do you know exactly? How many of them have you defended? Does anyone else have access to your server?
What if someone is attacking you right now? And now... and now also...?
Unfortunately, there's no one-size-fits-all way to recognize an attack. But there are tools that can give you a significant advantage.
What's worked best for me lately:
In fact, even large companies make mistakes, even on trivial things like the XSS (cross-site scripting) attack.
The question is not whether someone will ever break your website. The question is when it will happen and whether you will be prepared enough to deal with it. Maybe a hacker has had access to your server for months and you don't know it (yet).
By the time you find out about the hacker's work, it's usually too late and the hacker has done everything they needed to do. He has very likely placed malware all over the server and has at least partial control over the machine.
This is a chaotic type of problem and you need to act fast.
Since this is the last stage of the attack, I personally recommend disconnecting the web server completely from the internet and start to gradually figure out what all happened. Plus, we will never know exactly if the server is hiding something else. The attacker always has a significant head start.
If we decide to put the last working backup back on the server, we will be helping the attacker a lot. He already knows how to break into your server and there is nothing stopping him from doing it again in a few hours. In addition, the backup probably contains malware or some other type of virus.
Although this is a very unpopular option among my clients, I personally always recommend completely deleting WordPress sites first, or any systems that the client doesn't update that have a lot of security threats. For example, if you host 30 sites on one server that are more than 2 years old, you are virtually guaranteed that at least one of them contains some form of vulnerability.
If you don't understand the issue, you'd better contact a suitable specialist early on who has deep knowledge of your issue and understands things in a broad context.
If you are managing a website for a client who has had a security incident, it is your responsibility to inform them. If any data (such as passwords, but often much more) is leaked, you must also inform end users that their password is public knowledge and they should change it everywhere. If you use a slow hashing function (for example, Bcrypt + salt), you will make it significantly more difficult for an attacker to crack passwords. (Unfortunately, Bcrypt passwords can be cracked). If you wish to receive regular information about whether your account has been leaked, I recommend registering with Have i been pwned?. For more information about security breach, please visit the OOOO website.
In the last six months I finished reading the book Atomic Habits, which was an eye-opener. It describes a process of incremental 1% improvement every day that will do a lot in the long run.
Since I am approached by companies and individuals at various stages of technology debt, I would like to summarize the worst things:
nofollowto avoid being indexed by Google. Sensitive content that your competitors must not know must be password protected.
There are many more vulnerabilities and the problems vary from project to project. If you need to do a quick server audit, I recommend using Maldet and then hiring a suitable specialist to help you do a full site audit, and not just for security reasons.
Security engineers are like plastic in the ocean - just forever. Get used to it.
You will also have noticed that nature almost always uses the reactionary principle. This means that something happens in a particular environment and the surrounding organisms react to it in different ways. This approach has many advantages, but one huge disadvantage - you will always be left behind.
As a thinking person (designer, developer, consultant) you have a great advantage, and that is to be actionable - that is, to know in advance a certain portion of the big risks and actively prevent them from happening in the first place. You may never prevent all screw-ups, but you can at least mitigate the consequences, or build control mechanisms that detect problems early so you have time to react.
Most attacks take place over a long period of time, and if you log, you will usually have enough time to detect the problem.
Jan Barášek Více o autorovi
Autor článku pracuje jako seniorní vývojář a software architekt v Praze. Navrhuje a spravuje velké webové aplikace, které znáte a používáte. Od roku 2009 nabral bohaté zkušenosti, které tímto webem předává dál.
Rád vám pomůžu: