[CentOS] server express stuk maken

[sjaakie]

Waarde system-engineers,

Twee collega's van mij moeten volgende week hun RHCE examen gaan doen. Om die redenen hebben ze ons (= de rest van het bedrijf) gevraagd om hun servertje te slopen als practice test...

Zijn er hier nog mensen die leuke ideeën hebben?

De regels:
- het moet een beetje lastig zijn
- het moet wel enigzins te herstellen/fixen zijn
- de real life cases scoren natuurlijk het beste...

[Cyphax]

Ik neem aan dat je iets anders wilt dan de standaard rm -rf / voor zover dat uberhaupt nog echt kan?

Eens kijken, leuke ideeen.. corrupt maken van /etc/passwd en de LAN-interface(s) mollen (softwarematig dan he)? Hebben die collega's trouwens fysieke toegang, en kunnen ze zo nodig bijvoorbeeld booten van LAN of CD?

[ Voor 3% gewijzigd door Cyphax op 05-09-2008 14:07 ]

[begintmeta]

Hardware beschadigen kan ook een behoorlijk real life scenario zijn (afhankelijk van de gebruikte hardware natuurlijk): bijvoorbeeld een defect netwerkkabeltje, een read-only IDE-kabeltje erin zetten, geheugen met wat foutjes erin...

Verder kun je kleine modificaties doen in configuratiebestanden, sockets op andere plaatsen laten aanmaken en het belangrijkste: flink rommelen met lees-en-schrijfrechten, remote exploits openen (&gewoon (root)account aanmaken zodat je eventuele correcties in bestanden of permissies weer ongedaan kunt maken totdat ze eraan denken dat hun server onveilig is...)

[ Voor 4% gewijzigd door begintmeta op 05-09-2008 14:22 ]

[deepbass909]

Als er een pATA schijf in zit, dan veroorzaakt het er scheef op drukken van de connector op de schijf ook altijd leuke effecten (van wel goed herkent worden, maar IO-fouten, tot helemaal niet werken of juist foutloos werken).

Je kan ook zelf busybox/bin-utils zelf compileren met verkeerde optimalisaties.

Of wat ook leuk gaat, je partitie waar op gelogt wordt, tot op een paar mb helemaal vol maken of een hele krappe quota geven. Dan mekkert de server nog niet dat hij geen logbestanden meer kan maken, maar wordt hij wel bagger traag en gaat rare fouten maken (services die spontaan stoppen omdat ze niet meer kunnen loggen). Omdat ze niet meer kunnen loggen, wordt het debuggen ook nog eens lastig. Ook leuk is om hem te laten loggen naar een virtuele memory disk. Bij een crash ben je dan ook direct je logbestanden kwijt.

[Wolfboy]

libc.so.* weggooien?
Filesystem/database/mail bestanden corrupt maken?

[Jaap-Jan]

mbr + partitieinformatie overschrijven met nullen of random data. Ik krijg er trouwens wel een gevoel van

[DiedX]

Wolfboy schreef op vrijdag 05 september 2008 @ 14:56:
libc.so.* weggooien?

^^

chattr +i op een paar cruciale files?

[stefklep]

passwd database legen of vol zetten met troep, root passworden verklooien enzo bepaalde processen in /etc/init.d/ aanpassen of allemaal chmoden zo dat ze niet gestart worden

[ Voor 38% gewijzigd door stefklep op 05-09-2008 15:02 ]

[Kees]

- foute gateway instellen (1 cijfertje anders oid, bijv 100.0.0.1)
- chattr op een paar leuke files
- /etc/fstab stukmaken
- sleep 100 voor sshd start
- libraries verkloten
- filesystems ro mounten ipv rw
- filesystem waar gelogt wordt vol maken / logfiles zeer groot maken

[DiedX]

Kees schreef op vrijdag 05 september 2008 @ 15:05:
- sleep 100 voor sshd start
..
- filesystems ro mounten ipv rw

[Rainmaker]

