/ Forside / Teknologi / Internet / Sikkerhed / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Sikkerhed
#NavnPoint
stl_s 37026
arlet 26827
miritdk 20260
o.v.n. 12167
als 8951
refi 8694
tedd 8272
BjarneD 7338
Klaudi 7257
10  molokyle 6481
Sikkerheds paradox
Fra : Bo Simonsen


Dato : 29-11-02 18:28

Hej!

Jeg har et par hjemmesider liggende på min Linux server, jeg er kommet
lidt i et sikkerheds paradox. Da jeg faktisk har 2 muligheder for
opsætning af hostingen:

* Oprette en UNIX-account med shellen /bin/false

* Bruge pure-ftpd med en virtual user, og ligeledes qmail med en virtuel
user. Og tilsidst et virtual host entry i apache.

Ulempen ved den sidste er at alt hænger på en UNIX account, så brugeren
faktisk kan se php filer etc, og overskrive deres data.

FTP'en er chrooted, men de kan gøre det gennem php.

Håber i forstår min problemstilling.

/Bo


 
 
Jesper Louis Anderse~ (29-11-2002)
Kommentar
Fra : Jesper Louis Anderse~


Dato : 29-11-02 18:26

On Fri, 29 Nov 2002 18:28:18 +0100,
Bo Simonsen <postmaster@mail.geekworld.dk> wrote:

>
> * Oprette en UNIX-account med shellen /bin/false
>
> * Bruge pure-ftpd med en virtual user, og ligeledes qmail med en virtuel
> user. Og tilsidst et virtual host entry i apache.
>

Hvad siger din sikkerhedspolitik? Hvad er konsekvenserne af at der
brydes ind på systemet? Hvad gør du hvis uheldet er ude?

Overvej det på et lidt mere abstrakt plan end du gør nu. Mit bud er at
du mangler overvejelserne i ovenstående først.


--
Jesper

Alex Holst (29-11-2002)
Kommentar
Fra : Alex Holst


Dato : 29-11-02 18:38

Bo Simonsen <postmaster@mail.geekworld.dk> wrote:
> Jeg har et par hjemmesider liggende på min Linux server, jeg er kommet
> lidt i et sikkerheds paradox. Da jeg faktisk har 2 muligheder for
> opsætning af hostingen:
>
> * Oprette en UNIX-account med shellen /bin/false
>
> * Bruge pure-ftpd med en virtual user, og ligeledes qmail med en virtuel
> user. Og tilsidst et virtual host entry i apache.
>
> Ulempen ved den sidste er at alt hænger på en UNIX account, så brugeren
> faktisk kan se php filer etc, og overskrive deres data.

Stoler du mere paa OS'et eller dine daemons til at lave adgangskontrol?
I naesten alle tilfaelde ville jeg vaelge OS'et, give brugeren en
passende shell (/bin/false, sftp-server, "cvs server", whatever) og derefter
benytte mig af forskellige funktioner i daemons paa mit system til at
soerge for at brugeren ikke kunne tilgaa unoedvendige resourcer.

Hvad vil du helt praecist beskytte imod, og hvor langt vil du gaa? Er
det saa farligt, at dine brugere kan laese hinandens index.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

Bo Simonsen (29-11-2002)
Kommentar
Fra : Bo Simonsen


Dato : 29-11-02 23:20

Alex Holst wrote:

> Stoler du mere paa OS'et eller dine daemons til at lave adgangskontrol?

Jeg ville stole mere på mit OS, da der mindst chance for fejl, i
softwaren. OG da daemons er 3 parts software.

> Hvad vil du helt praecist beskytte imod, og hvor langt vil du gaa? Er
> det saa farligt, at dine brugere kan laese hinandens index.html?

Det ville nok være farligt, hvis en "ond" bruger fik fat i password til
database server, gennem et php script.

Derved kan brugeren jo risikere at miste alt sit data, eller misbrug af
hans data.

Men jeg har jo pr. definition ingen onde brugere på mit system, med
mindre brugeren ikke vælger sit password ordenligt, så der er en person
der får "ulovlig" adgang til mit system.

/Bo


Alex Holst (29-11-2002)
Kommentar
Fra : Alex Holst


Dato : 29-11-02 23:20

Bo Simonsen <postmaster@mail.geekworld.dk> wrote:
> Det ville nok være farligt, hvis en "ond" bruger fik fat i password til
> database server, gennem et php script.

Jeg arbejder paa helt at undgaa passwords til databaser. getpeereid(2)
er ferm til den slags, og saa undgaar man problemer med passwords og
andet foelsomt i world-readable filer. Adgangen er bundet til brugerens
uid, og for at faa adgang til brugerens konto skal man kaempe sig forbi
to faktor auth. Held og lykke.

> Derved kan brugeren jo risikere at miste alt sit data, eller misbrug af
> hans data.

Soerg for at have backup.

Apache's suExec tillader at man fjerne world-readable bitten og faar
Apache til at switche egid for hver vhost. Det vil sige, at filerne skal
blot vaere group-readable af den bruger som Apache switcher til, og
ingen andre. Brugeren skal blot kunne skrive til sine filer. Apache maa
naturligvis paa intet tidspunkt kunne skrive til filerne.

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

Bo Simonsen (30-11-2002)
Kommentar
Fra : Bo Simonsen


Dato : 30-11-02 01:25

Alex Holst wrote:

> Jeg arbejder paa helt at undgaa passwords til databaser. getpeereid(2)
> er ferm til den slags, og saa undgaar man problemer med passwords og
> andet foelsomt i world-readable filer. Adgangen er bundet til brugerens
> uid, og for at faa adgang til brugerens konto skal man kaempe sig forbi
> to faktor auth. Held og lykke.

umiddelbart ser det ikke ud til at det system kald er integeret i Linux
kernen.

http://www.cs.helsinki.fi/linux/linux-kernel/2001-35/0512.html

> Apache's suExec tillader at man fjerne world-readable bitten og faar
> Apache til at switche egid for hver vhost. Det vil sige, at filerne skal
> blot vaere group-readable af den bruger som Apache switcher til, og
> ingen andre. Brugeren skal blot kunne skrive til sine filer. Apache maa
> naturligvis paa intet tidspunkt kunne skrive til filerne.

Mange tak for rådet.

/Bo


Peter Brodersen (30-11-2002)
Kommentar
Fra : Peter Brodersen


Dato : 30-11-02 18:06

On Fri, 29 Nov 2002 18:28:18 +0100, Bo Simonsen
<postmaster@mail.geekworld.dk> wrote:

>FTP'en er chrooted, men de kan gøre det gennem php.

Hvis PHP er det eneste, der volder dig problemer, så aktiver PHP's
Safe Mode-funktionalitet.

--
- Peter Brodersen

Søg
Reklame
Statistik
Spørgsmål : 177501
Tips : 31968
Nyheder : 719565
Indlæg : 6408527
Brugere : 218887

Månedens bedste
Årets bedste
Sidste års bedste