Linux Beveiliging

[Peppershade]

Op dit forum zitten best veel IT beheerders, en ik vroeg me af wat jullie gebruiken en doen om een Linux server goed te beveiligen tegen de boze buitenwereld. Zoals welke firewall software er veel wordt gebruikt met welke cruciale instellingen etc.

Zelf gebruik ik altijd Configserver Firewall met een disabled rootlogin + ssh user met minimale rechten. Maar ik ben zeker benieuwd wat andere doen en gebruiken.

[TommieW]

Beveiligen van wat, is eerder de vraag. Het is ook behoorlijk afhankelijk van welke software erop draait.

Sowieso altijd SELinux aan hebben om te beginnen. Daarnaast via firewalld alleen open zetten wat nodig is. En, misschien wel het belangrijkste, altijd bij blijven met patches.

Edit: SSH bij voorkeur niet open hebben staan richting het internet, gebruik daar een VPN voor. Als het echt niet anders kan: fail2ban.

[ Voor 19% gewijzigd door TommieW op 13-01-2018 19:49 ]

[tafkaw]

Fail2ban aan iptables haken.

[TheBorg]

CSF kan ook een rapportje uitdraaien met wat suggesties. Daar ga ik altijd even doorheen. Daarnaast alles up to date houden en voor de rest niks.

[AW_Bos]

TommieW schreef op zaterdag 13 januari 2018 @ 19:48:

Edit: SSH bij voorkeur niet open hebben staan richting het internet, gebruik daar een VPN voor. Als het echt niet anders kan: fail2ban.

Bij sterke voorkeur geen root-pass gebruiken, maar SSH-keys.
SSH eventueel op andere poort draaien.

[TheBorg]

Ik moest even zoeken maar het is

code:

csf -m

Deze server draaid geen mail services. Heb je CPanel dan zijn de suggesties wel wat uitgebreider.

[ Voor 13% gewijzigd door TheBorg op 13-01-2018 20:04 ]

[unezra]

AW_Bos schreef op zaterdag 13 januari 2018 @ 19:58:
[...]

Bij sterke voorkeur geen root-pass gebruiken, maar SSH-keys.

Uberhaupt rootlogin uit zetten. Nergens voor nodig. Daar heb je sudo voor.
Rootpassword als je het al hebt, enkel via het console toe staan en veilig maken.

SSH eventueel op andere poort draaien.

Dat noemen ze:
Security-by-obscurity.

In geen geval is dat een goed idee en het is vooral doodonhandig.
Want:
a) je moet onthouden op welke poort ssh draaide
b) in je firewall (als je die buiten je linux doos hebt) moet je opeens rare poorten gaan toe staan

Zijn nog wat meer redenen waarom je dat niet moet willen.

[eric.1]

Software Firewall op iedere machine? Alle servers hangen achter ons Firewall-cluster; dit cluster handelt de voornaamste filtering/Firewalling af.
- Scheiding dmv VLAN's + alleen verkeer toestaan wat vooraf gedefinieerd is dmv Firewalling (zowel in- als outbound)
- Geen overbodige of verouderde software op de servers laten staan.
- Scheduled updates
- AIDE
- Policies (login/password/password-expire...)
- Sysctl hardening
- Rsyslog
- SELinux
- NTP goed configureren
- Logs extern opslaan
- Audits/Scans/Steekproeven/monitoring
- Password-management (hoe dus iedere werknemer wachtwoorden opslaat)
- Toegangsbeheer (welke medewerker wel/niet bij welke server moet kunnen)
...

Maarja, het ligt er natuurlijk wel aan wat voor server het is en waarvoor deze dient.

[MainframeX]

Voor wat betreft ssh; gewoon key based authenticatie gebruiken en password auth uitzetten. Dan kan je de ssh port gewoon open laten staan in de firewall, desnoods met fail2ban om op z'n minst bruteforce protectie te hebben.

Verder is eigenlijk alles al genoemd vwb basis beveiliging. Hardening is een hele andere kwestie en zou ik echt toespitsen op de applicatie stack die je draait.

[mcmking]

Ik raad jou aan om naar de website center of internet security te gaan, hierin zijn pdf bestanden met mooie richtlijnen om een server te beveiligen (redhat, centos, ubuntu, oel, andere linux servers etc.). Je kan ook in google CIS compliance opzoeken.

[HollowGamer]

TommieW schreef op zaterdag 13 januari 2018 @ 19:48:
Beveiligen van wat, is eerder de vraag. Het is ook behoorlijk afhankelijk van welke software erop draait.

Sowieso altijd SELinux aan hebben om te beginnen. Daarnaast via firewalld alleen open zetten wat nodig is. En, misschien wel het belangrijkste, altijd bij blijven met patches.

