---

Hej

Jeg har en RH 9.0 firewall stående på min ADSL, hvor jeg ønsker at
installere følgende:
- Samba
- Apache
- MySQL
- ProFTPD


Iptables sættes op til kun at tillade adgang på port 139, 80, 3306 og 21 for
udvalgte IP'er.
SSH er tilladt for alle.


Det forekommer mig, at det er uhensigtsmæssigt at installere den slags
services på en firewall, men hvad er de reelle sikkerhedsrisikoer ved det?

Mvh
Jimmy


PS Spurgte også i .unix, men det passer vist bedre her.

---

"Jimmy" <nyhedsgruppe@get2net.dk> wrote:

>Jeg har en RH 9.0 firewall stående på min ADSL, hvor jeg ønsker at
>installere følgende:
> - Samba
> - Apache
> - MySQL
> - ProFTPD
>
>Iptables sættes op til kun at tillade adgang på port 139, 80, 3306 og 21 for
>udvalgte IP'er.
>SSH er tilladt for alle.
>
>
>Det forekommer mig, at det er uhensigtsmæssigt at installere den slags
>services på en firewall, men hvad er de reelle sikkerhedsrisikoer ved det?

Det betyder at der er flere stykker programmel som det kan være
vigtigt at holde opdateret med sikkerhedsrettelser.

Hvis du kun tillader adgang fra kendte og pålidelige IP-adresser, og
ikke har upålidelige lokale brugere på maskinen, så er faren nok
stærkt begrænset i praksis, da du vel næppe har seriøse personlige
fjender af den slags der kan finde på og ud af at spoofe IP-adresser.

Husk at følge med i evt. sikkerhedsrettelser, især til ssh, som du jo
tillader hvem som helst at bruge.

Jeg har selv gjort meget ud af at sikre min hjemmefirewall/-server mod
indbrud. Jeg beskrev det engang på Usenet - se evt.
http://www.google.dk/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=vkve9ugjr71jh8dckegieb8mnujabp5p0b%40dtext.news.tele.dk


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

---

"Jesper Dybdal" <jdunet@u8.dybdal.dk> wrote in message
news:tpa4mvkr6rm9tgb9iu3nt70f8c42u3g727@dtext.news.tele.dk...
> "Jimmy" <nyhedsgruppe@get2net.dk> wrote:
>
> >Jeg har en RH 9.0 firewall stående på min ADSL, hvor jeg ønsker at
> >installere følgende:
> > - Samba
> > - Apache
> > - MySQL
> > - ProFTPD
> >
> >Iptables sættes op til kun at tillade adgang på port 139, 80, 3306 og 21
for
> >udvalgte IP'er.
> >SSH er tilladt for alle.
> >
> >
> >Det forekommer mig, at det er uhensigtsmæssigt at installere den slags
> >services på en firewall, men hvad er de reelle sikkerhedsrisikoer ved
det?
>
> Det betyder at der er flere stykker programmel som det kan være
> vigtigt at holde opdateret med sikkerhedsrettelser.

Ja det er sandt.


> Jeg har selv gjort meget ud af at sikre min hjemmefirewall/-server mod
> indbrud. Jeg beskrev det engang på Usenet - se evt.
>
http://www.google.dk/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=vkve9ugjr71jh8d
ckegieb8mnujabp5p0b%40dtext.news.tele.dk

Jeg fangede ikke altsammen - specielt ikke det med "suexec" og hvordan man
får iptables til at filtrere på brugerniveau.

Tak for svarene til Jer begge.
Det lader til at jeg godt kan starte apt-get

Mvh
JImmy

---

Jimmy wrote:
>
> Hej
>
> Jeg har en RH 9.0 firewall stående på min ADSL, hvor jeg ønsker at
> installere følgende:
> - Samba
> - Apache
> - MySQL
> - ProFTPD
>
> Iptables sættes op til kun at tillade adgang på port 139, 80, 3306 og 21 for
> udvalgte IP'er.
> SSH er tilladt for alle.
>
> Det forekommer mig, at det er uhensigtsmæssigt at installere den slags
> services på en firewall, men hvad er de reelle sikkerhedsrisikoer ved det?

Sikkerhedsmæssigt vil der være en fordel ved at placere serverne
på en anden maskine end firewallen og sætte denne server maskine
i en DMZ zone. Men jeg formoder du synes det vil være overkill.

