---

Godaften dk.edb.* folk

Bare for sjov og spas har jeg designet (ikke kodet) et alternativ til NIS.
Det nye design synes jeg er meget mere sikkert og nemmere at finde ud af,
men det burde jeg jo også mene eftersom jeg selv har lavet det. Jeg søger
derfor nogen der vil læse dette første udkast til CFC (jeg kalder det
Central File Control) gennem, inden jeg skriver videre og sender det indtil
FreeBSD. Dette er nok primært for folk der ikke kan lide NIS, men ligemeget
om du er vild med NIS eller ikke kender NIS, så kan du måske rette mit
design lidt. Alt konstruktivt kritik er velkommen.
Hvis du synes dette lyder spændende, så skriv til mig og jeg sender dig mere
info.

mvh
db

ps: Teksten er på engelsk.

---

Daniel Blankensteiner wrote:

> Bare for sjov og spas har jeg designet (ikke kodet) et alternativ til NIS.

NIS har sgu' ikke noget med "sjov og spas" at gøre. Det er noget af det
sikkerhedsmæssigt værste l..., jeg indtil dato har været ude for (excl.
Microsoft Outlook mm.)


> Det nye design synes jeg er meget mere sikkert og nemmere at finde ud af,
> men det burde jeg jo også mene eftersom jeg selv har lavet det. Jeg søger
> derfor nogen der vil læse dette første udkast til CFC (jeg kalder det
> Central File Control) gennem, inden jeg skriver videre og sender det
> indtil FreeBSD. Dette er nok primært for folk der ikke kan lide NIS, men
> ligemeget om du er vild med NIS eller ikke kender NIS, så kan du måske
> rette mit design lidt. Alt konstruktivt kritik er velkommen.

Ok. Her er så den første kritik: Hvorfor starter du ikke med at spørge
rundt omkring, hvad folk ønsker sig af en NIS erstatning ? Samlede du
kommentarerne ville du dermed have en kravspecifikation at gå ud fra.
Det er meget bedre end at sidde på sit lille kammer og /forestille/
sig, hvad folk har brug for.

-Claus

---

"Claus Rasmussen" <clr@cc-consult.dk> wrote in message
news:ahf60t$ngn$1@sunsite.dk...
> > Bare for sjov og spas har jeg designet (ikke kodet) et alternativ til
NIS.
>
> NIS har sgu' ikke noget med "sjov og spas" at gøre. Det er noget af det
> sikkerhedsmæssigt værste l..., jeg indtil dato har været ude for (excl.
> Microsoft Outlook mm.)

Jeg skriver SGU heller ikke at det har noget med sjov og spas at gøre! Jeg
skriver at jeg bare for sjov og fordi jeg havde lyst, har designet et
alternativ til NIS, netop fordi jeg synes det er for usikkert.......læs og
forstå venligt hvad jeg skriver.

> > Det nye design synes jeg er meget mere sikkert og nemmere at finde ud
af,
> > men det burde jeg jo også mene eftersom jeg selv har lavet det. Jeg
søger
> > derfor nogen der vil læse dette første udkast til CFC (jeg kalder det
> > Central File Control) gennem, inden jeg skriver videre og sender det
> > indtil FreeBSD. Dette er nok primært for folk der ikke kan lide NIS, men
> > ligemeget om du er vild med NIS eller ikke kender NIS, så kan du måske
> > rette mit design lidt. Alt konstruktivt kritik er velkommen.
>
> Ok. Her er så den første kritik: Hvorfor starter du ikke med at spørge
> rundt omkring, hvad folk ønsker sig af en NIS erstatning ?

Hvad tror du denne posting har til formål?

>Samlede du
> kommentarerne ville du dermed have en kravspecifikation at gå ud fra.
> Det er meget bedre end at sidde på sit lille kammer og /forestille/
> sig, hvad folk har brug for.

Jeg ved hvad jeg selv kunne tænke mig og har lavet et design på det, men
inden jeg arbejder videre med det, vil jeg høre om det er noget folk synes
lyder godt og om de har forslag til forbedringer.

mvh
db

---

"Claus Rasmussen" <clr@cc-consult.dk> wrote in message
news:ahf60t$ngn$1@sunsite.dk...
> Daniel Blankensteiner wrote:
>
> > Bare for sjov og spas har jeg designet (ikke kodet) et alternativ til
NIS.
>
> NIS har sgu' ikke noget med "sjov og spas" at gøre. Det er noget af det
> sikkerhedsmæssigt værste l..., jeg indtil dato har været ude for (excl.
> Microsoft Outlook mm.)

Rolig nu <g>. Man kan jo godt for sjov få den idé at forsøge at designe en
erstatning til NIS.

> > Det nye design synes jeg er meget mere sikkert og nemmere at finde ud
af,
> > men det burde jeg jo også mene eftersom jeg selv har lavet det. Jeg
søger
> > derfor nogen der vil læse dette første udkast til CFC (jeg kalder det
> > Central File Control) gennem, inden jeg skriver videre og sender det
> > indtil FreeBSD. Dette er nok primært for folk der ikke kan lide NIS, men
> > ligemeget om du er vild med NIS eller ikke kender NIS, så kan du måske
> > rette mit design lidt. Alt konstruktivt kritik er velkommen.
>
> Ok. Her er så den første kritik: Hvorfor starter du ikke med at spørge
> rundt omkring, hvad folk ønsker sig af en NIS erstatning ? Samlede du
> kommentarerne ville du dermed have en kravspecifikation at gå ud fra.
> Det er meget bedre end at sidde på sit lille kammer og /forestille/
> sig, hvad folk har brug for.

Min erfaring med NIS er at langt de fleste "kun" bruger det til
centralisering af brugere & grupper samt tilhørende validering.
Set ud fra det synspunkt, så findes der allerede et glimrende alternativ som
de fleste unix leverandører supportere, incl. Sun som med Solaris 9 endda
bruger det som default. Navnet er LDAP, og sikkerheden opnås via SASL &
SSL/TLS.

/Jesper

---

"Jesper Frank Nemholt" <jfn@dassic.com> wrote in message
news:ahf7br$rdm$1@sunsite.dk...
> Min erfaring med NIS er at langt de fleste "kun" bruger det til
> centralisering af brugere & grupper samt tilhørende validering.
> Set ud fra det synspunkt, så findes der allerede et glimrende alternativ
som
> de fleste unix leverandører supportere, incl. Sun som med Solaris 9 endda
> bruger det som default. Navnet er LDAP, og sikkerheden opnås via SASL &
> SSL/TLS.

CFC er også primært rettet mod styring af diverse bruger control filer som
/etc/ftpusers o.s.v. Men jeg må nok hellere lige kaste et blik på LDAP

mvh
db

---

"Jesper Frank Nemholt" <jfn@dassic.com> writes:

> Min erfaring med NIS er at langt de fleste "kun" bruger det til
> centralisering af brugere & grupper samt tilhørende validering.

Og automountermaps.
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus

---

Jesper Frank Nemholt wrote:

> "Claus Rasmussen" <clr@cc-consult.dk> wrote in message
>>
>> NIS har sgu' ikke noget med "sjov og spas" at gøre. Det er noget af det
>> sikkerhedsmæssigt værste l..., jeg indtil dato har været ude for (excl.
>> Microsoft Outlook mm.)
>
> Rolig nu <g>. Man kan jo godt for sjov få den idé at forsøge at designe en
> erstatning til NIS.

Ok. Men jeg har brugt RIGELIGT med tid på at finde ud af, hvilket !"#¤
NIS er. Så jeg er stadig en smule "touchy". Det endte med, at jeg lavede
mine egne stenaldertools til at løse problemet. Men hele problemstillingen
omkring sikkerhedsmæssig forsvarlig central/decentral styring af konfigu-
rationsfiler/passwords/osv. er EMM et uløst problem på un*x.

[...]

> Min erfaring med NIS er at langt de fleste "kun" bruger det til
> centralisering af brugere & grupper samt tilhørende validering.
> Set ud fra det synspunkt, så findes der allerede et glimrende alternativ
> som de fleste unix leverandører supportere, incl. Sun som med Solaris 9
> endda bruger det som default. Navnet er LDAP, og sikkerheden opnås via
> SASL & SSL/TLS.

Problemet er, at LDAP langt fra tilfredsstiller de krav, man har
i det virkelige liv. Der er mange services, der kræver adgang til
konfigurations /filer/, som ikke er omfattet af LDAP. Man ender derfor
tit i et underligt misk-mask af NIS, LDAP og noget man selv har flikket
sammen.

Desuden har LDAP nøjagtigt samme svaghed som NIS: Alt ligger på
en central server. Det giver (blandt andet) to problemer:

o Går serveren ned, går _hele_ dit netværk på røven. Tag noget så
banalt som en 'ls'. Den scanner /etc/passwd for brugernavne til sin
listning. Er der ikke hul igennem til LDAP eller NIS, må man vente
på en time-out før det giver noget output. Du kan forestille dig,
hvad det vil gøre ved en travl server.

o Bliver den centrale server cracket er det det samme som at _hele_
dit netværk er blevet cracket. Forestil dig, at du har tyve servere,
som du skal til at reinstallere, fordi blot en enkelt er blevet
cracket.

Daniel kalder sit projekt for CFC (Central File Control). Jeg ville
hellere se et projekt med forkortelsen DFC (Distributed File Control).

-Claus

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> omkring sikkerhedsmæssig forsvarlig central/decentral styring af konfigu-
> rationsfiler/passwords/osv. er EMM et uløst problem på un*x.

Giver Kerberos en løsning?

> o Går serveren ned, går _hele_ dit netværk på røven. Tag noget så
> banalt som en 'ls'. Den scanner /etc/passwd for brugernavne til sin
> listning. Er der ikke hul igennem til LDAP eller NIS, må man vente
> på en time-out før det giver noget output. Du kan forestille dig,
> hvad det vil gøre ved en travl server.

NIS understøtter flere servere på samme netværk. Det sjove kommer når
man har flere fysiske netsegmenter.

> o Bliver den centrale server cracket er det det samme som at _hele_
> dit netværk er blevet cracket. Forestil dig, at du har tyve servere,
> som du skal til at reinstallere, fordi blot en enkelt er blevet
> cracket.

Uddyb lige. Med fælles password over hele systemet, hvad skulle der
så ellers ske? Root er iøvrigt sædvanligvis udenfor NIS-systemet i et
velkonfigureret sysetm.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus

---

Thorbjoern Ravn Andersen wrote:

> Claus Rasmussen <clr@cc-consult.dk> writes:
>
>> omkring sikkerhedsmæssig forsvarlig central/decentral styring af konfigu-
>> rationsfiler/passwords/osv. er EMM et uløst problem på un*x.
>
> Giver Kerberos en løsning?

Uden at have studeret Kerberos i detaljer, tror jeg det ikke.


>> o Går serveren ned, går _hele_ dit netværk på røven. Tag noget så
>> banalt som en 'ls'. Den scanner /etc/passwd for brugernavne til sin
>> listning. Er der ikke hul igennem til LDAP eller NIS, må man vente
>> på en time-out før det giver noget output. Du kan forestille dig,
>> hvad det vil gøre ved en travl server.
>
> NIS understøtter flere servere på samme netværk. Det sjove kommer når
> man har flere fysiske netsegmenter.

Ja, /det/ fandt jeg ud af Desuden er jeg stadig ikke vild med at
have et par servere som er 100% kritiske for netværkets samlede funk-
tion. Man har lidt samme problemstilling omkring DNS, men her hjælper
det at hardcode IP adresserne for de essentielle maskiner i /etc/hosts.

