[disc] Features voor in een veilige webserver

[Verwijderd]

Ik ben bezig met het schrijven van een eigen webserver. De nadruk binnen dit hobbyprojectje ligt op veiligheid. Momenteel beschikt mijn webserver al over de volgende beveiligings features:

• Limiet stellen aan maximale totale aantal connecties
• Limiet stellen aan maximale aantal connecties vanaf een IP-adres.
• Mogelijkheid om IP-addressen te bannen voor een X aantal seconde op het moment dat er troep gestuurd wordt of omdat er teveel of te snel achter elkaar geconnect wordt,
• Upload snelheid kan gelimiteerd worden om het plattrekken van de lijn te voorkomen.
• Basic authentication
• Limiet stellen aan runtime tijd van een CGI programma.
• Instellen welke IP-adressen wel/geen toegang hebben tot bepaalde directories.
• Server draaien in een chroot omgeving.
• CGI processen kunnen onder de uid/gid van de eigenaar worden uitgevoerd.

Wat al in de planning zit:
• SSL verbindingen (wat een kut library is OpenSSL zeg )
• Limiet stellen aan aantal requests naar files in een bepaalde directory.

Heeft iemand nog stoere/handige/leuke ideeen voor een veilige webserver?

[avon]

ICMP blokeren scheelt je een hele hoop gekiddy aan je server.

+ Misschien niet zo zeer gericht op de webserver aanzich maar refer check op het verwerken van formulieren.

[muba]

