Kormányablak, Ügyfélkapu, magyarorszag.hu, kormany.hu
KORMÁNYABLAK, ÜGYFÉLKAPU - A ZÁRT AJTÓK MÖGÖTT...
(nem hivatalos e-kormányzati témájú oldal)
  
BEMUTATKOZÁS 
E-KÖZIGAZGATÁS 
IT BIZTONSÁG 
  
































  Mottó:
Verba volant,
scripta manent.
/Latin közmondás/
2012. január 12.  
 A syslog nem naplopó 
   
A BalaBit Open Academy (2011. november 24.) rendezvény valóban magas színvonalú előadásai közül sok dolog maradt meg a fejemben, de az egyik számomra meglepő adat Höltzl Péter előadásában hangzott el, miszerint a naplózási funkció (IT rendszereknél) szükségességét - a felhasználói válaszok alapján - egyebek mellett 7%-ban a jogszabályi előírások (is) indokolják.

Elmékszem, hogy annak idején, 2001. tájékán, amikor először kellett a Common Criteria módszertan fejezeteit olvasgatnom egy terméktanúsítás során, meglepődtem azokon a szigorú követelményeken, amelyek szerint ha a naplózó modul nem működik, akkor akár blokkolni is kellhet bizonyos funkciókat. Ha nincs naplóesemény, akkor nem lehet az eseményeket elemezni, utólag felelősségre vonni bárkit is, felderíteni az esetleges behatolás folyamatát, ezért indokoltak lehetnek a szigorúnak tűnő védelmi intézkedések.

A különböző felderítésekhez (pl. bűntényekhez) kapcsolódó ötletekkel, segédalkalmazásokkal a "computer forensics" témakörre rákeresve lehet többet megtudni. A "computer forensics" feladatai közé tartozik többek között az esetleges hack kapcsán a sérülékenység felderítése, vagy a törölt adatok helyreállítása merevlemezeken is, esetleg céges alkalmazott tevékenységeinek nyomonkövetése. A naplóadatok kinyerése, elemzése a legtöbb "computer forensics" témakör esetében alapvető fontosságú, amit nyilván a támadó is tud, ezért amennyire lehet, el kell is kell tüntetnie a nyomokat a pl. /var/log naplóállományaiból vagy a .bash_history állományból. A helyi állományokban még akár törölhet is a támadó utólag, azonban a naplóüzenetek (még a .bash_history is átiranyítható a syslog-ba) már addigra rég kikerülhettek egy távoli syslog szerverre...

Ahhoz hogy a naplóadatok alapján "computer forensics" feladatokat végre lehessen hajtani, az alapvető tervezési-üzemeltetési követelményeknek meg kell felelni, amelyeket néhány ökölszabályként megfogalmaznak a manapság divatos módszertanok is.

A CC (Common Criteria) külön funkcionális osztályt (Class FAU: Security audit) rendelt a naplózásnak. (Az alábbi idézetek a CC v3.1 (2009. július) változatú dokumentumaiból származnak.)
  • FAU_STG.1 Protected audit trail storage
    FAU_STG.1.2 The TSF shall be able to [selection, choose one of: prevent, detect] unauthorised modifications to the stored audit records in the audit trail.

    A naplóállományok módosíthatóságának megelőzése az írási jogosultságok korlátozásával, a módosíthatóságának észlelése digitális aláírással valósítható meg.

  • FAU_STG.3 Action in case of possible audit data loss
    FAU_STG.3.1 The TSF shall [assignment: actions to be taken in case of possible audit storage failure] if the audit trail exceeds [assignment: pre-defined limit].

    A naplóírási funkció bármilyen okból (pl. jogosultság, merevlemez megtelt) fakadó, pillanatnyi vagy maradandó leállása miatt akár az alkalmazás egyéb funkcióit is letilthatják.
A PCI-DSS (Payment Card Industry - Data Security Standard v2.0) előírásait a bankkártyás rendszereken túlmenően szélesebb körben is használják, ezért érdemes megnézni, hogy mit írnak a naplózásról. (Az alábbi idézetek a PCI-DSS v2.0 (2010. október) változatú dokumentumaiból származnak.)
  • 10.5 Secure audit trails so they cannot be altered.

    (ld. Common Criteria FAU_STG.1.2)

  • 10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from back-up).

    Bírósági ügyek esetén nyilvánvalóan az egy év letelte után sem selejtezik az ügy szempontjából fontos naplóállományokat.
Természetesen felkeltette az érdeklődésemet, hogy a kriptográfia alkalmazása hogy megy a syslog üzeneteknél. Nem is kellett sokáig keresgélnem, hiszen az IETF (Internet Engineering Task Force) listájában szerepelt minden, ami ehhez kapcsolódik:
  • RFC 5424 - The Syslog Protocol

    A syslog üzenetek felépítését, illetve a kommunikációban résztvevő feleket ("Originator" - "Relay" - "Collector") határozza meg.

  • RFC 5848 - Signed Syslog Messages

    A speciális tartalmú, digitális aláírást magában foglaló syslog üzenet felépítését határozza meg.
Néhány napi olvasgatás után összeállt a kép annyira, hogy megszülessen egy kis alkalmazás, a syslog.PHP, amely képes a hagyományos syslog üzenetek mellett egy aláírt syslog üzenetet ("ssign" struktúra, "Signature Block") is létrehozni a vonatkozó szabványoknak megfelelően. Valahogy így (a VER értéke mutatja, hogy DSA vagy RSA alapján megy-e a kódolás, illetve SHA-1 vagy SHA-256 lenyomatokról van-e szó):

Az aláírt syslog szabványa (RFC 5848) kapcsán azért van néhány észrevételem:
  • Az "ssign" aláírás típusú syslog üzenet 1-99 sor (esemény típusú syslog üzenet) lenyomatát tárolhatja szabvány szerint (a "CNT" értéke is ezt mutatja). Ez azt jelenti, hogy egy-egy blokkot külön aláírás struktúra zár le. De, ha én (pl. támadóként) kiemelek egy ilyen védett, aláírt blokkot, akkor azt senki sem veszi észre az egész naplóban, nincs semmilyen láncolás, visszacsatolás az előző blokkokra vonatkozólag: nagyjából hasonló a helyzet, mint a kriptográfiai kódolási módozatoknál az ECB (Electronic Codebook) és a CBC (Cipher-block Chaining) között.

  • A szabvány kifejezetten az OpenPGP DSA implementációra hivatkozik, de természetesen bármilyen más, szabványos megoldással működik (pl. OpenSSL).

  • A DSA kódoló algoritmus támogatása, használata kötelező SHA-1, illetve SHA-256 lenyomatképzéssel együtt a szabvány szerint, de természetesen működik ez ugyanúgy RSA kódoló algoritmussal is.

Az alkalmazásba belereszeltem néhány self-test funkciót is ("happy day scenario" + negatív utakkal együtt), amelyhez részben Martin Schütte, illetve a NetBSD és Google csapata adta a mintaadatokat (ezúton is thx!).



Kapcsolódó anyagok:
 vissza 
   
  info@kormanyablak.org
info@ugyfelkapu.info