Ravindra BagaleCourses & study guides मराठी Track your progress

32. Linux and Network Hardening

32.5 Web Server Hardening

By Last updated:

Apache (/etc/httpd/conf/httpd.conf or a file in /etc/httpd/conf.d/):

ServerTokens Prod
ServerSignature Off
TraceEnable Off
<Directory /var/www/html>
    Options -Indexes -Includes
    AllowOverride None
</Directory>
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set Content-Security-Policy "default-src 'self'"

Nginx (inside http {} or the server {} block):

server_tokens off;
autoindex off;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
client_max_body_size 10m;
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

PHP (/etc/php.ini): expose_php = Off, display_errors = Off, allow_url_include = Off, and disable_functions = exec,passthru,shell_exec,system if your app does not need them.

Always keep HTTPS with a valid certificate (Chapter 11) and redirect HTTP to HTTPS. Test and reload:

sudo apachectl configtest && sudo service httpd reload
sudo nginx -t && sudo service nginx reload
curl -I https://reels.example.in        # check the headers

A WAF (web application firewall) such as ModSecurity or AWS WAF adds another layer against SQLi and XSS, but it never replaces fixing the code (Chapter 29).

Ravindra Bagale's Tip

If you set a very strict Content-Security-Policy, the site's CSS/JS gets blocked and students end up removing the header altogether. First test with Content-Security-Policy-Report-Only, look in the browser console to see what gets blocked, and then apply the real header.

Lab

Run Nikto (Chapter 20) against your lab web server and save the output. Apply the Apache or Nginx settings above plus the PHP settings, reload, and run Nikto again. List which findings disappeared and check the new headers with curl -I.

Real incident: Yoido Full Gospel Church – web shell on the ERP server leads to data on 850,000 members (Oct 2026)

1. What happened

On 7 October 2026, Yoido Full Gospel Church in Seoul, South Korea's largest church, said the personal data of 850,000 members may have leaked: names and dates of birth, plus a record of changes that included 2,629 resident registration number changes, 3,964 phone number changes and 7,202 address changes. Korea's internet security agency KISA warned the church at 3 p.m. on 6 October; at 1 a.m. on 7 October the church blocked outside access and changed its server passwords, and it later said it had deleted the malicious files and plans to replace its firewalls. The threat-intelligence firm Oasis Security had found the data on an overseas attacker's server: about 47.3 GB, including about 960,000 member records, about 330,000 donation records, about 68,000 approval documents and 14,706 internal messenger conversations. A second Seoul church, SaRang Church, was also hit (about 89,000 members and 286 staff) through leaked logins and access-control (IDOR) bugs. Oasis said the attack logs mentioned AI sub-agents and looked machine-written, but the exact role of AI is not clear. How the web shell was first placed is not public yet. Educational framing only.

