CERT-In’s 6-Hour Breach Reporting Rule: What It Means When Your Servers Are on Linux
Last month I audited an Ubuntu server for a manufacturing client. The authentication log showed over 800 failed login attempts in 7 days.
That number alone means little. Every internet-facing server gets hammered by bots. What mattered was this: nobody at the company could tell me whether it was bot noise or something worse. The log had never been read.
Here’s the uncomfortable question. If 1 of those attempts had succeeded, could they have filed a report with CERT-In within 6 hours, with evidence attached? Their log retention wouldn’t have survived 6 weeks, let alone reconstructed an intrusion timeline.
Most Indian companies running Linux infrastructure are in the same position. The rule has been in force since 2022. Readiness for it hasn’t moved much.
The rule, minus the legalese
In April 2022, CERT-In issued directions under Section 70B(6) of the IT Act. The core obligation: report listed cyber incidents within 6 hours of noticing them or being informed about them.
The list of reportable incidents is long. Unauthorised access, ransomware, data breaches, website defacement, attacks on servers such as database, mail and DNS servers, malicious code, identity theft. Around 20 categories in the annexure.
It applies to service providers, intermediaries, data centres and body corporates. If you run servers for a business in India, assume you’re covered.
Non-compliance sits under Section 70B(7), which carries imprisonment up to a year or a fine. And the fine may be about to get heavier: a proposal under the Jan Vishwas framework would raise it from Rs 1 lakh to Rs 1 crore. Enforcement appetite is moving in one direction.
6 hours is an evidence problem, and evidence lives in logs
The 6-hour window sounds like a speed problem. Work through what the report actually asks for and it becomes an evidence problem.
CERT-In’s incident reporting format wants the time of the incident, the affected systems, the symptoms, and relevant logs. You can only supply those if the logs exist, cover the period in question, and carry timestamps you can trust.
On a Linux server, that evidence lives in predictable places:
Who got in. /var/log/auth.log on Ubuntu and Debian, /var/log/secure on RHEL and its cousins. Every SSH login, every sudo, every failure.
What the service saw. journald holds service-level events, but by default it caps retention by disk size, so it may hold days or months depending on how noisy the box is. You won’t know until you check.
What touched the network. UFW or iptables logs, plus nginx or Apache access logs. These tell you what the attacker probed before they got in.
What they did after. auditd, if you configured it. Shell history, if the attacker was careless. Attackers usually aren’t.
And one thing that undermines all of the above: time. I recently found a production server whose NTP sync had been broken for months. If your server clock disagrees with reality by 11 minutes, your incident timeline is fiction, and CERT-In’s directions specifically require synchronising system clocks to NPL or NIC time sources.
The 6-hour readiness check
Run these 5 commands on any Linux server you’re responsible for. Together they take about 2 minutes.
# 1. Recent failed logins. If this surprises you, you have a monitoring gap.
sudo lastb | head -20
# 2. Volume of failures in the current auth log.
sudo grep -c "Failed password" /var/log/auth.log
# 3. Is your clock actually synchronised?
timedatectl
# 4. How far back does your auth history go?
sudo ls -lh /var/log/auth.log*
# 5. How much journal history are you holding?
sudo journalctl --disk-usageIf command 4 shows 4 or 5 rotated files spanning about a month, you’re on Ubuntu’s defaults. CERT-In expects 180 days of logs, which is a separate obligation and a separate article. The short version: defaults fail it.
If command 3 shows the clock unsynchronised, fix that today. It costs one command and its absence poisons every other piece of evidence you hold.
Where the rule is genuinely fuzzy
I’ll be honest about the part the rule’s critics are right about. “Targeted scanning” appears on the reportable list, and every internet-facing server on earth gets scanned constantly. Read literally, you’d file reports hourly.
Nobody does, and CERT-In’s own FAQ steers toward incidents of substance. In practice the severity judgment is yours to make. My advice: make it in writing. For each event you decide is background noise rather than a reportable incident, keep a 2-line note saying what you saw and why you classified it that way.
That note costs 30 seconds. If your judgment is ever questioned, it’s the difference between a documented decision and negligence.
3 things to do this week
First, verify time sync on every server. timedatectl, and if it’s off, enable systemd-timesyncd pointed at an Indian NTP source.
Second, extend log retention beyond 180 days so the evidence exists when the clock starts.
Third, decide in writing who files the CERT-In report, and run one rehearsal: pick a fake incident, pull the real logs, fill the real form, time yourselves. My bet is your first drill takes longer than 6 hours. Better to learn that on a Tuesday afternoon than during a breach.
The companies that handle this rule well aren’t the ones with the biggest security budgets. They’re the ones who found out where their logs were before someone else did.
Arun Valecha is the founder of AV Services, a Linux infrastructure management firm in Mumbai. He has run production Linux servers for clients since 1999.