Edit: SSH bij voorkeur niet open hebben staan richting het internet, gebruik daar een VPN voor. Als het echt niet anders kan: fail2ban.

Zonder SELinux of Appammor ben je niet perse slechter af.
Genoeg andere manieren om je te beveiligen: firejail, containers, etc.

Inderdaad geen SSH openzetten, al zou dit wel weer kunnen met keys.
Maar liever gebruik ik inderdaad een OpenVPN verbinding en dan pas andere services linken.

Zie ook: https://wiki.archlinux.org/index.php/Security

[ Voor 3% gewijzigd door HollowGamer op 14-01-2018 20:08 ]

[Barreljan]

Kijk ook eens naar Lynis voor het stukje hardening. Daarin de scan worden diverse zaken aangehaald (sysctl, http, malware, user dingen etc etc)

https://cisofy.com/lynis/

Geeft veel input over zaken die beter kunnen. Niets is verplicht, je moet per item ook wel je eigen onderzoek doen wat het inhoud en goed controleert na je wat aanpast.

Hoe ik beveiling nu heb? Eerst SSL VPN naar hardware firewall, dan op de servers:
SELinux enforcing (altijd leuk met labels in de web dirs ) , iptables (input en forwarding default drop) + Fail2ban, SSH-key (root disabled), mijn user in wheel (sudo) maar met password, maldet voor malware scanning en dan met behulp van Lynis hardening toepassen (waarbij de hardening score uiteindelijk 85 of hoger moet zijn) én via /etc/profile een stukje code toegevoegd wat alle commands logged naar syslog en de lokale syslog daemon dit specifieke niet in file opslaat maar remote logged.

edit;
tevens elke week in cron: yum update --security
elke maand in cron: yum update (met check if kernel update >> reboot)

verdere cruciale items?
in /etc/rc.d/rc.local een verwijzing naar een shell script die mailt dat de machine gereboot is én een script die checkt (en mail if not) of selinux enforcing is

ntp/dns en zulke items zijn basis dingen die je natuurlijk goed hebt evenals je domain/hostname

[ Voor 21% gewijzigd door Barreljan op 17-01-2018 12:28 ]

[Kafka]

In /etc/hosts.allow
sshd:{jouw ip adres}


In /etc/hosts.deny
sshd:all


Alle ip’s worden voor ssh geblokkeerd behalve jouw ip adres.
Wel oppassen want deze rule is direct aktief.

Ssh server moet wel tcp wrappers ondersteunen.
Werkt ook voor andere services, zoals ftpd of httpd.

[ Voor 36% gewijzigd door Kafka op 20-01-2018 10:13 ]

[Lethalis]

Qua beveiliging doe ik niet heel veel, behalve de standaard dingen:
- PfSense firewall er tussen. Dit blokkeert al zo ongeveer alles, behalve de services die ik met de buitenwereld wil delen.
- Machines regelmatig bijwerken, zodat de diensten die open staan zo min mogelijk bekende vulnerabilities hebben.
- Goede wachtwoorden gebruiken. Dit voorkomt een hoop ellende.
- VPN's gebruiken voor toegang vanaf remote locaties (vaak IPSEC verbindingen die via de PfSense lopen).

Soms twijfel ik weleens of ik toch SSH beschikbaar zal stellen buiten de VPN om (omdat die er toch nog best vaak uit ligt).

Mocht ik dat gaan doen, dan zou ik:
- Met beveiligde key pairs gaan werken. Dan heb je de key en het wachtwoord nodig (something you have + something you know).
- Eventueel alleen bepaalde IP adressen toestaan.
- Als ik echt paranoide ben, alles dat ik open zet in aparte Linux containers draaien.

Naar mijn idee zit ik dan redelijk safe. Natuurlijk kun je er veel meer aan doen, maar de vraag is hoe zinvol dat is.

[ Voor 4% gewijzigd door Lethalis op 20-01-2018 14:08 ]

[Thc_Nbl]

Ik gebruik eigenlijk alleen nog ufw + iptables GEO ip en fail2ban combinatie.
SSH en POP/IMAP zijn alleen mogelijk vanaf een nederlands ip (geoip) en de rest via ufw en fail2ban.
voor mail gebruik ik z-push (ActiveSync) + apache voor de exchange support voor mobiele devices, zodat het wel toegankelijker blijft voor de gebruikers en tot nu toe bevalt dit prima.

[GlowMouse]

unezra schreef op zaterdag 13 januari 2018 @ 20:08:
[...]

Uberhaupt rootlogin uit zetten. Nergens voor nodig. Daar heb je sudo voor.

Dat noemen ze:
Security-by-obscurity.