2. How the hack happened (Oasis Security's analysis – high-level)

  1. The attacker first tried mass logins against South Korean church websites, including this church.
  2. A web shell – a small script file that lets an outsider run commands through the website – ended up in the web folder of the church's ERP server (the system that runs members, donations and administration).
  3. The attacker studied the ERP program's own files and decrypted its settings file, which held the database administrator (MSSQL sysadmin) login. The "encryption" key was inside the program, so it protected nothing.
  4. With database admin rights, they used the database's built-in feature for running system commands and its links to other database servers to reach more servers.
  5. They got around a database monitoring tool and reached file storage (NAS) and other connected systems.
  6. They gathered the data in one place and moved about 47.3 GB to their own overseas server. Oasis found that server, and KISA alerted the church.

3. How to stop it / defend (this lesson: web server hardening)

  • Web root must not be writable by the web app (Ch.8: 755 folders, 644 files). Only a tightly controlled upload folder may be writable, and scripts must never run from it.
  • Watch the web root for new script files (.aspx, .php, .jsp) with file-integrity monitoring or EDR, and hunt for web shells by recently changed files (Ch.6: find -mmin).
  • Never give the website or app the database admin account. The app should use a low-privilege account that can touch only its own tables.
  • Keep secrets out of config files that the app can read and decrypt – use a secrets manager, and change the password if it was ever stored that way.
  • Switch off dangerous features you do not need, such as running OS commands from the database – the same idea as PHP disable_functions above.
  • Segment and limit outbound traffic (32.6): the ERP server should not reach the NAS freely, and tens of gigabytes leaving for an unknown overseas server should raise an alert.
  • Rate-limit and alert on mass login attempts (the limit_req line above) and put MFA on every admin login.

4. How to take care so it won't happen again (checklist)

  • [ ] Run a weekly check for new or changed script files in every web root, and alert on them.
  • [ ] List every app's database account and remove admin rights that the app does not need.
  • [ ] Search config files for stored passwords, move them to a secrets manager, and rotate them.
  • [ ] Turn off database command-execution features and unused links between database servers.
  • [ ] Set an alert for unusually large uploads from servers to the internet.
  • [ ] India students: schools, temples, trusts and NGOs here also run old ERP and member systems with very little security – apply this checklist, and report incidents to CERT-In within the required time (see Ch.34).

Source: Yoido Full Gospel Church press release, 7 October 2026 (as reported by SBS News and Seoul Economic Daily, 7 October 2026); The Asia Business Daily, Kim Heeyun, "Yoido Full Gospel Church Hacked; Names, Birth Dates of 850,000 Members May Have Been Exposed", 7 October 2026; Oasis Security blog, "Analysis of Cyber Intrusions Targeting Major Religious Organizations in South Korea", October 2026; Seoul Economic Daily, "Two Large Korean Churches Breached, Member and Donation Data Exposed", 6 October 2026; Decrypt, 7 October 2026.

Check if you're safe: Is My Website Hacked? · Website Security Checklist

Real incident: Arara Message (Japan) – up to ~77M email addresses exposed; service suspended (Nov 2026)

1. What happened

In this lesson you learnt that strings, hashes and file types help you tell a real notice from junk – and that a big mail platform holds millions of addresses in one place.

  • On 2 November 2026, Japanese email-delivery firm Arara (Paycloud Holdings subsidiary; product Arara Message) published a further notice on unauthorized access.
  • It said about 77 million email addresses may have been taken from roughly 97 client servers, affecting up to about 380 companies. Exposed fields could include names, gender, birth dates, phones, membership IDs and addresses. It said it did not hold credit-card numbers.
  • Attackers also sent up to about 7.13 million suspicious emails that impersonated credit-card notices.
  • The service was fully suspended on 31 October 2026 and remained stopped with no restart date in the early November notices. Japan Times and Jiji covered the same disclosure window around 2–3 November 2026.

2. How the hack happened (public reporting only – high-level)

  1. Arara Message hosted email-delivery data for many client companies on shared / client servers.
  2. Attackers gained unauthorized access to those environments (exact first door not fully public in English summaries).
  3. Large subscriber / address lists were copied; some data was reused to blast phishing-style card emails.
  4. Arara suspended the service, notified clients and published updated counts (~77M addresses, ~380 firms).
  5. Clients and end users were told to treat unexpected card emails as suspect and wait for official restart news.

3. How to stop it / defend (this lesson: strings, hashes, careful handling)

Why: one mail SaaS breach can spray phishing that looks “official” because the attacker already has the real address list.

Controls you can use:

  1. Segment and encrypt customer lists; give support staff least privilege, not a full export.
  2. Watch odd admin / mail restarts on servers you own (Example 1).
  3. Inventory where subscriber files live so you know what to freeze after a vendor alert (Example 2).
  4. Hash and filetype-check any “official notice” sample before you forward it to staff (Example 3).
  5. Vendor IR clause: how fast they tell you, how they suspend sends, and who owns the customer notice.
  6. Tell users: Arara / card emails during the outage are phishing until your bank says otherwise.

Example 1: spot recent mail-related admin actions in your auth log.

  1. Run sudo grep -iE 'mail|smtp|sendgrid|ses' /var/log/auth.log | tail -n 5
  2. Output: like Nov 1 03:12:08 mail sudo: admin : TTY=pts/0 ; USER=root ; COMMAND=/bin/systemctl restart postfix.
  3. What it means: someone restarted mail as root at 3 a.m. – ask why before you ignore it.

Example 2: find subscriber export files on a host you own.

  1. Run find /var/lib/mail-app -name '*.sql' -o -name 'subscribers*' 2>/dev/null | head
  2. Output: like /var/lib/mail-app/exports/subscribers-20261028.csv.
  3. What it means: a full list sits on disk. Lock permissions and stop blind copies to laptops.

Example 3: fingerprint a notice file before sharing it.

  1. Run sha256sum /tmp/notice-sample.txt 2>/dev/null; file /tmp/notice-sample.txt 2>/dev/null
  2. Output: like e3b0c44298fc1c14... /tmp/notice-sample.txt\n/tmp/notice-sample.txt: ASCII text.
  3. What it means: you have a hash and a simple type. Compare with the vendor’s published sample; do not open random .exe “notices”.

4. How to take care so it won't happen again (checklist)

  • [ ] Mail-vendor contracts name breach notice time and send-kill switch.
  • [ ] Subscriber exports are encrypted, access-logged and rare.
  • [ ] Odd overnight mail admin actions page a human.
  • [ ] Staff verify vendor notices by hash / official URL, not only by email.
  • [ ] Users get a one-line “ignore card mails during outage” banner.
  • [ ] After restore, rotate SMTP and API keys the vendor issued.

Source: Arara / Paycloud Holdings Japanese disclosure notice and updates, 2 November 2026; Jiji English, "77 M. Email Addresses Leak from Arara Message Due to Cyberattack"; The Japan Times, more Japan firm breaches including Arara, 3 November 2026; Nikkei xTECH / INTERNET Watch same-window reporting.

Ravindra Bagale's Tip

When your mail vendor is breached, assume the attacker already has the real address list. Suspend sends, verify notices by official URL or hash, and tell users that “card warning” emails during the outage are phishing.

Check if you're safe: Phishing Link Checker