Hvis du ellers sætter softwaren rigtigt op, og holder den
opdateret, tror jeg ikke, det udgør noget stort sikkerhedsproblem.

Jeg vil fraråde at bruge Red Hats default opsætning af iptables,
skriv selv dit regelsæt, det kan næsten ikke undgå at blive bedre.
Bortset fra det kender jeg ikke nogen faldgrupper i opsætningen
af den nævnte software, er der andre, som kender nogen?

Apache er, fordi den ikke kører som root, ikke så ricicabel som
f.eks. en ssh server. På den anden side bruger RH9.0 apache 2.0,
som naturligvis ikke er så gennemtestet som apache 1.3. Om 2.0
er god nok vil jeg ikke udtale mig om.

Der findes mange ftp servere, ProFTPD har vist ikke den dårligste
security record. Men da en ftp server typisk kører som root er
det tilgengæld en man bør være opmærksom på.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.

---

"Kasper Dupont" <kasperd@daimi.au.dk> wrote in message
news:3F622DF5.A6344A30@daimi.au.dk...
> Jimmy wrote:
> >
> > Hej
> >
> > Jeg har en RH 9.0 firewall stående på min ADSL, hvor jeg ønsker at
> > installere følgende:
> > - Samba
> > - Apache
> > - MySQL
> > - ProFTPD
> >
> > Iptables sættes op til kun at tillade adgang på port 139, 80, 3306 og 21
for
> > udvalgte IP'er.
> > SSH er tilladt for alle.
> >
> > Det forekommer mig, at det er uhensigtsmæssigt at installere den slags
> > services på en firewall, men hvad er de reelle sikkerhedsrisikoer ved
det?
>
> Sikkerhedsmæssigt vil der være en fordel ved at placere serverne
> på en anden maskine end firewallen og sætte denne server maskine
> i en DMZ zone. Men jeg formoder du synes det vil være overkill.

Nej - Langt fra.
Det er hvad jeg har nu, men jeg kan faktisk spare en maskine (filserveren)
væk ved at placere den på firewallen.



> Jeg vil fraråde at bruge Red Hats default opsætning af iptables,
> skriv selv dit regelsæt.


Enig - Det har jeg også gjort.


> Der findes mange ftp servere, ProFTPD har vist ikke den dårligste
> security record. Men da en ftp server typisk kører som root er
> det tilgengæld en man bør være opmærksom på.

Min kører som nobody og brugerne kan kun skrive i deres egne biblioteker.

Mvh
Jimmy

---

Jimmy wrote:
>
> "Kasper Dupont" <kasperd@daimi.au.dk> wrote in message
> news:3F622DF5.A6344A30@daimi.au.dk...
>
> > Der findes mange ftp servere, ProFTPD har vist ikke den dårligste
> > security record. Men da en ftp server typisk kører som root er
> > det tilgengæld en man bør være opmærksom på.
>
> Min kører som nobody og brugerne kan kun skrive i deres egne biblioteker.

Hvordan kan de skrive i deres eget bibliotek, hvis serveren kører
som nobody?

--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.

---

"Kasper Dupont" <kasperd@daimi.au.dk> wrote in message
news:3F624422.2B3E854F@daimi.au.dk...
> Jimmy wrote:
> >
> > "Kasper Dupont" <kasperd@daimi.au.dk> wrote in message
> > news:3F622DF5.A6344A30@daimi.au.dk...
> >
> > > Der findes mange ftp servere, ProFTPD har vist ikke den dårligste
> > > security record. Men da en ftp server typisk kører som root er
> > > det tilgengæld en man bør være opmærksom på.
> >
> > Min kører som nobody og brugerne kan kun skrive i deres egne
biblioteker.
>
> Hvordan kan de skrive i deres eget bibliotek, hvis serveren kører
> som nobody?


[root@GSM root]# ps auxwww | grep "pro"
nobody 436 0.0 0.3 2268 1052 ? S Sep01 0:00 proftpd:
(accepting connections)
gsm 3716 0.0 0.4 2656 1396 ? S 00:27 0:00 proftpd:
gsm - 192.168.1.33: IDLE

Mvh
Jimmy

---

"Jimmy" <nyhedsgruppe@get2net.dk> wrote:

