[Linux] Gehacked, kan niet meer inloggen..

[aKeY]

Hallo,

Mijn linux machine is dus na alle zekerheid gehacked....
Ik heb mijn machine dus 2 jaar zonder problemen online gehad, totdat ik er gisteren achterkwam dat ik via imap niet meer kon inloggen.

Na wat zoek werk kwam ik erachter dat er een aantal files zijn gewijzigd waaronder, passwd, shadow, gshadow en group.
Deze zijn allemaal gewijzigd in dezelfde naam, alleen met een - je erachter.

Ook stond in mijn /etc dir een file genaamd: .pwd.lock

Ook was er nieuw account met root rechten aangemaakt: CAI
Ik kan nu dus zelf niet meer inloggen vanuit de shell of via een ssh verbinding.

Ik heb de machine dus van het inet gehaald, en ingelogd via "linux single" om alle ww files weer terug te zetten.
Het inloggen via ftp gaat nu wel weer, maar via shell of ssh kan ik niet inloggen.

Als ik op de shell, met een account wil inloggen typ ik de usernaam in maar na de ENTER springt ie direct weer terug op LOGIN:

Ik heb een vermoede dat iemand via ssh is binnengekomen (draai nog een oudere versie) en ik heb van de week even mijn ssh verbinding open moeten leggen naar de wereld omdat ik vanuit een andere lokatie in moest loggen dan alleen op mijn interne netwerk...

Iemand enig id, hoe ik het weer voormekaar kan krijgen dat ik weer in kan loggen op de shell?

[Solarsparc]

Als je gehackt bent, kun je het beste ff helemaal reinstallen. Je weet nooit wat voor troep (backdoors, rootkits, etc.) zo'n hacker achterlaat op je systeem, je kunt het iig nooit meer 100% vertrouwen zonder reinstall.

[_nethack]

Het inloggen lukt wel, maar je wordt gelijk weer uitgelogged?
Kijk eens wat er aan de hand is met de shell van de user.
Zowieso maakt het weinig uit, de enige juiste optie in namelijk een herinstallatie van de machine.

[aKeY]

Als ik de username intyp en dan enter, krijg ik geen leeg veld voor het ww, maar spring weer direct terug om mijn username in te typen...

Als ik kijk naar bv. het root account, staat er gewoon /bin/bash als shell....

Inderdaad, ik was ook van plan om het systeem op nieuwe te installeren, maar ik wil wel nog even wat dingen backuppen (configfiles voor apache etc...)

[-FoX-]

Als je er direct weer uitspringt heeft te maken dat je shell niet geladen kan worden.

[Verwijderd]

Is er ingesteld (bij SSH) dat je niet via root kan inloggen ?

[aKeY]

Verwijderd schreef op 26 januari 2003 @ 15:19:
Is er ingesteld (bij SSH) dat je niet via root kan inloggen ?

Je kan dus gewoon met root inloggen als je wilt, dit doe ik alleen nooit, altijd via een su-

Ook een les voor de volgende keer....

[aKeY]

-FoX- schreef op 26 januari 2003 @ 15:19:
Als je er direct weer uitspringt heeft te maken dat je shell niet geladen kan worden.

Waar kan ik dit zo vinden, behalve dat dit goed staat in de passwd file?

[_nethack]

aKeY schreef op 26 januari 2003 @ 15:15:
Inderdaad, ik was ook van plan om het systeem op nieuwe te installeren, maar ik wil wel nog even wat dingen backuppen (configfiles voor apache etc...)

Heel goed opletten wat je overzet naar de nieuwe installatie!!
Data meenemen is geen probleem, maar configfiles zul je regel voor regel moeten nalopen.
Absoluut geen binaries en/of sources van het systeem overzetten, ook daar kunnen backdoors inzitten!

[Verwijderd]

staat er nog wat in je logs? (wie heeft er via ssh ingelogd?)
en mocht je 'm niet opnieuw installeren kijk dan ook goed naar de output van netstat

[aKeY]

_nethack schreef op 26 January 2003 @ 15:22:
[...]