Hvor tit oplever du i øvrigt, at der ikke er hul igennem til DNS
serverne ? For mig sker det lige rigeligt tit til at jeg kunne undvære
/etc/hosts fuldstændigt.


>> o Bliver den centrale server cracket er det det samme som at _hele_
>> dit netværk er blevet cracket. Forestil dig, at du har tyve servere,
>> som du skal til at reinstallere, fordi blot en enkelt er blevet
>> cracket.
>
> Uddyb lige. Med fælles password over hele systemet, hvad skulle der
> så ellers ske? Root er iøvrigt sædvanligvis udenfor NIS-systemet i et
> velkonfigureret sysetm.

Ideen er, at du ikke må have fælles passwords over hele systemet. Der
skal være mulighed for at definere grupper af brugere, der har adgang
til at administrere web-serveren/mailserveren/filserveren/database-
serveren/osv. Sådan er i hvert fald min sikkerhedsfilosofi: Der skal
være adskillelse mellem forskellige funktioner, så der ikke er nogen
overløbseffekt fra een cracket server til en anden.

Det kan "nemt" lade sig gøre uden at bruge LDAP. Man opretter bare
brugerne på de maskiner, de har lov til at arbejde på og så skal de
selv styre at skifte passwords på de forskellige maskiner. Bliver
f.eks web-serveren cracket betyder det intet for databaseserveren,
da ingen af de informationer, der ligger på web-serveren hjælper
crackeren til at komme ind på databaseserveren.

Enter LDAP: Nu har vi en situation, hvor en enkelt server rummer
samtlige password til alle servere (husk at det blot er et spørgs-
mål om tid før en server er rootet, hvis der kommer en cracker ind
på en almindelig konto). Dvs. at du indfører et sikkerhedsmæssigt
single-point-of-failure.

Og i følge vores allesammens Murphy er det garanteret, at det vil
ske en dag. God fornøjelse med at reinstallere hele maskinparken
siger jeg bare

-Claus

---

"Claus Rasmussen" <clr@cc-consult.dk> wrote in message
news:ahfb2n$a3s$1@sunsite.dk...
> >> o Går serveren ned, går _hele_ dit netværk på røven. Tag noget så
> >> banalt som en 'ls'. Den scanner /etc/passwd for brugernavne til sin
> >> listning. Er der ikke hul igennem til LDAP eller NIS, må man vente
> >> på en time-out før det giver noget output. Du kan forestille dig,
> >> hvad det vil gøre ved en travl server.
> >
> > NIS understøtter flere servere på samme netværk. Det sjove kommer når
> > man har flere fysiske netsegmenter.

Begge problemer prøver jeg at komme til livs i CFC.

> >> o Bliver den centrale server cracket er det det samme som at _hele_
> >> dit netværk er blevet cracket. Forestil dig, at du har tyve servere,
> >> som du skal til at reinstallere, fordi blot en enkelt er blevet
> >> cracket.

Jep, men hvordan vil du knække den nød? Du skal jo have en server der står
for det hele, styrer det hele og samler det hele? Dog burde loghost's og
ligende ikke benytte sig af NIS eller CFC.

mvh
db

---

Daniel Blankensteiner wrote:

>> >> o Bliver den centrale server cracket er det det samme som at _hele_
>> >> dit netværk er blevet cracket. Forestil dig, at du har tyve servere,
>> >> som du skal til at reinstallere, fordi blot en enkelt er blevet
>> >> cracket.
>
> Jep, men hvordan vil du knække den nød? Du skal jo have en server der står
> for det hele, styrer det hele og samler det hele? Dog burde loghost's og
> ligende ikke benytte sig af NIS eller CFC.

Man skal netop sørge for at der _ikke_ er en central server. I stedet
skal de enkelte maskiner indikere hvilken information, de ønsker at
modtage fra andre maskiner, og hvilken information, de selv udbyder.

Med et sådant system vil det være muligt at definere klasser af maskiner
som kan opdatere hinandne og evt. push informationen videre til andre
klasser af maskiner.

-Claus

---

"Claus Rasmussen" <clr@cc-consult.dk> wrote in message
news:ahh30h$ii0$1@sunsite.dk...
> Man skal netop sørge for at der _ikke_ er en central server. I stedet
> skal de enkelte maskiner indikere hvilken information, de ønsker at
> modtage fra andre maskiner, og hvilken information, de selv udbyder.
>
> Med et sådant system vil det være muligt at definere klasser af maskiner
> som kan opdatere hinandne og evt. push informationen videre til andre
> klasser af maskiner.

Det vil blive et helvede at vedligeholde.

mvh
db

---

Daniel Blankensteiner wrote:

> "Claus Rasmussen" <clr@cc-consult.dk> wrote in message
>
>> Man skal netop sørge for at der _ikke_ er en central server. I stedet
>> skal de enkelte maskiner indikere hvilken information, de ønsker at
>> modtage fra andre maskiner, og hvilken information, de selv udbyder.
>>
>> Med et sådant system vil det være muligt at definere klasser af maskiner
>> som kan opdatere hinandne og evt. push informationen videre til andre
>> klasser af maskiner.
>
> Det vil blive et helvede at vedligeholde.

server_group WebServers = server1, server2, server3, server4
share /etc/httpd/apache.conf WebServers

server_group AllServers = WebServers, DNSServers, MailServers
share /etc/hosts AllServers

user_group WebUsers = user1, user2, user3, user4
share Webusers WebServers

osv.

-Claus

---

"Claus Rasmussen" <clr@cc-consult.dk> wrote in message
news:ahh57o$onp$1@sunsite.dk...
> > Det vil blive et helvede at vedligeholde.
>
> server_group WebServers = server1, server2, server3, server4
> share /etc/httpd/apache.conf WebServers
>
> server_group AllServers = WebServers, DNSServers, MailServers
> share /etc/hosts AllServers
>
> user_group WebUsers = user1, user2, user3, user4
> share Webusers WebServers

Ja og det skal du gøre ved samtlige servere (og clients?). Hvad så hvis du
vil ændre noget?

mvh
db

---

"Daniel Blankensteiner" <db@traceroute.dk> writes:

> Ja og det skal du gøre ved samtlige servere (og clients?). Hvad så hvis du
> vil ændre noget?

Du har en central server hvorfra du kan ssh'e ud som root på alle
maskiner. Herfra distribuerer du dine konfigurationer.
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus

---

"Thorbjoern Ravn Andersen" <thunderbear@bigfoot.com> wrote in message
news:kkn0sj4v9m.fsf@mimer.null.dk...
> > Ja og det skal du gøre ved samtlige servere (og clients?). Hvad så hvis
du
> > vil ændre noget?
>
> Du har en central server hvorfra du kan ssh'e ud som root på alle
> maskiner. Herfra distribuerer du dine konfigurationer.

Konfigurere hele LAN'et manuelt eller hvad mener du? ellers skal du jo have
en hovedkilde at konfigurere fra og så er det jo centralt, som Claus ikke
vil have det.

mvh
db

---

"Daniel Blankensteiner" <db@traceroute.dk> writes:

> "Thorbjoern Ravn Andersen" <thunderbear@bigfoot.com> wrote in message
> news:kkn0sj4v9m.fsf@mimer.null.dk...
> > > Ja og det skal du gøre ved samtlige servere (og clients?). Hvad så hvis
> du
> > > vil ændre noget?
> >
> > Du har en central server hvorfra du kan ssh'e ud som root på alle
> > maskiner. Herfra distribuerer du dine konfigurationer.
>
> Konfigurere hele LAN'et manuelt eller hvad mener du? ellers skal du jo have
> en hovedkilde at konfigurere fra og så er det jo centralt, som Claus ikke
> vil have det.

lan med dhcp, opret root key på alle maskiner
herefter kan konfigurationsfiler vedligeholdes centralt
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus

---

Daniel Blankensteiner wrote:

> Ja og det skal du gøre ved samtlige servere (og clients?). Hvad så hvis du
> vil ændre noget?

Så bruger man naturligvis det fine system, som du lige har lavet.

-Claus

---

"Claus Rasmussen" <clr@cc-consult.dk> wrote in message
news:ahhq72$bod$2@sunsite.dk...
> > Ja og det skal du gøre ved samtlige servere (og clients?). Hvad så hvis
du
> > vil ændre noget?
>
> Så bruger man naturligvis det fine system, som du lige har lavet.

Hehe....jeg går ikke udfra det var alvorligt ment.

mvh
db

---

Daniel Blankensteiner wrote:

>> Så bruger man naturligvis det fine system, som du lige har lavet.
>
> Hehe....jeg går ikke udfra det var alvorligt ment.

Hvorfor ikke ? Det virker ret indlysende for mig: For hver klasse af
maskiner specificerer du hvor den vil acceptere at få sin konfigurations-
fil fra og til hvilke klasser af servere, den vil videregive sine
informationer til. Resten kan klares med en if-sætning på hostname.

-Claus

---

"Claus Rasmussen" <clr@cc-consult.dk> wrote in message
news:ahhr7h$bod$3@sunsite.dk...
> >> Så bruger man naturligvis det fine system, som du lige har lavet.
> >
> > Hehe....jeg går ikke udfra det var alvorligt ment.
>
> Hvorfor ikke ? Det virker ret indlysende for mig: For hver klasse af
> maskiner specificerer du hvor den vil acceptere at få sin konfigurations-
> fil fra og til hvilke klasser af servere, den vil videregive sine
> informationer til. Resten kan klares med en if-sætning på hostname.

Godt så, glad you like that part of it

mvh
db

---

Claus Rasmussen <clr@cc-consult.dk> wrote:
> Man skal netop sørge for at der _ikke_ er en central server.

Jeg sidder her med savl halvt nede af min t-shirt, ganske uforstaaende
overfor dine protester mod et central styret system.

I et kritisk system vil der naturligvis vaere tilstraekkeligt mange af
disse centrale maskiner til at garantere den oppetid den paagaeldende
installation har brug for.

I et kritisk system tager man de noedvendige skridt for at bringe
risikoen for indbrud ned til et acceptabelt niveau.

Jeg vil paastaa at hvis man ikke har fuld kontrol over sit netvaerk fra
en central funktion, kan *det* gaa hen og blive et sikkerhedsproblem da
manuelle opdateringer af services tager timer modsat en styret
opdatering der tager ganske faa sekunder.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.area51.dk/

---

Alex Holst <a@mongers.org> writes:

> Jeg sidder her med savl halvt nede af min t-shirt

Godt det stoppede inden det nåede tastaturet eller andre strømførende
dele.

> I et kritisk system tager man de noedvendige skridt for at bringe
> risikoen for indbrud ned til et acceptabelt niveau.

Bjørnefælder i græsset.

> Jeg vil paastaa at hvis man ikke har fuld kontrol over sit netvaerk fra
> en central funktion, kan *det* gaa hen og blive et sikkerhedsproblem da
> manuelle opdateringer af services tager timer modsat en styret
> opdatering der tager ganske faa sekunder.

Hvilket traditionelt har været WIndows' problem, og stadig er det, der
hvor der er uskolede administratorer.

Et interessant projekt var tidligere cfengine - jeg ved ikke om det er
gået koldt siden jeg kiggede på det for et par år siden.
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus

---

Alex Holst wrote:

> Claus Rasmussen <clr@cc-consult.dk> wrote:
>> Man skal netop sørge for at der _ikke_ er en central server.
>
> Jeg sidder her med savl halvt nede af min t-shirt, ganske uforstaaende
> overfor dine protester mod et central styret system.

Hehe...

Men jeg er argt imod centrale systemer, når man taler sikkerhed eller
driftsstabilitet. Vil man have sikkerhed (og hvis man planlægger efter
at man en dag bliver cracket), er det nødvendigt at ingen maskine rummer
mere information, end den har behov for. Dvs. ingen maskiner, der rummer
passwords for andre maskiner.

