What cybersecurity is
Cybersecurity means keeping three things at once: that nobody who should not see your information sees it, that nobody changes it without permission, and that it is there when you need it. Almost nobody picks you personally; what knocks on your door is a list a machine is running against thousands of addresses.
- Lesson 1 of 12
- Beginner
- Free, no signup
The three things security keeps
The definitions are from FIPS 199; the examples are from an ordinary working day.
-
Confidentiality
Whoever should not see it, does not. The customer list does not turn up on the internet.
-
Integrity
Nobody changes it without permission. The prices are the ones you set.
-
Availability
It is there when you need it. The site is up when the customer arrives in the morning.
The three do not carry equal weight and their order differs for everybody. For a shop, correctness and availability usually come first; for a site holding client files, confidentiality does.
Last checked: Facts and tool names in this lesson are re-checked against their sources on this date.
What exactly does cybersecurity protect?
Three things, and few people hold all three in mind at once. Cybersecurity means keeping information, and the systems that hold it, confidential, correct and available. These three are not our invention: the American National Institute of Standards and Technology defines all three in FIPS 199, calling confidentiality "preserving authorized restrictions on information access and disclosure", integrity "guarding against improper information modification or destruction", and availability "ensuring timely and reliable access to and use of information".
Now the same three in the language of your own day. Confidentiality means your customer list does not turn up on the internet. Integrity means the prices in your shop are the ones you set and nobody has quietly removed a zero. Availability means that when a customer comes to the site in the morning, the site is up.
And a position here: when most people say security they picture confidentiality alone, somebody reading something of mine. But what actually ruins a working day is usually one of the other two. A site that is down for a day loses money and trust; a site whose content somebody edits quietly is worse, because for a long while nobody notices. Ransomware is an attack on exactly those two: it does not take your data away, it takes it out of your reach.
One practical consequence follows from that split. The right question is not "how do I increase my site security", it is "which of these three hurts me most if it goes". For a personal blog the answer is usually availability. For a shop, the correctness of orders and payments. For a site holding client files, confidentiality. The order of your work comes out of that answer, not out of a checklist you found on the internet.
Who comes for my site, and why me at all?
This is the question almost every owner of a small site asks themselves, and the answer they give themselves is wrong: "I am nobody, who would bother with me." The real answer is that nobody is bothering with you, and that is exactly why they knock on your door every day.
The numbers come from this site own log, for one full day, 6 September 2026. In that single day 191 requests reached rgb.ir asking for a file or a piece of software that is either not here at all or only means something to an attacker. Those 191 requests came from 24 different addresses and asked for 90 different paths. 169 of them got a 404 and nothing else, which is the answer "no such thing here".
They break down like this: 62 requests looked for the configuration file of a framework, 60 looked for a file that prints the server configuration, 37 were about WordPress, 19 were hunting for a ready made back door, and the remaining 13 were miscellaneous. The only family that got anything other than a 404 was the WordPress one, because WordPress is the only software actually running here; and even those got a redirect or a dropped connection rather than a login form.
But the striking thing in that log is not the counts, it is the repetition. At 2:20 in the morning one rented machine asked for 57 addresses one after another and finished the lot in 60 seconds. Nineteen hours later, at 9 in the evening, a different machine at a different address asked for exactly the same 57 addresses; the list, in the same order, was identical line for line. Those 57 were nothing exotic either: 28 different spellings of one configuration file and 29 different places a configuration printing file might sit. Neither of those files exists on this site. Both machines described themselves as Chrome, one on a Mac and one on Windows.
On the same day we were asked for things that are frankly funny: the control software of a 3D printer, a school management system, a Chinese PHP framework, and the log page of a WordPress mail plugin we do not have. None of it is installed here and nobody checked whether it was before knocking. That is what opportunistic means: nobody chose your site, you were simply on the list.
Why is the scanner looking for somebody else back door?
On that same day, 19 of those 191 requests were hunting for something that only exists if the site has already been broken into. Ten different names and paths, all from one family: a web shell, the file an attacker leaves behind after getting in so that next time they can walk back without effort. Security firms have analysed and documented this family for years and it is known by name.
Think for a second about what that means. Those requests were not trying to break into our site at all. They were asking whether somebody else had already broken in and left the door open. A site that was hacked once and then apparently cleaned still has a permanently open door, if that one file was left behind, and anybody who knows its name can walk through it without any new attack being needed.
Several practical conclusions follow, and you see them less often in the usual security lists. First: removing the malware with a plugin is not enough; what matters is finding the way in and closing it, or the same thing happens again next week. Second: after any incident every password and key is replaced, not only the administrator one. Third and more important than both: the reliable way to bring an infected site back is to restore a backup whose date is certainly earlier than the break in, and that is what turns backups from a boring chore into your single most important security decision.
One honest note as well: none of us can tell from a log who was behind those 19 requests. Whether it was an attacker or a researcher scanning the internet is not visible in the request itself, and any claim about it is a guess. What a log shows is behaviour, not intent.
The five habits that cover most of the risk
When the attacker is a script running a list, the defence is not supposed to be complicated either. Five habits make most of that list ineffective and none of them needs expertise.
Keeping things updated. That script hunts for known weaknesses, meaning things the software vendor has already patched. A site that is up to date is effectively invisible to most of the list. The UK National Cyber Security Centre also puts installing updates promptly among the handful of core actions in its short list of advice to ordinary users.
A unique password per account. The point here is not that the password is hard, it is that it is not reused. A reused password means a breach at an unimportant site also opens your important account. And one widespread belief that the official guidance contradicts: periodically changing your password is not necessary. SP 800-63B, from that same American standards institute, states plainly that services shall not require users to change passwords periodically, and shall force a change only when there is evidence of compromise. The details come in the passwords and two factor lesson of this path.
Two factor on the accounts that matter. Email first, then the rest, because email is the recovery key to all your other accounts and whoever takes it has taken those too.
Backups, and more importantly keeping them somewhere else. A backup sitting on the same server is useless in the kind of incident that takes the whole server. And the most honest sentence in this section: a backup that has never been tested is an assumption, not a backup.
Suspicion of any message that is in a hurry. This is the only habit that is not technical, and the one that appears least in the official lists. Almost every successful scam carries an artificial urgency: your account closes tonight, your parcel goes back within the hour. Pausing prevents more loss in practice than any piece of software. The phishing lesson in this path opens up how to recognise it.
And how much of it works: on this very server the login protection system locked somebody out only 3 times between 30 August and 4 September 2026, while 191 reconnaissance requests hit the site in a single day. The gap between those two numbers is not an accident: almost none of those scripts ever reach the stage of trying a password, because the thing they were looking for is not there.
Five habits, and four things that do not replace them
The five habits
- Keep the system and plugins updated, because the scripts hunt weaknesses already patched.
- A unique password per account. Not being reused matters more than being hard.
- Two factor, on email first, since it is the key to every other account.
- A backup off that same server, with a clear date and tested at least once.
- A pause in front of any message that is in a hurry; artificial urgency is the main sign.
These do not substitute
- Stacking several security plugins, which produces more conflict than protection.
- Changing passwords periodically, which the official guidance explicitly does not require.
- Counting blocked attacks in a daily report, which is not a sign an incident happened.
- Hiding the login address, which is one extra layer and not a lock.
The right hand column is not a list of useless things; they are things that do not make you secure on their own and are often used as a substitute for the five on the other side. A targeted attack is stopped by none of these ten and is a different subject.
What to do if you think you have just been hacked
Separate one thing first, because most of the panic starts here. Seeing attempts in a report does not mean a break in. All 191 requests we counted in the second section were attempts and not one of them worked. If your security plugin tells you every day that so many attacks were blocked, that means the work is being done, not that something happened.
The real signs are different: successful logins from somewhere you have not been, an administrator account you did not create, files with a strange modification date, visitors being redirected to another site in a way that only happens on mobile or only from search results, a browser warning on your own site, or emails sent in your name that you did not send.
If you see one of these, the order of the work matters. From another device you are sure is clean, change the password of your main email and turn on two factor; as long as the email is in somebody else hands, any other password you change can simply be recovered again. Then tell your host, because only they have the server side records. Keep one copy of the site as it is now, untouched, even infected; if you wipe everything you will never learn how they got in and that same way stays open. And last, restore a backup with a date you are sure predates the incident.
One warning that costs people money: the first answers to a search for "my site is hacked" are usually advertisements. Nobody can give you a firm price and a firm time before looking at your site, and anybody quoting a number without having seen anything is selling something else.
The fast path, with AI
The usual way to get secure is to open a long list of tasks and then, out of fatigue, do none of them. The faster way is to sit down for ten minutes first and write your own threat model: what you have, which of it hurts most to lose, and which of the five habits covers exactly that. A language model is good for this, because what it does is sort something you wrote yourself, not know anything about you.
- On paper or in a file, list what you have that is worth something: accounts as categories rather than by name; the site and the domain; files that exist in only one copy; and money that moves from somewhere to somewhere.
- Next to each one write a single word: what happens if tomorrow morning it is gone, or in somebody else hands. That one word does more work than any elaborate scoring.
- Give the list to the model and ask it to pick exactly the first three actions, with reasons, drawn from those five habits. A fast, cheap model is enough here; the work is sorting, not expert judgement.
- Do those three the same day and close the rest of the list. An open, undone list is itself a kind of insecurity.
Copy-ready recipe
Your role is to help write a personal threat model. Work only from the list I give and add nothing to it.
What I have, by category:
{list}
What happens if each is lost, one sentence each:
{impact}
The five habits you may choose from, and only these:
1 keeping things updated, 2 a unique password per account, 3 two factor, 4 a backup off that same server, 5 a pause in front of hurried messages.
Give the output like this:
a) A table with the columns: asset, worst realistic outcome, which of the five habits covers it.
b) Exactly three actions for today, in order of importance, each with one sentence of reasoning. No more than three.
c) One short paragraph headed "what this does not cover".
Rules: propose nothing outside those five habits. If you need something for the ranking that is not in my list, ask instead of guessing. Do not recommend any product or tool by name. Write no number about the probability or statistics of attacks.Before you trust the output: Two things never go in, with no exception: real usernames and passwords, and the email address or number you use to recover your accounts. Together those two are precisely what an attacker is after, and you would be writing the list of them somewhere the model and the company behind it also see. Write categories, not instances. And do not treat the model answer as a plan either: what it did was sort your own sentences, and if its ranking disagrees with your instinct, your instinct about your own business is the more reliable one.
AI in this kind of work
In security the boundary of what a language model can do is clearer than in any other subject. Good: explaining an error message or a warning in plain words, sorting a list you wrote yourself, translating a technical text. Bad: asking whether you have been hacked. For that question the model has no data from your system at all, and what it produces is said with confidence rather than knowledge.
Tools that actually help
- Claude For when you have a long technical text and want to know what it says: a service security policy, or a scan report. Iran is not on Anthropic supported countries list, so there is no official route to sign up or pay.
- Gemini For sorting that threat model list and for translating English browser and operating system warnings. Google own privacy page for Gemini says explicitly not to enter confidential information, and Iran is not in its list of available regions.
- ChatGPT Just as useful for the same work. On access from Iran we write nothing without a source behind it: OpenAI supported countries page does not answer our server, and we do not manufacture an unchecked claim.
Where it backfires
Two specific risks, and the first is one nobody expects. Models deliver outdated security advice with total confidence, because that advice has been repeated in internet text for years. The clearest example is periodic password changes: section 3.1.1.2 of the American standards institute guideline SP 800-63B says plainly that services shall not require periodic changes and shall force a change only on evidence of compromise, and the same section also forbids imposing character composition rules; yet many answers you get still recommend both. Measure a model security answer against an official source, not against how confident it sounds. The second risk is yours: everything genuinely sensitive in security, meaning passwords, keys, configuration files and recovery addresses, is exactly what must not be pasted into any online tool, and Google own guidance says the same. To see what paying for these tools from Iran looks like, see the buying guide.
Sources: NIST SP 800-63B: password verifier requirements Google: Gemini Apps privacy and data Google: where Gemini Apps are available Anthropic: supported countries
Where this advice stops
Everything in this lesson is about the opportunistic attack, the script running a list. A targeted attack, where somebody has specifically chosen you, follows different rules and none of the five habits above stops it; that subject needs an organisation, a budget and people, and it does not fit in this path. The numbers we gave are not world statistics either: they are one site log on one day and the next day they differ; the shape carries over, the figures do not. And the last one, more important than both: this lesson is about keeping your site and your accounts, not about the security of an organisation with dozens of staff and an internal network, which is a discipline of its own.
From our own work
Every number in this lesson came from the same server that just handed you this page, and was read again today. The rgb.ir access log for one full day, 6 September 2026: 191 reconnaissance requests, 24 source addresses, 90 different paths, 169 answers of 404; and two different machines that, nineteen hours apart, asked for the very same list of 57 addresses, one of them inside 60 seconds. In the lockout table of the login protection system there are only 3 rows between 30 August and 4 September, which is exactly the difference between a scan and a real attempt to get in. Two more things, because we measure ourselves by this lesson standard: of the 1224 user accounts on this site only 1 is an administrator and that one has two factor, but the other accounts are not even offered the option, and that gap is our site shortcoming rather than our advice; and the backups are copied to outside cloud storage and verified by checksum, the latest on 6 September at 682.4 MB, yet we do not regularly test a full restore and we count that as our own weakness. WordPress on this site is on version 7.1 today with no plugin update pending.
Real follow-up questions
My site is small, is it still a target?
Yes, but not in the sense you imagine. Nobody chose your site; a script walking a list of addresses arrives at yours too, the way it arrived at ours 191 times in a single day. Size is simply not in the equation for this kind of attack, and only matters for a targeted one.
My security plugin reports blocked attacks every day, am I in trouble?
No. That number counts knocks, not entries, and it is large on any site connected to the internet. The number to actually watch is a successful login from somewhere you have not been, and a user or file appearing that you did not create. If the daily report does anything, it tells you the plugin is working.
Where do I start if I can only do one thing?
With your main email: a unique password and two factor, today. Email is the recovery key to all your other accounts, so until it is safe anything you do to the others is temporary. If a second thing becomes possible, put one backup somewhere off the site server.