>"Kasper Dupont" <kasperd@daimi.au.dk> wrote in message
>news:3F624422.2B3E854F@daimi.au.dk...
>> Hvordan kan de skrive i deres eget bibliotek, hvis serveren kører
>> som nobody?
>
>
>[root@GSM root]# ps auxwww | grep "pro"
>nobody 436 0.0 0.3 2268 1052 ? S Sep01 0:00 proftpd:
>(accepting connections)
>gsm 3716 0.0 0.4 2656 1396 ? S 00:27 0:00 proftpd:
>gsm - 192.168.1.33: IDLE

ps-kommandoen viser kun det aktuelle "effective user ID". Den viser
ikke om processen stadig er i stand til at skifte tilbage til root.
Det er den utvivlsomt, da den ellers ikke ville kunne skifte til den
bruger som logger ind med ftp.

Prøv en
cat /proc/NNNN/status
hvor NNNN er procesnummeret (her 436).

Den indeholder bl.a. to linjer à la
Uid: 1001 1001 1001 1001
Gid: 104 104 104 104

Hvis de fire Uid'er er ens og de fire Gid'er er ens (som her), så har
processen ingen mulighed for at skifte væk fra den
Uid/Gid-kombination. Hvis nogle af Uid'erne er 0, har den stadig
mulighed for at skifte tilbage til at være root.

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

---

"Jesper Dybdal" <jdunet@u8.dybdal.dk> wrote in message
news:gsr5mvosh407i9viacaicju1kmar4o7g39@dtext.news.tele.dk...
> "Jimmy" <nyhedsgruppe@get2net.dk> wrote:
>
> >"Kasper Dupont" <kasperd@daimi.au.dk> wrote in message
> >news:3F624422.2B3E854F@daimi.au.dk...
> >> Hvordan kan de skrive i deres eget bibliotek, hvis serveren kører
> >> som nobody?
> >
> >
> >[root@GSM root]# ps auxwww | grep "pro"
> >nobody 436 0.0 0.3 2268 1052 ? S Sep01 0:00 proftpd:
> >(accepting connections)
> >gsm 3716 0.0 0.4 2656 1396 ? S 00:27 0:00 proftpd:
> >gsm - 192.168.1.33: IDLE
>
> ps-kommandoen viser kun det aktuelle "effective user ID". Den viser
> ikke om processen stadig er i stand til at skifte tilbage til root.
> Det er den utvivlsomt, da den ellers ikke ville kunne skifte til den
> bruger som logger ind med ftp.
>
> Prøv en
> cat /proc/NNNN/status
> hvor NNNN er procesnummeret (her 436).
>
> Den indeholder bl.a. to linjer à la
> Uid: 1001 1001 1001 1001
> Gid: 104 104 104 104


Name: proftpd
Uid: 0 99 0 99
Gid: 99 99 99 99


> Hvis de fire Uid'er er ens og de fire Gid'er er ens (som her), så har
> processen ingen mulighed for at skifte væk fra den
> Uid/Gid-kombination. Hvis nogle af Uid'erne er 0, har den stadig
> mulighed for at skifte tilbage til at være root.

Hmm ja ok...
Vel endnu en grund til at anvende SCP fremfor FTP.

Tak for den information.

Mvh
Jimmy

---

"Jimmy" <nyhedsgruppe@get2net.dk> wrote:

>Name: proftpd
>Uid: 0 99 0 99
>Gid: 99 99 99 99

>Hmm ja ok...
>Vel endnu en grund til at anvende SCP fremfor FTP.

Der er ikke noget galt i at en ftp-server har root-rettigheder - det
er den simpelthen nødt til at have indtil den har verificeret
brugeren.

Tilsvarende er sshd også nødt til at have root-rettigheder indtil den
har verificeret brugeren. I OpenSSH har de dog nu lavet en mekanisme
("Privilege separation") som gør at det kun er en lille isoleret del
af koden der udføres med root-rettigheder - det reducerer risikoen for
at en fejl får alvorlige konsekvenser temmelig meget.

Ved at bruge scp i stedet for ftp opnår du ikke mindst forbedret
sikkerhed fordi du alligevel skal bruge ssh, og derfor er scp "gratis"
mht. sikkerhed: hvis ssh er sikker, er scp det også.