Vil man have driftsstabilitet er redundans kodeordet. Og jeg mener ikke
redundans af single-point-of-failure maskiner. Jeg mener redundans i
de services som single-point-of-failure maskinerne udbyder. Som f.eks
/etc/hosts, der er redundant information i forhold til DNS.


> I et kritisk system vil der naturligvis vaere tilstraekkeligt mange af
> disse centrale maskiner til at garantere den oppetid den paagaeldende
> installation har brug for.
>
> I et kritisk system tager man de noedvendige skridt for at bringe
> risikoen for indbrud ned til et acceptabelt niveau.

Tja. Jeg ville sige, at i et kritisk system planlægger man med, hvad
der sker den dag een af serverne bliver kompromitteret. Og alle servere
/bliver/ kompromitteret en dag. Forhold dig til det.

På bundlinien er, at uden NIS/LDAP har man et sikkerhedsniveau, der gør,
at et indbrud på en enkelt server ikke kan sprede sig til andre servere.
Men livet uden NIS/LDAP er for besværligt, så man sænker sit sikkerheds-
niveau af bekvemmelighedsgrunde. Min pointe er, at det ikke er ønsket om
bekvemmelighed, der stiller sig i vejen for sikkerheden. Det er designet
af NIS/LDAP, der gør.

(og så mangler vi i øvrigt en diskussion af, hvad man gør med alle de
filer, der ikke er omfattet af NIS/LDAP og som man alligevel gerne vil
have distribueret)


> Jeg vil paastaa at hvis man ikke har fuld kontrol over sit netvaerk fra
> en central funktion, kan *det* gaa hen og blive et sikkerhedsproblem da
> manuelle opdateringer af services tager timer modsat en styret
> opdatering der tager ganske faa sekunder.

Software opdateringer er en hel anden snak.

-Claus

---

"Claus Rasmussen" <clr@cc-consult.dk> wrote in message
news:ahhq5k$bod$1@sunsite.dk...
> (og så mangler vi i øvrigt en diskussion af, hvad man gør med alle de
> filer, der ikke er omfattet af NIS/LDAP og som man alligevel gerne vil
> have distribueret)

host host.....kigger rundt....kigger ned.........host

mvh
db

---

Claus Rasmussen <clr@cc-consult.dk> wrote:
> Men jeg er argt imod centrale systemer, når man taler sikkerhed eller
> driftsstabilitet. Vil man have sikkerhed (og hvis man planlægger efter
> at man en dag bliver cracket), er det nødvendigt at ingen maskine rummer
> mere information, end den har behov for. Dvs. ingen maskiner, der rummer
> passwords for andre maskiner.

Man kunne ogsaa sige, at vil man have sikkerhed bruger man ikke
passwords. Det er vist derfor vi blandt andet er uenige; jeg ville
aldrig bruge en form for brugervalidering som kan replayes. Statiske
passwords kan replayes.

Din holdning med at bruge /etc/hosts i stedet for at bygge et stabilt
netvaerk med DNS services der altid er tilgaengelige er fyringsgrundlag
i min verden.

> Tja. Jeg ville sige, at i et kritisk system planlægger man med, hvad
> der sker den dag een af serverne bliver kompromitteret. Og alle servere
> /bliver/ kompromitteret en dag. Forhold dig til det.

Vroevl. Det er muligt at designe sig ud af mange sikkerhedsproblemer,
som djb har vist adskellige gange. Programmer som er udsatte skal vaere
smaa og lette at verficere. Een saadan central server behoever kun koere
een service, og der er ingen grund til at denne service er tilgaengelig
fra udsatte maskiner.

> På bundlinien er, at uden NIS/LDAP har man et sikkerhedsniveau, der gør,
> at et indbrud på en enkelt server ikke kan sprede sig til andre servere.
> Men livet uden NIS/LDAP er for besværligt, så man sænker sit sikkerheds-
> niveau af bekvemmelighedsgrunde. Min pointe er, at det ikke er ønsket om
> bekvemmelighed, der stiller sig i vejen for sikkerheden. Det er designet
> af NIS/LDAP, der gør.

Jeg syntes det er meget bekvemmeligt at have et hoejt sikkerhedsniveau.
Giv en almindelig kontorarbejder valget mellem 35 passwords (som skiftes
hvert 2-3 maaned) eller et token samt en 25 tegns passphrase (som
skiftes 2-6 maaned).

>> Jeg vil paastaa at hvis man ikke har fuld kontrol over sit netvaerk fra
>> en central funktion, kan *det* gaa hen og blive et sikkerhedsproblem da
>> manuelle opdateringer af services tager timer modsat en styret
>> opdatering der tager ganske faa sekunder.
>
> Software opdateringer er en hel anden snak.

Er du ikke bekymret for at der introduceres en trojan paa din
distributionsserver? Taenk hvis nogen bryder ind i den.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.area51.dk/

---

Alex Holst wrote:

> Claus Rasmussen <clr@cc-consult.dk> wrote:
>
>> Men jeg er argt imod centrale systemer, når man taler sikkerhed eller
>> driftsstabilitet. Vil man have sikkerhed (og hvis man planlægger efter
>> at man en dag bliver cracket), er det nødvendigt at ingen maskine rummer
>> mere information, end den har behov for. Dvs. ingen maskiner, der rummer
>> passwords for andre maskiner.
>
> Man kunne ogsaa sige, at vil man have sikkerhed bruger man ikke
> passwords. Det er vist derfor vi blandt andet er uenige; jeg ville
> aldrig bruge en form for brugervalidering som kan replayes. Statiske
> passwords kan replayes.

Prøv at forklare.


> Din holdning med at bruge /etc/hosts i stedet for at bygge et stabilt
> netvaerk med DNS services der altid er tilgaengelige er fyringsgrundlag
> i min verden.

Hvilken verden ? Jeg er meget lidt begejstret for at bruge DNS til vigtige
servere overhovedet. Bind har simpelthen haft for mange bugs til at jeg
stoler på, at et hostname ikke bliver spoofet. Men jeg bruger det alli-
gevel, og har så /etc/hosts som backup, hvis DNS serveren skulle være
nede.

Jeg har i øvrigt svært ved at se, hvad en produktionsserver overhovedet
skal bruge DNS til. De interne servere som den kommunikerer med ligger
som regel på faste ip-adresser, som kun yderst sjældent ændres, og til
ekstern kommunikanikation vil der /som/ /regel/ være tale om svar på
forespørgsler (det gælder ikke altid).


>> Tja. Jeg ville sige, at i et kritisk system planlægger man med, hvad
>> der sker den dag een af serverne bliver kompromitteret. Og alle servere
>> /bliver/ kompromitteret en dag. Forhold dig til det.
>
> Vroevl. Det er muligt at designe sig ud af mange sikkerhedsproblemer,
> som djb har vist adskellige gange. Programmer som er udsatte skal vaere
> smaa og lette at verficere. Een saadan central server behoever kun koere
> een service, og der er ingen grund til at denne service er tilgaengelig
> fra udsatte maskiner.

Du planlægger efter, at du er perfekt. Jeg planlægger efter, at jeg _ikke_
er det. Min erfaring er, at med min metode går alt efter planen


>> På bundlinien er, at uden NIS/LDAP har man et sikkerhedsniveau, der gør,
>> at et indbrud på en enkelt server ikke kan sprede sig til andre servere.
>> Men livet uden NIS/LDAP er for besværligt, så man sænker sit sikkerheds-
>> niveau af bekvemmelighedsgrunde. Min pointe er, at det ikke er ønsket om
>> bekvemmelighed, der stiller sig i vejen for sikkerheden. Det er designet
>> af NIS/LDAP, der gør.
>
> Jeg syntes det er meget bekvemmeligt at have et hoejt sikkerhedsniveau.
> Giv en almindelig kontorarbejder valget mellem 35 passwords (som skiftes
> hvert 2-3 maaned) eller et token samt en 25 tegns passphrase (som
> skiftes 2-6 maaned).

Jeg har ikke noget problem med, at almindelige kontorbrugere kører efter
dit system. Og jeg mener og at det er sikkert nok til "kontorbrug" (hvor
Outlook virus og andet godt er den største fare alligevel). Det jeg ikke
er så vild med er, at der indføres det samme sikkerhedsniveau for servere,
som firmaets eksistens afhænger af og som måske ligger og flytter rundt
på millioner af kroner.

Jeg kan fortælle dig om et crack, jeg læste om for nogen år siden: Det
var et projekt, der gik ud på at undersøge hvor mange maskiner over hele
internettet, der havde en vulnerability. Undervejs i undersøgelsen blev
de så selv cracket.

Cracket skete ved, at en bruger havde ssh adgang fra sin NT maskine der-
hjemme. Der var så kommet en virus på (via Outlook sikkert) som havde
pillet ved ssh'en. Derved havde crackerne fået fat i passwordet til
serverne og de fyrede nu et script af, der rippede maskinen for al
interessant information og installerede en bagdør i løbet af 13 sekunder.

Derfor holder det simpelthen ikke, at basere sin sikkerhedspolitik på,
at man ikke bliver cracket. Man _bliver_ cracket en dag. Der skal ikke
mere til end at en enkelt medarbejder er lidt uopmærksom og 13 sekunder
senere ligger alle firmaets PBS transaktioner hos den russiske mafia !


>>> Jeg vil paastaa at hvis man ikke har fuld kontrol over sit netvaerk fra
>>> en central funktion, kan *det* gaa hen og blive et sikkerhedsproblem da
>>> manuelle opdateringer af services tager timer modsat en styret
>>> opdatering der tager ganske faa sekunder.
>>
>> Software opdateringer er en hel anden snak.
>
> Er du ikke bekymret for at der introduceres en trojan paa din
> distributionsserver? Taenk hvis nogen bryder ind i den.

Jow, jow. Men for at begrænse diskussionen har vi indtil videre holdt os
til at diskutere password og delte konfigurationsfiler, som Daniels system
ville håndtere.

-Claus

---

----- Original Message -----
From: "Claus Rasmussen" <clr@cc-consult.dk>
> > Er du ikke bekymret for at der introduceres en trojan paa din
> > distributionsserver? Taenk hvis nogen bryder ind i den.
>
> Jow, jow. Men for at begrænse diskussionen har vi indtil videre holdt os
> til at diskutere password og delte konfigurationsfiler, som Daniels system
> ville håndtere.

Vi har nu ikke diskuteret CFC så meget. Det er blevet nævnt nogle svagheder
og mangler ved NIS og LDAP, men det er rettet i CFC. Så der må jo være noget
ved CFC I ikke kan lide, eftersom I ikke hopper rundt med festhatte og råber
"CFC, CFC, CFC".

mvh
db

---

Daniel Blankensteiner <db@traceroute.dk> wrote:
> Vi har nu ikke diskuteret CFC så meget. Det er blevet nævnt nogle svagheder
> og mangler ved NIS og LDAP, men det er rettet i CFC. Så der må jo være noget
> ved CFC I ikke kan lide, eftersom I ikke hopper rundt med festhatte og råber
> "CFC, CFC, CFC".

Jeg kan ikke forestille mig at jeg faar brug for systemet, saa jeg har
ikke kommenteret det. Jeg kan ikke lide ideen med, at klienterne kan
opdatere filerne som ligger paa serveren. Der er flere grunde til dette.

F.eks. at hvis passwd bliver aendret paa to maskiner paa samme tid,
hvilken er saa den "rigtige"? Du skal til at lave en slags 3. way merge.
Det betyder ogsaa, at root (laes: en angriber med root) kan oprette
almindelige bruger konti paa andre maskiner, og derfra forsoege at finde
huller i SUID filer, eller i kernen. Tilfoejelser af kontoer skal ske
fra en central, velbeskyttet maskine.