Zolang je met een eigen ssh-key moet inloggen als root (of als je de enige admin bent), is het uitzetten van de rootlogin ook een vorm van security-by-obscurity.

[unezra]

GlowMouse schreef op zaterdag 20 januari 2018 @ 23:50:
[...]
Zolang je met een eigen ssh-key moet inloggen als root (of als je de enige admin bent), is het uitzetten van de rootlogin ook een vorm van security-by-obscurity.

Nope. Dat is het niet.
Je maakt daadwerkelijk je attach surface kleiner door het uitschakelen van rootlogin plus dat je met sudo veel meer traceability hebt over wie wat heeft gedaan.

[syl765]

Sudo vind ik geen oplossing.
Wat je ziet op onze servers waar veel beheerders op actief zijn is dat men standaard altijd al begint met sudo.
Als pietje inlogt, en gewoon een listing doet van zijn home dir dan typt pietje ~ sudo ls -al
Je ziet het vooral bij de jongere linux admins. De regels beginnen met sudo is er zo ingeslepen dat het een automatisme is geworden.

Een tweede gevaar met sudo (mijn mening) is dat je root rechten koppelt aan meer dan alleen de root key.
Je hebt voor al je gebruikers met sudo rechten dus ook een wachtwoord.
stel je hebt 50 admins die allemaal sudo rechten hebben, dan heb je dus 50 verschillende wachtwoorden waarmee je als root je ding kan doen. Ik weet je kan via sudo ook presies bepalen wat user x wel en niet mag, maar in de praktijk zie je vaak toch gewoon userx mag alles.

ssh laten luisteren op een andere poort is geen definitieve oplossing, maar voorkomt wel dat de scripts die langs wandelen jou server zullen overslaan op het SSH vlak.
De simpelere script kiddies zullen ook denken er is geen SSH aanwezig. Je vangt zo al een hoop ellende af.
Ten tweede, gebruik je firewall om alles wat geen toegang nodig heeft te blokkeren. SSH is dus alleen toegankelijk voor jou bekende ip adressen. Ja soms vervelend als je ergens anders zit, maar wel de beste oplossing.

En natuurlijk gebruik je gezond verstand. Patch je server en hou je logs in de gaten.

[ Voor 4% gewijzigd door syl765 op 21-01-2018 11:17 ]

[CH4OS]

unezra schreef op zaterdag 13 januari 2018 @ 20:08:
Dat noemen ze:
Security-by-obscurity.

In geen geval is dat een goed idee en het is vooral doodonhandig.
Want:
a) je moet onthouden op welke poort ssh draaide
b) in je firewall (als je die buiten je linux doos hebt) moet je opeens rare poorten gaan toe staan

Zijn nog wat meer redenen waarom je dat niet moet willen.

Volgens mij doelde @AW_Bos op de combinatie. Obscuur wellicht, maar het helpt wel degelijk. Port forward stel je eenmalig in en in de meeste ssh apps kun je connecties / sessies aanmaken, dus ook 1 keer instellen. Vervolgens hang je er ssh keys aan.

Thc_Nbl schreef op zaterdag 20 januari 2018 @ 23:43:
Ik gebruik eigenlijk alleen nog ufw + iptables GEO ip en fail2ban combinatie.
SSH en POP/IMAP zijn alleen mogelijk vanaf een nederlands ip (geoip) en de rest via ufw en fail2ban.
voor mail gebruik ik z-push (ActiveSync) + apache voor de exchange support voor mobiele devices, zodat het wel toegankelijker blijft voor de gebruikers en tot nu toe bevalt dit prima.

Geo ip (of andere externe) databases nooit vertrouwen. Bij mijn vorige isp had ik maandenlang een ip adres uit Djibouti (volgens de Geo ip database) terwijl ik toch echt in Nederland zit.

[ Voor 37% gewijzigd door CH4OS op 21-01-2018 11:38 ]

[unezra]

syl765 schreef op zondag 21 januari 2018 @ 11:15:
Sudo vind ik geen oplossing.
Wat je ziet op onze servers waar veel beheerders op actief zijn is dat men standaard altijd al begint met sudo.
Als pietje inlogt, en gewoon een listing doet van zijn home dir dan typt pietje ~ sudo ls -al
Je ziet het vooral bij de jongere linux admins. De regels beginnen met sudo is er zo ingeslepen dat het een automatisme is geworden.

Sorry!?
sudo vind je geen oplossing?

sudo is niet voor niets standaard op een aantal distro's en daar de enige manier om in te loggen.
Het idee achter sudo is enerzijds een stuk extra beveiliging (je hoeft geen rootpassword te delen, het rootpassword leg je in de kluis voor noodgevallen) en traceability. Als een sysadmin een f*ckup maakt is veel makkelijker te achterhalen wie dat is geweest. (Tenzij diegene moedwillig zijn/haar sporen uit wist maar dan heb je reden voor een compleet ander gesprek.)