Xitami (http://www.imatix.com) heeft de volgende optie: een maximum stellen voor de bestandsgrootte voor bestanden die via zo'n upload formuliertje verstuurd worden. Is het bestand groter dan deze maximum, dan wordt de upload gewoon genegeerd.

[elevator]

- Maximale request tijd van een request
- Minimaal aantal bytes/sec throughput

[Verwijderd]

elevator schreef op 04 april 2004 @ 17:03:
- Maximale request tijd van een request
- Minimaal aantal bytes/sec throughput

Heb ik beide.

[DanielB]

SSL is geen kutlibrary, 't probleem is dat je gewoon the fine manual moet lezen

[chem]

logging, en log-analysetools

[Verwijderd]

Zorgen dat je geen buffer-overruns krijgt....

[faabman]

AvOn schreef op 04 april 2004 @ 17:01:
ICMP blokeren scheelt je een hele hoop gekiddy aan je server.

+ Misschien niet zo zeer gericht op de webserver aanzich maar refer check op het verwerken van formulieren.

ICMP lijkt me iets wat op OS-niveau of daarvoor al geblocked moet zijn...

referrers worden door sommige browsers / tooltjes (norton IS) gesloopt, dus een dat is een onnodige toevoeging...

Wat per site handig kan zijn is een dataverkeer limiet en een maximale grote van een map...

[Soultaker]

Verwijderd schreef op 04 april 2004 @ 16:58:
• Upload snelheid kan gelimiteerd worden om het plattrekken van de lijn te voorkomen.

Dat lijkt me niet heel handig. Als je veel requests krijgt op een webserver, kun je er beter een klein aantal tegelijk afhandelen dan een heleboel tegelijk op een lage snelheid. Als je teveel requests tegelijk afhandelt dan stijgt het gebruik van resources als geheugen en threads en gaat bovendien de gemiddelde tijd per request omhoog. Om dat te voorkomen moet je een laag aantal concurrente requests (een aantal in de orde van het aantal processoren in het systeem, bijvoorbeeld) afhandelen.

• Server draaien in een chroot omgeving.

De vraag is hoe praktisch dat is, als je bestanden van verschillende gebruikers wilt serven. Het is ook erg lastig met het uitvoeren van cgi-applicaties die verwachten dat utillities op bepaalde plekken te vinden zijn.

[nero355]

faabman schreef op 04 april 2004 @ 20:41:
[...]


ICMP lijkt me iets wat op OS-niveau of daarvoor al geblocked moet zijn...

Leek mij ook maar durfde niks te zeggen

referrers worden door sommige browsers / tooltjes (norton IS) gesloopt, dus een dat is een onnodige toevoeging...

Is dit het fenomeen dat als ik iets bij guru3d.com wil downloaden en het redirecten begint ik weer bij de hoofdpagina uitkom en dus niks kan downloaden daar

Heb dat namelijk niet meer sinds ik een andere Firewall gebruik .........

[Verwijderd]

KewlKiddo: heb je een link van een goede OpenSSL manual voor me?
AvOn: ICMP pakketten hebben niks met een webserver te maken, ze komen niet eens aan bij m'n webserver.
chem: logging heb ik. Log analyse tools nog niet, maar heeft niet direkt met de veiligheid van de server te maken. Maar zal het noteren, thnx
vicz: ik durf voorzichtig te garanderen () dat mijn server bufferoverflow-vrij is.
soultaker: uploadsnelheid limieteren is ook niet bedoeld voor alle files, maar voor grote files (zoals bijvoorbeeld films) die mogelijkerwijs een lange tijd de lijn dicht kunnen trekken. chroot omgeving is idd niet handig als je userdirectories (/~username/) wil serven. Maar voor een server met maar een paar vaste websites is het zeer veilige feature. Daarbinnen CGI scripts uitvoeren is geen probleem. Ik lever bij de webserver een tool mee die programma's (zoals bijvoorbeeld bash of perl) inclusief bijbehorende libraries kan 'verhuizen' naar binnen de chroot omgeving. Werkt perfect.

[ Voor 4% gewijzigd door Verwijderd op 04-04-2004 22:17 ]

[Spider.007]

Waar kunnen we deze webserver downloaden? En mag ik vragen waarom je niet voor Apache hebt gekozen; dat volgens mij standaard al deze features heeft? Als je zegt dat je gewoon zelf wat wilde programmeren is dat ook goed Het lijkt me alleen flink veel werk

[Soultaker]

Apache is wel een beetje groot/lomp. Het project van de topic starter heeft meer weg van thttpd, een kleine webserver die ook throttling ondersteund en ge'chroot draait.

[chris]

Spider.007 schreef op 04 april 2004 @ 22:21:
Waar kunnen we deze webserver downloaden? En mag ik vragen waarom je niet voor Apache hebt gekozen; dat volgens mij standaard al deze features heeft? Als je zegt dat je gewoon zelf wat wilde programmeren is dat ook goed Het lijkt me alleen flink veel werk

Verwijderd schreef op 04 april 2004 @ 16:58:
Ik ben bezig met het schrijven van een eigen webserver. De nadruk binnen dit hobbyprojectje ligt op veiligheid. Momenteel beschikt mijn webserver al over de volgende beveiligings features:

[...]

Lezen

[ Voor 37% gewijzigd door chris op 04-04-2004 22:46 ]

[Spider.007]

chris schreef op 04 april 2004 @ 22:46:
[...]


[...]


Lezen

Je mag mijn vraag ook lezen als "Waarom start je een hobby project op om bestaande functionaliteit te herschrijven"

[Verwijderd]

Spider.007 schreef op 04 april 2004 @ 22:21:
Waar kunnen we deze webserver downloaden? En mag ik vragen waarom je niet voor Apache hebt gekozen; dat volgens mij standaard al deze features heeft? Als je zegt dat je gewoon zelf wat wilde programmeren is dat ook goed Het lijkt me alleen flink veel werk

De webserver heet Hiawatha is te downloaden via http://hiawatha.leisink.org/
Zoals in de reply hierboven al zegt: het is een hobby project. Je moet als nerd toch een hobby project hebben

Het is allemaal begonnen met dat ik voor veel vrienden Linux servers installeerde om internet te delen (tja, als je eenmaal bekend staat als Linux nerd). En dan wilde ze ook nog hun studentenhuis website erop kwijt. Beetje kut om Apache op een 386 met 16 MB te plaatsen. Helemaal als die huiswebsite uit 1 pagina en wat plaatjes bestaat en 1 keer in de week wordt opgevraagd. Heb toen zelf een webserver van een paar kilobyte geklust. En als je eenmaal aan het klussen gaat......

[Verwijderd]

Spider.007 schreef op 04 april 2004 @ 22:49:
[...]


Je mag mijn vraag ook lezen als "Waarom start je een hobby project op om bestaande functionaliteit te herschrijven"

Heeft Apache de mogelijkheid om 'kuttende IP adressen' te blokkeren? Upload snelheid aanpassen? En maximale aantal connecties (per IP)?

[ Voor 5% gewijzigd door Verwijderd op 04-04-2004 22:55 ]

[Verwijderd]

Soultaker schreef op 04 april 2004 @ 22:25:
Apache is wel een beetje groot/lomp. Het project van de topic starter heeft meer weg van thttpd, een kleine webserver die ook throttling ondersteund en ge'chroot draait.

Ik ken thttpd. Ik ben alleen van mening dat select() geen goede methode is om een volledige webserver mee te klussen. Maar dat is een lang verhaal.....

[Soultaker]

Heb je zin om het lange verhaal uit de doeken te doen? Ik ben namelijk wel benieuwd. (En een groot fan van single-threaded netwerkservers waar mogelijk).

[Verwijderd]

Soultaker schreef op 04 april 2004 @ 23:02:
Heb je zin om het lange verhaal uit de doeken te doen? Ik ben namelijk wel benieuwd. (En een groot fan van single-threaded netwerkservers waar mogelijk).

Als je select() gebruikt, dan handel je een stukje binnengekomen data af en duik je weer terug de select() in, wachtend op een volgend stukje data. Tijdens de afhandeling van een zo'n stukje data mag je, voor een optimale afhandeling, geen gebruik maken van systemcalls, want dan staat je process-state op sleeping. Een webserver die select() gebruikt voor de connectie afhandeling zal daarom ook een te uploaden file ook via select() afhandelen, dus: stukje lezen en select() in, stukje gelezen->uit select(), stukje sturen en select() in, stukje gestuurd->uit select(), stukje lezen enz. Doe je echter wel een systemcall tussen het uit de select() springen en terugkeren naar select(), dan ligt je process tijdelijk dood. Geen ramp in een multitasking omgeving, maar als je zo'n webserver dedicated gebruikt is dat dus niet optimaal. Er is nog niet echt een probleem geschetst voor webservers, maar wat als je bijvoorbeeld een directoryindex wilt weergeven (HTML geformateerd). Een directory inlezen is natuurlijk een systeemcall. Het is goed mogelijk, maar je code wordt er niet echt handig of leesbaar door als je elke directory-lees actie via select() gaat doen. En als je bijvoorbeeld een directory wilt scannen op de aanwezigheid van een userconfigfile (.htaccess in Apache) en indien aanwezig wilt inlezen, ga je dit dan ook via select() doen? Niet handig dus.

Gebruik je echter threading, dan kan, als een thread tijdens de afhandeling een systemcall doen, een andere thread een andere connectie verder afhandelen. Een webserver kan dan altijd iets doen en hoeft nooit te wachten op een systemcall.

Waar select() wel ideaal voor is (select() heeft als voordeel dat het tijd scheelt door het niet te hoeven aanmaken en weghalen van nieuwe processen) is voor daemons die simpele recht-toe recht-aan acties moeten uitvoeren. Goed voorbeeld: inetd. Keb zelf een daemon geklust die luistert naar meerdere poorten en logt wat daar op binnenkomt (soort van honey-pot), dus lezen van socket en schrijven naar disk, meer niet. Zoiets is ideaal voor select(). Een eenvoudige webserver kan ook goed met select(), maar zo gauw je geavanceerdere dingen gaat doen (waar dus heel simpel gezegd tussen de select()'s door systemcalls voor nodig zijn) dan zal select() geen optimale performance leveren denk ik. Je moet er dus voor zorgen dat je door het gebruik van select() niet soort van cooperative muilti-tasking code moet gaan schrijven.

[ Voor 84% gewijzigd door Verwijderd op 04-04-2004 23:29 ]

[Soultaker]

Ah, ik kan het wel met je eens zijn. thttpd gebruikt inderdaad allerlei ingewikkelde code om zowel files als sockets asynchroon te kunnen lezen/schrijven. Ik kan me voorstellen dat voor ingewikkeldere toepassingen de code op die manier veel te complex wordt (en dus lastig correct te schrijven en te onderhouden), maar voor een relatief simpele service als HTTP in essentie is lijkt het me ideaal.

Sowieso verdient threading al snel de voorkeur wanneer een service CPU-bound is aangezien je simpele requests niet wilt laten wachten op de ingewikkeldere (en handmatige scheduling waarschijnlijk meer moeite kost dan het waard is).

[Verwijderd]

Verwijderd schreef op 04 april 2004 @ 22:52:
[...]


De webserver heet Hiawatha is te downloaden via http://hiawatha.leisink.org/
Zoals in de reply hierboven al zegt: het is een hobby project. Je moet als nerd toch een hobby project hebben

Het is allemaal begonnen met dat ik voor veel vrienden Linux servers installeerde om internet te delen (tja, als je eenmaal bekend staat als Linux nerd). En dan wilde ze ook nog hun studentenhuis website erop kwijt. Beetje kut om Apache op een 386 met 16 MB te plaatsen. Helemaal als die huiswebsite uit 1 pagina en wat plaatjes bestaat en 1 keer in de week wordt opgevraagd. Heb toen zelf een webserver van een paar kilobyte geklust. En als je eenmaal aan het klussen gaat......

Leuke site.... ik mis alleen de screenshot sectie

[Verwijderd]

Verwijderd schreef op 05 april 2004 @ 04:44:
Leuke site.... ik mis alleen de screenshot sectie

Alsjublief, wijsneus.

[DumbAss]

Hee Gentoo, onderhoud jij ook een Gentoo ebuild?

[Spider.007]

Het verhaal op je site ziet er leuk uit... Vergeet niet dat je extention spelt als extension

[TeeDee]

Niet zozeer te maken met security (ligt eraan hoe je het leest ) maar meer met een feature, wanneer kunnen we dit op windows knallen?

[Verwijderd]

DumbAss schreef op 05 april 2004 @ 08:50:
Hee Gentoo, onderhoud jij ook een Gentoo ebuild?

Uhh, nee. Nog niet uitgezocht hoe dat werkt. Source tarball is ook nog niet compleet: make install werkt nog maar half. Ben het nog aan het leren De debian package is wel compleet.

[Verwijderd]

TeeDee schreef op 05 april 2004 @ 09:27:
Niet zozeer te maken met security (ligt eraan hoe je het leest ) maar meer met een feature, wanneer kunnen we dit op windows knallen?

Wellicht dat het onder cigwin werkt. Maar porten naar Windows zal ik niet doen, ik heb echt een gloeiende hekel aan Windows: teveel gezeik mee gehad.

[Verwijderd]

Spider.007 schreef op 05 april 2004 @ 09:18:
Het verhaal op je site ziet er leuk uit... Vergeet niet dat je extention spelt als extension

big oops!! zal het veranderen! thnx


Maaruh..... iemand nog stoere ideeen voor in mijn webserver?

[ Voor 15% gewijzigd door Verwijderd op 05-04-2004 10:01 ]

[TeeDee]

Support voor Mono?

[Verwijderd]

TeeDee schreef op 05 april 2004 @ 10:01:
Support voor Mono?

Uhh.... hmmm.... hoe werkt dah?

Ik bedoel eigenlijk meer beveiligingsfeatures die je graag in een webserver wilt zien maar nog niet in de bestaande webservers zitten. Ik heb met Hiawatha niet echt heel grote plannen (hoewel ik een tijdje terug van een amerikaan een mailtje kreeg die enthousiast was over Hiawatha en het momenteel aan het testen is voor gebruik in zijn bedrijfje). Hiawatha is een hobby project van me en de features die ik erin prop zijn meer experimenteel. Ik heb nog geen idee hoe ze uitpakken op het moment je Hiawatha gebruikt voor een druk bezochte website (ook nog niet de mogelijkheid voor gehad). Hiawatha is nog niet blootgesteld aan de slashdot test.

[ Voor 47% gewijzigd door Verwijderd op 05-04-2004 10:06 ]

[curry684]

Spider.007 schreef op 04 april 2004 @ 22:49:
[...]


Je mag mijn vraag ook lezen als "Waarom start je een hobby project op om bestaande functionaliteit te herschrijven"

Weet je hoe vaak 'Hello world' al is geschreven? En hoeveel mensen hier op het forum in PHP een stack-based parser hebben geschreven?

Leren programmeren doe je door te programmeren. Wat moet je doen als je voor je hobbyprojectje iets moet maken dat nog nooit iemand gemaakt heeft? Een 3D-OS dat de toekomst kan voorspellen of zo?

Oftewel: beperk je aub tot on-topic commentaar. Vanzelfsprekend is dit (nog) geen revolutionair wereldschokkend project, nobody cares

[Verwijderd]

curry684 schreef op 05 april 2004 @ 10:07:
Oftewel: beperk je aub tot on-topic commentaar. Vanzelfsprekend is dit (nog) geen revolutionair wereldschokkend project, nobody cares

Maar met wat nuttige input gaat het dat zeker worden! Dus kom maar op met je beveiligings ideeen. Wat mis je in Apache/IIS/sunONE/NSCA/enz?

Hoewel de al aanwezige beveiligingsfeatures nog puur theoretisch zijn (wel geimplementeerd, maar nog niet grootschalig getest), ben ik van mening dat ze zeker de moeite waard zijn.

[TeeDee]

Verwijderd schreef op 05 april 2004 @ 10:03:
[...]
Ik bedoel eigenlijk meer beveiligingsfeatures die je graag in een webserver wilt zien maar nog niet in de bestaande webservers zitten. Ik heb met Hiawatha niet echt heel grote plannen (hoewel ik een tijdje terug van een amerikaan een mailtje kreeg die enthousiast was over Hiawatha en het momenteel aan het testen is voor gebruik in zijn bedrijfje). Hiawatha is een hobby project van me en de features die ik erin prop zijn meer experimenteel. Ik heb nog geen idee hoe ze uitpakken op het moment je Hiawatha gebruikt voor een druk bezochte website (ook nog niet de mogelijkheid voor gehad). Hiawatha is nog niet blootgesteld aan de slashdot test.

Okay, het was meer in de trend van handige/leuke ideeën
Verder zal ik nog even verder verzinnen

- het tegengaan van "deeplinks" e.d. (zit toch in referrer checking?)

_{Ik wil de "zware" taak op me nemen om het op windows platform aan de praat te krijgen, zonder cygwin}

[ Voor 5% gewijzigd door TeeDee op 05-04-2004 10:23 ]

[Verwijderd]

TeeDee schreef op 05 april 2004 @ 10:18:
_{Ik wil de "zware" taak op me nemen om het op windows platform aan de praat te krijgen, zonder cygwin}

Cool natuurlijk, maar is dat niet tering veel werk?

- het tegengaan van "deeplinks" e.d. (zit toch in referrer checking?)

Da's idd wel cool. *genoteerd* Zit idd in de referer. Wel kut dat sommige gebruikers zo paranoia zijn dat ze alle HTTP headers met sterretjes of hekjes overschrijven.

More, more!

[ Voor 41% gewijzigd door Verwijderd op 05-04-2004 10:30 ]

[Spider.007]

curry684 schreef op 05 april 2004 @ 10:07:
[...]

Weet je hoe vaak 'Hello world' al is geschreven? En hoeveel mensen hier op het forum in PHP een stack-based parser hebben geschreven?

Leren programmeren doe je door te programmeren. Wat moet je doen als je voor je hobbyprojectje iets moet maken dat nog nooit iemand gemaakt heeft? Een 3D-OS dat de toekomst kan voorspellen of zo?

Oftewel: beperk je aub tot on-topic commentaar. Vanzelfsprekend is dit (nog) geen revolutionair wereldschokkend project, nobody cares

Uiteraard herschrijf ook ik het wiel vele malen; dus het is niet zo dat ik het nut van dit project in twijfel wil trekken. Ik vond het gewoon leuk om te horen waarom de TS ervoor kiest om juist een webserver zelf te gaan programmeren; met zo'n achtergrond verhaal is de scope van het product en zijn mogelijkheden en features dus ook makkelijker in te schatten

Oftewel; voordat ik kan inschatten welke features nuttig kunnen zijn in dit project heb ik een achtergrond nodig. Die heb ik nu en wat mij betreft was die vraag dan ook niet offtopic

[Verwijderd]

Spider.007 schreef op 05 april 2004 @ 10:28:
[...]

no problem Spider! Maaruh..... kom maar op met je ideeen!

[TeeDee]

Verwijderd schreef op 05 april 2004 @ 10:26:
[...]
Cool natuurlijk, maar is dat niet tering veel werk?
[...]

Jah
* TeeDee wil ook graag leren

[curry684]

Verwijderd schreef op 05 april 2004 @ 10:26:
[...]
Da's idd wel cool. *genoteerd* Zit idd in de referer. Wel kut dat sommige gebruikers zo paranoia zijn dat ze alle HTTP headers met sterretjes of hekjes overschrijven.

Da's dus een violation of protocol en mag je afstraffen Een 'conforming HTTP/1.1 client' geeft geen HTTP-referer veld indien er een user-induced actie aanleiding is tot de pageview (adres ingetypt of favorite aangeklikt), oftewel bevat een geldig veld. Indien er geen geldige content instaat mag jij een "HTTP 400 Malformed Request" teruggeven

[Verwijderd]

curry684 schreef op 05 april 2004 @ 10:43:
[...]

Da's dus een violation of protocol en mag je afstraffen Een 'conforming HTTP/1.1 client' geeft geen HTTP-referer veld indien er een user-induced actie aanleiding is tot de pageview (adres ingetypt of favorite aangeklikt), oftewel bevat een geldig veld. Indien er geen geldige content instaat mag jij een "HTTP 400 Malformed Request" teruggeven

Zozo, stenge BOFH hoor.

Maar ik geef je helemaal gelijk. En in Hiawatha is een 400 een mogelijke ban. Rotte met die paranoia huisvaders die 'veilig' het internet op gaan!

[Verwijderd]

TeeDee schreef op 05 april 2004 @ 10:34:
[...]
Jah
* TeeDee wil ook graag leren

Tja, hoe doen we dat dan? Terwijl jij een Hiawatha versie naar Windows port, prog ik natuurlijk door aan een volgende versie. Een CVS kan natuurlijk, maar om heeeeel eerlijk te zijn, ik zie het niet zo zitten om allemaal Windows code door mijn code te zien verschijnen.....

[curry684]

Verwijderd schreef op 05 april 2004 @ 10:47:
[...]

Zozo, stenge BOFH hoor. [afbeelding]

offtopic:
Hier op GoT hebben we gewoon :w voor de nette anti-aliased variant van die smiley:

[Erkens]

Ik heb even je manual vluchtig doorgelezen, maar ik zie dat je wel kan aangeven op welke poort er geluisterd moet worden, maar ik lees niets over het daarbij gebruikte ip?
Of worden alle IP's gebonden?

[Verwijderd]

Erkens schreef op 05 april 2004 @ 11:36:
Ik heb even je manual vluchtig doorgelezen, maar ik zie dat je wel kan aangeven op welke poort er geluisterd moet worden, maar ik lees niets over het daarbij gebruikte ip?
Of worden alle IP's gebonden?

Alle IP's worden idd gebonden. Maar in de volgende release kan met behulp van een AccessList aangegeven worden welke IP addresen toegang hebben tot welk domein of welke directory.

Alleen aan opgegeven devices bind()-en, klinkt goed. *genoteerd*

[Verwijderd]

Verwijderd schreef op 05 april 2004 @ 11:46:
[...]


Alle IP's worden idd gebonden. Maar in de volgende release kan met behulp van een AccessList aangegeven worden welke IP addresen toegang hebben tot welk domein of welke directory.

Alleen aan opgegeven devices bind()-en, klinkt goed. *genoteerd*

Kan iemand een kleine tip geven over hoe ik dat doe? Ik loop nu al een tijdje te zoeken op Google, maar ik heb eerlijk gezegd geen idee waar ik moet beginnen met zoeken.

Ik wil dus voor elkaar krijgen dat m'n webserver niet naar alle netwerkdevices luistert, maar alleen naar bijvoorbeeld lo en eth0.

[Soultaker]

Je kunt alleen aangeven aan welk adres je wilt binden, niet aan welke interface. Een interface kan immers een willekeurig aantal adressen hebben. Als je aan alle adressen van een specifieke interface wil binden, moet je eerst met getifaddrs de addressen van die interface vinden en daar dan een voor een aan binden.

In andere webservers is het ook gebruikelijk dat je de adressen (en niet de interfaces) opgeeft waaraan je wil binden. Meestal zijn de specifieke interfaces niet zo interessant, maar de adressen des te meer. (Denk bijvoorbeeld aan een PPP verbinding die dynamisch aan een interface verbonden wordt en dus een andere interface kan hebben, maar wel hetzelfde adres.)

[ Voor 37% gewijzigd door Soultaker op 07-04-2004 13:55 ]

[0xDEADBEEF]

Soultaker schreef op 07 april 2004 @ 13:53:
Je kunt alleen aangeven aan welk adres je wilt binden, niet aan welke interface. Een interface kan immers een willekeurig aantal adressen hebben. Als je aan alle adressen van een specifieke interface wil binden, moet je eerst met getifaddrs de addressen van die interface vinden en daar dan een voor een aan binden.

In andere webservers is het ook gebruikelijk dat je de adressen (en niet de interfaces) opgeeft waaraan je wil binden. Meestal zijn de specifieke interfaces niet zo interessant, maar de adressen des te meer. (Denk bijvoorbeeld aan een PPP verbinding die dynamisch aan een interface verbonden wordt en dus een andere interface kan hebben, maar wel hetzelfde adres.)

En andersom ? Het keihard binden aan een interface ? Denk aan een WAN-kant met DHCP.
Denk dat dat juist de "hindernis" is

[ Voor 5% gewijzigd door 0xDEADBEEF op 07-04-2004 14:25 ]

[Verwijderd]

Soultaker schreef op 07 april 2004 @ 13:53:
Je kunt alleen aangeven aan welk adres je wilt binden, niet aan welke interface. Een interface kan immers een willekeurig aantal adressen hebben. Als je aan alle adressen van een specifieke interface wil binden, moet je eerst met getifaddrs de addressen van die interface vinden en daar dan een voor een aan binden.

Een voor een binden, dat betekent dus dat ik meerdere sockets krijg. Is er geen andere manier zodat ik maar 1 socket heb waar de verschillende addressen aan gekoppeld zijn?

_edit_
of zou ik meerdere keren bind() kunnen doen op een socket? effe proberen....

[ Voor 8% gewijzigd door Verwijderd op 07-04-2004 20:38 ]

[Verwijderd]

Verwijderd schreef op 07 april 2004 @ 20:33:
of zou ik meerdere keren bind() kunnen doen op een socket? effe proberen....

Dat werkt dus niet. Iemand een idee hoe ik meerdere addressen aan 1 socket bind?
Loop nu al een uur tevergeefs te google-en.....

[MisterData]

Misschien support voor Pike

[Erkens]

Verwijderd schreef op 08 april 2004 @ 18:23:
[...]

Dat werkt dus niet. Iemand een idee hoe ik meerdere addressen aan 1 socket bind?
Loop nu al een uur tevergeefs te google-en.....

Ik denk dat je daarvoor toch echte meerdere sockets moet openen

MisterData schreef op 08 april 2004 @ 18:59:
Misschien support voor Pike

kan dat niet gewoon als CGI proces draaien?

[BezurK]

MisterData schreef op 08 april 2004 @ 18:59:
Misschien support voor Pike

offtopic:
Hahah als ik die site bekijk en die grafiek onderaan met "lines of code added" moet ik meteen aan een uitspraak van Bill Gates denken: "Measuring programming progress by lines of code is like measuring aircraft building progress by weight."

[Verwijderd]

Het is alweer een tijdje geleden, maar ik ben nog steeds aan het klussen aan mijn webserver. Een aantal van de in dit topic genoemde features zijn ondertussen opgenomen in de webserver: binden aan een IP adres en deeplinken blokkeren.

Iemand nog meer leuke ideeen voor een veilige webserver?

[Alarmnummer]

Verwijderd schreef op 21 augustus 2004 @ 18:06:
Het is alweer een tijdje geleden, maar ik ben nog steeds aan het klussen aan mijn webserver. Een aantal van de in dit topic genoemde features zijn ondertussen opgenomen in de webserver: binden aan een IP adres en deeplinken blokkeren.

Iemand nog meer leuke ideeen voor een veilige webserver?

Probeer je server zelf te gaan hacken. Niemand weet beter dan jij hoe je server in elkaar steekt.

Verder is een ketting zo sterk als zijn zwakste schakel. Wordt alles trouwens geunit test?

[ Voor 9% gewijzigd door Alarmnummer op 21-08-2004 18:52 ]

[Macros]

Worden alle buffers gecontrolleerd op overflows? Vooral in C(++) is dat een probleem.

[Verwijderd]

Ben uiteraard al helemaal los gegaan op m'n eigen webserver. Ik ben geen leek op het gebied van hacken en buffer overflows en durf daarom best te stellen dat mijn server veilig is.

Er zal nog best een foutje in de code zitten, maar dat zal zich dan alleen uiten in het niet goed werken van een bepaalde feature.

Iemand anders die los wil gaan? 82.210.86.227 poort 80 Let op, de banning-feature staat uiteraard aan. Dus als je los gaat kan het zeker gebeuren dat je voor een bepaalde tijd (max 1 minuut in mijn config) gebanned wordt.

(En nee, niet op andere poorten gaan kutten. En ja, ik (lees Snort) zie alles.)

[ Voor 9% gewijzigd door Verwijderd op 21-08-2004 19:48 . Reden: laatste regel ]

[commeric]

Mogelijkheid tot PHP ondersteuning? Want dan zou het wel eens een interessant project kunnen worden

[Verwijderd]

Voordat iedereen features gaat lopen roepen die er al inzitten:
http://hiawatha.leisink.org/ --> features

Ja dus, PHP wordt ondersteund (als CGI).

[Infinitive]

commeric schreef op 21 augustus 2004 @ 19:52:
Mogelijkheid tot PHP ondersteuning? Want dan zou het wel eens een interessant project kunnen worden

Moest het geen veilige server worden?

Je kicked nu pas mensen nadat de verbinding is tot stand gebracht. Misschien dat je moet blocken via een firewall. Dat maakt je wat beter bestending tegen dos attacks.

[Verwijderd]

Van Hiawatha website:
CommandChannel (control Hiawatha by telnetting to a special port)

Is dat wel zo veilig?

[0xDEADBEEF]

Hm :

Banning-feature

Heb gemerkt dat als pagina's te snel na elkaar opgevraagd worden, dat voor rare dingen kan zorgen icm een proxy ( hiawatha is vast een vhost ).

Hiawatha has been tested and runs perfectly on Linux, FreeBSD _{and MacOS X}

iptables/ipfw/ipfilter kan prima traffic shapen/rate limiten

Voor de rest: je kan het ook embedden lijkt mij en what about packages ?.

edit:
Ah, .deb's

offtopic:
While trying to retrieve the URL: http://hiawatha.leisink.org/index.php?

The following error was encountered:

* Zero Sized Reply

Squid did not receive any data for this request.

[ Voor 19% gewijzigd door 0xDEADBEEF op 21-08-2004 20:20 ]

[MTWZZ]

Verwijderd schreef op 04 april 2004 @ 22:54:
[...]


Heeft Apache de mogelijkheid om 'kuttende IP adressen' te blokkeren? Upload snelheid aanpassen? En maximale aantal connecties (per IP)?

Het lijkt me dat dit soort dingen net als met ICMP op OS level geblocked moeten worden. Dit omdat het OS dit veel effectiever kan doen. Je bent zo namelijk geen resources kwijt aan threads/childs (of wat je ook gebruikt).
Dit soort blocks zijn goed te automatiseren icm snort en consorten.

[Verwijderd]

@Infinitive: IP's waarvan continue gekut wordt kan je idd beter via een firewall blocken. Maar helaas is het niet altijd zo simpel. Denk aan inbel ip-adressen. En om nou zo'n IP adres permanent te blocken. Daarbij, veel hackers haken al af als je ze een tijdje blokkeert

@Zef: ja, die CommandChannel is alleen via localhost te bereiken.

@0xDEADBEEF: pagina's te snel achter elkaar opvragen wordt idd gezien als flooding. Als je ervanuit gaat dat een pagina uit niet meer dan X objecten bestaat (HTML files, plaatjes, etc), dan hoeft er in princiepe niet meer dan X objecten per tijd eenheid opgevraagd te worden. Deze tijd eenheid is de minimale tijd die nodig is om de pagina te bekijken. Dit is natuurlijk maar theorie die in de praktijk anders werkt. In mijn config mag je niet meer dan 15 files in 1 seconde op vragen. Ben je gebanned, dan ben je gezien de hoeveelheid files op mijn pagina's duidelijk aan het flooden geweest. Je kan natuurlijk ook om een andere reden gebanned zijn: maximale aantal connecties vanaf jou IP ( 8 ) of het sturen van zooi.
En een firewall kan geen traffic shapen op basis van het URL, Hiawatha wel.

@MTWZZ: Hiawatha kan op een flexibele manier bannen. Heeft zo z'n voordelen boven een statische IP ban. Hiawatha kan op basis van content een tijdelijke ban geven, iets wat een OS moeilijke kan. En het hoeft helemaal geen extra resources te kosten. Een thread aanmaken voor een client doe je natuurlijk pas nadat de connectie is goedgekeurd.

[ Voor 20% gewijzigd door Verwijderd op 21-08-2004 21:31 . Reden: antwoord op MTWZZ ]

[Exe-cuter]

Dit zijn nog eens echte Tweaker-projectjes ! Ben zelf beetje aan het experimenteren met linux, dus zal zeker eens gebruik maken van je programma.

[edit]
Waarom eigenlijk deze naamkeuze ?

[ Voor 13% gewijzigd door Exe-cuter op 21-08-2004 22:00 ]

[igmar]

Leuk project, maar waarom multithreaded ? Threading is zeker niet sneller als single-proces, vereist locking, en geeft problemen met third-party libs. Ik heb opmerkingen betreft syscalls gelezen, maar voor threads staat er tegenover dat locking kostbaar is, de linux pthread code verre van optimaal is, threads per stuk een heel stackframe kosten en absoluut niet sneller zijn als een oplossing gebaseerd op bv poll.

[Verwijderd]

@Exe-cuter: De naamkeuze is op zich logisch: Hiawatha als kleine broertje van Apache (Apache was de naam van een grote indiane stam)

@igmar: gezien mijn eerdere opmerking over de syscalls: multithreading heeft als grote voordeel dat je code netter en overzichtelijker wordt, dus minder kans op fouten.

[Alarmnummer]

Verwijderd schreef op 22 augustus 2004 @ 00:54:
@igmar: gezien mijn eerdere opmerking over de syscalls: multithreading heeft als grote voordeel dat je code netter en overzichtelijker wordt, dus minder kans op fouten.

Multithreading maakt alles juist veel gecompliceerder. Deadlocks, raceproblemen etc. Ik vind het nog altijd een lastig onderdeel.

[igmar]

Verwijderd schreef op 22 augustus 2004 @ 00:54:
@igmar: gezien mijn eerdere opmerking over de syscalls: multithreading heeft als grote voordeel dat je code netter en overzichtelijker wordt, dus minder kans op fouten.

Die heb ik gelezen en ze zijn niet correct :

Gebruik je echter threading, dan kan, als een thread tijdens de afhandeling een systemcall doen, een andere thread een andere connectie verder afhandelen. Een webserver kan dan altijd iets doen en hoeft nooit te wachten op een systemcall.

Systemcalls zijn redelijk kort van duur. Op een single-CPU machine hebben threads in dit geval geen enkel voordeel : D'r zit een dure context switch tussen. Verder is LinuxThreads verre van optimaal, dat is met NTPL gelukkig wat beter. Het verhaal van Dan Kegel is het lezen waard: D'r staan daar een paar event-based webservers op die kwa performances aan de top staan.

Verder zijn threaded apps echt een pain in the ass om te debuggen, en is de code en opbouw niet per definitie leesbaarder.

[Verwijderd]

Hoe dan ook, voor beide methodes (select() en threads) is wat te zeggen. Beide hebben voor- en nadelen. Deze discussie kan zo nog wel vele schermen doorgaan, want uiteindelijk blijft de beste keuze voor een van beide methodes subjectief.

Feit blijft dat ik denk dat Hiawatha ondertussen een zeer goede webserver is geworden. Waar dit topic om begonnen is: heeft iemand nog andere leuke ideeen voor in een webserver waar de nadruk ligt op security?

Is er daarnaast iemand bereid om de server te testen? Keb em zelf al ergens met succes in een productie omgeving draaien.

[ Voor 1% gewijzigd door Verwijderd op 22-08-2004 14:13 . Reden: typo ]

[Verwijderd]

Exe-cuter schreef op 21 augustus 2004 @ 21:59:
Waarom eigenlijk deze naamkeuze ?

Een Apache is een indiaan, en Hiawatha is een klein en dapper indiaantje.
Ken je klassiekers! (Donald duck)

[Exe-cuter]

Verwijderd schreef op 22 augustus 2004 @ 14:53:
[...]

Een Apache is een indiaan, en Hiawatha is een klein en dapper indiaantje.
Ken je klassiekers! (Donald duck)

Leuke naamkeuze. Dat Hiawatha een indiaan (stam) was wist ik nog niet

[Verwijderd]

[Verwijderd]

Ik denk zelf dat het zo goed als onmogelijk is om in een taal waarin mogelijk bufferoverflows voorkomen een veilige applicatie te bouwen, tenzij je een of ander verificatietooltje voor je applicatie bouwt.

[Verwijderd]

Verwijderd schreef op 22 augustus 2004 @ 17:20:
Ik denk zelf dat het zo goed als onmogelijk is om in een taal waarin mogelijk bufferoverflows voorkomen een veilige applicatie te bouwen, tenzij je een of ander verificatietooltje voor je applicatie bouwt.

Onzin, kwestie wat weten wat je doet en elke buffer goed controleren.

[Radiant]

Ziet d'r al goed uit
Misschien een feature om bepaalde User-Agent's te blokkeren (download accelerators enzo)?

[gorgi_19]

* gorgi_19 gaat eventjes opruimen....

Klein verzoekje aan iedereen, mag het wat liever naar elkaar toe? Een stelling tot de grond toe afmaken op basis van argumenten, geen probleem.

Maar laat dan wel de argumenten overheersen

Het hele unit test gedeelte heb ik afgesplitst naar [rml][ ALG] Unit Tests: vereist voor veiligheid of niet? *[/rml] Gaarne daar verder

[ Voor 91% gewijzigd door gorgi_19 op 22-08-2004 19:35 ]

[Verwijderd]

Mooi.... weet iemand nog leuke security-features voor in mijn webserver?

[igmar]

Wat betreft C zijn kwa veiligheid een aantal regels aan te bevelen :

- Gebruik geen str*cpy, str*cat of gets(). Voor gets() kun je fgets() gebruiken, en voor de stringfuncties zijn de strlcpy en strlcat uit OpenBSD aan te raden.
- Vermijd functies die statische libc buffers gebruiken. De thread-safe functies gebruiken deze niet.
- Check begincondities in functies met assert()'s. Het spaart je soms uren zoekwerk uit, en met een assert is tenminste duidelijk dat d'r wat fout gaat.
- Vertrouw geen invoer van buitenaf. Ga geen buffer van x bytes allocateren als dat aangegeven wordt, maar check eerst of het wel logisch is
- Gebruik valgrind
- Ik zet zelf een sloot warnings aan, meestal betekend warning == bug.

De code van de TS zag d'r degelijk uit, maar ik heb toch wat opmerkingen :

- Gebruik indien mogelijk statische variabelen
- Tonnen else - if voor de error checking maakt het onleesbaar, ik gebruik dan een goto maar label aan het einde van de functie, en schoon dan op. Da's ook meteen de enige goede toepasing van een goto
- Valgrind klaagt een x aantal keer over het gebruik van uninitialized variabele in syscalls en condities
- 't lekt memory

in log.c : Waarom de logfile constant openen en weer sluiten ? Ik zou de FILE * gewoon statisch maken, en d'r een pthread_mutex omheenzetten op concurrent access te regelen. Indien de messages < 512 bytes zijn kun je dat zelfs achterwege laten.

Verder net werk, van dit soort code moet d'r meer komen

[ Voor 5% gewijzigd door igmar op 22-08-2004 19:44 ]

[Erkens]

Verwijderd schreef op 22 augustus 2004 @ 19:28:
Mooi.... weet iemand nog leuke security-features voor in mijn webserver?

ik heb hem zojuist gedownload en ging hem compilen (zorg er even voor dat je README niet een of ander perl scriptje is ) en kwam er achter dat je verplicht bent om hem als root te starten. Op zich begrijpelijk als je daarna direct naar een eigen user gaat (oid) echter het lijkt me toch ook wel handig dat ik hem als normale user kan starten zonder root rechten. (uiteraard kan je dan poort 80 niet gebruiken, maar daar gaat het niet om, daar draait Apache al )

[Verwijderd]

@igmar: dank voor je commentaar, zoiets wilde ik horen. Ik gebruik valgrind, maar ben geen geheugenlekje tegengekomen. Zal nog eens kijken. thnx.

Keb zelf een hekel aan goto's. Dan liever do-while(false) icm breaks. Veel checks achter elkaar zijn naar mijn mening nooit mooi te krijgen. Het werkt nu goed, dus ik laat het zo.

De logfile descripter. Da's idd een puntje.

@Erkens: ik weet het, de README is niet de juiste plaats voor een script. Maar ben autotools nog aan het leren en wist niet zo gauw hoe ik zo'n extra script goed moest toevoegen. Een vriend van me is me autotools aan het leren en ik hoop na les 2 wat meer te kunnen Probleem is alleen dat we beide een beetje krap in onze tijd zitten, maar er word aan gewerkt.

[Erkens]

Verwijderd schreef op 22 augustus 2004 @ 20:11:
@Erkens: ik weet het, de README is niet de juiste plaats voor een script. Maar ben autotools nog aan het leren en wist niet zo gauw hoe ik zo'n extra script goed moest toevoegen. Een vriend van me is me autotools aan het leren en ik hoop na les 2 wat meer te kunnen Probleem is alleen dat we beide een beetje krap in onze tijd zitten, maar er word aan gewerkt.

mja, maakt mij niet uit, maar zoiets verwacht ik niet in een README, dan liever geen README, maargoed.
Maar ik kon in de readme dus niet vinden of het wel mogelijk is om als een normale user die server te kunnen starten?

[Verwijderd]

Erkens schreef op 22 augustus 2004 @ 20:17:
Maar ik kon in de readme dus niet vinden of het wel mogelijk is om als een normale user die server te kunnen starten?

Je bent natuurlijk vrij om de code aan te passen. Onderaan in hiawatha.c effe de getuid()==0 check wegslopen.

[Erkens]

Verwijderd schreef op 22 augustus 2004 @ 20:39:
[...]

Je bent natuurlijk vrij om de code aan te passen. Onderaan in hiawatha.c effe de getuid()==0 check wegslopen.

true (+ die "Warning: can't change uid/gid.") maar een setting hiervoor zou handig zijn, zeker met het oog op security, want ik zou echt nergens voor root rechten nodig hebben, immers ik draai ook niet op een poort <1024

---

[edit]
hmm, zelfs dan is het niet aan de praat te krijgen icm php:

Warning: couldn't bind to port 8080. Hiawatha has not been started!

Alleen als ik PHP enable in de config (met het juiste path!), heb verder niks bijzonders gedaan. Verder draait hij prima, alleen de combi met php niet.

[ Voor 28% gewijzigd door Erkens op 22-08-2004 21:01 ]

[Verwijderd]

Erkens schreef op 22 augustus 2004 @ 20:45:
true (+ die "Warning: can't change uid/gid.") maar een setting hiervoor zou handig zijn, zeker met het oog op security, want ik zou echt nergens voor root rechten nodig hebben, immers ik draai ook niet op een poort <1024

In de volgende versie zal ik die check weglaten. Is idd niet zo handig

Alleen als ik PHP enable in de config (met het juiste path!), heb verder niks bijzonders gedaan. Verder draait hij prima, alleen de combi met php niet.

Dan moet er al wat draaien op poort 8080....

[Erkens]

Verwijderd schreef op 22 augustus 2004 @ 21:16:
Dan moet er al wat draaien op poort 8080....

nee, er draait niets op poort 8080, daarnaast als ik die php settings weer uit de config haal dan werkt het wel.

code:

# Hiawatha httpd.conf
#
ServerPort = 8080
ServerId = 33:33
ConnectionsTotal = 32
ConnectionsPerIP = 6
TimeForRequest = 15
MaxKeepAlive = 32
SystemLogfile = /home/michael/hiawatha/system.log

PHPprogram = /usr/bin/php
TimeForCGI = 5
#ReconnectDelay = 2

Hostname = www.erkens.nl.eu.org
WebsiteRoot = /home/michael/public_html
UserWebsites = no
StartFile = index.php
LogFile = /home/michael/hiawatha/access.log

dit werkt, echter php files hebben een 403.
goed, ik voeg er een regel tussen:

code:

ExecutePHP = yes

en hij kan niet starten omdat poort 8080 in gebruik is, wat dus 100% zeker weten niet het geval is.

[Verwijderd]

Erkens schreef op 22 augustus 2004 @ 21:25:
en hij kan niet starten omdat poort 8080 in gebruik is, wat dus 100% zeker weten niet het geval is.

Vergeet niet dat als je net met een browser naar de webserver hebt lopen connecten en je direkt daarna de webserver stopt, de gebruikte poort een tijdje onbruikbaar is (TCP timeout). Zie 'netstat -ano | grep 8080' voor meer info.

[Erkens]

Verwijderd schreef op 22 augustus 2004 @ 21:33:
[...]

Vergeet niet dat als je net met een browser naar de webserver hebt lopen connecten en je direkt daarna de webserver stopt, de gebruikte poort een tijdje onbruikbaar is (TCP timeout). Zie 'netstat -ano | grep 8080' voor meer info.

Ik weet heus wel hoe TCP poorten etc werken hoor
Maar als een applicatie afgesloten wordt dient deze de die poorten vrij te geven, iets wat jij blijkbaar niet doet

Heb het nu werkend gekregen door steeds het poortnummer te veranderen want anders kost het me teveel tijd Kwam er wel achter dat ik mijn PHP hiervoor opnieuw moet compilen.

Security Alert! The PHP CGI cannot be accessed directly.

This PHP CGI binary was compiled with force-cgi-redirect enabled. This means that a page will only be served up if the REDIRECT_STATUS CGI variable is set, e.g. via an Apache Action directive.

Het is een keuze om PHP via CGI te benaderen, aan de ene kant kan het veiliger zijn (rechten van PHP bijvoorbeeld) maar aan de andere kant kost het performance.

[Verwijderd]

Erkens schreef op 22 augustus 2004 @ 22:27:
Het is een keuze om PHP via CGI te benaderen, aan de ene kant kan het veiliger zijn (rechten van PHP bijvoorbeeld) maar aan de andere kant kost het performance.

Klopt, maar het is ook niet mijn bedoeling om Apache na te maken. Als je een race-monster wil met veel features, dan moet je Apache nemen. Ben je op zoek naar een lichte, veilige webserver, dan is Hiawatha een betere keuze.

[Verwijderd]

Je mag in command.c wel wat commentaar zetten. De rest heb ik nog niet bekeken.

[Erkens]

Verwijderd schreef op 22 augustus 2004 @ 23:46:
Je mag in command.c wel wat commentaar zetten. De rest heb ik nog niet bekeken.

offtopic:
hiawatha.c is net zo erg, heb er wat in aan moeten passen om het werkend te krijgen

[Verwijderd]

Verwijderd schreef op 22 augustus 2004 @ 23:46:
Je mag in command.c wel wat commentaar zetten. De rest heb ik nog niet bekeken.

commentaar is voor mietjes

[Exe-cuter]

Commentaar is de basis van opensource
(Allez, niet dat ik er iets van afweet, maar vind het toch verdomd handig )

[Soultaker]

Een paar puntjes van commentaar. Als ik met het configure-script de installation prefix aanpas, dan worden de paden naar de config files en HTTP directory niet aangepast (en dan kan 'ie ze dus niet vinden).

Ik heb 'm getest onder FreeBSD 5 en daar geeft 'ie bij het compileren de melding:

In file included from libstr.c:13:
serverconfig.h:39: error: syntax error before "pthread_mutex_t"

Dit is op te lossen door in serverconfig.h eerst pthread.h te includen. (FreeBSD 4 en 5 hebben allebei native UNIX threads, in tegenstelling tot Linux.)

Daarna de volgende melding:

hiawatha.o: In function `accept_connection':
/home/maks/hiawatha-2.7/hiawatha.c:880: undefined reference to `pthread_attr_init'
/home/maks/hiawatha-2.7/hiawatha.c:881: undefined reference to `pthread_attr_setdetachstate'
/home/maks/hiawatha-2.7/hiawatha.c:883: undefined reference to `pthread_create'

Dit is op te lossen door -pthread aan de CFLAGS toe te voegen. (Geen idee of dit kwaad kan onder andere systemen of dat deze optie alleen onder BSD toegevoegd mag/moet worden.)

Verder missen sommige header files inclusions guards (#ifndef ... / #define .. / #endif); niet vereist maar naar mijn mening onnodig tegen de conventies ingaan.

Tenslotte vond ik ook de root-check nogal irritant; ik maak zelf wel uit onder welke user ik 'm uitvoer. (Zeker als ik een non-priviliged TCP port gebruik.) Als je exploits wilt voorkomen door niet als root user te draaien, dan zou het juist geen kwaad moeten kunnen om 'm direct al onder de goede user uit te voeren. Onder BSD is het bijvoorbeeld gebruikelijk om start-up scripts te gebruiken die al naar de juiste user su'en. Dit voorkomt bijvoorbeeld problemen wanneer de hiawatha executable zelf gehacked is.

Als ik tijd teveel heb zal ik er nog eens wat gedetailleerder naar kijken. Dat zal er dus wel niet van komen.

[ Voor 10% gewijzigd door Soultaker op 24-08-2004 17:38 ]

[Verwijderd]

Ik ben bezig met versie 2.8. Daarin is de root-check weg, per functie commentaar opgenomen met een omschrijving van de functie, het TCP-timeout probleem bij een herstart opgelost en een aantal andere kleine bugjes gefixed. Ik zal ook kijken naar het FreeBSD probleem, keb hier ook ergens nog een FreeBSD bak staan

Maar eerst nog effe hard leren voor een tentamen die ik morgen ochtend heb. (statistiek, bleeeeh! )

Alvast bedankt voor de feedback allemaal!!


Is er iemand van jullie btw goed met openssl? Ik probeer al een tijdje ssl aan de praat te krijgen in Hiawatha, maar vanwege de pthreads lukt me dat niet. Bij het verbinden naar de server krijg ik dan een "unknown SSL error".... fijn he!
Iemand die er effe wil kijken, mail me op [e-mail]. Dan stuur ik je de SSL versie van Hiawatha toe.

[ Voor 28% gewijzigd door Verwijderd op 25-08-2004 10:24 . Reden: ssl vraagje ]

[Verwijderd]

http://slashdot.org/

Post of ze je server willen hacken, kun je gelijk kijken of je server écht secure is.

(of moest dit in het andere topic??? :\ )

[Verwijderd]

Als je echt zoveel vertrouwen hebt in je webserver, moet je maar prijsgeld uitloven voor de persoon die je webserver als eerste hackt. Je moet dan al die "verlangzaam een hack-poging" dingen uitzetten, omdat het anders zo lang duurt, maar dat heeft niets met de veiligheid te maken.

Als het veilig is=> iedereen gaat je webserver gebruiken en je bent cool .
Als het niet veilig is=>dan sta je lekker voor paal .

Je kunt gewoon niet zeggen dat het de meest veilige webserver is, omdat je dat niet weet.

[Verwijderd]

@Defied: heb ik over zitten denken. Alleen, denk niet dat mijn huis ADSL lijntje dat trekt.... En daarbij, het is te massaal opeens. Mocht er toch nog een foutje in zitten, dan krijg ik op die manier natuurlijk nooit te weten wat het foutje is geweest.

@gang-ster: prijzengeld.... tja, als ik geld zou hebben Maar bij deze daag ik iedereen van Tweakers.NET uit om mijn webserver te hacken. En die "verlangzaam een hack-poging" dingen blijven natuurlijk aan, juist om ongeduldige hackers tegen te gaan. En dat heeft zeker wel met veiligheid te maken, alleen op een niet-technisch vlak .

In ieder geval, versie 2.8 is uit! Geen root-check, elke functie is van commentaar voorzien, plus nog een aantal andere features. Ik heb de source van mijn libssl toegevoegd. Mocht er zich een SSL guru onder jullie bevinden, of ie even wil kijken naar die lib. Ben namelijk niet zo goed in OpenSSL icm pthreads....

[ Voor 16% gewijzigd door Verwijderd op 26-08-2004 18:52 . Reden: daarom ]

[Verwijderd]

Checker-de-check!!! Keb net mijn volgende autotools lesje gehad. De installatie vanuit source loopt nu perfect. Een make install zet alles op de goede plek. Het is getest onder Linux, MacOSX en FreeBSD. Ik moet nog 1 feature request uitwerken, effe testen en dan release ik em.

[Verwijderd]

Leuk project, nette code ook. Heb even vluchtig met cscope gekeken naar buffer overflows, maar het zag er wel netjes gecode uit
Wel 1 opmerking, ik las dat je getuid() gebruikt om te kijken of je wel root bent.
Dat kan je in theorie wel doen, maaarrr...

code:

blasty@peyote:~$ cat getuid.c
#include <unistd.h>
#include <stdio.h>

int main() {
        if (getuid() == 0)
                printf("You are root!\n");
        else
                printf("You are not root!\n");

        return 0;
}
blasty@peyote:~$ gcc -o getuid getuid.c -Wall
blasty@peyote:~$ ./getuid
You are not root!
blasty@peyote:~$ cat uidzero.c
int getuid() { return 0; }
int geteuid() { return 0; }
int getgid() { return 0; }
int getegid() { return 0; }
blasty@peyote:~$ gcc -shared uidzero.c -o uidzero.so
blasty@peyote:~$ LD_PRELOAD=./uidzero.so sh
root@peyote:~# ./getuid 
You are root!
root@peyote:~# unset LD_PRELOAD
root@peyote:~# sh
blasty@peyote:~#

Je kan dit soort LD_PRELOAD truukjes voorkomen door met de -static flag te compilen (gcc). Nadeel is dat je binary dan wel wat groter word