Linux Infrastructure Hardening para sa APAC Systems

Karamihan sa production Linux systems ay mas malapit sa default configuration nila kaysa aminin ng kahit sino. Umiiral ang hardening documents, madalas naisulat para sa audit taon pa ang layo, pero hindi tugma ang servers. Sa gap sa pagitan ng “documented baseline” at “actual configuration” reliable na nakatira ang attackers.

Ang Linux hardening ay ang disiplin ng pagsasara sa gap na iyan, sa paraang nakaliligtas sa susunod na deployment.

Ang defaults ay simula, hindi posture #

Compatibility, hindi security, ang priority ng default Linux install. Kasama rito ang mga services na hindi mo ginagamit, kernel features na hindi kailangan, at logging na sapat lang para sa desktop pero hindi para sa compromised production host. Ang hardening ay proseso ng paggawa sa general-purpose machine na iyon tungong purpose-built.

Nahahati sa ilang kategorya ang mabigat na bahagi:

• Kernel at sysctl tuning: network protections (halimbawa, pagwawalang-bahala sa ICMP redirects, pag-enable ng source-route filtering), filesystem restrictions, at memory protections tulad ng address space layout randomisation.
• Service minimisation: pag-disable at pag-alis ng hindi tinatakbo ng host, para walang pwedeng i-exploit na hindi naman ginagamit.
• Mandatory access control: SELinux o AppArmor para pigilan ang maaaring gawin ng process, kahit na-compromise pa ito.
• Systemd at container hardening: pag-drop ng capabilities, pagharang sa raw socket access, at pag-restrict sa syscalls gamit ang seccomp profiles.
• Audit at logging: pagkuha ng mga mahahalagang events, inilalabas ng host para hindi mabura ng attacker ang bakas nila.

Ang CIS Benchmarks pa rin ang pinaka-praktikal at pinakakilalang codification ng mga controls na ito, at OpenSCAP ang nag-aautomate ng pag-aapply at pag-aaudit nito.

Config as code, o wala talaga #

Ang hardening guide sa wiki ay wish-list. Ang hardening na nakatira sa code (Ansible role, Packer image, Kubernetes admission policy) ay katotohanan. Kapag code ang baseline, tatlong bagay ang nagbabago:

1. Reproducible ito. Bawat bagong host ay nagmamana ng baseline, hindi lang yung naalala ng may hawak na i-configure.
2. Testable ito. Nagfe-fail ang build kapag nag-drift ang setting dahil compliance scan sa CI.
3. Reviewable ito. Pull request ang pagbabago ng baseline, may parehong review discipline tulad ng application code.

Iyan ang pagitan ng hardening bilang annual event at hardening bilang property ng platform.

Immutability bilang end state #

Ang logical na konklusyon ay immutable infrastructure: hindi ina-patch sa lugar ang hosts at containers, pinapalit lang sila. Binubuo, sini-scan at dine-deploy ang bagong image; sinisirain ang luma. imposible na ang configuration drift dahil walang pwedeng mag-drift: build artifact ang tumatakbong system.

Natural na tambal ng immutable infrastructure ang hardening-as-code. Hindi ka nagmementena ng baseline; kinokompila mo ang security sa loob ng image. Kapag lumabas ang vulnerability, rebuild ang solusyon, hindi midnight SSH session.

Lampas sa host #

Hindi natatapos sa operating system ang hardening. Ang parehong disiplina ay umaabot sa ilang direksyon, bawat isa may sariling failure mode.

Containers: nagmamana ng lahat, tapos nagdadagdag pa ng sariling risks. Container image na gawa sa base layer na hindi hardened, dala ang lahat ng host-level weaknesses sa bawat pod na tumatakbo nito. Nasa upstream ang solusyon: minimal base images, scanned sa CI, tumatakbo bilang non-root na may read-only filesystems, dropped capabilities, at seccomp profiles na nililimitahan ang syscalls sa talagang kailangan lang ng workload. Marami nang hiniharang ng default seccomp profile; ang profile na naka-tune sa observed syscall behaviour ang haharang sa natitira. Kubernetes admission policies ang nag-eenforce sa lahat fleet-wide, para ang non-compliant deployment hindi maka-schedule kahit kailan.

OT environments: mas mataas ang stakes. Sa industrial at operational technology settings, sumasalpukan ng availability ang hardening sa paraang hindi nakita ng office IT. Isang maling CIS control sa building management system, production line PLC network, o hospital device segment ay hindi nagproproduce ng finding: nagproproduce ito ng downtime, minsan may safety consequences pa. Kaya baligtad ang sequence sa OT hardening: passive monitoring at inventory muna, changes sa maintenance windows na may rollback plans, at controls na pinipilot sa mirrors ng production bago dumampot sa totoo. Ang IT nagtatanong “secure ba ang sistemang ito?”; ang OT dapat magtanong “kaya ba naming protektahan ito nang hindi namin pinapatay?”

Drift detection: pagsasara ng loop. Nabubulok ang baselines sa routine changes: nagbukas ang engineer ng port para mag-debug, muling nag-enable ang installer ng isang service, hindi bumalik ang hotfix sa code. Walang detection, ang hardened host ngayon ay soft host next year. Epektibong pattern: daily configuration scanning na kinukumpara ang live hosts at images sa coded baseline, findings na niruruta bilang alerts diretso sa owners, hindi nakatago sa quarterly report na walang nagbabasa. Ang drift na nadetect sa loob ng isang araw ay ticket; ang drift nadetect pagkatapos ng isang taon ay incident investigation.

Ang hardened host sa likod ng over-permissive cloud IAM role, o sa loob ng unscanned container pipeline, exposed pa rin. Pinakamatibay na posture: trato sa host baseline, container build chain, cloud configuration at identity boundaries bilang iisang tuluy-tuloy na surface, at ganito rin ang monitoring.

Ang Linux & Infrastructure Hardening namin ay nagdadalhatid ng baselines bilang code at automated drift detection, at ang Configuration & Architecture Assessment namin ay sumusuri sa cloud at identity layer sa paligid ng host. Para sa buong larawan, i-schedule ang Engineering & Scoping Session.