Een tweede gevaar met sudo (mijn mening) is dat je root rechten koppelt aan meer dan alleen de root key.
Je hebt voor al je gebruikers met sudo rechten dus ook een wachtwoord.
stel je hebt 50 admins die allemaal sudo rechten hebben, dan heb je dus 50 verschillende wachtwoorden waarmee je als root je ding kan doen. Ik weet je kan via sudo ook presies bepalen wat user x wel en niet mag, maar in de praktijk zie je vaak toch gewoon userx mag alles.

Als je extra beveiliging wilt doorvoeren, zorg je er voor dat iedereen 2 accounts heeft.
1 mortal user account en 1 elevated account. Dat elevated account maak je lid van de sudoers groep en je verlangt van iedereen dat dat wachtwoord een ander wachtwoord is dan het reguliere mortal user wachtwoord.

Een enkel rootpassword dat iedereen die systeembeheer taken moet uitvoeren weet, is een veel groter gevaar dan sudo. (Het fijne is ook nog eens, gaat iemand uit dienst, blokkeer je dat account en kan diegene niets meer. Zonder welk wachtwoord dan ook ooit te veranderen.)

Je kunt ook nog met ssh keys werken. Heb je meteen 2-factor authentication te pakken. (Of Yubikey met een strong password danwel met OTP.)

Heel veel manieren om zoiets veilig te maken. Sudo niet gebruiken wegens bovengenoemde redenen is er daar alleen niet 1 van.

ssh laten luisteren op een andere poort is geen definitieve oplossing, maar voorkomt wel dat de scripts die langs wandelen jou server zullen overslaan op het SSH vlak.
De simpelere script kiddies zullen ook denken er is geen SSH aanwezig. Je vangt zo al een hoop ellende af.

Die ellende vang je ook af met een goede firewall, fail2ban en eventueel een accesslist op je ssh. (Precies wat je hier boven beschrijft, enkel toe staan vanaf bekende IP adressen.)

Het is niet "geen definitieve oplossing", het is een van de klassieke vormen van security by obscurity en in mijn beleving per definitie een ontzettend slecht idee.

Ten tweede, gebruik je firewall om alles wat geen toegang nodig heeft te blokkeren. SSH is dus alleen toegankelijk voor jou bekende ip adressen. Ja soms vervelend als je ergens anders zit, maar wel de beste oplossing.

ssh toegankelijk maken voor enkel bekende IP adressen is wél een extra laag van beveiliging en geen security-by-obscurity.
Je sshd op een andere poort laten draaien is enkel dat en ontzettend onhandig. Het levert extra onveiligheid op. Stel dat je ssh op poort 34211 laat draaien (om een willekeurig poortnummer te noemen), iemand komt vers binnen in je organisatie of je documenteert het slecht (of je hebt iemand van buiten nodig om je te assisteren), diegene ziet een vreemd poortnummer en moet gaan zitten herleiden waar dat in vredesnaam voor dient. In het beste geval knalt 'ie het dicht in de firewall want vreemd poortnummer.

Well known ports zijn er met reden. Het houd je firewall en beveiliging logisch en precies dat levert meer veiligheid op dan iets als ssh op een rare poort laten draaien.

En natuurlijk gebruik je gezond verstand. Patch je server en hou je logs in de gaten.

[GlowMouse]

unezra schreef op zondag 21 januari 2018 @ 08:41:
[...]


Nope. Dat is het niet.
Je maakt daadwerkelijk je attach surface kleiner door het uitschakelen van rootlogin plus dat je met sudo veel meer traceability hebt over wie wat heeft gedaan.

De attack surface wordt niet kleiner, want je moet een ander account aanmaken en sudo-access geven. Na een succesvolle aanval kunnen alle sudo-traces worden gewist, dus ook dat zie ik niet als een veiligheidsvoordeel. Bij meerdere admins kan het gebruik van sudo best voordelen bieden, maar veiligheid komt enkel door obscurity.

[unezra]

GlowMouse schreef op zondag 21 januari 2018 @ 16:33:
[...]
De attack surface wordt niet kleiner, want je moet een ander account aanmaken en sudo-access geven. Na een succesvolle aanval kunnen alle sudo-traces worden gewist, dus ook dat zie ik niet als een veiligheidsvoordeel. Bij meerdere admins kan het gebruik van sudo best voordelen bieden, maar veiligheid komt enkel door obscurity.

Veiligheid komt NOOIT door obscurity.