Heel goed opletten wat je overzet naar de nieuwe installatie!!
Data meenemen is geen probleem, maar configfiles zul je regel voor regel moeten nalopen.
Absoluut geen binaries en/of sources van het systeem overzetten, ook daar kunnen backdoors inzitten!

Klopt, ga ik ook goed opletten..
Ik kan trouwens zien als ik een "lastlog" deels waar de gene vandaan komt:

subdomein.subdomein.?.? het lijkt of ie de regel afkapt...

Kan ik nog ergens anders zien (geen /var/log/secure, want daar staat verder niks interresants in) waar iemand gelogd staat met inloggen?

[Verwijderd]

Verwijderd schreef op 26 januari 2003 @ 15:26:
staat er nog wat in je logs? (wie heeft er via ssh ingelogd?)
en mocht je 'm niet opnieuw installeren kijk dan ook goed naar de output van netstat

Netstat is meestal een van de eerste dingen die een rootkit vervangt voor een trojan versie. Gebruik liever lsof om dergelijke backdoors te zien, hoewel lsof net zo makkelijk vervangen kan worden. In de praktijk gebeurd dat alleen minder dan dat netstat wordt vervangen.

Kan ik nog ergens anders zien (geen /var/log/secure, want daar staat verder niks interresants in) waar iemand gelogd staat met inloggen?

Los van het feit of je nog meer in je logs vindt hoeft dit niet perse de aanvaller te zijn. Logfiles kunnen gewist of gewijzigd zijn en ook de machine in je logs kan weer gehacked zijn. Alleen met de medewerking van de admins van die machine zou je eventueel verder terug kunnen zoeken, maar of dat de moeite waard is?

[ Voor 32% gewijzigd door Verwijderd op 26-01-2003 15:34 ]

[Verwijderd]

aKeY schreef op 26 January 2003 @ 15:21:
Je kan dus gewoon met root inloggen als je wilt, dit doe ik alleen nooit, altijd via een su-

Ook een les voor de volgende keer....

Maakt niet uit als je het via SSH doet vanwege de encryptie.

[aKeY]

Ik ben dus zelf admin van die machine, dus moet ik hetzelf oplossen...

Maargoed, ik heb dus alle logfiles doorgezocht waarvan ik dacht daar kan ik iets vinden, maar niks dus...
Het enigste wat ik kan zien over de gebruiker die ingelogd was, is met "lastlog", daar staat een inlog van het account root, vanaf een voor mij onbekend domein..

Wat ik nu alleen wil is, toch de shell aan de gang krijgen zodat ik het 1 en ander nog kan doen, anders moet ik steeds in "linux single" mode opstarten en dat lijkt mij niet de bedoeling...

Als ik trouwens probeer te connecten via mijn windows ssh client (puTTY) krijg ik een connection refused....

Terwijl de machine wel online is en aan het internet hangt... (ander kon ik momenteel niet posten hier... )

[ Voor 20% gewijzigd door aKeY op 26-01-2003 15:48 ]

[Verwijderd]

Kijk eens of de rechten van je bash, sh , csh goed staan .

[ Voor 82% gewijzigd door Verwijderd op 26-01-2003 16:10 ]

[Buffy]

Als je genoeg ruimte hebt op je harddisk/partitie voor een tweede install kan je ervoor kiezen om de huidige installatie naar een quarantaine directory te verhuizen een een schoon installatie op de bestaande partitie aan te brengen.

Dus:

- booten vanaf (schone) rescue disk
- mounten root partitie
- in gemounte root partitie mkdir quarantaine
- met mv alle directories verplaatsen in de directory quarantaine
- nieuwe install op bestaande partitie (niet overschrijven dus )
- booten nieuwe install, inloggen en data en (gecontroleerde) config terug zetten uit de quarantaine directory.
- laatste patches installeren
- alle passwoords vernieuwen die op die bak stonden (fetchmail, pap/chap secrets etc) of die afgeluisterd kunnen zijn.

[-FoX-]

shell-probleem:
rechten nakijken op die shell
shell controleren op wijzigen (naam ed)

je probleem dat je krijgt komt voor als de verwijzing in je passwd niet teruggevonden kan worden, waardoor de shell niet opgestart kan worden.

