Hoe heb jij root gebruikers gechecked? Als iemand joun root wachtwoord heeft (om wat voor duistere reden dan ook) hoe wil jij dan controleren dat jij hebt ingelogd? De enigste die het root wachtwoord heeft ben jij. Dan ben jij een beveiligingsrisico en niet een ander die het wachtwoord ook kent.

En als je andere gebruikers hebt die Root hebben is dat niet zo handig, je kan doormiddel van een acceslist (geen idee meer hoe die heet) aangeven welke gebruiker welke rechten heeft en welke commando's mag uitvoeren. /etc/sudoers/ is die acceslist volgens mij.

Voor de rest is Linux beveiliging voor mij niet besteed. Denk dat andere gebruikers je daar meer mee kunnen helpen.

Je zou ook nog naar crontab kunnen kijken voor de rest is je lijst wel compleet denk ik.

Er zijn meerdere soorten logs die je kunt bekijken,
bekijk deze link eens:
https://www.eurovps.com/blog/important-linux-log-files-you-must-be-monitoring/

rkhunter installeren, en behoorlijk gebruik ervan leren benutten in combinatie met depends zoals unhide en tripwire pakketten.

sha512sum benutten en meer dan standaard tests laten doen via rkhunter.conf in je /etc map

rkhunter database in read only partitie proppen, liefst netwerkpartitie die je na --propupd standaard weer readonly maakt.

ieder uur ofzo laten draaien via crontabs en dan resultaten laten mailen of output naar bestand pipen en dan via gpg encrypten en via http post of ftp op een server uploaden om gemakkelijk zonder iedere keer op afstand in te loggen te downloaden/lezen.

http://rkhunter.sourceforge.net/

[edit]kijk maar eens wat rkhunter doet, en naar opties in die rkhunter.conf met wat googlen erbij en handleiding etc waartoe veel mogelijkheden via internet gegeven zijn krijg je heel veel te leren...

"Gehacked" betekent niets. De vraag de je hier stelt is het equivalent van de medische student die zich vertwijfeld afvraagt of'ie lupus heeft. Dat is dus niet echt een nuttige vraag. Mischien dat je kan beginnen daar wat aan te doen.

Dat doe je door met de Stealth file integrity checker onder de radar te gaan. Denk heel goed na over hoe je dat goed opzet. Win advies in van collega's die er ervaring mee hebben. Het alternatief is tripwire, ook een Debian pakket.

https://fbb-git.gitlab.io/stealth/

https://packages.debian.org/stretch/stealth

Doe jij eens beter een beetje rustig. Heel veel media etc roept over 'gehacked' dus krijgen sommigen daar op zo'n forum als hier over te praten. Gehacked betekend gecompromitteerd en dat is niet 'niets'.

@TS (topic starter);
als je dat voorbeeld over rkhunter gekregen hebt te bekijken, zijn er nog wat mogelijkheden gegeven op vlak van memory mapping/management, waarbij bijvoorbeeld Rekall een handige tool is;

http://www.rekall-forensic.com/

https://www.forensicswiki.org/wiki/Linux_Memory_Analysis

https://en.wikipedia.org/wiki/Memory_protection

het is bijvoorbeeld handig om mogelijkheden nader bekeken te krijgen van commandos als free and vmstat.

en type ook eens 'man mlock' en 'man 2 mlock' etc in om nog wat meer te weten te krijgen (gebruik q toets om uit linux handleidingen interface te gaan). onder aan de pagina zie je bijv. 'See also: proc(5)' en om daar te komen toets je 'man 5 proc'. handig he? proc is handig om te begrijpen bij security.

hier nog wat handleidingkjes/presentaties die mensen die handig zijn;

http://www.enterprisenetworkingplanet.com/netsysm/article.php/3741281/Understand-Linux-Virtual-Memory-Management.htm

https://www.coursera.org/lecture/hacking-patching/security-in-memory-systems-and-virtual-memory-layout-BNwTk (stukkie handige videopresentatie is wel gemakkelijk gratis te 'testen')

en dan hier wat meer gecompliceerde voorbeelden om nóg meer geleerd te krijgen, misschien kost dat wat tijd alleen dat is wel heel leerzaam als je interesse gekregen hebt;

https://blog.gdssecurity.com/labs/2017/9/5/linux-based-inter-process-code-injection-without-ptrace2.html

en beter onthouden dat die rekall tool een hele handig is om geheugen te helpen automatisch bewaakt te krijgen.. :)

Bedankt voor je velen tips, ik ga deze uitproberen

Kèk naah je ège.

Dat wil niet zeggen dat ze daar wat nuttigs roepen, of dat het hier hetzelfde nadoen ineens wel wat betekent.

Vandaar de vraag: Waar wil je het nou echt over hebben? Welke problemen danwel dreigingen ben je bang voor? Benoemen graag. Expliciet en in detail. Of je kan vragen wat de gebruikelijke dreigingen zijn. En ook dan komen we vrij snel op allerlei details als "wat doen je servertjes nou eigenlijk?"