Het hele idee van "security-by-obscurity" word gezien als niet veilig. Veiligheid bereik je op andere manieren, niet door je ssh poort op een niet standaard poort te zetten.

En hoe denk je dat je al je traces kunt wissen als het sudo account gehackt is?
http://hintcafe.net/post/...tralized-sudo-and-logging

Als een account gehackt word weet je niet of dat de schuld van diegene is, maar je kunt het account wel meteen dicht zetten zonder dat je compleet al je toegang tot het systeem kwijt bent (tenzij de aanvaller dat onmogelijk heeft gemaakt) en iedere actie is gelogd op een extern systeem.

sudo heeft eigenlijk altijd voordelen en ik kan geen nadelen bedenken, wel kan het handig zijn het rootpassword in de kluis te leggen en enkel via het console toegankelijk te maken. (Dus nooit remote.)

Helemaal leuk, combineer dit met een centraal authenticatiesysteem en je hebt nog wat extra veiligheid. Medewerker uit dienst of wachtwoord gelekt: Account centraal uitschakelen en nérgens meer toegang toe.

Met sudo kun je dan ook weer leuke dingen uithalen door mensen specifieke rechten te geven en specifieke rechten te ontnemen. Ook dat draagt bij aan de veiligheid. Er is veel meer mogelijk dan "sudo su -" en lokale accounts

[ Voor 14% gewijzigd door unezra op 21-01-2018 16:47 ]

[GlowMouse]

unezra schreef op zondag 21 januari 2018 @ 16:44:
[...]


En hoe denk je dat je al je traces kunt wissen als het sudo account gehackt is?
http://hintcafe.net/post/...tralized-sudo-and-logging

Met remote logging krijg je met sudo evenveel bruikbare informatie bij een hack als bij een root-login. Loggen van sudo biedt zeker voordelen, maar niet bij een succesvolle aanval.

Als een account gehackt word weet je niet of dat de schuld van diegene is, maar je kunt het account wel meteen dicht zetten zonder dat je compleet al je toegang tot het systeem kwijt bent (tenzij de aanvaller dat onmogelijk heeft gemaakt) en iedere actie is gelogd op een extern systeem.

Je kunt iemands ssh-key ook uitcommenten bij de root-user.

Helemaal leuk, combineer dit met een centraal authenticatiesysteem en je hebt nog wat extra veiligheid. Medewerker uit dienst of wachtwoord gelekt: Account centraal uitschakelen en nérgens meer toegang toe.

Een centraal authenticatiesysteem kan ook gebruikt worden voor de root-user.

Met sudo kun je dan ook weer leuke dingen uithalen door mensen specifieke rechten te geven en specifieke rechten te ontnemen. Ook dat draagt bij aan de veiligheid. Er is veel meer mogelijk dan "sudo su -" en lokale accounts

Dat draagt zeker bij aan veiligheid, maar daarvoor hoeft root login niet te worden uitgeschakeld.

Ik zie geen enkel steekhoudend argument waarom het uitschakelen van de root-user geen vorm is van security-by-obscurity. Als je op internet zoekt, is het belangrijkste argument telkens dat scriptkiddies altijd het root-account proberen omdat die op elk *nixsysteem bestaat.

[unezra]

GlowMouse schreef op zondag 21 januari 2018 @ 17:50:
[...]
Met remote logging krijg je met sudo evenveel bruikbare informatie bij een hack als bij een root-login. Loggen van sudo biedt zeker voordelen, maar niet bij een succesvolle aanval.

Niet?
Met remote logging weet je *exact* wat de aanvaller heeft gedaan. Dat lijkt me best nuttig om te weten.

[...]
Een centraal authenticatiesysteem kan ook gebruikt worden voor de root-user.

Klopt maar je mist precies datgene dat sudo zo belangrijk maakt:
Traceability. Als iemand met sudo een f*ckup maakt weet je wie je de oren moet wassen, met root niet. Het hele idee is dat in een ideale wereld, iedere beheeractie word gelogd en herleidbaar is naar een account. (Idealiter naar een persoon maar dat is heel lastig tenzij je met biometrie gaat werken. Voor fysieke toegang is dat wel te doen en gebeurt dat ook, in beheer is dat eigenlijk alleen mogelijk als je met 4-ogen constructies gaat werken. Ik weet dat in specifieke gevallen dat ook gedaan word. Dan weet je ook exact welke actie door wie is uitgevoerd omdat er tenminste 1 getuige is van de actie.)

[...]
Dat draagt zeker bij aan veiligheid, maar daarvoor hoeft root login niet te worden uitgeschakeld.