Du slipper naturligvis også for at der bliver sendt passwords i
klartekst over nettet - det kunne i princippet være vigtigt, men jeg
har aldrig nogensinde hørt om nogen hjemmebrugere der faktisk fik
sniffet deres password og fik problemer pga. det.

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

---

"Jimmy" <nyhedsgruppe@get2net.dk> wrote:

>Det forekommer mig, at det er uhensigtsmæssigt at installere den slags
>services på en firewall, men hvad er de reelle sikkerhedsrisikoer ved det?

Hvis det lykkes for nogen at bryde ind paa firewall-maskinen
gennem en usikker service og faa root-access, ligger vejen til
hele dit netvaerk aaben.

Hvis den usikre service i stedet koerer paa en selvstaendig
maskine, og resten af netvaerket er beskyttet mod denne maskine,
f.eks. ved at den er placeret paa et DMZ, kan en angriber stadig
faa root-access paa maskinen, men han faar svaert ved at komme
videre til resten af netvaerket.


--
Allan Olesen, Lunderskov.
Danske musikere tjener penge ved ulovlig softwarekopiering.

---

Allan Olesen wrote:
>
> "Jimmy" <nyhedsgruppe@get2net.dk> wrote:
>
> >Det forekommer mig, at det er uhensigtsmæssigt at installere den slags
> >services på en firewall, men hvad er de reelle sikkerhedsrisikoer ved det?
>
> Hvis det lykkes for nogen at bryde ind paa firewall-maskinen
> gennem en usikker service og faa root-access, ligger vejen til
> hele dit netvaerk aaben.
>
> Hvis den usikre service i stedet koerer paa en selvstaendig
> maskine, og resten af netvaerket er beskyttet mod denne maskine,
> f.eks. ved at den er placeret paa et DMZ, kan en angriber stadig
> faa root-access paa maskinen, men han faar svaert ved at komme
> videre til resten af netvaerket.

Hvis der er maskiner på netværket, som er vigtigere end serverne,
så er DMZ zonen en god idé. Men hvis de fem nævnte servere er det
vigtigste på netværket, så vil man måske være ligeglad med, om man
kan komme vidre fra serverne til andre maskiner på netværket. I
stedet bør man i så fald fokusere på at undgå nogen får kontrol
over serverne i første omgang. Det er alt sammen en vurdering af,
hvor det er vigtigst at investere kræfter på sikring af systemet.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.

---

"Allan Olesen" <aolesen@post3.tele.dk> wrote in message
news:3f623c01$0$54838$edfadb0f@dread11.news.tele.dk...
> "Jimmy" <nyhedsgruppe@get2net.dk> wrote:
>
> >Det forekommer mig, at det er uhensigtsmæssigt at installere den slags
> >services på en firewall, men hvad er de reelle sikkerhedsrisikoer ved
det?
>
> Hvis det lykkes for nogen at bryde ind paa firewall-maskinen
> gennem en usikker service og faa root-access, ligger vejen til
> hele dit netvaerk aaben.


Ja det er rigtigt.
Det vigtigste af alt er at mine data på min filserver ikke kan hentes eller
slettes af andre.
At skære et sikkerhedsled væk er ikke optimalt.

Men, hvis man nu antager følgende:
- Minimalt antal brugere
- Brugeres password er 20 tegn lange og består af specialtegn, store og små
bogstaver samt tal
- Alle porte undtagen 22 er lukket udefra (Enkelte IP'er har adgang til
flere porte)
- iptables er konfigureret korrekt
- Der ikke afvikles tvivlsomme programmer på firewallen, som installerer
bagdøre

Hvis ovenstående gælder, og sikkerheden stadig ikke er i top, må det betyde,
at iptables ikke er sikker nok.

Er det korrekt eller for firkantet?

Mvh
Jimmy

---

Jimmy <nyhedsgruppe@get2net.dk> wrote:
> Det vigtigste af alt er at mine data på min filserver ikke kan hentes eller
> slettes af andre.

Den letteste maade at faa adgang til dine filer, vil vaere at angribe en
af de IP adresser der har adgang igennem dit IP filter og tilgaa din ftp
eller smb server ved at opsnappe brugernavn og passwords.