nssswitch vernaggelen (ldap erin zetten, zonder een LDAP server te configureren)
initrd weggooien
root uid 100 geven
/tmp non-writable maken
een filesystem tunen zodat 90% gebruikt kan worden door superuser (tune2fs -m 90)
etc.
etc.

[IcE_364]

code:

:(){ :|:& };:

in rc.local plaatsen

[Palomar]

IcE_364 schreef op vrijdag 05 september 2008 @ 15:13:

code:

:(){ :|:& };:

in rc.local plaatsen

wat doet dat? (nee, ga ik niet proberen).

[Dirk]

Hmm google helpt hier ook slecht: Resultaten 1 - 10 van circa 11.280.000.000

[alx]

Allemaal wel leuke ideeen, maar sommigen daarvan zijn zeer onwaarschijnlijk. Beetje zinloos om het systeem zodanig te vernaggelen dat het herinstalleren + bepalen dat dat nodig is minder tijd kost dan het fixen van het probleem. Bovendien:

sjaakie schreef op vrijdag 05 september 2008 @ 13:49:
[...]
- de real life cases scoren natuurlijk het beste...

- geen ruimte meer om te loggen
- ro ipv rw
- rotte of inconsistente configs
- ergens een (semi-)rotte netwerkkabel of connector
lijken me het meest logisch. Zijn ook weer te fixen.

- allerlei absurd ingestelde low-level file system dingen
- weggooien of vervangen met rotte versies van essentiele libs en andere binaries
- password en shadow files volledig corrumperen; root uid != 0
lijken me minder logisch.

--edit: wel een goede gelegenheid om het restoren van wat backupped (user)data eens te testen

[ Voor 5% gewijzigd door alx op 05-09-2008 15:33 ]

[Wirf]

IcE_364 schreef op vrijdag 05 september 2008 @ 15:13:

code:

:(){ :|:& };:

in rc.local plaatsen

Ik gok dat het iets is zoals:

code:

while true; do {
   while true; do
       true;
   done &
done &

oftewel een forkbomb

Edit: lol net ff hier lokaal geprobeerd om de syntax goed te krijgen... gelijk mn hele bak vast
_{(de syntax hierboven is dus niet goed)}

[ Voor 20% gewijzigd door Wirf op 05-09-2008 15:49 ]

[Verwijderd]

Mogen externe aanvallen ook?

[Rainmaker]

alx schreef op vrijdag 05 september 2008 @ 15:30:
- allerlei absurd ingestelde low-level file system dingen
- weggooien of vervangen met rotte versies van essentiele libs en andere binaries
- password en shadow files volledig corrumperen; root uid != 0
lijken me minder logisch.

- chattr is juist heel populair, daar staan al die studieboeken van RH131 mee vol. Laatst nog een "real-life" scenario gehad waarbij /tmp niet meer te beschrijven was.
- filesystem corruptie is very real. Daar kunnen je libraries ook door vernaggeld raken. Ik ben het met je eens dat dit wat moeilijk te repareren is.

[Eijkb]

Sommige dingen die ik hier lees staan gelijk aan "in brand steken", uiteraard ook een uitstekende optie.

Ik weet ook niet in hoeverre Sjaakie en collega's thuis zijn op de linux bak en welke rechten ze hebben? Bij een redelijk ingerichte installatie kan een gebruiker alleen zijn eigen gedeelte verkloten. Als je root rechten hebt kan je inderdaad van alles verkloten maar hou het wel reeël. Het zullen niet de eersten zijn die vol goede moed roepen "vern**k mijn installatie" en achteraf alleen een nieuwe installatie hebben gedraaid zonder het probleem te vinden.

Kloten met .passwd is bv. grappig maar zonder backup (als in: pleur ook de .bak bestanden weg) ook weer lastig te herstellen.

Heb zo geen tips, kom problemen genoeg tegen irl en die zijn iedere keer weer anders.

[Blonde Tux]

e2fsck /dev/hda(x) met een gemount fs

Gewoon kijken of tie oplettend is: De netwerkkabel loshalen

[deepbass909]

Een volle /var/log is bijzonder realistisch en veroorzaakt per app een andere reactie. De ene blijft gewoon door ratelen alsof er niks aan de hand is, de ander crasht finaal.

De TS wil storingen hebben die irl ook voorkomen. Een brakke IDE- of netwerkverbinding overkomt vrijwel iedereen eens in z'n leven en dat kan ook rare effecten hebben.

Een root password veranderen/onbruikbaar maken is misschien wel de meest gebruikte manier die een hacker toepast als hij root-access heeft gehad om het systeem onbruikbaar te maken.

[DiedX]

Zat me te bedenken: eea combineren met een leuke crontab?

[Sprite_tm]

Wat erg gemeen is maar ws wat lastig te regelen: Zorgen dat je swap op een schijf staat die stuk aan het gaan is. Heb ik es gehad: het erge is dat zelfs Knoppix (iig toendertijd) de swap probeert te gebruiken en keihard op z'n bek gaat, wat je niet echt verwacht van een live-CD in op de HD na goede hardware Verder zou je kunnen kijken of ze achter een 'dd if=/dev/random of=/lib/libc.so.6 count=100' kunnen komen, wat evt een real-life gevolg van filesystem corruption kan wezen, en wat best irritant te debuggen is.. En als 'weggevertje' zou je eens kunnen proberen of ze achter een lege CMOS-batterij kunnen komen: batterij van mobo afslopen, power van de PC af, power erop.

[dusty]

Een 'leuke met crontab'?: elk uur een shutdown laten uitvoeren.

[Sprite_tm]

Kan, maar hoe realistisch is dat?

Oeh, TS, als je besluit de server te slopen, wel ff posten hoe en of het ze gelukt is om 't te repareren

[ Voor 62% gewijzigd door Sprite_tm op 05-09-2008 16:51 ]

[Rainmaker]

Eijkb schreef op vrijdag 05 september 2008 @ 15:56:
Ik weet ook niet in hoeverre Sjaakie en collega's thuis zijn op de linux bak en welke rechten ze hebben? Bij een redelijk ingerichte installatie kan een gebruiker alleen zijn eigen gedeelte verkloten. Als je root rechten hebt kan je inderdaad van alles verkloten maar hou het wel reeël.

Als die collega's ook maar een kans willen hebben om het RHCE examen te halen, denk ik dat ze toch wel redelijk tot goed thuis zijn op een linux bak, of anders dit heel snel moeten gaan leren.

https://www.redhat.com/courses/rh302_rhce_exam/

The certification exam consists of two parts conducted in a single day. The exam is performance-based, meaning that candidates must perform tasks on a live system, rather than answering questions about how one might perform those tasks.
...
...
The audience for RH302 includes the following:
...
people with extensive system administration experience on the current version of Red Hat Linux, or with extensive experience on a recent version who are also familiar with changes between that version and the current version who have prepared for the exam on their own.

Tijdens het (praktijk) examen krijg je een machine die niet doet wat ie moet doen. Die moet je fixxen. Volgens mij krijg je wel gewoon root rechten, ook al weet ik dit niet zeker.

[ Voor 13% gewijzigd door Rainmaker op 05-09-2008 17:21 ]

[Arioch]

chown -R www-data:www-data /var

[ Voor 6% gewijzigd door Arioch op 05-09-2008 19:22 ]

[Seth4Chaos]

deepbass909 schreef op vrijdag 05 september 2008 @ 16:38:
Een volle /var/log is bijzonder realistisch en veroorzaakt per app een andere reactie. De ene blijft gewoon door ratelen alsof er niks aan de hand is, de ander crasht finaal.

Dat had ik vorige week nog, niet /var/log maar /var zelf. Doordat deze vol stond kon mysql zijn queries niet in de binary-log schrijven met gevolg dat die de (nieuwe) queries niet verwerkte.
Gevolg hiervan was dat de backups hingen (bacula) aangezien die gebruik maakt van mysql.
Het duurde even voordat ik erachter was aangezien het erop leek dat het de-spoolen niet goed ging...

dus als je een bak met bacula en mysql hebt is dit wel een leuke.

[pistole]

ook erg leuk is om je subnet van een netwerk te verandere in bijvoorbeeld /32 ; je leest daar erg makkelijk overheen (eigen ervaring.. )

[robbert]

Wirf schreef op vrijdag 05 september 2008 @ 15:36:
oftewel een forkbomb

Werkt zo'n formbom altijd op elke machine? Of kan men er iets aan doen zodat ze niet meer werken? Zou ik hiermee bijvoorbeeld alle publieke *n?x bakken op de uni plat kunnen krijgen (nee, ik was het niet van plan te proberen ).

edit:
Ik zie net Forkbomb - Prevention

[ Voor 12% gewijzigd door robbert op 06-09-2008 17:40 ]

[Verwijderd]

robbert schreef op zaterdag 06 september 2008 @ 17:38:
[...]

Werkt zo'n formbom altijd op elke machine? Of kan men er iets aan doen zodat ze niet meer werken? Zou ik hiermee bijvoorbeeld alle publieke *n?x bakken op de uni plat kunnen krijgen (nee, ik was het niet van plan te proberen ).

edit:
Ik zie net Forkbomb - Prevention

Onder debian en ubuntu wel mits de configuratie niet is aangepast. Maar bij unixen met goede defaults niet.

[daft_dutch]

Arioch schreef op vrijdag 05 september 2008 @ 19:21:
chown -R www-data:www-data /var

deze kan ik aan raden. er gaat veel zooi mis en het is te fixen.
vooral met een sql server en dat soort dingen in /var

[zomertje]

Een volle /var is ook irri, want dan zijn je logfiles ook niet compleet als je pech hebt

[Keiichi]

Probleempje waar ik vaak op heb lopen te vloeken is een volle filesystem bij een cups server.

Niet zo vel dat er door root niets meer geschreven kan worden (Tja, je hoort je printserver niet als root te draaien, maar toch). Logbestanden vullen zich gewoon aan, maar er is geen plek voor te spoolen. En cups is zo heerlijk k*t met loggen

[Olaf van der Spek]

sjaakie schreef op vrijdag 05 september 2008 @ 13:49:
Zijn er hier nog mensen die leuke ideeën hebben?

[CentOS 5.2] TCP connect timed out, geen firewall
Al is dat misschien wat lastig na te bootsen.

[TrailBlazer]

Ik weet niet wat die server moet doen maar een leuke fuckup maken in iptables is ook altijd leuk. Rechten op bestanden vernaggelen doet het ook altijd goed lijkt me. Verkeerde DNS server in /etc/resolv.conf waardoor resolven door de SSH daemon erg lang duurt zodat de inlogprompt nogal lang op zich laat wachten.

[_JGC_]

stateful firewall met iptables bouwen en met sysctl je net.netfilter.nf_conntrack_max setting erg laag zetten. Dan nog een oplossing vinden voor het feit dat er ook gelogd wordt naar dmesg, anders is het te makkelijk.
Heeft mij op een BSD firewall destijds 10 minuten kijken, een reboot en vervolgens nog 10 minuten op je hoofd krabben gekost. Problemen die je dan krijgt zijn als volgt:

#ssh webserver
- key incorrect melding (kwam nog door OpenSSL update van debian)
- ~/.ssh/known_hosts aanpassen
#ssh webserver
webserver: no route to host
#ssh 127.0.0.1
127.0.0.1: no route to host

dan ga je wel even vreemd staan kijken... oorzaak was een firewall met max 5000 states terwijl de servers achter de firewall liever 15000 hadden.

[ninjazx9r98]

Zet het default runlevel op 0

[Blonde Tux]

of 6

[odysseus]

Laatst heb ik een typfoutje in de regel voor mijn rootpartitie in mijn /etc/fstab gehad - en dat was behoorlijk lastig. Zodra er een fout zit in dat bestand, kan je die schijf alleen nog read-only mounten. Dat heeft tot gevolg dat je /etc/fstab niet kunt aanpassen, want die staat immers op de read-only partitie...simpel en realistisch probleem . Read-write remount werkt overigens niet, omdat dat altijd de fstab leest - zonder een (mij bekende / gedocumenteerde) manier om dat uit te schakelen.

[Wirf]

odysseus schreef op dinsdag 09 september 2008 @ 17:18:
Laatst heb ik een typfoutje in de regel voor mijn rootpartitie in mijn /etc/fstab gehad - en dat was behoorlijk lastig. Zodra er een fout zit in dat bestand, kan je die schijf alleen nog read-only mounten. Dat heeft tot gevolg dat je /etc/fstab niet kunt aanpassen, want die staat immers op de read-only partitie...simpel en realistisch probleem . Read-write remount werkt overigens niet, omdat dat altijd de fstab leest - zonder een (mij bekende / gedocumenteerde) manier om dat uit te schakelen.

Volgens mij kun je gewoon "mount -o remount,rw /" doen hoor?
Dat werkt bij mij tenminste wel altijd.

Maar ontopic: init=/bin/sh achter de kernel boot parameters zetten? (is nog vrij onschuldig)

[ajvdvegt]

Disable de loopback interface eens, dan is 'localhost' niet meer te resolven, wat allerlei vage vertragingen geeft.

[TrailBlazer]

Ik heb inderdaad wel eens in mijn firewallconfig al het verkeer van en naar het loopback gedenied. Allemaal interne processen gaan dan de mist in.

[Verwijderd]

Wirf schreef op dinsdag 09 september 2008 @ 19:38:
[...]


Volgens mij kun je gewoon "mount -o remount,rw /" doen hoor?
Dat werkt bij mij tenminste wel altijd.

Maar ontopic: init=/bin/sh achter de kernel boot parameters zetten? (is nog vrij onschuldig)

Dat werkt bij een verkeerde fstab waarschijnlijk niet omdat mount dan in fstab de bijbehorende partitie gaat zoeken. "mount -o remount,rw /dev/sda1 /" (vul voor sda1 natuurlijk je root device/partitie in) zou volgens mij wel moeten werken? Andere optie is;

code:

# mount /dev/sda1 /mnt
# cd /mnt/etc
# vi fstab

Moet kunnen aangezien je je root disk nog niet rw hebt gemount.

Back on topic, door een installatie met de franse slag heb ik een boot partitie waarvan mijn systeem gestart wordt maar die vervolgens niet gemount wordt. Om iets in grub te wijzigen moet daarom eerst de boot partitie ergens gemount worden. Met name frustrerend na een kernel update; "Waarom boot dat kreng nog steeds de oude kernel?"

Ook leuk is een proces dat zodanig veel naar een bestand schrijft dat de schijf vol loopt, dat bestand dan te verwijderen maar het proces laten draaien. (Nooit op linux uitgeprobeerd maar op HP-UX duurde het even voor ik doorhad dat de file wel weg was maar de inode nog in gebruik en dus de schijf nog steeds vol ... )

Op een raw database partitie (zoals met sybase of informix) een filesystem maken geeft fantastische meldingen in je database log.

Tenslotte, lang lang geleden eens gedaan (weet niet of het nog werkt), /dev/kmem overschrijven...

[WHiZZi]

of gewoon wat leuke grapjes met hdparm uitvoeren...
Bijvoorbeeld in de crontab wat schedulen, of met het at-commando

hdparm -U /dev/hdX # unregister IDE interface
hdparm -w /dev/hdx # Reset HDD

of als je het echt goed kaputt wil maken:

--make-bad-sector deliberately corrupt a sector directly on the media (VERY DANGEROUS)

of de syslogger kapot maken, geeft ook altijd fijne vragen

[Wolfboy]

TrailBlazer schreef op dinsdag 09 september 2008 @ 20:29:
Ik heb inderdaad wel eens in mijn firewallconfig al het verkeer van en naar het loopback gedenied. Allemaal interne processen gaan dan de mist in.

iptables -P INPUT drop
iptables -A INPUT -s 10.0.0.0/24 -j ACCEPT

En dan nog een lading "standaard" iptable regels, vind maar eens uit dat 127.0.0.0/8 er niet bij staat