De grap is dus nu net dat je remote root login juist wel moet uitschakelen voor een extra stuk veiligheid, maar dat het lokaal heel handig kan zijn. Sloop je op de eoa manier sudo, is het handig om er als root op het console nog in te kunnen. Aan de andere kant, sloop je sudo, is misschien een rescue cd ook nog wel een optie.

Ik zie geen enkel steekhoudend argument waarom het uitschakelen van de root-user geen vorm is van security-by-obscurity. Als je op internet zoekt, is het belangrijkste argument telkens dat scriptkiddies altijd het root-account proberen omdat die op elk *nixsysteem bestaat.

Klopt, maar dat maakt de maatregel nog geen security-by-obscurity.
Je schakelt daadwerkelijk een stukje van het attack surface uit door een account uit te schakelen. Da's heel wat anders dan ssh op een andere poort laten draaien die je binnen ongeveer 30 seconden gevonden hebt. Een uitgeschakelde rootlogin betekend dat je er als root niet meer in kunt, met ssh ligt dat anders. 1 nmapje d'r overheen en je bent er.

Nadelen van ssh op een andere poort laten draaien heb ik al eerder in dit topic genoemd. Juist daardoor, is het gevaar groter door het te verplaatsen dan de winst die het oplevert...

[gekkie]

GlowMouse schreef op zondag 21 januari 2018 @ 17:50:
Ik zie geen enkel steekhoudend argument waarom het uitschakelen van de root-user geen vorm is van security-by-obscurity. Als je op internet zoekt, is het belangrijkste argument telkens dat scriptkiddies altijd het root-account proberen omdat die op elk *nixsysteem bestaat.

Nehh bestond overal behalve op Apple's dan heh, nouja tenzij je er lief om vroeg, dan bestond het opeens wel weer, zonder password, want we hadden er geen. Hoe zouden we dat moeten noemen .. security-by-...
En de obscure workaround was om gewoon wel een root account met password aan te maken .

Overigens scheelt het, als je je ssh poort niet limiteert tot een beperkt aantal ip-addressen, wel aardig in de karrevracht aan logging als je je SSH niet op de default poort draait.
Wat er dan nog aanklopt en gelogd wordt, heeft kennelijk al iets meer moeite gedaan en is derhalve interessanter dan de wetenschap dat 1001-scriptkiddies met hun lampionnetje voor je deur staan.

Overigens is je sudo wijzigen wel een van de meer irritante dingen, zeker als het gelijk live moet.
Foutje is zo gemaakt en gelijk vrij desastreus.
Fijn met een screen of tmux je sessie in leven houden .. een "sudo -i" en vervolgens eerst testen met een separate shell of de meuk nog werkt. En in de tussen tijd schietgebedjes dat de bak niet om een andere reden toevallig plat gaat.

[ Voor 15% gewijzigd door gekkie op 21-01-2018 18:09 ]

[Thralas]

unezra schreef op zondag 21 januari 2018 @ 11:47:
Een enkel rootpassword dat iedereen die systeembeheer taken moet uitvoeren weet, is een veel groter gevaar dan sudo. (Het fijne is ook nog eens, gaat iemand uit dienst, blokkeer je dat account en kan diegene niets meer. Zonder welk wachtwoord dan ook ooit te veranderen.)

Ik denk dat we even onderscheid moeten maken tussen situaties. Enerzijds een systeem dat voor thuisgebruik door één beheerder wordt beheerd, anderzijds een gedeelde machines waar er zo nu en dan verloop is in de set beheerders.

99/100 keer stelt hier iemand de vraag in de context van een thuisgebruiker waar er sprake is van een enkele beheerder en dan papegaait iedereen hier dat rootlogin uitmoet omdat het o-zoveel veiliger is.

Volgens mij is dat waar @GlowMouse het mee oneens is, en daar heeft 'ie wat mij betreft helemaal gelijk in.

Je kunt ook nog met ssh keys werken. Heb je meteen 2-factor authentication te pakken. (Of Yubikey met een strong password danwel met OTP.)

Iedereen zou met keys moeten werken, zeker op machines die aan het internet hangen. Als dat het gevak was dan waren alle SSH-bruteforcers allang out of business.

Een key met een wachtwoord vind ik de term 2FA niet waard. Tenzij je die key in een smartcard bewaart is toegang tot één machine om zowel de key als het wachtwoord te achterhalen. Een Yubikey is wel een prima voorbeeld.

unezra schreef op zondag 21 januari 2018 @ 16:44:
Het hele idee van "security-by-obscurity" word gezien als niet veilig.

Ik denk dat dit alleen klopt als je het nuanceert tot de notie dat 'security by obscurity' altijd sluitpost in je beveiligng is, het systeem zonder obscurity in principe óók veilig is en daarnaast dat het ook een noemenswaardige inspanningsverhoging oplevert.