Naar du skriver "multicast", mener du saa IP multicasting?

Hvordan virker servere og clients? Begge skal jo naesten vaere daemons
der koerer som root for at dit system kan virke. Systemet kan kun virke
i et miljoe hvor man stoler 100% paa brugerne.

Dit system virker ikke paa tvaers af OS. F.eks. ser passwd paa Solaris
lidt anderledes ud end passwd paa OpenBSD.

Du forsoeger at erstatte NIS med noget som virker paa naesten samme
maade. Der er intet ved dit system som ikke kan goeres bedre med et ssh
forbindelser og nogle Makefiles. Jeg forstaar ikke motivationen.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.area51.dk/

---

"Alex Holst" <a@mongers.org> wrote in message
news:3d3cabb6$0$26785$edfadb0f@dspool01.news.tele.dk...
> > Vi har nu ikke diskuteret CFC så meget. Det er blevet nævnt nogle
svagheder
> > og mangler ved NIS og LDAP, men det er rettet i CFC. Så der må jo være
noget
> > ved CFC I ikke kan lide, eftersom I ikke hopper rundt med festhatte og
råber
> > "CFC, CFC, CFC".
>
> Jeg kan ikke forestille mig at jeg faar brug for systemet, saa jeg har
> ikke kommenteret det. Jeg kan ikke lide ideen med, at klienterne kan
> opdatere filerne som ligger paa serveren. Der er flere grunde til dette.
>
> F.eks. at hvis passwd bliver aendret paa to maskiner paa samme tid,
> hvilken er saa den "rigtige"?

Dette er kun et problem hvis det er den samme bruger. Hvis brugerne martin
og casper begge er medlem af samme gruppe og begge skifter password, vil
følgende ske:
Martin kommer først til serveren og får ændret sit password.
Nu updates alle klienter eller Casper forbinder sig også for at updatere,
men i begge tilfælde vil serveren modtage en ny streng med caspers ændringer
og LAN'et vil blive opdateret igen. Så eftersom Martin ikke piller ved
caspers navn, password eller default shell (og omvendt), er ovenstående ikke
et problem.
Håber det forklaret hvad jeg mener godt nok?

>Du skal til at lave en slags 3. way merge.
> Det betyder ogsaa, at root (laes: en angriber med root) kan oprette
> almindelige bruger konti paa andre maskiner, og derfra forsoege at finde
> huller i SUID filer, eller i kernen. Tilfoejelser af kontoer skal ske
> fra en central, velbeskyttet maskine.

Du kan ikke oprette nye konti fra klienter, men du kan ændre alm brugeres
password.
Men du kan ikke ændre wheel eller root. Du har vel heller ikke givet alm
brugere adgang til CFC servere eller andre servere, så en rooted klient kan
kun hacke en "klient" hvor person allerede havde adgang.

> Naar du skriver "multicast", mener du saa IP multicasting?

Ja.

> Hvordan virker servere og clients? Begge skal jo naesten vaere daemons
> der koerer som root for at dit system kan virke. Systemet kan kun virke
> i et miljoe hvor man stoler 100% paa brugerne.

Det er netop lavet fordi man ikke kan stole 100% på brugerne. Men ja,
klienten skal køre som root.

> Dit system virker ikke paa tvaers af OS. F.eks. ser passwd paa Solaris
> lidt anderledes ud end passwd paa OpenBSD.

Jo da, hvis password filen ikke se ens ud, så laver du en solaris passwd ved
at lave:
Local_file=""
Remote_file"/hvor/solaris/nu/ligger/sin/passwd/fil"
/COMMENT
Indsæt en kopi af solaris passwd her

> Du forsoeger at erstatte NIS med noget som virker paa naesten samme
> maade. Der er intet ved dit system som ikke kan goeres bedre med et ssh
> forbindelser og nogle Makefiles. Jeg forstaar ikke motivationen.

Tja, det var et forsøg værd.

mvh
db

---

Daniel Blankensteiner wrote:

> Vi har nu ikke diskuteret CFC så meget. Det er blevet nævnt nogle
> svagheder og mangler ved NIS og LDAP, men det er rettet i CFC. Så der må
> jo være noget ved CFC I ikke kan lide, eftersom I ikke hopper rundt med
> festhatte og råber "CFC, CFC, CFC".

Det skyldes for det første, at vi, der har deltaget i diskussionen, er
uenige om flere fundamentale ting (ikke sådan at "Alex er dum", men at
der er forskellige måder at gøre tingene på).

For det andet lider CFC under det problem, at du starter der forkerte
sted. Din slagplan bør EMM være:

1). Definer hvilket problem, du vil løse (og beskrive hvorfor
det ikke kan løses med de værktøjer som vi har allerede).
2). Bank en demonstration sammen. Kvaliteten af koden er noget
nær ligegyldig. Det vigtige er, at det implementerer kernen
i dit system og at folk kan prøve det.
3). Indsaml reaktioner.
4). Skriv en "rigtig" version, hvor du søger at lave et kvalitets-
produkt.
5). Skriv specifikationen.

Du starter simpelthen bagfra ! Jeg har set alt for mange open-source
projekter, der aldrig nåede længere end til pkt. 5 uden nogensinde at
have været igennem punkt 1-4. Du skal istedet følge Linus' devise:
"Show me the code".

For det tredje er vi en smule skeptiske overfor, om du har den rette
erfaring til at lave et sådant produkt. Jeg vil sige, at for at du
kan lave en meningsfuld kravspecifikation, skal du have en masse
erfaring med de praktiske problemstillinger, men står overfor i et
driftsmiljø.

For det fjerde kræver det en betydelig rutine som programmør, at skrive
_sikker_ kode. Der er ingen, der vil røre CFC med en ildtang ellers.

For det femte er det et stort projekt, som der næppe er så mange, der
kan afsætte tid til at medvirke til. Du skal nok regne med, at det
vil tage en 2-3 år at få færdigt.

Det er ikke for at tage modet fra dig, men det er en forklaring på,
hvorfor reaktionen ikke ligefrem har været på "festhatte" niveau. Det
er ikke fordi vi ikke mener, at det ville være en guds velsignelse
at slippe af med NIS, men fordi vi /ved/ hvilket arbejde, udholdenhed
og kompetence det kræver at gennemføre et sådant projekt.

-Claus

---

"Claus Rasmussen" <clr@cc-consult.dk> wrote in message
news:ahk1mm$n72$1@sunsite.dk...
> For det tredje er vi en smule skeptiske overfor, om du har den rette
> erfaring til at lave et sådant produkt. Jeg vil sige, at for at du
> kan lave en meningsfuld kravspecifikation, skal du have en masse
> erfaring med de praktiske problemstillinger, men står overfor i et
> driftsmiljø.

Tja, I har jo læst om designet i storetræk, så udfra det kan I vel
nogenlunde se om det kan bruges.

> Det er ikke for at tage modet fra dig, men det er en forklaring på,
> hvorfor reaktionen ikke ligefrem har været på "festhatte" niveau. Det
> er ikke fordi vi ikke mener, at det ville være en guds velsignelse
> at slippe af med NIS, men fordi vi /ved/ hvilket arbejde, udholdenhed
> og kompetence det kræver at gennemføre et sådant projekt.

Ja ok, men jeg har stadig ikke få af vide hvad ved designet I ikke kan lide.
Du er ikke så meget for central styring og eftersom det hele bygger derpå,
kan jeg godt forstå du ikke siger så meget. Men der er meget andet ved
systemet der kan kommenteres.

mvh
db

---

Claus Rasmussen <clr@cc-consult.dk> wrote:
>> Man kunne ogsaa sige, at vil man have sikkerhed bruger man ikke
>> passwords. Det er vist derfor vi blandt andet er uenige; jeg ville
>> aldrig bruge en form for brugervalidering som kan replayes. Statiske
>> passwords kan replayes.
>
> Prøv at forklare.

En form for challenge response system som, selv hvis der blev sniffet,
en angriber ikke senere kan bruge til at logge ind som dig.

> Hvilken verden ? Jeg er meget lidt begejstret for at bruge DNS til vigtige
> servere overhovedet. Bind har simpelthen haft for mange bugs til at jeg
> stoler på, at et hostname ikke bliver spoofet.

Jeg bruger ikke BIND. Hvis jeg brugte BIND ville det nok blive version
4.x som foelger med i OpenBSD, men djbdns er simpelthen overlegen baade
fra et administrativt og sikkerhedsmaessigt synspunkt.

> Du planlægger efter, at du er perfekt. Jeg planlægger efter, at jeg _ikke_
> er det. Min erfaring er, at med min metode går alt efter planen

Indtil fornyligt har jeg skam vaeret vant til at reagere paa indbrud
regelmaessigt, og det er vel derfor jeg har den holdning jeg har. Jeg
har set aarsagen til mange indbrud, og i hvert tilfaelde har der vaeret
smaa dumme fejl som gjorde indbruddet muligt. De fleste angribere ville
ikke have en chance hvis der var blot smaa ting som baade inbound og
outbound filtering stod i vejen.

Der er naturligvis angribere med stoerre resourcer end som saa, men de
angriber bestemte maal, og saa vil det vaere en del af risk management
at finde og rette fejlene i den software og de procedurer man bruger for
andre kan goere det.

> Det jeg ikke er så vild med er, at der indføres det samme
> sikkerhedsniveau for servere, som firmaets eksistens afhænger af og
> som måske ligger og flytter rundt på millioner af kroner.

Hvad skulle der vaere galt med at bruge tokens som en del af
brugervalidering?

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.area51.dk/

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> Hvilken verden ? Jeg er meget lidt begejstret for at bruge DNS til vigtige
> servere overhovedet. Bind har simpelthen haft for mange bugs til at jeg
> stoler på, at et hostname ikke bliver spoofet. Men jeg bruger det alli-
> gevel, og har så /etc/hosts som backup, hvis DNS serveren skulle være
> nede.

Der findes andre DNS-servere end BIND.

> Cracket skete ved, at en bruger havde ssh adgang fra sin NT maskine der-
> hjemme. Der var så kommet en virus på (via Outlook sikkert) som havde
> pillet ved ssh'en. Derved havde crackerne fået fat i passwordet til
> serverne og de fyrede nu et script af, der rippede maskinen for al
> interessant information og installerede en bagdør i løbet af 13 sekunder.

Interessant. Har du en URL.
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus

---

Thorbjoern Ravn Andersen wrote:

>> Cracket skete ved, at en bruger havde ssh adgang fra sin NT maskine der-
>> hjemme. Der var så kommet en virus på (via Outlook sikkert) som havde
>> pillet ved ssh'en. Derved havde crackerne fået fat i passwordet til
>> serverne og de fyrede nu et script af, der rippede maskinen for al
>> interessant information og installerede en bagdør i løbet af 13 sekunder.
>
> Interessant. Har du en URL.

Jeg har lige søgt på slashdot (jeg mener det var der, jeg fandt historien
i sin tid) men uden resultat.

-Claus

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> >> omkring sikkerhedsmæssig forsvarlig central/decentral styring af konfigu-
> >> rationsfiler/passwords/osv. er EMM et uløst problem på un*x.
> >
> > Giver Kerberos en løsning?
>
> Uden at have studeret Kerberos i detaljer, tror jeg det ikke.

Hvorfor ikke. Kerberos er netop beregnet til den slags ting.