[Verwijderd]

Als je je bak opnieuw osptart, dan als boot parameter meegeven

init=/bin/sh

Dan hoef je niet in te loggen en kan je als root aan de slag gaan, en dus ook
Cai verwijderen.

[Verwijderd]

Als je graag je data wil backuppen kan je misschien ook deze HD in een andere pc hangen en een backup maken. Daarna kan je hem dan weer in je server terug doen en je kan weer veilig opnieuw installeren.

[aKeY]

Ik heb ffe een complete backup gemaakt van alles files die ik nodig vond....
Config files bekeken op eventuele aanpassingen etc....

Ik ben nu een nieuwe machine aan het inrichten met redhat 7.3 (de gehackte was 7.0) en 8.0 wil ik nog niet draaien, waarom dat weet ik ook niet .

Meteen even alle laatste updates eroverheen doen na de redhat install + alle pakketten die ik draaide : ssh, apache, ftp etc.... updaten naaar de laatste versies, en hopen dat die klojo die het wilde verzieken het laat om nog eens iets te proberen...

NOG meer aan beveiliging doen, ga ik zeker even naar kijken....

Iemand nog tips met nuttige logfile checkers of automatische portscan blokkers ala nmap ofzoiets?
Of een link naar uitvoerige beschrijving van bescherming van linuxmachines? (dus niet de basics...)

[Verwijderd]

Het is wel een debian howto, maar normaal gezien kan je hier ook voldoende uithalen over het hoe en wat
http://www.debian.org/doc...ebian-howto/index.en.html

let er ook op dat je je beveiliging niet exact hetzelfde opzet, anders weet de "hacker" weer dadelijk je zwakke plek.

[deadinspace]

aKeY schreef op 26 januari 2003 @ 15:09:
Na wat zoek werk kwam ik erachter dat er een aantal files zijn gewijzigd waaronder, passwd, shadow, gshadow en group.
Deze zijn allemaal gewijzigd in dezelfde naam, alleen met een - je erachter.

/etc/passwd- en soortgelijke files zijn backup-files, gemaakt door programma's die die files wijzigen (zoals adduser en consorten). Die zijn niks om je zorgen over te maken.

Het feit dat de originele passwd files weg zijn is wel iets om over na te denken btw.

Ook stond in mijn /etc dir een file genaamd: .pwd.lock

Dat is een lock-file, om te zorgen dat niet meerdere programma's tegelijk aan de passwd files gaan knutselen. Die file hoort slechts tijdelijk te bestaan, maar als hij dat niet doet is een crack niet het eerste waar ik aan zou denken.
Waarschijnlijk staat deze file er nog om dezelfde reden dat de /etc/passwd files weg zijn - er is iets fout gegaan bij het editen van die files.

Ook was er nieuw account met root rechten aangemaakt: CAI

Dat is wel een serieuze reden om je zorgen te maken ja. Als je echt gecrackt bent, dan is dat btw waarschijnlijk wel de reden dat je passwd files pleite zijn.


Als je echt gecrackt bent (of heel sterk dat vermoeden hebt) dan is het inderdaad het veiligst om te herinstalleren. Dat is al vaker gezegd, maar het is wel belangrijk.
En security updates bijhouden uiteraard.

[Verwijderd]

aKeY schreef op 26 januari 2003 @ 19:28:

Ik ben nu een nieuwe machine aan het inrichten met redhat 7.3 (de gehackte was 7.0) en 8.0 wil ik nog niet draaien, waarom dat weet ik ook niet .

rh8 gebruikd apache2......is voor sommige mensen een goede reden.

je kan als je je nieuwe systeem opzet de oude partitie met de noexec en nodev optie mounten.....je weet maar nooit.

[aKeY]

Het nieuwe systeem is nu kaal geinstalleerd, morgen ga ik als eerste security updates draaien en alles dichtzetten... (het systeem hangt uiteraard nog niet aan het inet...)
Apache 2 laat ik nog even varen denk ik, ik blijf nog even bij het oude vertrouwde versie..