Het voorbeeld van de poorten faalt op dat laatste (iemand die wérkelijk wilt weten waar je SSH draait weet dat binnen een minuut), maar het principe is hartstikke valide. Zo niet: bel de NSA even op inzake Suite A.

Helemaal leuk, combineer dit met een centraal authenticatiesysteem en je hebt nog wat extra veiligheid. Medewerker uit dienst of wachtwoord gelekt: Account centraal uitschakelen en nérgens meer toegang toe.

Dat is dan ook een van de usecases waar het disablen van rootlogin wél nuttig is.

Met sudo kun je dan ook weer leuke dingen uithalen door mensen specifieke rechten te geven en specifieke rechten te ontnemen. Ook dat draagt bij aan de veiligheid. Er is veel meer mogelijk dan "sudo su -" en lokale accounts

Maar die use cases zijn dermate specifiek dat het niet echt als een concreet voordeel benoembaar is in een lijstje 'algemene' securitytips.

Niet?
Met remote logging weet je *exact* wat de aanvaller heeft gedaan. Dat lijkt me best nuttig om te weten.

Je verbouwt z'n argument. Hij betwistte het nut van remote logging niet, enkel dat sudo daar niets aan toevoegt.

Traceability. Als iemand met sudo een f*ckup maakt weet je wie je de oren moet wassen, met root niet.

Overal 'sudo' voor tikken is twee seconden een goed idee, daarna doet iedereen gewoon 'sudo su', mezelf incluis.

Het hele idee is dat in een ideale wereld, iedere beheeractie word gelogd en herleidbaar is naar een account.

auditd lijkt me daar een geschiktere kandidaat voor dan sudo

Je schakelt daadwerkelijk een stukje van het attack surface uit door een account uit te schakelen.

Ik geloof dat je voor wat betreft beheer, auditing en logging absoluut een punt hebt, maar qua 'attack surface' werkt dat alleen in die zeer specifieke gevallen.

GlowMouse schreef op zondag 21 januari 2018 @ 17:50:
Ik zie geen enkel steekhoudend argument waarom het uitschakelen van de root-user geen vorm is van security-by-obscurity.

@unezra had een punt in het geval van centrale authenticatie - op een systeem met meerdere gebruikers kun je dan gemakkelijker zien wie er (vermoedelijk) inlogde.

Als je op internet zoekt, is het belangrijkste argument telkens dat scriptkiddies altijd het root-account proberen omdat die op elk *nixsysteem bestaat.

Dat is inderdaad meestal de reden waarom het hier wordt geroepen. Spijker, kop.

In de meeste gevallen komt de vraagstelling voort uit een gebruiker die als enige beheerder z'n server managet en daar alleen op inlogt voor beheer waarvoor rootrechten vrijwel onontkoombaar zijn. Dan voegt het disablen van remote root niets, nul, nada toe.

EDIT: bonus, deze twee artikelen vond ik erg inspirerend voor SSH security in een enterpiseomgeving:

Meet Securitybot: Open Sourcing Automated Security at Scale
Distributed Security Alerting

[ Voor 3% gewijzigd door Thralas op 21-01-2018 18:43 ]

[unezra]

Thralas schreef op zondag 21 januari 2018 @ 18:28:
[...]
Ik denk dat we even onderscheid moeten maken tussen situaties. Enerzijds een systeem dat voor thuisgebruik door één beheerder wordt beheerd, anderzijds een gedeelde machines waar er zo nu en dan verloop is in de set beheerders.

99/100 keer stelt hier iemand de vraag in de context van een thuisgebruiker waar er sprake is van een enkele beheerder en dan papegaait iedereen hier dat rootlogin uitmoet omdat het o-zoveel veiliger is.

Volgens mij is dat waar @GlowMouse het mee oneens is, en daar heeft 'ie wat mij betreft helemaal gelijk in.

Als dat de reden is van het oneens zijn:

Ik redeneer vanuit een bedrijfsomgeving of tenminste vanuit een omgeving met meerdere beheerders. Hoewel ik het gebruik van sudo en het non-gebruik van rootlogin ook in privé situaties beter vind en de argumenten vóór rootlogin compleet moot.

[...]
Iedereen zou met keys moeten werken, zeker op machines die aan het internet hangen. Als dat het gevak was dan waren alle SSH-bruteforcers allang out of business.

Een key met een wachtwoord vind ik de term 2FA niet waard. Tenzij je die key in een smartcard bewaart is toegang tot één machine om zowel de key als het wachtwoord te achterhalen. Een Yubikey is wel een prima voorbeeld.