Du boer soerge for, at indbrud paa maskinerne bag de godkendte IP
adresser bliver opdaget i tide -- dette kan goeres ved at benytte file
integrity checking vaerktoejer.

Hvis du har mulighed for at benytte en type validering der ikke kan
opsnappes og replayes ligesom statiske passwords kan, er det en
betydelig forhindring. SSH understoetter brug af SSH keys og diverse
smart cards samt X9.9 tokens.

Du boer benytte OpenSSH's privsep funktion til at begraense skaden i
tilfaelde af en sikkerhedsfejl i koden.

[..]
> Hvis ovenstående gælder, og sikkerheden stadig ikke er i top, må det betyde,
> at iptables ikke er sikker nok.

IPtables giver dig ingen forbedret sikkerhed hvis en angriber paa en af
de godkendte IP adresser har adgang lige igennem og det er faktisk det
du er mest udsat med den konfiguration du har beskrevet.

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

---

"Alex Holst" <a@mongers.org> wrote in message
news:ol2b31-fh2.ln1@miracle.mongers.org...
> Jimmy <nyhedsgruppe@get2net.dk> wrote:
> > Det vigtigste af alt er at mine data på min filserver ikke kan hentes
eller
> > slettes af andre.
>
> Den letteste maade at faa adgang til dine filer, vil vaere at angribe en
> af de IP adresser der har adgang igennem dit IP filter og tilgaa din ftp
> eller smb server ved at opsnappe brugernavn og passwords.

smb sender koder krypteret, men det gør FTP ikke.
Jeg dropper FTP og anvender SCP i stedet.

Hvad mener du med at angribe en af de IP adresser der har fået adgang?
Mener du angribe dem og gå videre derfra eller lade som om man kommer
derfra?


> Hvis du har mulighed for at benytte en type validering der ikke kan
> opsnappes og replayes ligesom statiske passwords kan, er det en
> betydelig forhindring. SSH understoetter brug af SSH keys og diverse
> smart cards samt X9.9 tokens.


Jeg kan godt installere keys til SSH - giver det en større grad af
beskyttelse i forhold til at sende koden manuelt når man logger ind?


> > Hvis ovenstående gælder, og sikkerheden stadig ikke er i top, må det
betyde,
> > at iptables ikke er sikker nok.
>
> IPtables giver dig ingen forbedret sikkerhed hvis en angriber paa en af
> de godkendte IP adresser har adgang lige igennem og det er faktisk det
> du er mest udsat med den konfiguration du har beskrevet.


Hvis det kun er de tilladte IP'er, der reelt kan angribe mig er faren til at
overse.

Tak for svaret.

Mvh
Jimmy

---

Jimmy <nyhedsgruppe@get2net.dk> wrote:
> smb sender koder krypteret, men det gør FTP ikke.
> Jeg dropper FTP og anvender SCP i stedet.
>
> Hvad mener du med at angribe en af de IP adresser der har fået adgang?
> Mener du angribe dem og gå videre derfra eller lade som om man kommer
> derfra?

Jeg mener, at bryde ind i en af de IP adresser der har adgang,
installere en keystroke logger og opsnappe brugerens kodeord naar det
bliver indtastet. I saadan et tilfaelde giver kryptering on-the-wire
dig ingen sikkerhedsmaessig fordel.

> Jeg kan godt installere keys til SSH - giver det en større grad af
> beskyttelse i forhold til at sende koden manuelt når man logger ind?

SSH keys er et kryptografisk challenge/response system baseret paa to
faktorer: selve SSH noeglefilen samt passwordet som noeglefilen er
krypteret med. Hvis en angriber kan komme i besiddelse af begge disse,
giver det naturligvis heller ikke nogen form for beskyttelse.

> Hvis det kun er de tilladte IP'er, der reelt kan angribe mig er faren
> til at overse.

Din maskine kan angribes gennem OpenSSH fra hele nettet. Soerg for altid
at koere en version uden kendte sikkerhedsfejl. Som naevnt kan du
drastisk nedsaette risikoen af et hul i sshd ved at benytte privsep.

Din maskine kan yderligere angribes gennem MySQL og Samba, men kun fra
de IP adresser du slipper igennem dit filter. De vigtigste punkter der
kan beskytte dig herfra, er konfiguration af de to services og at
uddanne brugerne bag disse IP adresser i hvordan de boer beskytte deres
egne systemer.

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