> > NIS understøtter flere servere på samme netværk. Det sjove kommer når
> > man har flere fysiske netsegmenter.
>
> Ja, /det/ fandt jeg ud af Desuden er jeg stadig ikke vild med at
> have et par servere som er 100% kritiske for netværkets samlede funk-
> tion. Man har lidt samme problemstilling omkring DNS, men her hjælper
> det at hardcode IP adresserne for de essentielle maskiner i
> /etc/hosts.

Det er nu ikke så svært igen, bare DNS'en er meget robust.

> Hvor tit oplever du i øvrigt, at der ikke er hul igennem til DNS
> serverne ? For mig sker det lige rigeligt tit til at jeg kunne undvære
> /etc/hosts fuldstændigt.

Meget sjældent (nu er det længe siden jeg rodede med det), men jeg
satte også en caching DNS-server op på hvert fysisk netsegment.

> > Uddyb lige. Med fælles password over hele systemet, hvad skulle der
> > så ellers ske? Root er iøvrigt sædvanligvis udenfor NIS-systemet i et
> > velkonfigureret sysetm.
>
> Ideen er, at du ikke må have fælles passwords over hele systemet. Der
> skal være mulighed for at definere grupper af brugere, der har adgang
> til at administrere web-serveren/mailserveren/filserveren/database-
> serveren/osv. Sådan er i hvert fald min sikkerhedsfilosofi: Der skal
> være adskillelse mellem forskellige funktioner, så der ikke er nogen
> overløbseffekt fra een cracket server til en anden.

Nu ved jeg ikke hvor meget du faktisk har skullet lytte til brugere af
sådanne systemer, men jeg kan godt love dig at du bliver upopulær hvis
folk skal holde styr på 20 adgangskoder for at kunne lave deres
arbejde.

Resten klarer sudo.

> brugerne på de maskiner, de har lov til at arbejde på og så skal de
> selv styre at skifte passwords på de forskellige maskiner. Bliver

Uh! Dvs flere passwords på flere maskiner? Som folk selv skal holde
styr på? Jeg tror ikke det går i praksis.

> Enter LDAP: Nu har vi en situation, hvor en enkelt server rummer
> samtlige password til alle servere (husk at det blot er et spørgs-
> mål om tid før en server er rootet, hvis der kommer en cracker ind
> på en almindelig konto). Dvs. at du indfører et sikkerhedsmæssigt
> single-point-of-failure.

Det afhænger så SANDELIG af din opsætning, og hvilket software du
kører.

Jeg så fornyligt en udgave af GCC som beskyttede mod bufferoverruns,
og det var rigtigt smart. Dell shippede enm askine hvor ALT software
var oversat med denne compiler. Det hjalp en del.

> Og i følge vores allesammens Murphy er det garanteret, at det vil
> ske en dag. God fornøjelse med at reinstallere hele maskinparken
> siger jeg bare

At have en enkelt passwordprocedure forhindrer ikke at man forsøger at
knække de ekstisterende passwords. Det findes der programmer til.
Ideen er at gøre det inden crackeren gør det.
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus

---

Thorbjoern Ravn Andersen wrote:

> Claus Rasmussen <clr@cc-consult.dk> writes:
>
>> > Giver Kerberos en løsning?
>>
>> Uden at have studeret Kerberos i detaljer, tror jeg det ikke.
>
> Hvorfor ikke. Kerberos er netop beregnet til den slags ting.

Kan Kerberos flette filer ? F.eks fletter NIS passwd, shadow og group
filerne. Kan Kerberos distribuere filer eller give netværkstransparant
adgang til filerne ? Hvad sker der, hvis der ikke er hul til andre
maskiner ?


>> > Uddyb lige. Med fælles password over hele systemet, hvad skulle der
>> > så ellers ske? Root er iøvrigt sædvanligvis udenfor NIS-systemet i et
>> > velkonfigureret sysetm.
>>
>> Ideen er, at du ikke må have fælles passwords over hele systemet. Der
>> skal være mulighed for at definere grupper af brugere, der har adgang
>> til at administrere web-serveren/mailserveren/filserveren/database-
>> serveren/osv. Sådan er i hvert fald min sikkerhedsfilosofi: Der skal
>> være adskillelse mellem forskellige funktioner, så der ikke er nogen
>> overløbseffekt fra een cracket server til en anden.
>
> Nu ved jeg ikke hvor meget du faktisk har skullet lytte til brugere af
> sådanne systemer, men jeg kan godt love dig at du bliver upopulær hvis
> folk skal holde styr på 20 adgangskoder for at kunne lave deres
> arbejde.

Du skal have et password pr. funktion. F.eks web-admininistrator e-mail-
administrator eller oracle administrator. Dertil kommer så root. Hvis
du er over hele banen bliver det ikke mere end 5 passwords formentlig.

Men du bestemmer også selv, hvor mange passwords du vil have kørende.
I en lille biks, vil du bruge eet password over hele linien. I et stort
setup, vil der være folk nok til at nogle af dem arbejder mest med nogle
få funktioner.


>> brugerne på de maskiner, de har lov til at arbejde på og så skal de
>> selv styre at skifte passwords på de forskellige maskiner. Bliver
>
> Uh! Dvs flere passwords på flere maskiner? Som folk selv skal holde
> styr på? Jeg tror ikke det går i praksis.

Det var en "tænkt" situation. Det jeg ville demonstrere var, at det er
muligt at have den sikkerhedsmæssige garanti, jeg efterlyser (brandmure
mellem forskellige serverfunktioner), hvis man anvender tilstrækkeligt
med håndkraft.


>> Enter LDAP: Nu har vi en situation, hvor en enkelt server rummer
>> samtlige password til alle servere (husk at det blot er et spørgs-
>> mål om tid før en server er rootet, hvis der kommer en cracker ind
>> på en almindelig konto). Dvs. at du indfører et sikkerhedsmæssigt
>> single-point-of-failure.
>
> Det afhænger så SANDELIG af din opsætning, og hvilket software du
> kører.

Det ændrer ikke på, at du har et-single-point of failure sikkerheds-
mæssigt. Du _må_ tage stilling til den situation, at NIS serveren
bliver cracket. Det er simpelthen bare et spørgsmål om tid, før det
sker.

-Claus

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> >> Uden at have studeret Kerberos i detaljer, tror jeg det ikke.
> >
> > Hvorfor ikke. Kerberos er netop beregnet til den slags ting.
>
> Kan Kerberos flette filer ? F.eks fletter NIS passwd, shadow og group
> filerne. Kan Kerberos distribuere filer eller give netværkstransparant
> adgang til filerne ? Hvad sker der, hvis der ikke er hul til andre
> maskiner ?

Kerberos giver - så vidt jeg ved - den sikre adgang. Det er så op til
dig at få det flettet med andre ting. Jeg ved ikke mere om det end
det. Er der andre der gør?

> > Nu ved jeg ikke hvor meget du faktisk har skullet lytte til brugere af
> > sådanne systemer, men jeg kan godt love dig at du bliver upopulær hvis
> > folk skal holde styr på 20 adgangskoder for at kunne lave deres
> > arbejde.
>
> Du skal have et password pr. funktion. F.eks web-admininistrator e-mail-
> administrator eller oracle administrator. Dertil kommer så root. Hvis
> du er over hele banen bliver det ikke mere end 5 passwords formentlig.

Problemet med det, er at sådan er Unix ganske enkelt ikke skruet
sammen som det er i dag. Så du skal have seperate konti pr funktion.
Det er heller ikke nødvendigvis ideelt.

Muligvis kunne det give mening i kombination med sudo.

> Det var en "tænkt" situation. Det jeg ville demonstrere var, at det er
> muligt at have den sikkerhedsmæssige garanti, jeg efterlyser (brandmure
> mellem forskellige serverfunktioner), hvis man anvender tilstrækkeligt
> med håndkraft.

Selvfølgelig er alt muligt. I praksis tror jeg problemet er meget
mindre end du tror - hvor mange mennesker havde du forestillet dig der
skulle lave det her?

> Det ændrer ikke på, at du har et-single-point of failure sikkerheds-
> mæssigt. Du _må_ tage stilling til den situation, at NIS serveren
> bliver cracket. Det er simpelthen bare et spørgsmål om tid, før det
> sker.

Jeg ville være meget mere bekymret for at NIS serveren blev spoofet.
Jeg ville ikke køre NIS på et netværk hvor sikkerheden var vigtig og
hvor man kunne frygte fjendtlige maskiner koblet fysisk til nettet.

Så længe den slags problemer findes, vil jeg ikke bekymre mig om
crackning af NIS-serveren. NIS-serveren vil naturligvis befinde sig
et sted hvor dens synlighed er absolut minimal.
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus

---

Claus Rasmussen wrote:

> Problemet er, at LDAP langt fra tilfredsstiller de krav, man har
> i det virkelige liv. Der er mange services, der kræver adgang til
> konfigurations /filer/, som ikke er omfattet af LDAP. Man ender derfor

Fx.? Som du mener burde være styre af et sådanne system?

> Desuden har LDAP nøjagtigt samme svaghed som NIS: Alt ligger på
> en central server. Det giver (blandt andet) to problemer:

Nej det kan ligge på flere.

> o Går serveren ned, går _hele_ dit netværk på røven. Tag noget så

Serverne. Hvis det er for sandsynligt at fx. 3 servere crasher samtidig så
brug 10.

> banalt som en 'ls'. Den scanner /etc/passwd for brugernavne til sin
> listning. Er der ikke hul igennem til LDAP eller NIS, må man vente
> på en time-out før det giver noget output. Du kan forestille dig,
> hvad det vil gøre ved en travl server.

Nu ved jeg ikke hvordan LDAP eller NIS virker med hensyn til cache, men der
er forhåbentligt noget cache på klienten.

> o Bliver den centrale server cracket er det det samme som at _hele_
> dit netværk er blevet cracket. Forestil dig, at du har tyve servere,
> som du skal til at reinstallere, fordi blot en enkelt er blevet
> cracket.

Hvis en brugerkonto bliver kompromiteret ominstallere du så automatisk
maskinen/alle de maskiner han har adgang til?
Fx. er det ikke alt for svært at få fat i en password brugeren indtaster på
den kompromiterede maskine.

Nu findes der jo også andet end servere. På Daimi har vi antageligt adgang
til i hvert fald 200 maskiner, jeg ville nødigt skulle huske et password
til dem alle.

--
Jesper
1:19am up 10:57, 2 users, load average: 0.93, 0.71, 0.85

---

Jesper FA wrote:

> Claus Rasmussen wrote:
>
>> Problemet er, at LDAP langt fra tilfredsstiller de krav, man har
>> i det virkelige liv. Der er mange services, der kræver adgang til
>> konfigurations /filer/, som ikke er omfattet af LDAP. Man ender derfor
>
> Fx.? Som du mener burde være styre af et sådanne system?

/etc/host, /etc/passwd, /etc/shadow, /etc/group, /etc/auto.*, /etc/alias,
/etc/services, /etc/protocol, /etc/ntp.conf osv. Generelt alle filer,
der ikke er maskinspecifikke.

Rækken er næsten endeløs og i nogle tilfælde vil det nærmest være
hele /etc kataloget, der er ens fra maskine til maskine. Men hverken
NIS eller LDAP kan dele vilkårlige filer. Så selv hvis man accepterer
de sikkerhedsmæssige og driftsmæssige ulemper ved NIS/LDAP er der
stadig en hel del filer, man ikke kan dele automatisk.


>> Desuden har LDAP nøjagtigt samme svaghed som NIS: Alt ligger på
>> en central server. Det giver (blandt andet) to problemer:
>
> Nej det kan ligge på flere.

Ja, ja. Men der er stadig tale om en 100% kritisk funktion, som du
indfører _alene_ af bekvemmelighed.