Maar ik ga dus wel even naar nieuwe versie's + patches van fetchmail, imap, sendmail, apache, en de rest van de "zaakjes" die ik had draaien kijken en probeer het ook vol te houden om deze regelmatig te updaten...

Het is nu bij een "hack" gebleven, zonder erge schade en dat wil ik graag ook zo houden in de toekomst... :-)

Bedankt allen voor uw response :-)

[The Jester]

Inderdaad: booten met linux init=/bin/bash en dan alles wegpleuren wat er niet in hoort.
Ook is het raadzaam een apart user-account aan te maken (bijv. 'remote') en alleen deze user SSH-rechten geven om in te loggen. Dan wordt 'root' gewoon geweigerd! Zelf inloggen kan dan met ssh -l remote <host> vervolgens su je naar root & voila!
Zorg ook even dat ALLEEN SSH2 geaccepteerd wordt !!

[alt-92]

Ik dacht dat een goed opgezette sshd config geen directe root login toeliet?

[Creepy]

BackSlash32 schreef op 27 January 2003 @ 08:12:
Ik dacht dat een goed opgezette sshd config geen directe root login toeliet?

Standaard word het niet toegestaan om remote in te loggen met root, maar je hebt altijd mensen die dit makkelijk vinden en dit zelf weer aanzetten.

IMHO staat dat in een "goed opgezette" sshd config uit ja, maar dat is dus persoonlijk.

Mijn sshd heb ik zo geconfigged dat alleen users met een valid shell kunnen inloggen. Normale gebruikers geef je dan /bin/false o.i.d. als shell en die users zullen nooit kunnen inloggen m.b.v. ssh.

[aKeY]

Op mijn systeem (redhat 7.0) was het zo dat ssh standaard geinstalleerd stond zodat root ook kon inloggen...

Maar dat ga ik dus wel even aanpassen op de nieuwe machine..

[deadinspace]

Creepy schreef op 27 January 2003 @ 08:39:
Standaard word het niet toegestaan om remote in te loggen met root, maar je hebt altijd mensen die dit makkelijk vinden en dit zelf weer aanzetten.

Standaard staat het tegenwoordig aan.

IMHO staat dat in een "goed opgezette" sshd config uit ja, maar dat is dus persoonlijk.

Eens

Mijn sshd heb ik zo geconfigged dat alleen users met een valid shell kunnen inloggen. Normale gebruikers geef je dan /bin/false o.i.d. als shell en die users zullen nooit kunnen inloggen m.b.v. ssh.

Bij mij moet een user in een bepaalde group zitten wil hij kunnen inloggen met SSH. Dat is nog stricter.

[Verwijderd]

standaard kunnen alle gewone users via ssh inloggen. dit is best onveilig. op sommige system zijn er genoeg gebruikers waarbij het passwd b.v. gelijk is aan de username en meer van dat soort dingen.
de meeste gebruikers gebruiken enkel ftp (webserver), imap/pop3 (mailserver) of samba/nfs (fileserver) en ze gebruiken dus ssh helemaal niet......ik stel het vaak so in dat mensen in de groep ssh moeten zitten om te kunnen ssh'en....

[Stalkert]

Goed laat ik de GOT db niet verder vervuilen en gebruik (misbruik) maken van dit topic. Ik zat zojuist wat in mijn access_log te kijken van mijn webserver en kwam daar tot het volgende. Kan iemand mij uitleggen wat hier gebeurt ?

code:

212.254.97.206 - - [27/Jan/2003:03:55:32 +0100] "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 282 "-" "-"
212.254.97.206 - - [27/Jan/2003:03:55:33 +0100] "GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 280 "-" "-"
212.254.97.206 - - [27/Jan/2003:03:55:33 +0100] "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 290 "-" "-"
212.254.97.206 - - [27/Jan/2003:03:55:34 +0100] "GET /d/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 290 "-" "-"
212.254.97.206 - - [27/Jan/2003:03:55:36 +0100] "GET /scripts/..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 304 "-" "-"
212.254.97.206 - - [27/Jan/2003:03:55:38 +0100] "GET /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 321 "-" "-"
212.254.97.206 - - [27/Jan/2003:03:55:41 +0100] "GET /_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 321 "-" "-"
212.254.97.206 - - [27/Jan/2003:03:55:42 +0100] "GET /msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 337 "-" "-"
212.254.97.206 - - [27/Jan/2003:03:55:43 +0100] "GET /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 303 "-" "-"
212.254.97.206 - - [27/Jan/2003:03:55:44 +0100] "GET /scripts/..%c0%2f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 303 "-" "-"
212.254.97.206 - - [27/Jan/2003:03:55:45 +0100] "GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 303 "-" "-"
212.254.97.206 - - [27/Jan/2003:03:55:47 +0100] "GET /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 303 "-" "-"
212.254.97.206 - - [27/Jan/2003:03:55:49 +0100] "GET /scripts/..%%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400 287 "-" "-"
212.254.97.206 - - [27/Jan/2003:03:55:52 +0100] "GET /scripts/..%%35c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400 287 "-" "-"
212.254.97.206 - - [27/Jan/2003:03:55:54 +0100] "GET /scripts/..%25%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 304 "-" "-"
212.254.97.206 - - [27/Jan/2003:03:55:57 +0100] "GET /scripts/..%252f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 304 "-" "-"

[Dommel]

Dat ziet er uit als een nimda/code-red aanval als ik me niet vergis.

[smoking2000]

Lijkt op een worm ala Nimda / Code Red aangezien het win32 files probeerd aan te spreken, niets om je zorgen over te maken.

edit:

ChristuS was net iets eerder.....

[ Voor 18% gewijzigd door smoking2000 op 27-01-2003 19:46 ]

[Spider.007]

Stalkert schreef op 27 januari 2003 @ 19:32:
Goed laat ik de GOT db niet verder vervuilen en gebruik (misbruik) maken van dit topic. Ik zat zojuist wat in mijn access_log te kijken van mijn webserver en kwam daar tot het volgende. Kan iemand mij uitleggen wat hier gebeurt ?

code:

.....

dat is een standaard code red attack; niets om je zorgen over te maken

edit:
nou, mooi drie antwoorden op een rij... en we zijn het allemaal met elkaar eens

[ Voor 12% gewijzigd door Spider.007 op 27-01-2003 19:48 ]

[miniBSD]

Je kunt eventueel nog de toegang beperken door middel van hosts.allow en hosts.deny en de toegang loggen:

sshd: ALL : twist = echo "sshd access %u@%h - %c on `date` " >> /var/adm/sshd.log

[aKeY]

Ik heb in /etc/host.deny alles dichtgezet, en in /etc/host.allow alleen wat nodig is om op mijn interne netwerk op de machine te komen....

Dank u miniBSD, ga ik meteen even aanpassen, zodat er nog mer gelogd word...

ik ga dit topic nu maar eens gebruiken om nog meer tips te krijgen om een veiliger systeem te krijgen...

Dank u nogmaals alvast

[aKeY]

Hmm als ik:

sshd: ALL : twist = echo "sshd access %u@%h - %c on `date` " >> /var/adm/sshd.log

probeer in de host.allow file en in hosts.deny zet ik ALL:ALL werkt dit niet.
Ik kan dus niet inloggen...

[miniBSD]

Je hebt helemaal gelijk, dit was voor af te wijzen en te loggen. Voor het toestaan moet je:

sshd: ALL: spawn = echo "sshd access %u@%h - %c on `date` " >> /var/adm/sshd.log : allow

[aKeY]

Ok dank je, ga ik vanavond meteen even proberen, ik zit op mijn werk momenteel...

[Verwijderd]

http://www.nsa.gov/selinux/index.html

't is ff lastig compilen, maar als het eenmaal draait is 'ie net zo stabiel, en nóg veiliger

[edit]
vergeet trouwens niet ext3 of reiserfs support aan te zetten, die staan niet default aan (was ik zelf de 1e keer compilen vergeten, kon ik weer opnieuw beginnen )

[ Voor 42% gewijzigd door Verwijderd op 29-01-2003 10:27 ]

[Verwijderd]

Wat voor xtra's bied dat selinux? iemand al ervaring? review?

[aKeY]

Hee dat werkt goed dat loggen van de sshd sessie's ! thanks :-)