Dat maak jij ervan. Vaak genoeg blijkt het toch "we hebben er zelf een zooitje van gemaakt" te betekenen, alleen wilde iemand dat niet toegeven. Dus is het minstens dubbelzinnig en daarmee al gewoon geen nuttige basis om op te bouwen. Dus als je "gecompromitteerd" bedoelt, zeg dan ook "gecompromitteerd".

haha @anoniempje à la 'kèk naah je ège'; thumbs up xD

Ik werk met persoonlijke data van een universiteit.
Ik heb een webserver en database en een tussen database om de achterste database onbereikbaar te maken zeg maar.
De bedreigingsniveau is hoog en realistisch en verwacht dat zelfs dat staatshackers ons zullen aanvallen omdat universiteiten regelmatig door inlichtingendiensten worden gehacked.

Overweeg om met Stealth ook automatisch de md5sum digest van respectievelijk een binary dump van de BIOS firmware en de MBR van de harde schijf periodiek te controleren. Wijzingen daarin zijn uiterst verdacht.

Lees daarvoor met de flashrom utility het BIOS live uit en gebruik DD voor het verkrijgen van een binary dump van de maindrive bootblock. Gebruik md5sum ter controle. Uitleg, zie ook het volgende topic:

https://www.security.nl/posting/581736

Als dan het zogenoemde bedreigingsniveau zo hoog is, dan de volgende vragen;

1. krijg je een vaste bezoekersbase zeg maar die moeten inloggen?
2. krijgen die bezoekers vanaf vaste ips in te loggen of ook vanaf onbekende ips?
3. in hoeverre krijgen bezoekers verstand van threatlevel, dus vormen in principe zwakste schakel?
4. is het alleen die backoffice database die threatlevel oorzaak genoemd wordt?
5. behoort die 'tussendatabase' realtime verbonden met backend database of is update/synchronisatie toereikend om functie webplatform?
6. behoort backend db beschrijfbaar te zijn of volstaat readonly toegang?
7. krijgen jullie middelen om verschillende internet aansluitingen te benutten en/of andere hosting partij in te schakelen?
8. MOET beide backend en frontend db per sé via database server software of behoort flat database bij een van beide tot de mogelijkheden/ preferably bij frontend (in combinatie met voordelen bijv. bestandsssyteemfuncties bijv.)?
9. vertel aub dat mobiele toegang/smartphones NIET HOEVEN?????

paar tips;
1. liever niet met php werken maar met perl cgi.
2. liever nginx dan apache2, ook sneller
3. pas op met military grade security en ubuntu, liever gentoo qua linux of bsd, niet dat er bij ubuntu base geen mogelijkheden gegeven zijn, alleen voorzichtig gezegd 'anders' en véél meer broncode controle en configuratie nodig.
4. frontend en backend via verschillende internet aansluitingen
5. bij military grade liefst géén mobiele toegang via bijv. smartphones tot db functies en wanneer dan smartphones waarbij gebruiker niet zelfs controle over telefoon/apps krijgt OF enorm inboeten qua veiligheid met zelf geschreven dikke app en dan via encrypted rss db functies bijvoorbeeld.

Bedankt voor deze goede tip!

Jij bent ook de TS? Anoniem is hierin zo waardeloos... .

Misschien gewoon eens met de universiteit IT afdeling overleggen? Die hebben vaak veel meer kennis gegeten van dit soort beveiligingen. Als jij werkelijk het doelwit kan zijn van staatshackers of inlichtingendiensten dan moet je er zelf niet eens aan beginnen. Je moet dan over hele andere beveiligingsmaatregelen gaan denken. SIEM, IDS/IPS. Maar je moet je huidige host nooit vertrouwen voor scanning.

De tip bevat een fout.

Gebruik in plaats van md5sum de veiliger sha256sum. Het MD5 algoritme wordt niet langer als veilig beschouwd. Sommige inmiddels slechte gewoonten op de commandline slijten helaas langzaam.

Een sha512sum onder stealth toepassen zou nog beter zijn, maar dat kan qua reken tijdsduur onpraktisch worden zodra honderden files en binaries, waaronder de tevens de MBR en de BIOS firmware, periodiek moeten worden controleerd.


https://en.wikipedia.org/wiki/Md5sum

Helemaal mee eens (even de gedachte van een troll daargelaten) kan dit niet iets zijn van één persoon met als enige ondersteuning een forum als dit (ondanks alle goede bedoelingen).

Een aanvullende leestip: Micah Lee

https://theintercept.com/2018/04/28/computer-malware-tampering/


De auteur legt daarin uit hoe je monitoring van laptop firmware kunt uitvoeren.

Vergeet niet een md5hash van de tripwire db (/var/lib/tripwire) te maken na elke tripwire --init en deze op te schrijven.
Iemand met roottoegang kan je IDS ook gewoon validaten namelijk dus je merkt niets.