>> o Går serveren ned, går _hele_ dit netværk på røven. Tag noget så
>
> Serverne. Hvis det er for sandsynligt at fx. 3 servere crasher samtidig så
> brug 10.

Det er ikke realistisk at afsætte så mange servere til noget så simpelt.


>> banalt som en 'ls'. Den scanner /etc/passwd for brugernavne til sin
>> listning. Er der ikke hul igennem til LDAP eller NIS, må man vente
>> på en time-out før det giver noget output. Du kan forestille dig,
>> hvad det vil gøre ved en travl server.
>
> Nu ved jeg ikke hvordan LDAP eller NIS virker med hensyn til cache, men
> der er forhåbentligt noget cache på klienten.

NIS har ikke cache SVJV. LDAP ved jeg ikke med.


>> o Bliver den centrale server cracket er det det samme som at _hele_
>> dit netværk er blevet cracket. Forestil dig, at du har tyve servere,
>> som du skal til at reinstallere, fordi blot en enkelt er blevet
>> cracket.
>
> Hvis en brugerkonto bliver kompromiteret ominstallere du så automatisk
> maskinen/alle de maskiner han har adgang til?

Hvis du tager sikkerhed seriøst (dvs. hvis der er penge involveret), så
ja. Det er du simpelthen nødt til. Du må regne med, at med mindre du er
sikkerhedsekspert, så er crackerne betydeligt dygtigere end dig (og mig).

Den eneste sikkerhedsmæssigt forsvarlige er dels at have en firewall mod
nettet, dels en firewall mod det interne net (kontorbrugernes) og så nogle
solide brandmure mellem de enkelte servere.

Du må ikke på nogen måde få lettere ved at gennemtrænge det samlede system
blot fordi du cracker en del af systemet. Dvs. der må ikke lægge mere end
den højst nødvendige information på hver maskine.

Det er nemlig sikkert at en eller anden dag, så bliver du cracket. Uanset
hvor meget du så end anstrenger dig for at undgå det.


> Fx. er det ikke alt for svært at få fat i en password brugeren indtaster
> på den kompromiterede maskine.

Nemlig.


> Nu findes der jo også andet end servere. På Daimi har vi antageligt adgang
> til i hvert fald 200 maskiner, jeg ville nødigt skulle huske et password
> til dem alle.

Nej og det ville jeg også. Men det er det, der er problemet: NIS/NIS+/LDAP
tilfredsstiller ikke fuldt ud de krav om sikkerhed, bekvemmelighed og flek-
sibilitet som man kræver i dag. Så når maskinparken gror en over hovedet
forfalder man alligevel til NIS plus den sædvanlige samling hjemmeflikkede
scripts.

Derfor er et alternativ meget velkomment.

-Claus

---

"Claus Rasmussen" <clr@cc-consult.dk> wrote in message
news:ahh45c$mmn$1@sunsite.dk...
> > Fx.? Som du mener burde være styre af et sådanne system?
>
> /etc/host, /etc/passwd, /etc/shadow, /etc/group, /etc/auto.*, /etc/alias,
> /etc/services, /etc/protocol, /etc/ntp.conf osv. Generelt alle filer,
> der ikke er maskinspecifikke.
>
> Rækken er næsten endeløs og i nogle tilfælde vil det nærmest være
> hele /etc kataloget, der er ens fra maskine til maskine. Men hverken
> NIS eller LDAP kan dele vilkårlige filer. Så selv hvis man accepterer
> de sikkerhedsmæssige og driftsmæssige ulemper ved NIS/LDAP er der
> stadig en hel del filer, man ikke kan dele automatisk.

Jep, www.nynis.subnet.dk

> Nej og det ville jeg også. Men det er det, der er problemet: NIS/NIS+/LDAP
> tilfredsstiller ikke fuldt ud de krav om sikkerhed, bekvemmelighed og
flek-
> sibilitet som man kræver i dag. Så når maskinparken gror en over hovedet
> forfalder man alligevel til NIS plus den sædvanlige samling hjemmeflikkede
> scripts.
>
> Derfor er et alternativ meget velkomment.

Ok, så lad os lave et

mvh
db

---

"Claus Rasmussen" <clr@cc-consult.dk> wrote in message
news:ahf9bp$4dl$1@sunsite.dk...
> Problemet er, at LDAP langt fra tilfredsstiller de krav, man har
> i det virkelige liv. Der er mange services, der kræver adgang til
> konfigurations /filer/, som ikke er omfattet af LDAP. Man ender derfor
> tit i et underligt misk-mask af NIS, LDAP og noget man selv har flikket
> sammen.

Med CFC kan ALLE filer styres fra et sted.

> Desuden har LDAP nøjagtigt samme svaghed som NIS: Alt ligger på
> en central server. Det giver (blandt andet) to problemer:
>
> o Går serveren ned, går _hele_ dit netværk på røven. Tag noget så
> banalt som en 'ls'. Den scanner /etc/passwd for brugernavne til sin
> listning. Er der ikke hul igennem til LDAP eller NIS, må man vente
> på en time-out før det giver noget output. Du kan forestille dig,
> hvad det vil gøre ved en travl server.
>
> o Bliver den centrale server cracket er det det samme som at _hele_
> dit netværk er blevet cracket. Forestil dig, at du har tyve servere,
> som du skal til at reinstallere, fordi blot en enkelt er blevet
> cracket.

Dem har jeg svaret på i en anden post, men de er også fixet.

> Daniel kalder sit projekt for CFC (Central File Control). Jeg ville
> hellere se et projekt med forkortelsen DFC (Distributed File Control).

Det er umuligt at have 200 clienter og 10 servere, som alle skal kunne
update hinanden o.s.v.. Der bliver nødt til at være en der styrer det og
hvis den ene ikke er online, så brug den næste i listen.

mvh
db

---

"Claus Rasmussen" <clr@cc-consult.dk> wrote in message
news:ahf9bp$4dl$1@sunsite.dk...
> Jesper Frank Nemholt wrote:
>
> > "Claus Rasmussen" <clr@cc-consult.dk> wrote in message
> >>
> >> NIS har sgu' ikke noget med "sjov og spas" at gøre. Det er noget af det
> >> sikkerhedsmæssigt værste l..., jeg indtil dato har været ude for (excl.
> >> Microsoft Outlook mm.)
> >
> > Rolig nu <g>. Man kan jo godt for sjov få den idé at forsøge at designe
en
> > erstatning til NIS.
>
> Ok. Men jeg har brugt RIGELIGT med tid på at finde ud af, hvilket !"#¤
> NIS er. Så jeg er stadig en smule "touchy". Det endte med, at jeg lavede
> mine egne stenaldertools til at løse problemet. Men hele problemstillingen
> omkring sikkerhedsmæssig forsvarlig central/decentral styring af konfigu-
> rationsfiler/passwords/osv. er EMM et uløst problem på un*x.

Det ved jeg nu ikke lige..... på Tru64 har man TruCluster V5. Her har man
cluster filesystem, d.v.s. alle maskiner i clusteret har samme filsystem,
som dog kan overrides til specielle filer (CDSL) der er specifikke for hver
enkelt maskine, men ting som /etc/hosts, /etc/password o.s.v. er det samme
uanset hvilken maskine man roder med i clusteret.
Man kan et stykke hen ad vejen lave det samme med Veritas Cluster Server
(Solaris, AIX, HP-UX), men det er ikke integreret så godt i operativsystem
(i og med at det er et 3rd parts produkt).

> > Min erfaring med NIS er at langt de fleste "kun" bruger det til
> > centralisering af brugere & grupper samt tilhørende validering.
> > Set ud fra det synspunkt, så findes der allerede et glimrende alternativ
> > som de fleste unix leverandører supportere, incl. Sun som med Solaris 9
> > endda bruger det som default. Navnet er LDAP, og sikkerheden opnås via
> > SASL & SSL/TLS.
>
> Problemet er, at LDAP langt fra tilfredsstiller de krav, man har
> i det virkelige liv. Der er mange services, der kræver adgang til
> konfigurations /filer/, som ikke er omfattet af LDAP. Man ender derfor
> tit i et underligt misk-mask af NIS, LDAP og noget man selv har flikket
> sammen.

LDAP er ikke løsningen på alt, det er jeg helt enig i. Et cache-coherent
cluster filesystem (som også gælder rod-filsystemet) er en lagt mere elegant
løsning, men teknisk meget mere kompleks at lave og stiller en del krav til
hardwaren. Derfor finder man pt. kun den slags på kommerciel unix.

Da vi på mit arbejde har en blanding af AIX, VMS, Tru64, Solaris og HP-UX
har vil valgt at standardisere hvor vi kan og så køre med egne løsninger for
resten (d.v.s. løsninger såsom rsync over ssh til at distribuere
konfigurations-filer fra en central server o.s.v.).

> Desuden har LDAP nøjagtigt samme svaghed som NIS: Alt ligger på
> en central server. Det giver (blandt andet) to problemer:
>
> o Går serveren ned, går _hele_ dit netværk på røven. Tag noget så
> banalt som en 'ls'. Den scanner /etc/passwd for brugernavne til sin
> listning. Er der ikke hul igennem til LDAP eller NIS, må man vente
> på en time-out før det giver noget output. Du kan forestille dig,
> hvad det vil gøre ved en travl server.

LDAP cacher den slags og refresher selv løbende. Første gang du laver en ls
tager det tid, efterfølgende lookups er cached.
M.h.t. central server så er LDAP ligesom DNS ret nemt at sætte op redundant.
På mit arbejde har vi en redundant LDAP slave løsning på hvert subnet. Det
er lavet via en hardware load-balancing så der ikke går tid med at prøve at
søge på den første for derefter at time ud og prøve nummer 2. Load
balanceren holder øje med de 2 slaver og bypasser automatisk hvis en af dem
er død.

Denne løsning er valgt fremfor normal master/slave da dette som regel
resulterer i en uønsket timeout når masteren er død.

Mange ser load balancere såsom dem fra Alteon/Nortel som noget man kun
bruger ud imod verden (d.v.s. web servere til internet), men faktisk er det
en fortrinlig (og forholdsvis billig) måde at få løst availability problemer
internt på sit firma net.

> o Bliver den centrale server cracket er det det samme som at _hele_
> dit netværk er blevet cracket. Forestil dig, at du har tyve servere,
> som du skal til at reinstallere, fordi blot en enkelt er blevet
> cracket.

Jeg har > 500 servere på mit arbejde. Decentral administration af dem er
komplet umuligt...det kræver alt for mange ressourcer.
Centralisering & standardisering er en nødvendighed.

/Jesper

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> > Bare for sjov og spas har jeg designet (ikke kodet) et alternativ til NIS.
>
> NIS har sgu' ikke noget med "sjov og spas" at gøre. Det er noget af det
> sikkerhedsmæssigt værste l..., jeg indtil dato har været ude for (excl.
> Microsoft Outlook mm.)

NIS er designet førend verden gik af lave. Ønsker man sikkerhed skal
man bruge NIS+ som kun findes til Solaris.

Hvad er der galt med LDAP?

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus

---

Thorbjoern Ravn Andersen wrote:

> NIS er designet førend verden gik af lave. Ønsker man sikkerhed skal
> man bruge NIS+ som kun findes til Solaris.

RedHat kommer med det som standard.

Men NIS+ (og LDAP) løser langt fra alle problemer omkring deling af
informationer i et netværk. Se min svar til Jesper for en opremsning
af /nogle/ af problemerne.

-Claus

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> Ideen er, at du ikke må have fælles passwords over hele systemet
>
> Det kan "nemt" lade sig gøre uden at bruge LDAP. Man opretter bare
> brugerne på de maskiner, de har lov til at arbejde på og så skal de
> selv styre at skifte passwords på de forskellige maskiner.

