ace3@midway.uchicago.edu
dd if=/dev/hda8 of=/etc/dosswap
gzip -9 /etc/dosswap
mkswap /dev/hda8 XXXXX
swapon -av
Zorg dat je een regel toevoegt in het /etc/fstab bestand voor de swappartitie
swapoff -av
zcat /etc/dosswap.gz | dd of=/dev/hda8 bs=1k count=100
# Merk op dat hiermee slechts de eerste 100 blokken naar de partitie worden
# teruggeschreven.
# Ik heb door ervaring gemerkt dat dit voldoende is
> Wat zijn hier de voors en tegens van?
Voors: je bespaart een substantiële hoeveelheid schijfruimte
Tegens: Als stap 5 niet automatisch gaat, dan moet je eraan denken dit met de hand te doen, en het vertraagt het rebootproces met een nanoseconde :-)
michael@actrix.gen.nz
Hier is een truuk die ik al een paar keer heb moeten gebruiken
Als je per ongeluk een tekstbestand verwijdert, zoals bijvoorbeeld wat email, of het resultaat van een programmeersessie op de late avond, hoeft alles niet verloren te zijn. Als het bestand het ooit naar disk haalde, d.w.z. dat het daar meer dan 30 seconden was, dan kan het zijn dat de inhoud nog steeds op de diskpartitie voorkomt.
Je kunt de opdracht grep gebruiken om de ruwe diskpartitie te doorzoeken op de inhoud van het bestand.
Ik verwijderde bijvoorbeeld onlangs per ongeluk een deel van m'n email. Dus staakte ik onmiddellijk mijn activiteiten die deze partitie konden wijzigen: in dit geval zag ik gewoon af van het opslaan van mijn bestanden of het uitvoeren van compilaties, enz. Onder andere omstandigheden heb ik me de moeilijkheid op de hals gehaald door het systeem in single user modus te brengen en het bestandssysteem te unmounten.
Ik paste toen de opdracht egrep toe op de diskpartitie: in mijn geval bevond het emailbericht zich in /usr/local/home/michael/, dus aan de uitvoer van df, kon ik zien dat dit op /dev/hdb5 was.
sputnik3:~ % df
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/hda3 18621 9759 7901 55% /
/dev/hdb3 308852 258443 34458 88% /usr
/dev/hdb5 466896 407062 35720 92% /usr/local
sputnik3:~ % su
Password:
[michael@sputnik3 michael]# egrep -50 'ftp.+COL' /dev/hdb5 > /tmp/x
Nu ben ik extreem voorzichtig wanneer ik met diskpartities aan de gang
ga, dus ik pauzeerde om er zeker van te zijn dat ik de syntax van de
opdracht begreep VOORDAT ik de return indrukte. In dit geval bevatte
de email het woord 'ftp' gevolgd door wat tekst gevolgd door het woord
`COL'. Het bericht bestond uit ongeveer 20 regels, dus gebruikte ik -50
om alle regels rondom de woorden te krijgen. Voorheen gebruikte ik altijd
-3000 om er zeker van te zijn dat ik alle regels kreeg van een of andere
broncode. Ik stuurde de uitvoer van egrep door naar een andere diskpartitie.
Hiermee voorkwam ik dat er over het bericht heengeschreven zou worden
waar ik naar aan het zoeken was.
Vervolgens gebruikte ik strings om me te helpen de uitvoer te inspecteren.
strings /tmp/x | less
Zeker weten dat de email zich daarin bevond.
Deze methode is niet betrouwbaar; alle of een deel van de schijfruimte kan reeds zijn hergebruikt.
Deze truuk is waarschijnlijk alleen bruikbaar op single user systemen. Op multi-user systemen met nogal wat diskactiviteit, kan de ruimte die je hebt vrijgemaakt reeds weer zijn gebruikt. En de meesten van ons kunnen niet zomaar de box vandaan trekken bij onze gebruikers wanneer we ooit een bestand moeten herstellen.
Op mijn systeem thuis is deze truuk me in de afgelopen paar jaar bij ongeveer drie gelegenheden van pas gekomen - gewoonlijk wanneer ik per ongeluk wat van het werk van die dag verwijderde. Als waar ik aan werk het overleeft tot een punt waarvan ik het gevoel heb dat ik een belangrijke voortgang hebt geboekt, wordt er op een diskette een backup van gemaakt, dus ik heb deze truuk nog niet zo vaak nodig gehad.
jadestar@rahul.net
Gebruik de Immutable Flag
Neem direct na de installatie en configuratie van je systeem de /bin, /sbin, /usr/bin, /usr/sbin en /usr/lib door (plus nog een paar van de andere gebruikelijke verdachte bestanden en maak royaal gebruik van de opdracht 'chattr +i '. Voeg dat ook toe aan de kernelbestanden in root. Nu 'mkdir /etc/.dist/' kopieer alles vanuit /etc/ naar beneden (Ik doe dit in twee stappen met /tmp/etcdist.tar ter voorkoming van recursie) in die directory. (Optioneel kun je gewoon /etc/.dist.tar.gz aanmaken) -- en dat als immutable markeren.
De reden voor dit alles is het beperken van de schade die je als root kunt aanrichten. Je zal geen bestanden overschrijven door een misplaatst omleidingsteken, en je zal het systeem niet onbruikbaar achterlaten door een verdwaalde spatie in een 'rm -fr' opdracht (je kunt nog steeds heel wat schade aan je gegevens aanrichten -- maar je libs en bins zullen veiliger zijn.
Dit maakt ook een diversiteit aan beveiligings- en denial of service uitbuitingen óf onmogelijk óf moeilijker (aangezien veel daarvan erop vertrouwen een bestand te kunnen overschrijven via de acties van een of ander SUID programma die *niet voorziet in een willekeurige shellopdracht*).
Het enige ongerief hierbij onstaat bij het bouwen en uitvoeren van een 'make install' op diverse soorten systeembinary's. Aan de andere kant voorkomt het ook dat een 'make install' de bestanden overschrijft. Wanneer je vergeet de Makefile in te lezen en chattr -i toe te passen op de bestanden die op het punt staan te worden overschreven (en de directory's waaraan je bestanden toe wilt voegen) -- mislukt de make. Je past er dan gewoon de chattr opdracht op toe en start het opnieuw op. Je kunt die gelegenheid ook gebruiken om je oude bin's, libs of wat dan ook naar een .old/ directory te verplaatsen of ze hernoemen of er tar op toepassen of wat dan ook.
jadestar@rahul.net
Alle nieuwe software begint onder /usr/local! of /usr/local/`hostname`
Als je distributie /usr/local leeg laat, creëer dan een /usr/local/src, /usr/local/bin enz en gebruik dat. Plaatst de distributie zaken in de /usr/local structuur dan wil je wellicht een 'mkdir /usr/local/`hostname`' uit laten voeren en er de groep 'wheel' +w aan toekennen (ik maak het ook SUID en SGID om ervan verzekerd te zijn dat elk lid van de wheel groep daaronder alleen iets met eigen bestanden kan doen, en dat alle aangemaakte bestanden zullen toebehoren aan de 'wheel' groep.
Disciplineer jezelf nu om *ALTIJD! ALTIJD! ALTIJD!* nieuwe packages onder /usr/local/src/.from/$WAAR_IK_HET_VANDAAN_HAALDE/ plaatst (voor de .tar of wat voor bestanden dan ook) en bouw ze onder /usr/local/src (of .../$HOSTNAME/src). Zorg dat ze onder de lokale hiërarchie worden geïnstalleerd. Plaats een symlink vanuit de lokale hiërarchie naar elk element dat ergens anders naartoe gaat als het *beslist moet" worden geïnstalleerd in /bin, /usr/bin of elders.
De reden hiervoor -- ook als is het wat meer werk -- is dat het helpt isoleren waarvan een backup moeten worden gemaakt en wat moet worden terruggezet van een backup of opnieuw geïnstalleerd in geval van een volledige herinstallatie vanaf de distributiemedia (tegenwoordig gewoonlijk van een CD). Door gebruik te maken van een /usr/local/.from directory houd je ook een informele log bij van waar je bronnen vandaan komen. -- wat helpt wanneer je op zoek bent naar nieuwe updates -- en van groot belang kan zijn bij het monitoren van de security announcement lists.
Een van mijn systemen thuis werd samengesteld voordat ik deze maatregelen zelf toepaste. Ik heb nog maar erg weinig met de configuratie van mijn thuissysteem gedaan en ik ben de *enige* persoon die het ooit gebruikt.
Als contrast zijn de systemen die ik op het werk heb ingesteld (toen mij hier de rol van systeembeheerder werd toevertrouwd) allen op deze manier ingesteld --- beheerd door veel contractanten en andere MIS mensen, zijn er een groot aantal upgrades en installatie van packages op geïnstalleerd. Niettemin heb ik een zeer goede indruk welke elementen precies werden geplaatst *na* de initiële installatie en configuratie.
dossey@ou.edu
Ik nam notitie van een paar overmatig moeilijke of onnodige procedures aanbevolen in de 2c tips sectie van Issue 12. Aangezien er meer van zijn, stuur ik het je op:
#!/bin/sh
# lowerit
# zet alle bestandsnamen in de huidige directory om naar kleine letters
# werkt alleen met gewone bestanden--wijzigt geen directorynamen
# zal vragen om verificatie voor een bestaand bestand te overschrijven
for x in `ls`
do
if [ ! -f $x ]; then
continue
fi
lc=`echo $x | tr '[A-Z]' '[a-z]'`
if [ $lc != $x ]; then
mv -i $x $lc
fi
done
Wauw. Dat is een lang script. Ik zou daarvoor geen script schrijven, ik
zou in plaats daarvan deze opdracht gebruiken:
for i in * ; do [ -f $i ] && mv -i $i `echo $i | tr '[A-Z]' '[a-z]'`;
done;
op de opdrachtregel.
Degene die het aanleverde zei dat de wijze waarop hij het script schreef hij dit voor de leesbaarheid deed (zie hieronder).
Op naar de volgende tip, deze over het toevoegen en verwijderen van gebruikers. Het gaat Geoff goed af tot aan de laatste stap. Reboot? Tjonge, ik hoop niet dat hij reboot elke keer als hij een gebruiker verwijdert. Het enige dat je hoeft te doen, is het uitvoeren van de eerste twee stappen. Welk type processen zou die gebruiker hebben lopen? Een irc bot? Het killen van de processen met een simpel
kill -9 `ps -aux |grep ^<username> |tr -s " " |cut -d " " -f2`
Voorbeeld, gebruikersnaam is foo
kill -9 `ps -aux |grep ^foo |tr -s " " |cut -d " " -f2`
Laten we daarmee te hebben afgerekend, verdergaan met het vergeten
root-wachtwoord.
De oplossing gegeven in de Gazette is de meest universele, maar niet de eenvoudigste. Met zowel LILO als loadlin, kan met het opgeven van de bootparameter "single" direct in de standaardshell zonder login of password prompt worden geboot. Vanaf daar, kan met elk wachtwoord wijzigen of verwijderen voor het typen van "init 3" om in multiuser modus te starten. Aantal reboots: 1 De andere manier Aantal reboots: 2
Justin Dossey
paul@geeky1.ebtech.net
We beginnen vanuit de ruwe, zuivere broncode. Zorg eerst dat je aan de sendmail broncode komt. Ik heb versie 8.9.0, wat zoals je op zal vallen, het nieuwste van het nieuwste is. Ik haalde het vanaf ftp.sendmail.org:/pub/sendmail/sendmail.8.9.0.tar.gz
Het is ongeveer 1Meg, en in overweging nemend dat ik 8.7.6 draai, denk ik dat het de moeite waard is. Als dit werkt, zul je dit ongetwijfeld te horen krijgen, anders kan ik de nieuwe HOWTO versies er niet uitkrijgen zonder e-mail:)
Pak het uit, nu je de broncode hebt. Er zal in de huidige
directory een dir met de naam sendmail-8.9.0
worden aangemaakt. Ga
naar die directory en lees de bestanden README en RELEASE_NOTES
(en verbaas je over de updates die zijn gedaan).
Ga nu met cd naar src. Hier zal je meeste werk worden uitgevoerd.
Een beknopte notitie: Sendmail is een klein, krachtig en goed geschreven programma. De sendmail binary zelf compileert in minder dan 5 minuten op mijn 5x86 133 met 32Megs RAM! De gehele compilatie en installatie nam (zonder config) minder dan 15 minuten in beslag!
Normaal gesproken gebruik ik BIND niet op mijn systeem, dus ik trof de regels
# ifndef NAMED_BIND
# define NAMED_BIND 1 /* gebruik Berkeley Internet Domain Server */
# endif
aan en wijzigde de 1 in een 0, ala:
# ifndef NAMED_BIND
# define NAMED_BIND 0 /* gebruik Berkeley Internet Domain Server */
# endif
Onder Debian 1.3.1, is db.h standaard geïnstalleerd in /usr/include/db, in plaats van in /usr/include, waar sendmail het hoopt te vinden. Ga naar de src, mailstats, makemap, praliases, rmail en smrsh directory's en voer de volgende opdracht uit:
./Build -I/usr/include/db
Zodra je dat hebt gedaan, cd .. en typ make install. Dat is het! Sendmail versie 8.9.0 zou nu moeten zijn geïnstalleerd! Dit uiteraard in de veronderstelling dat je reeds een originele configuratie hebt. Om alles op mijn systeem soepel te laten werken, moest ik het volgende aan het begin van /etc/sendmail.cf toevoegen, aangezien ik vrije mailinglists host voor mensen die majordomo gebruiken:
O DontBlameSendmail=forwardfileinunsafedirpath, forwardfileinunsafedirpathsafe
Sendmail 8.9.0 is tegenwoordig nogal eigenzinnig als het gaat om directory- en bestandspermissies, en het zal meldingen geven over dirs en bestanden in aliases of .forward bestanden die voor de groep of wereld schrijfbaar zijn. Ondanks dat het niet verstandig is deze eigenzinnigheid te deactiveren, draai ik het als enige persoon op de console en ik vond dat het ok was dit kleine beveiligingsgat toe te staan. YMMV.
jadestar@rahul.net
Creëer en onderhoud een /README.`hostname` en/of een /etc/README.`hostname` [Of mogelijk /usr/local/etc/README.`hostname` -Maint. ]
Maak vanaf *de eerste dag* dat je een systeem beheert, notities in een online logbestand. Je zou een "vi /README.$(hostname)" een regel in root's /bash_logout aan kunnen maken. Een andere manier om dit te doen is het schrijven van een su of sudo script die iets dergelijks doet als in:
function exit \
{ unset exit; exit; \
cat ~/tmp/session.$(date +%y%m%d) \
>> /README.$(hostname) && \
vi /README.$(hostname)
}
script -a ~/tmp/session.$(date +%y%m%d)
/bin/su.org -
(gebruik de opdracht typescript om een sessielog te creëren en maak een functie aan voor het automatisch toevoegen en bijwerken van de log).
Ik geef toe dat ik het automatiseren van dit beleid niet heb geïmplementeerd. Ik vertrouwde tot dusverre op zelfdiscipline. Ik heb echter met het idee gespeeld (zelfs tot aan het punt vooraf intypen van de scripts en shellfuncties zoals je ze hier ziet). Een ding dat me weerhoudt is de 'script' opdracht zelf. Ik denk dat ik een paar opdrachtregelparameters aan de broncode toe moet voegen (voor een pause/stop van het scriptopname vanaf de opdrachtregel) voordat ik ze aanlever voor gebruik.
Mijn laatste suggestie (voor deze ronde):
Het pad van root zou moeten bestaan uit 'PATH= /bin'
Dat is alles. Niets meer in het pad van root. Alles wat root doet wordt geleverd door een symlink vanuit /bin of door een alias of shellfunctie of is een script of binary in /bin, of wordt uitgetikt met een expliciet pad.
Dit maakt iedereen draaiend als root zich bewust (soms pijnlijk bewust) van hoe hij/zij binaire bestanden vertrouwt. De verstandige beheerder van een multi-user host zal periodiek zijn /bin en /.*history bestanden doorzoeken op bepaalde patronen en loopholes.
De echt gemotiveerde beheerder zal reeksen ontdekken die kunnen worden geautomatiseerd, plaatsen waar veiligheidscontroles kunnen worden ingevoegd, en taken waarvoor "root" privileges tijdelijk zouden moeten worden vermeden (opstarten van editors, MTA's en andere grote interactieve programma's met uitgebreide scriptmogelijkheden die in transparante of gegevensbestanden, *zouden* kunnen worden ingesloten zoals de befaamde vi ./.exrc en emacs ./.emacs en de zelfs meer verraderlijke $EXINIT en ingesloten header/footer macro's). Vanzelfspreken kunnen dergelijke opdrachten worden uitgevoerd met iets als:
cp $data $some_users_home/tmp
su -c $origcommand $whatever_switches
cp $some_users_home/tmp $data
(...waar de details afhangen van de opdracht).
De meeste van deze voorzorgsmaatregelen zijn voor de home- of voor een "single" user werkstation wat overdreven, maar vormen een erg goed beleid voor de beheerder van een multi-user systeem --- in het bijzonder wordt een publiek toegankelijk systeem (zoals die van netcom).
a.triulzi@ic.ac.uk
/usr/bin/X11/xdm
exec /usr/bin/X11/X -indirect hostname
Ik voeg dit toe omdat het me ongeveer een week kostte om alle problemen de kop in te drukken toen ik het wanhopig probeerde in te stellen voor mijn eigen subnet.
Voorbehoud: met oude SLS (1.1.1) kun je om een of andere reden een -nodaemon weglaten na de xdm regel -- dit werkt NIET met latere uitgaven.