Goede exploits laten niets achter in je syslog of in systemd logs.

Rkhunter en chkrootkit zijn zeer oud en checken slechts op bekende (oude) rootkits en standaard dingen als open poorten, promisc mode van je NIC. Een goede moderne rootkit zit op kernel/module niveau en ook in de bootsector en zal geen Open poorten (TCP) laten zien of UDP traffic naar bepaalde IP's net zoals processen van de rootkit die uit de processlist blijven.

Deze utilities zjin dus niet betrouwbaar. Tripwire is handig maar alleen als je een hash van de tripwire database ergens anders bewaart want root kan die database gewoon rebuilden (en ook logs van eventuele utilities clearen).

Ik wil me op malware focussen en ik zie dat nieuwe technieken inhouden dat ze 1) niets naar disk schrijven (dus tripwire heeft geen zin) en 2) na een reboot uit het geheugen zijn. Het analyzen van geheugendumps is de enige methode om deze malware te vinden en zo ver ben ik nog niet. Maar dit is een interessante uitdaging waar ik me jaren zoet mee kan houden ;)

Hoe weet je dat (zeker)? Indien er succesvol als root toegang is verkregen kan immers elk spoor worden gewist. Er zou een server ontwerp nodig zijn met een log waaraan je nieuwe records kan toevoegen en daarna alleen nog maar lezen en niet verwijderen, waarmee alles wordt vastgelegd, om zoiets te kunnen detecteren. Zoals bv. dit:

Cryptographic Support for Secure Logs on Untrusted Machines - B. Schneier and J. Kelsey: "ABSTRACT: In many real-world applications, sensitive information must be kept in log files on an untrusted machine. In the event that an attacker captures this machine, we would like to guarantee that he will gain little or no information from the log files and to limit his ability to corrupt the log files. We describe a computationally cheap method for making all log entries generated prior to the logging machine's compromise impossible for the attacker to read, and also impossible to undetectably modify or destroy." - https://www.schneier.com/academic/archives/1998/01/cryptographic_suppor.html

Ik heb niks kunnen waarnemen wat mij doet vermoeden dat onze servers gehacked zijn. Hoe krijg ik volgens jou zo'n ontwerp server ontwerp nodig zijn met 'write-once, read-only' logging? (want heb er nooit van gehoord)

Nee, dat is nu net de clou. Je kan het niet weten want een hacker met root kan immers alle sporen wissen...


Zie mijn post hierboven (iets lager scrollen dan jouw quote daarvan): https://www.security.nl/posting/585677/Re%3A+Server+monitoren

Tenzij je een fatsoenlijke aparte syslog server hebt, eventueel op een ander OS in een ander domein met andere credentials en 2FA.

De auteur geeft aan UEFITool te gebruiken om de BIOS firmware te dumpen, i.p.v. flashrom. Omdat in sommige gevallen bepaalde sectoren van de firmware om legitieme redenen kunnen wijzigen. Bijvoorbeeld door het eigenhandig wijzigen van het ingestelde boot volume. Met flashrom krijgt men dan naderhand een verkeerde checksum uitslag.

Met het gebruik van UEFITool kan een vals negatieve checksum test worden vermeden. Door alleen een checksum van de vaststaande gedeelten te maken, maar de sector met instellingen buiten beschouwing te laten.

https://github.com/LongSoft/UEFITool

Gebruik in plaats van md5sum de veiliger sha256sum. Uitleg is in eerder commentaar hierboven te vinden.


Om die reden moet je de IDS dan ook niet op de server of database zelf plaatsen, maar op een aparte dedicated logserver die de UPT kabel van de server passief snift met een eenvoudige, stille switch, die fungeert als een T-split. Vergelijk dit met een stil alarm, buiten de MAC-registratie en local IP-adressen tabel van de LAN router om. Voor de LAN router bestaat 'ie niet.

Dan kan je die aparte syslog server prima beveiligen met Cryptographic Support for Secure Logs on Untrusted Machines - B. Schneier and J. Kelsey. Of wil je de logs op die aparte syslog server met een andere aparte syslog server gaan beveiligen? En die dan weer met nog een aparte syslog server. En die...

Hoe kan je dan met zekerheid zeggen dat je niet gehacked bent ? Beetje tegenstrijdig je uitspraak. Indien je dit al na kan gaan, dan is dit hele topic toch overbodig; dan weet je immers reeds hoe je dit moet doen.

Excuses, ik weet niet met zekerheid of wij gehacked zijn. Ik heb inderdaad alleen niks kunnen observeren of wij wel of niet gehacked zijn en ik wil met dit soort maatregelen verder te kunnen uitsluiten of ik wel of niet ben gehacked en er zijn een paar goede tips langsgekomen die ik in de toekomst ga implementeren na het overleg wat ik met mijn baas ga hebben.