Det er da fuldstændigt håbløst. *Ingen* normale mennesker kan holde
styr på 20 forskellige passwords. Det eneste du opnår er at folk
skriver dem allesammen ned på en post-it sætter den på skærmen.

Kan *du* huske 20 forskellige passwords?

---

Jesper Harder wrote:

> Claus Rasmussen <clr@cc-consult.dk> writes:
>
>> Ideen er, at du ikke må have fælles passwords over hele systemet
>>
>> Det kan "nemt" lade sig gøre uden at bruge LDAP. Man opretter bare
>> brugerne på de maskiner, de har lov til at arbejde på og så skal de
>> selv styre at skifte passwords på de forskellige maskiner.
>
> Det er da fuldstændigt håbløst. *Ingen* normale mennesker kan holde
> styr på 20 forskellige passwords. Det eneste du opnår er at folk
> skriver dem allesammen ned på en post-it sætter den på skærmen.

Jeg skrev jo også "nemt" i situationstegn. Det var ironisk ment. Men
det nemme ligger i, at _hvis_ du kan huske alle disse passwords, så
har du et system, der har en højere grad af sikkerhed og driftssta-
bilitet end hvad du får med NIS/LDAP.


> Kan *du* huske 20 forskellige passwords?

Det kan jeg faktisk. Hos min forrige arbejdsgiver, som havde en kæmpe
farm af mainframes, var jeg oppe på at huske 25 passwords. Det er kun
et problem, når du starter i firmaet. Så skal du lære 25 passwords på
een gang. Men når du er inde i rutinen skal du kun lære et nyt et par
gange om ugen.

-Claus

---

Claus Rasmussen <clr@cc-consult.dk> wrote:
> Det kan jeg faktisk. Hos min forrige arbejdsgiver, som havde en kæmpe
> farm af mainframes, var jeg oppe på at huske 25 passwords. Det er kun
> et problem, når du starter i firmaet. Så skal du lære 25 passwords på
> een gang. Men når du er inde i rutinen skal du kun lære et nyt et par
> gange om ugen.

Disse passwords blev ikke skiftet regelmaessigt?

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.area51.dk/

---

Alex Holst wrote:

> Claus Rasmussen <clr@cc-consult.dk> wrote:
>> Det kan jeg faktisk. Hos min forrige arbejdsgiver, som havde en kæmpe
>> farm af mainframes, var jeg oppe på at huske 25 passwords. Det er kun
>> et problem, når du starter i firmaet. Så skal du lære 25 passwords på
>> een gang. Men når du er inde i rutinen skal du kun lære et nyt et par
>> gange om ugen.
>
> Disse passwords blev ikke skiftet regelmaessigt?

Jeg tror en gang i kvartalet i snit. Det /er/ altså ikke så svært, som
man forestiller sig. Prøv for sammenligningens skyld at tæl sammen hvor
mange passwords, dankort-koder og telefonnumre du kan udenad.

-Claus

---

Claus Rasmussen <clr@cc-consult.dk> wrote:
> Jeg tror en gang i kvartalet i snit. Det /er/ altså ikke så svært, som
> man forestiller sig. Prøv for sammenligningens skyld at tæl sammen hvor
> mange passwords, dankort-koder og telefonnumre du kan udenad.

Jeg har store problemer med at huske den slags. Jeg har en passphrase
til min SSH key, een til min GnuPG key, en pin kode til mit dankort, en
pin kode til mit irske kreditkort, og jeg skal slaa mit eget
telefonnummer op for at faa det rigtigt.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.area51.dk/

---

Alex Holst wrote:

> ..., og jeg skal slaa mit eget telefonnummer op for at faa det rigtigt.

LOL

-Claus

---

"Alex Holst" <a@mongers.org> wrote in message
news:3d3c7553$0$80827$edfadb0f@dspool01.news.tele.dk...
> Claus Rasmussen <clr@cc-consult.dk> wrote:
> > Det kan jeg faktisk. Hos min forrige arbejdsgiver, som havde en kæmpe
> > farm af mainframes, var jeg oppe på at huske 25 passwords. Det er kun
> > et problem, når du starter i firmaet. Så skal du lære 25 passwords på
> > een gang. Men når du er inde i rutinen skal du kun lære et nyt et par
> > gange om ugen.
>
> Disse passwords blev ikke skiftet regelmaessigt?

Man benytter ofte (hos de firmaer jeg arbejder hos) at hver maskine har et
unikt root password som skiftes jævnligt, men som følger en kode der gør at
de indviede (administratorerne) ud fra f.eks. navnet på maskinen eller dens
IP eller lignende kan password'et, f.eks. :

Det generelle password er x698xTR. Udskift x med tredje bogstav i maskinens
hostnavn.

Derved opnår man at hver maskine har et unikt root-password, men undgår at
det bliver et helvede for administratorerne at huske.


/Jesper

---

"Daniel Blankensteiner" <db@traceroute.dk> wrote:

>Bare for sjov og spas har jeg designet (ikke kodet) et alternativ til NIS.
>Det nye design synes jeg er meget mere sikkert og nemmere at finde ud af,
>men det burde jeg jo også mene eftersom jeg selv har lavet det. Jeg søger
>derfor nogen der vil læse dette første udkast til CFC (jeg kalder det
>Central File Control) gennem, inden jeg skriver videre og sender det indtil
>FreeBSD.

Har du ikke glemt at give URL'en til dit skrift?

--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).

---

"Jesper Dybdal" <jdunet@u8.dybdal.dk> wrote in message
news:49amju0m2ggadu1n5v4qfjtn5f1lo92itm@dtext.news.tele.dk...
> >Bare for sjov og spas har jeg designet (ikke kodet) et alternativ til
NIS.
> >Det nye design synes jeg er meget mere sikkert og nemmere at finde ud af,
> >men det burde jeg jo også mene eftersom jeg selv har lavet det. Jeg søger
> >derfor nogen der vil læse dette første udkast til CFC (jeg kalder det
> >Central File Control) gennem, inden jeg skriver videre og sender det
indtil
> >FreeBSD.
>
> Har du ikke glemt at give URL'en til dit skrift?

Lige nu ligger det som en .txt file (som jeg kan maile), men hvis folk synes
CFC lyder spændende, kommer der en hjemmeside og jeg vil skrive mere om det.

mvh
db

---

On Mon, 22 Jul 2002 00:07:11 +0200, Daniel Blankensteiner wrote:

> Lige nu ligger det som en .txt file (som jeg kan maile), men hvis folk
> synes CFC lyder spændende, kommer der en hjemmeside og jeg vil skrive
> mere om det.

Eller evt. fyre txtfilen op i dk.binaer?

Går udfra at du vil publicere det færdige program under BSD/GPL licensen,
så det er vigtigt at folk kommer med, selvom du ikke har så mange idéer
endnu.

--
/Bo

Highway MailService (2:236/100) - http://fido.geekworld.dk

---

"Bo Simonsen" <paltas@geekworld.dk> wrote in message
news:pan.2002.07.22.00.24.34.895080.449@geekworld.dk...
> > Lige nu ligger det som en .txt file (som jeg kan maile), men hvis folk
> > synes CFC lyder spændende, kommer der en hjemmeside og jeg vil skrive
> > mere om det.
>
> Eller evt. fyre txtfilen op i dk.binaer?

Det kunne jeg også gøre, men jeg venter lige på svar fra Claus.

> Går udfra at du vil publicere det færdige program under BSD/GPL licensen,
> så det er vigtigt at folk kommer med, selvom du ikke har så mange idéer
> endnu.

Ja til BSD licensen, ? til det sidste. Mener du at det er vigtigt folk
kommer med i design fasen? Det er jo også det jeg prøver på ved at poste
herind

mvh
db

---

On Mon, 22 Jul 2002 00:44:51 +0200, Daniel Blankensteiner wrote:


> Ja til BSD licensen, ? til det sidste. Mener du at det er vigtigt folk
> kommer med i design fasen? Det er jo også det jeg prøver på ved at poste
> herind

Ja jeg er glad bare det er en af OSI licenserne

--
/Bo

Highway MailService (2:236/100) - http://fido.geekworld.dk

---

"Bo Simonsen" <paltas@geekworld.dk> wrote in message
news:pan.2002.07.22.13.23.04.163783.408@geekworld.dk...
> > Ja til BSD licensen, ? til det sidste. Mener du at det er vigtigt folk
> > kommer med i design fasen? Det er jo også det jeg prøver på ved at poste
> > herind
>
> Ja jeg er glad bare det er en af OSI licenserne

Jeg kan ikke lide GPL, hvorfor tvinge open-source? Nej, så hellere bare give
koden fri og så kan folk gøre hvad de vil med den.
Mht til at tage penge for CFC, så synes jeg det vil virkelig forkert at
tjene penge på software, der er lavet på et gratis OS med gratis værktøjer.

>Sonny: Smid en URL til teksten, så vi kan review'e den.

Jeg har i øjeblikket ikke en hjemmeside, så jeg har oprettet en via sol.dk,
men de er sgu langsomme. Jeg skal nok sige til når den er klar til download.
Hvis du ikke kan vente, så kan jeg da sende den til dig

mvh
db

---

"Daniel Blankensteiner" <db@traceroute.dk> wrote in message
news:ahgrdt$ppc$1@sunsite.dk...
> >Sonny: Smid en URL til teksten, så vi kan review'e den.

Hurtig og primitiv side: http://www.nynis.subnet.dk/

mvh
db

---

Daniel Blankensteiner wrote:

> Hurtig og primitiv side: http://www.nynis.subnet.dk/

Har du overvejet at putte projektet på Sourceforge?

--
Niels Callesøe - nørd light
pfy[at]nntp.dk - http://www.pcpower.dk/disclaimer.php
"Again and again they struck him on the head with a
patch cable and spat upon him." - Book of THOL, verses

---

"Niels Callesøe" <pfy@nntp.dk> wrote in message
news:Xns92539BE6E9E07k5j6h4jk3@193.88.15.213...
> > Hurtig og primitiv side: http://www.nynis.subnet.dk/
>
> Har du overvejet at putte projektet på Sourceforge?

Hvad er sourceforge?

mvh
db

---

Daniel Blankensteiner <db@traceroute.dk> wrote:
> "Niels Callesøe" <pfy@nntp.dk> wrote in message
> news:Xns92539BE6E9E07k5j6h4jk3@193.88.15.213...
>> > Hurtig og primitiv side: http://www.nynis.subnet.dk/
>>
>> Har du overvejet at putte projektet på Sourceforge?
>
> Hvad er sourceforge?

Et forfaerdeligt sted (www.sf.net) som giver gratis CVS adgang, bug
tracking, webpage hosting, etc til open source projecter. Det er
langsomt, og jeg oplever at man ikke kan committe i timevis ad gangen,
og andre problemer. Jeg kan virkeligt ikke anbefale det.

Mht. dit nyt NIS projekt, saa kan du evt. kigge paa cf-engine for
inspiration paa nogle omraader.

Jeg byggede en funktionel kopi af cf-engine til min forrige arbejdsgiver
inden jeg stoppede. CCMS (change and configuration management
system) bestod af Makefiles, et par perlscripts og configurationsfiler.

Hosts blev listet som medlem af en eller flere roller (common, smtp,
http, pop3, nntp, etc) og for hver rolle blev genereret en liste over
brugere, packpages og andet som skulle vaere installeret. Filerne blev
opbevaret i CVS.