---

"Alex Holst" <a@mongers.org> wrote in message
news:i87b31-ra6.ln1@miracle.mongers.org...
> Jimmy <nyhedsgruppe@get2net.dk> wrote:
> > smb sender koder krypteret, men det gør FTP ikke.
> > Jeg dropper FTP og anvender SCP i stedet.
> >
> > Hvad mener du med at angribe en af de IP adresser der har fået adgang?
> > Mener du angribe dem og gå videre derfra eller lade som om man kommer
> > derfra?
>
> Jeg mener, at bryde ind i en af de IP adresser der har adgang,
> installere en keystroke logger og opsnappe brugerens kodeord naar det
> bliver indtastet.

OK - Så er jeg med.


> > Jeg kan godt installere keys til SSH - giver det en større grad af
> > beskyttelse i forhold til at sende koden manuelt når man logger ind?
>
> SSH keys er et kryptografisk challenge/response system baseret paa to
> faktorer: selve SSH noeglefilen samt passwordet som noeglefilen er
> krypteret med. Hvis en angriber kan komme i besiddelse af begge disse,
> giver det naturligvis heller ikke nogen form for beskyttelse.

Klart - men giver nøglefiler større sikkerhed end at indtaste user/pass i
min SSH klient, når jeg manuelt logger ind?



> > Hvis det kun er de tilladte IP'er, der reelt kan angribe mig er faren
> > til at overse.
>
> Din maskine kan angribes gennem OpenSSH fra hele nettet. Soerg for altid
> at koere en version uden kendte sikkerhedsfejl. Som naevnt kan du
> drastisk nedsaette risikoen af et hul i sshd ved at benytte privsep.

OK - Jeg vil se på om jeg kan finde noget om privsep på google.


Takker,
Jimmy

---

Jimmy <nyhedsgruppe@get2net.dk> wrote:
> Klart - men giver nøglefiler større sikkerhed end at indtaste user/pass i
> min SSH klient, når jeg manuelt logger ind?

Bestemt. Det goer at en angriber ikke blot kan gaette eller paa anden
maade opfange dit password og derefter logge ind som dig. Han skal ogsaa
vaere i besiddelse af din noeglefil hvilket normalt betyder han skal
bryde ind i din workstation.

>> Din maskine kan angribes gennem OpenSSH fra hele nettet. Soerg for altid
>> at koere en version uden kendte sikkerhedsfejl. Som naevnt kan du
>> drastisk nedsaette risikoen af et hul i sshd ved at benytte privsep.
>
> OK - Jeg vil se på om jeg kan finde noget om privsep på google.

Man-siden for sshd_config skulle vaere en begyndelse:

UsePrivilegeSeparation
Specifies whether sshd separates privileges by creating an
un- privileged child process to deal with incoming network
traffic. After successful authentication, another process
will be created that has the privilege of the authenticated
user. The goal of privilege separation is to prevent
privilege escalation by containing any corruption within
the unprivileged processes. The default is ``yes''.

Der er ogsaa:

http://www.citi.umich.edu/u/provos/ssh/privsep.html

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

---

"Alex Holst" <a@mongers.org> wrote in message
news:dqab31-jel.ln1@miracle.mongers.org...
> Jimmy <nyhedsgruppe@get2net.dk> wrote:
> > Klart - men giver nøglefiler større sikkerhed end at indtaste user/pass
i
> > min SSH klient, når jeg manuelt logger ind?
>
> Bestemt. Det goer at en angriber ikke blot kan gaette eller paa anden
> maade opfange dit password og derefter logge ind som dig. Han skal ogsaa
> vaere i besiddelse af din noeglefil hvilket normalt betyder han skal
> bryde ind i din workstation.

OK - så overgår jeg til nøgler.


> >> Din maskine kan angribes gennem OpenSSH fra hele nettet. Soerg for
altid
> >> at koere en version uden kendte sikkerhedsfejl. Som naevnt kan du
> >> drastisk nedsaette risikoen af et hul i sshd ved at benytte privsep.
> >
> > OK - Jeg vil se på om jeg kan finde noget om privsep på google.
>
> Man-siden for sshd_config skulle vaere en begyndelse:

Herligt - tak for hjælpen.

Mvh
Jimmy