Kan je op zo'n makkelijk manier ook loggen wie er wil connecten naar mijn proftpd server?
Daar zijn ook logs voor, maar dit is toch wel overzichtelijker vind ik

Alle security tips zijn welkom

[deadinspace]

aKeY schreef op 29 januari 2003 @ 18:55:
Alle security tips zijn welkom

Installeer logcheck. Die controleert periodiek je logs en mailt verdachte dingen naar jou (waarbij je kunt instellen wat precies verdacht is en wat niet).

[Verwijderd]

Wat je kunt doen is je syslogd extern logging over te geven aan een andere bak. Op die manier kan men logs verwijderen wat men wil, het wordt extern ook gelogged. Wel zorgen dat die externe bak secure is.

Een bridge met logging (snort/hogwash/iptables/etc) kan ook een leuke oplossing zijn.

Als ik jou was zou ik een reinstall doen, en eerst met een bootflop booten, dan alles overkopieren naar een andere bak/andere hdd. Zodat je alles later nog kunt uitzoeken.

It's cat & mouse play

[miniBSD]

Voor proftpd kun je ook werken met virtuele gebruikers. Dat wil zeggen dat deze gebruikers alleen geldig zijn voor ftp, en dus geen gebruiker zijn op je systeem.

http://www.castaglia.org/...mini-HOWTO-AuthFiles.html

[aKeY]

deadinspace schreef op 30 januari 2003 @ 10:52:
[...]

Installeer logcheck. Die controleert periodiek je logs en mailt verdachte dingen naar jou (waarbij je kunt instellen wat precies verdacht is en wat niet).

Heb ik ffe via google gezocht, staat nu in mijn bookmarks...
Heel handig pakketje inderdaad....

Ben nu bezig met verder alles aan het dichtzetten...
(inmiddels een nieuwe server geinstalleerd....)

[ Voor 6% gewijzigd door aKeY op 30-01-2003 23:11 ]

[Verwijderd]

Ook een echte aanrader is om de checklist van TrinityOS even stap voor stap te door lopen. Is bij mij eigenlijk het allereerste wat ik doe als ik een server geinstalleerd heb.

Daarna goede firewall installeren. Ik ben zelf erg gecharmeerd van Shorewall omdat deze zeer modulair en overzichtelijk is opgebouwd en biedt bovendien nog heel veel opties (VPN, blacklists etc).

Als derde stap gooi ik zelf altijd gelijk sendmail en wu-ftp eraf en vervang dat door Postfix en Proftp. Maar dat is een kwestie van smaak.

Laatste aanrader is Autoupdate installeren en dat in een cronjob zetten zodat de server zichzelf regelmatig update. Dat werkt uiteraard alleen als je voor een rpm installatie hebt gekozen.

Suc6 en sterkte verder...

[aKeY]

Verwijderd schreef op 31 January 2003 @ 00:21:
Ook een echte aanrader is om de checklist van TrinityOS even stap voor stap te door lopen. Is bij mij eigenlijk het allereerste wat ik doe als ik een server geinstalleerd heb.

Daarna goede firewall installeren. Ik ben zelf erg gecharmeerd van Shorewall omdat deze zeer modulair en overzichtelijk is opgebouwd en biedt bovendien nog heel veel opties (VPN, blacklists etc).

Als derde stap gooi ik zelf altijd gelijk sendmail en wu-ftp eraf en vervang dat door Postfix en Proftp. Maar dat is een kwestie van smaak.

Laatste aanrader is Autoupdate installeren en dat in een cronjob zetten zodat de server zichzelf regelmatig update. Dat werkt uiteraard alleen als je voor een rpm installatie hebt gekozen.

Suc6 en sterkte verder...

Dank je wel, hier heb ik zeker wat aan!
Ik ben nu mijn systeem volledig aan het patchen met de laatste rpm updates..

Ik was eigenlijk van plan om op mijn 7.1 (RH) ipchains te gaan gebruiken (omdat ik dan mijn script niet hoef aan te passen, maar Shorewall ziet er ook best spannend uit eigenlijk...
Eerst even afpatchen, en dan morgen de rest.....