Disse filer blev saa smidt ud paa hver host on commit, hvor en lille
daemon der koerte som root soergede for at oprette nye brugere,
de-aktivere gamle brugere, fjerne gamle packages og installere nye.
Derved blev en opgradering af f.eks. OpenSSH saa let som at laegge en ny
pakke paa filserveren. Man rettede derefter i versionen af OpenSSH
listet i 'common' rollen. Ved commit blev den gamle pakke fjernet fra
produktionsmaskinen og den nye installeret.

Vi havde egenligt planer om at bruge cf-engine, men naermere inspektion
af cf-engine koden viste at den ikke saa paen ud, og videre udvikling
saa ud til at vaere naesten doed. Det var et lidt for stort projekt at
arve.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.area51.dk/

---

"Alex Holst" <a@mongers.org> wrote in message
news:3d3c1799$0$26813$edfadb0f@dspool01.news.tele.dk...
> Et forfaerdeligt sted (www.sf.net) som giver gratis CVS adgang, bug
> tracking, webpage hosting, etc til open source projecter. Det er
> langsomt, og jeg oplever at man ikke kan committe i timevis ad gangen,
> og andre problemer. Jeg kan virkeligt ikke anbefale det.

Ok, godt jeg har fået en side på sol.dk så

> Hosts blev listet som medlem af en eller flere roller (common, smtp,
> http, pop3, nntp, etc) og for hver rolle blev genereret en liste over
> brugere, packpages og andet som skulle vaere installeret. Filerne blev
> opbevaret i CVS.
>
> Disse filer blev saa smidt ud paa hver host on commit, hvor en lille
> daemon der koerte som root soergede for at oprette nye brugere,
> de-aktivere gamle brugere, fjerne gamle packages og installere nye.
> Derved blev en opgradering af f.eks. OpenSSH saa let som at laegge en ny
> pakke paa filserveren. Man rettede derefter i versionen af OpenSSH
> listet i 'common' rollen. Ved commit blev den gamle pakke fjernet fra
> produktionsmaskinen og den nye installeret.
>
> Vi havde egenligt planer om at bruge cf-engine, men naermere inspektion
> af cf-engine koden viste at den ikke saa paen ud, og videre udvikling
> saa ud til at vaere naesten doed. Det var et lidt for stort projekt at
> arve.

Det lyder ellers som et smart system, synd det ikke blev til noget. Men
måske CFC skal udvides til også at inkludere pakke styring?
Måske flere ting?

mvh
db

---

Daniel Blankensteiner <db@traceroute.dk> wrote:
[Et par sandheder om sourceforge]
> Ok, godt jeg har fået en side på sol.dk så

sunsite.dk kunne vaere en mulighed ogsaa. De hoster gerne projekter.

[CCMS]
> Det lyder ellers som et smart system, synd det ikke blev til noget.

Medmindre du ved noget jeg ikke ved, er systemet nu i drift hos min
tidligere arbejdsgiver.

> Men måske CFC skal udvides til også at inkludere pakke styring?

Jeg tror du skal starte med en liste over requirements til dit system,
evt. med milestones. Til CCMS var kravene blandt andet at der skulle
vaere audit trails, roll back, mulighed for access control og approval
procedures.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.area51.dk/

---

"Alex Holst" <a@mongers.org> wrote in message
news:3d3c2949$0$26813$edfadb0f@dspool01.news.tele.dk...
> > Det lyder ellers som et smart system, synd det ikke blev til noget.
>
> Medmindre du ved noget jeg ikke ved, er systemet nu i drift hos min
> tidligere arbejdsgiver.

*G*, ok en lille misforståelse fra min side.

> > Men måske CFC skal udvides til også at inkludere pakke styring?
>
> Jeg tror du skal starte med en liste over requirements til dit system,
> evt. med milestones. Til CCMS var kravene blandt andet at der skulle
> vaere audit trails, roll back, mulighed for access control og approval
> procedures.

Ok, men jeg har aldrig prøvet at styre et stort LAN, derfor skriver jeg
herinde om jeg nu også har tænkt på det hele, er system brugbart, o.s.v..
Men grund til at jeg vil lave et system er pga. den dårlige sikkerhed i NIS
og min fremtidige behov for en sådan protokol.

mvh
db

---

Daniel Blankensteiner <db@traceroute.dk> wrote:
> Ok, men jeg har aldrig prøvet at styre et stort LAN, derfor skriver jeg
> herinde om jeg nu også har tænkt på det hele, er system brugbart, o.s.v..
> Men grund til at jeg vil lave et system er pga. den dårlige sikkerhed i NIS
> og min fremtidige behov for en sådan protokol.

Jeg tror ikke der er behov for en protokol, da f.eks. rsync, sftp, afs
eller andre metoder let kan bruges til at distribuere aendringer enten
via push eller pull. Ved brug af en af disse kan ogsaa tages hoejde for
adgangskontrol, og lign.

Problemet vil vaere dit design og evt. integration med andre systemer.
Du skal mest arbejde med dataopbevaring paa central maskinen, samt
taenke over hvordan agenterne paa de forskellige OS'er skal opfoere sig.

Jeg synes dit dokument beskriver et (halvt) system, men ikke hvilket
*problem* du rent faktisk forsoeger at loese. Hvis det kun er passwd,
group og hosts filerne du vil styre, findes der Kerberos og DNS til at
loese problemet.

Du skriver selv at du ikke havde et design i tankerne da du begyndte at
skrive, og det er ikke saadan man bygger et system uden at der pludslig
opstaar problemer.

Mit raad er at du vender tilbage naar du tror dit design er komplet. Der
er for mange huller og ubesvarede spoergsmaal til at vi kan hjaelpe ret
meget. Hvis du ikke selv har viden nok til at lave saadan et design
burde du nok helt lade vaere.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.area51.dk/

---

"Alex Holst" <a@mongers.org> wrote in message
news:3d3c44d4$0$13926$edfadb0f@dspool01.news.tele.dk...
> Jeg synes dit dokument beskriver et (halvt) system, men ikke hvilket
> *problem* du rent faktisk forsoeger at loese. Hvis det kun er passwd,
> group og hosts filerne du vil styre, findes der Kerberos og DNS til at
> loese problemet.

Ok, teknisk er der måske ikke så mange detaljer, men hvordan systemet skal
fungere synes jeg da jeg har forklaret.

> Du skriver selv at du ikke havde et design i tankerne da du begyndte at
> skrive, og det er ikke saadan man bygger et system uden at der pludslig
> opstaar problemer.
>
> Mit raad er at du vender tilbage naar du tror dit design er komplet. Der
> er for mange huller og ubesvarede spoergsmaal til at vi kan hjaelpe ret
> meget. Hvis du ikke selv har viden nok til at lave saadan et design
> burde du nok helt lade vaere.

Jeg vil netop ikke skrive 20 sider og have truffet alle valgene på forhånd,
jeg giver et billed af hvordan jeg synes det skal være, så vil du ikke
skrive hvilke huller og ubesvarede spørgsmål du synes der er?
Og nej, jeg har måske ikke viden nok til at lave et design pga. manglende
praktisk erfaring, men det skal ikke stoppe mig fra at forsøge og blive
klogere på det.

mvh
db

---

Alex Holst skrev:

> sunsite.dk kunne vaere en mulighed ogsaa. De hoster gerne projekter.

<URL: http://sunsite.dk/info/projectapplication.xml >

<URL: http://webapps.sunsite.dk/paf.php >

"SunSITE.dk Project Application Form

Sorry! We have taken this form offline because it has generated a real
flood of project applications, most of them very difficult to handle.

We won't accept any more applications at least until our list of
outstanding requests is down to one screenful. That said - if you have
a running OSS project and want to change hosting, just contact us
(Anti-Lamer system: find out yourself how to do that

The sunsite.dk staff."

Da db er igang, er der vel ikke noget i vejen for at spørge Sunsite om
de vil hjælpe.

---

On Mon, 22 Jul 2002 13:48:58 +0200, Daniel Blankensteiner wrote:

> Jeg kan ikke lide GPL, hvorfor tvinge open-source? Nej, så hellere bare
> give koden fri og så kan folk gøre hvad de vil med den. Mht til at tage
> penge for CFC, så synes jeg det vil virkelig forkert at tjene penge på
> software, der er lavet på et gratis OS med gratis værktøjer.

Er vi ikke enige om at BSD licensen også er en OSI licens?
--
/Bo

Highway MailService (2:236/100) - http://fido.geekworld.dk

---

"Bo Simonsen" <paltas@geekworld.dk> wrote in message
news:pan.2002.07.22.23.06.16.175263.3102@geekworld.dk...
> > Jeg kan ikke lide GPL, hvorfor tvinge open-source? Nej, så hellere bare
> > give koden fri og så kan folk gøre hvad de vil med den. Mht til at tage
> > penge for CFC, så synes jeg det vil virkelig forkert at tjene penge på
> > software, der er lavet på et gratis OS med gratis værktøjer.
>
> Er vi ikke enige om at BSD licensen også er en OSI licens?

Jep, jeg vil bare lige sige min mening om GPL Den hører måske ikke ind
under OSI?

mvh
db

---

In article <ahhsdh$jhp$1@sunsite.dk>, Daniel Blankensteiner wrote:

> Jep, jeg vil bare lige sige min mening om GPL Den hører måske ikke ind
> under OSI?

GPL eller din mening?

GPL, BSD og søstre er OSI-licenser.


--
Med venlig hilsen
Bo Simonsen

http://fido.geekworld.dk

---

"Bo Simonsen" <paltas@geekworld.dk> wrote in message
news:slrnajp2i0.3tl.paltas@obiwan.lan.geekworld.dk...
> > Jep, jeg vil bare lige sige min mening om GPL Den hører måske ikke
ind
> > under OSI?
>
> GPL eller din mening?

GPL, jeg tror ikke min mening står skrevet som en licens

> GPL, BSD og søstre er OSI-licenser.

oki

mvh
db

---

On Mon, 22 Jul 2002 00:07:11 +0200, Daniel Blankensteiner wrote:

> Lige nu ligger det som en .txt file (som jeg kan maile)

Sjovt, det er lige det format usenet-artikler bruger...


Mvh.

--
"Snurra min jord igen" Adam Sjøgren
asjo@koldfront.dk

---

On Sun, 21 Jul 2002 21:50:29 +0200, Daniel Blankensteiner wrote:

> Hvis du synes dette lyder spændende, så skriv til mig og jeg sender dig mere
> info.

Smid en URL til teksten, så vi kan review'e den.

--
/Sonny - #include <std.disclaimer.h>

"I don't have an attitude problem, you have a perception problem."

---

"Daniel Blankensteiner" <db@traceroute.dk> wrote in message
news:ahf38o$fnt$1@sunsite.dk...
> Bare for sjov og spas har jeg designet (ikke kodet) et alternativ til NIS.
> Det nye design synes jeg er meget mere sikkert og nemmere at finde ud af,
> men det burde jeg jo også mene eftersom jeg selv har lavet det. Jeg søger
> derfor nogen der vil læse dette første udkast til CFC (jeg kalder det
> Central File Control) gennem, inden jeg skriver videre og sender det
indtil
> FreeBSD. Dette er nok primært for folk der ikke kan lide NIS, men
ligemeget
> om du er vild med NIS eller ikke kender NIS, så kan du måske rette mit
> design lidt. Alt konstruktivt kritik er velkommen.
> Hvis du synes dette lyder spændende, så skriv til mig og jeg sender dig
mere
> info.

Gerne svar på hvad I synes om:
Måden serverene kommunikere på.
Måden serverene konfigureres.
Måden klienterne konfigureres.
Måden man styrer hvilke filer der skal deles og deres indhold.
Måden klienterne og serverne kommunikere.
Skal man både bruge multicast og "netgroups" eller er det nok med kun
multicast.
Måden servere og klienter updatere.
Systemet som en helhed o.s.v........

mvh
db