Yubikey kan op 2 manieren. OTP en met een strong password eventueel gecombineerd met een eigen passphrase dat je als aanvulling op dat password gebruikt. Technisch is ook dat laatste 2FA. Het is op de grens, maar omdat je op die manier kunt werken met wachtwoorden die geen zinnig mens kan onthouden, is het veiliger dan een kort wachtwoord dat nog wel te onthouden is en beschermt het beter tegen brute-force attacks domweg omdat een wachtwoord langer en complexer kan zijn.

OTP is natuurlijk volledig 2FA.

Met ssh keys kan dat anders zijn. Een ssh key wil je veilig bewaren maar als die machine waar de key op staat er een is waar je niet zomaar bij kunt, is het vind ik wel 2FA als snap ik dat je het op het randje vind.

[...]
Ik denk dat dit alleen klopt als je het nuanceert tot de notie dat 'security by obscurity' altijd sluitpost in je beveiligng is, het systeem zonder obscurity in principe óók veilig is en daarnaast dat het ook een noemenswaardige inspanningsverhoging oplevert.

Ik denk dat security by obscurity geen veiligheidsvoordeel oplevert, enkel veiligheidsnadelen.
Het is niet voor niets een praktijk die word afgeraden.

Je mag het dus ook niet als sluitpost in je beveiliging gebruiken, je moet het gewoon niet toepassen.

Het voorbeeld van de poorten faalt op dat laatste (iemand die wérkelijk wilt weten waar je SSH draait weet dat binnen een minuut), maar het principe is hartstikke valide. Zo niet: bel de NSA even op inzake Suite A.

Zie mijn eerdere argumenten. Je hebt het binnen een minuut te pakken en je hebt opeens een vreemde poort die je in je firewalls moet doorlaten. Alleen dat al levert een extra risico op.

[...]
Dat is dan ook een van de usecases waar het disablen van rootlogin wél nuttig is.

Ofwel: In bijna iedere andere case dan een enkele individuele vm of pc heb je daar mee te maken en is het uitschakelen van rootlogin zinvol. De corner case is nu net die losse PC.

[...]
Maar die use cases zijn dermate specifiek dat het niet echt als een concreet voordeel benoembaar is in een lijstje 'algemene' securitytips.

Specifiek?
Ik vind de PC thuis veel specifieker dan iedere omgeving met meerdere machines en beheerders.

[...]
Je verbouwt z'n argument. Hij betwistte het nut van remote logging niet, enkel dat sudo daar niets aan toevoegt.

Mijn argument is dat sudo altijd wat toe voegt en remote logging die waarde versterkt omdat traces minder makkelijk te verwijderen zijn.

[...]
Overal 'sudo' voor tikken is twee seconden een goed idee, daarna doet iedereen gewoon 'sudo su', mezelf incluis.

Dan nog kun je zien wie op een bepaald moment sudo su - heeft getikt.
Da's al beter dan het niet gebruiken van sudo. (Maar ik kan me prima situaties voorstellen waar je direct een goed gesprek hebt met je leidinggevende als je sudo su - tikt... Als je dat al mag en dat niet keihard is uitgeschakeld.)

[...]
auditd lijkt me daar een geschiktere kandidaat voor dan sudo

Combinatie lijkt me nog beter.
Het een sluit het ander niet uit.

[...]
Ik geloof dat je voor wat betreft beheer, auditing en logging absoluut een punt hebt, maar qua 'attack surface' werkt dat alleen in die zeer specifieke gevallen.

Ik vind dat niet zo specifiek. Maar goed, ook daar. Context waar vanuit ik redeneer is niet de context van een PCtje thuis of een enkel individueel vmetje van een particulier.

[...]
@unezra had een punt in het geval van centrale authenticatie - op een systeem met meerdere gebruikers kun je dan gemakkelijker zien wie er (vermoedelijk) inlogde.

De enige échte uitdaging is dat je alleen kunt zien welk account er inlogde, niet welke persoon dat was. Dat kan alleen als je met 4-ogen systemen gaat werken en dat is inderdaad een corner-case.

[...]

Dat is inderdaad meestal de reden waarom het hier wordt geroepen. Spijker, kop.

In de meeste gevallen komt de vraagstelling voort uit een gebruiker die als enige beheerder z'n server managet en daar alleen op inlogt voor beheer waarvoor rootrechten vrijwel onontkoombaar zijn. Dan voegt het disablen van remote root niets, nul, nada toe.

EDIT: bonus, deze twee artikelen vond ik erg inspirerend voor SSH security in een enterpiseomgeving:

Meet Securitybot: Open Sourcing Automated Security at Scale
Distributed Security Alerting

Ook eens doornemen. Sowieso een van de zaken om komend jaar eens naar te kijken.