Beveiliging

[icyx]

Naar aanleiding van het topic [FreeBSD] Remote root écht niet mogelijk? , zat ik me af te vragen wat eigenlijk de visie's zijn over hoe je het best je OS kan beschermen. Dit zat ik me hardop af te vragen, waarop Boudewijn reageerde dat hij het ook wel interessant zou vinden.
Dit topic is dus bedoeld om beveiligings discussie's te voeren. Het kan van alles zijn, van productie-servers tot oude desktopjes die nooit meer aanstaan, al heeft beveiliging dan niet zoveel zin meer .
edit: Na de onderstaande post van Trailblazer gelezen te hebben is het misschien handiger om het over kleine bedrijven & thuisgebruikers te hebben; het word inderdaad anders misschien wel een beetje een overkill...

Aangezien ik zelf niet echt veel van beveiligingen afweet, lijkt het me wel interessant om in ieder geval te kijken hoe anderen hun systeem dicht timmeren. Zelf heb ik het bijvoorbeeld best simpel, ik baseer mijn veiligheid op het volgende:
-SSHD geen root-logins laten accepteren
-Een fatsoenlijk wachtwoord gebruiken voor root & user.
-Niets op root laten draaien als het ook niet nodig is.
-Natuurlijk stealthing door de router
-Gezond verstand & NOS-gebruik

Ik vind dit zelf voldoende, aangezien het een laptop betreft, die niet altijd aanstaat, en achter de genoemde router staat. De enige user ben ik, dus daar hoef ik het ook niet voor te doen. (ik heb daardoor ook autologin aangezet, zodat mijn fluxbox sessie automatisch gestart word). Het belangrijkste vind ik echter het wachtwoord, deze is zo gemaakt dat brute-forcing te lang duurt om nog nuttig te zijn bij zo'n systeem (9 tekens). Ook is het wachtwoord geen woord, maar iets in de trant van Ab12cd33e

Hoe en waarom maken jullie gebruik op de door jullie verkozen beveiligingsmethode? Heeft het ook wel nut om een simpel thuis systeem met bijvoorbeeld Port knocking uit te rusten?
Ik zou zeggen, brand los!

[ Voor 5% gewijzigd door icyx op 13-11-2007 14:22 ]

[TrailBlazer]

heb je her hier over een prive of werk situatie. Bij een werksituatie kan het namelijk allemaal veel heftiger omdat geld een minder grote rol speelt.
Bij een profi organisatie kan je bijvoorbeeld denken aan een apart LAN segment voor management. Apart LAN segment voor ILO/RIB/Console access. Deze LAN segmenten zijn dan enkel te bereiken vanaf PC'S die enkel in een beveiligde ruimte staan. Uiteraard werkt je dan ook met OTP.
Op een productiesysteem staat uiteraard geen enkele compiler als je iets gecompiled wil hebben doe je dat op je testsysteem.
Het is alleen mogelijk om een scp sessie op te starten vanaf je productie naar je testsysteem om data op te halen enzovoort enzovoort. Verkeer tussen deze systemen gaat ook weer via een Firewall

[icyx]

TrailBlazer schreef op dinsdag 13 november 2007 @ 13:54:
heb je her hier over een prive of werk situatie. Bij een werksituatie kan het namelijk allemaal veel heftiger omdat geld een minder grote rol speelt.
Bij een profi organisatie kan je bijvoorbeeld denken aan een apart LAN segment voor management. Apart LAN segment voor ILO/RIB/Console access. Deze LAN segmenten zijn dan enkel te bereiken vanaf PC'S die enkel in een beveiligde ruimte staan. Uiteraard werkt je dan ook met OTP.
Op een productiesysteem staat uiteraard geen enkele compiler als je iets gecompiled wil hebben doe je dat op je testsysteem.
Het is alleen mogelijk om een scp sessie op te starten vanaf je productie naar je testsysteem om data op te halen enzovoort enzovoort. Verkeer tussen deze systemen gaat ook weer via een Firewall

Hmm, zo had ik inderdaad nog niet gedacht; je hebt inderdaad veel meer mogelijkheden dan. Ik denk dat het dan op zich wel mee kan doen in de discussie, maar het valt natuurlijk wel buiten het bereik van de gemiddelde gebruiker, en ook de kleinere bedrijfjes. Mijn pa heeft ook een eigen bedrijf, en daar is echt het budget niet voor deze systemen. Niet dat het heel belangrijk is, de pc's zijn voor administratie, maar toch. Bij het bedrijf draait alles dan ook achter een firewall & stealthed router, in combinatie met een wekelijkse backup van de gegevens.
Maargoed, het kan wel inderdaad, maar het zal een stuk minder relevant zijn. Laten we het dan maar op de thuisgebruiker / kleine bedrijven houden, waar het budget belangrijk is

[Sprite_tm]

Sja, voor standaard kleine workstations die nauwelijks aanstaan is denk ik veilige wachtwoorden, je distro vaak updaten en een firewall ergens tussen de apps en het kwaaie Internet wel genoeg. Als je een server draait is je bakkie meestal wat gevoeliger voor scriptkiddies (ivm vast IP en always-on) en kan je gaan denken aan een echt goed afgeschermde firewall, secure services (proftpd of vsftpd ipv wu-ftpd, qmail ipv sendmail) en services ge-chroot draaien, en evt geintjes als password-based SSH-access uitzetten.

[Verwijderd]

icyx schreef op dinsdag 13 november 2007 @ 13:41:
[...]
-Natuurlijk stealthing door de router
[...]

Eh, bedoel je hier dat je de TTL niet verkleint voor ieder pakketje wat over je router gaat (lekker handig, met nat en je router als endstation ) of dat je de hosts achter je nat device verstopt dmv nat (je doet toch wel aan ipid cloaking he?)?

Verder is het van belang om te kijken waar de attack vectors vandaan komen, en op welke manieren ze je netwerk proberen binnen te dringen. Een paar dingen springen hierbij in 't oog:

- ssh bruteforcing / exploiting
- webapplicatie exploitatie

Er zijn nog een sloot met andere mogelijke attack vectors, maar dit zijn de belangrijkste, omdat je, als je je hiertegen wapent, je de grote bulk aan attacks al kwijt bent. Wat kun je doen om dit op te vangen?

- logfile analyse
- id(p)s toepassen
- bekende 3v0l ranges blocken

=> logfile analyse:
Je kunt in je logfiles zoeken naar bv remote includes door te kijken naar http:// in je request strings. Tenzij je een website host die gebruik maakt van XSS, kun je hier binnen niet al te lange tijd de meeste standaard scanners te pakken krijgen. Ook filteren naar aparte useragent strings (windows 98 wordt bv vaak gebruikt in sploits, net zoals libwww-perl) kan je attacker ip's opleveren. Nadeel is dat een event al moet hebben plaatsgevonden voordat je het kunt detecteren.

=> id(p)s toepassen:
Dmv een (signature based) IDS (ala snort) kun je filteren op bekende attack vectors op netwerk niveau. Als je dit vervolgens combineert met een management systeem (in de vorm van een log-parsing script of iets als prelude-ids) kun je je IDS ombouwen tot IPS, waarmee je dus ook attacks kunt blocken. Afhankelijk van je setup kun je hiermee voorkomen dat iemand de daadwerkelijke 3v0l request aflevert op je server danwel dat de attack halverwege gestopt wordt.

=> bekende 3v0l ranges blocken
Op internet zijn talloze lijsten te vinden van ip adressen waarvan bekend is dat ervandaan attacks uitgevoerd worden. De recent gepubliceerde lijsten van het RBN (Russian Business Network) zijn daar een mooi voorbeeld van. Je kunt deze lijsten gebruiken om per-default toegang tot je omgeving te ontzeggen voor deze ip's/ranges. Je kunt dit natuurlijk ook verder voeren, door bv alleen verkeer de benelux, of alleen van de client dsl ranges uit de benelux toe te staan (er zijn wat geintjes met geoip uit te halen hiervoor).

Verder wil ik hierbij nog zeggen dat als je geen gekke services draait en je alles uptodate houd, de meeste "beveiliging" alleen neerkomt op monitoring en dus, in principe, niet direct nodig

[Boudewijn]

mja ik heb hier een vrij dichtgetimmerde OpenBSD sshd_config liggen (zelf wat aan getweakt), zal die zo eens publiceren.

Mijn beveiligingsmaatregelen (onder andere, secrity through obscurity is soms wel fijn ).

- Productie doos is niet de SSH doos (vanaf internet bereikbaar).
- Losse mail en webserver
- 3 verschillende OSen (mail: FreeBSD, web: gentoo, router+firewall: OpenBSD).
- Geen ports spullen geinstalleerd op router (alleen default install), en dus vrij veilig
- Regelmatig users password laten veranderen, maar niet TE regelmatig.
- Losse DMZ waarbij de NICs van de machines die aan het internet hangen minder mogen dan de overige nics. DMZ naar gewone LAN is ook met een losse OpenBSD router gedaan.
- Losse doos met UCARP geconfigged die de mail kan hosten zodra de reguliere mailserver down gaat. Andere software, hardware (sparc vs. x86) en OS.
- Routers booten naar com0. Je moet dus fysiek aanwezig zijn wil je kloten, of de nullmodem kabel moet even ergens aan worden gehangen. Geen SSH!

[ Voor 10% gewijzigd door Boudewijn op 13-11-2007 17:03 ]

[jurp5]

Wel leuk onderwerp, ik gebruik sinds een maand ssh-ssl-proxy http://sourceforge.net/projects/ssh-ssl-proxy/ .
Dat is een daemon die afhankelijk wat de client spreekt de connectie doorstuurt naar ssh of https. Zo krijg je minder password attacks en is je ssh moelijker te vinden, want hij draait gewoon op de https poort

Verder gebruik ik ook nog ssh keys en PremitRootLogin staat ook uit.

[ Voor 5% gewijzigd door jurp5 op 13-11-2007 21:17 . Reden: duidelijker gemaakt ]

[bvk]

Kijk eens aan, wat een losse opmerking niet teweeg brengt

Punt wat ik bij wil dragen aan de thuisgebruiker: zorg voor een router met niet alleen NAT, maar ook met een netjes te configureren firewall.
Zelf heb ik hele goede ervaringen met Zyxel, niet duur, maar wel veel opties.

Ik heb alleen rules aangemaakt voor FTP en SSH richting mijn FreeBSD server en verder nog HTTP/HTTPS naar mijn Windows Server 2008 testbak. De rest zit potdicht. Hoop ik...

[Crakie]

Ik heb geen server, maar mijn desktop (Kubuntu) staat ook zo'n beetje altijd aan. Ik heb daarom - en ook uit interesse overigens - onlangs wat zitten googlen om een en ander dicht te timmeren. Hieronder wat dat heeft opgeleverd en waar ik nog vragen over heb:

- Met het tooltje nmap gekeken welke poorten open staan en gechecked of dat klopt. Ik zit achter een hardwarerouter dus die poorten staan niet écht open naar de buitenwereld.
- SSH: geen root access en uitsluitend toegang via keys
- Firestarter geïnstalleerd om IP-tables grafisch te kunnen manipuleren.
- Via diverse sites geverifieerd dat ik in stealth mode draai op de belangrijkste poorten. Mijn router reageert echter wel op een ping verzoek. Vraag: ik kan bij god geen instelling op de router vinden waarmee ik dat kan veranderen. Iemand een idee? Het is een Copperjet 816-2P (en ik heb geen handleiding).
- De router heeft een firewall, maar die staat uit. Hij gebruikt wel NAT. Verdient het de aanbeveling die aan te zetten? Ik heb om eerlijk te zijn weinig verstand van netwerken, maar ik vermoed dat ik dan regels moet opstellen voor al het toegestane verkeer.

[TrailBlazer]

in principe wil je blokkeren wat voor verkeer je server naar buiten opzet. Zo voorkom je dat je spamruns gaat doen mocht je ooit besmet raken. Dus naar buiten poort 80 20 21 25 meer heb je niet nodig. Howel mischien news poort weet ik even niet.

[ Voor 10% gewijzigd door TrailBlazer op 13-11-2007 21:22 ]

[Mr_gadget]

Maar zou een spammer zijn eigen domein gebruiken voor spamruns? dwz in zijn geval is het geen server dus ook geen domein dus dan moet de spammer een eigen domein gebruiken (of de pop account).
Zou iemand mij een tip kunnen geven hoe je in debian / ubuntu een service als niet root kan draaien?

[Boudewijn]

mischien iets met daemon-tools proberen?

[CyBeR]

Mr_gadget schreef op dinsdag 13 november 2007 @ 21:34:
Maar zou een spammer zijn eigen domein gebruiken voor spamruns? dwz in zijn geval is het geen server dus ook geen domein dus dan moet de spammer een eigen domein gebruiken (of de pop account).

Je hoeft zelf geen e-mail te kunnen ontvangen om een spamrun te doen. Je kiest gewoon een willekeurig domein uit (mijne bijvoorbeeld ) en stelt dat in als afzenderadres. Vervolgens zit de eigenaar van dat domein (ik dus ) met de bounces opgescheept.

[ Voor 7% gewijzigd door CyBeR op 14-11-2007 00:44 ]

[Boudewijn]

true, daarom is mijn maildoos ook de enige die van binnenuit wat kan met poort 25

[Verwijderd]

Kan iemand mij nou eens uitleggen wat precies met de "stealth" mode bedoelt wordt? Het klinkt als een enorme vaporware optie namelijk Overigens is de measure die TrailBlazer voorstelt (egress filtering) een erg verstandige optie, maar is meestal vrij impopulair, vooral op thuis/mkb netwerken, omdat er dan opeens allerlei dingen niet meer werken.

[TrailBlazer]

stealth is gewoon de optie dat een router alle binnenkomende connecties die niet mogen gewoon droppeden geen FYN stuurt of iets dergelijks. Is een marketing term.

[eghie]

Houd er ook rekening mee dat je firewalls hebt op verschillende niveau's, namelijk: applicatie filter, packet filter en host filter. Je zou een applicatie filter op alle clients kunnen installeren, zodat ze toestemming moeten geven als een applicatie verbinding maakt met het internet. Packet filter en host filter op je firewall. Als het kan alle hosts uit aziatische landen filteren en rusland en andere landen die bekend staan om de vele hacks/spamruns. Gebruik hiervoor misschien ook dezelfde lijst als peerguardian.

Daarnaast zou je kunnen zorgen dat je alleen via een VPN verbinding, je servers kunt overnemen.

Ook heb je nog iets als port knocking. Je zou dat ook kunnen gebruiken om de boel wat af te schermen. Dit misschien voor als je geen VPN verbinding kunt gebruiken.

Je kunt een pakket als Nagios enzo gebruiken om je servers in de gaten te houden.

Om SSH tegen bruteforce te beveiligen zou je een pakket als fail2ban kunnen gebruiken. Wat je daarnaast ook nog zou kunnen doen, is met een log filter (bijv. swatch) je /var/log/auth.log filteren op successvolle logins via SSH, en die laten mailen, zodat je weet wie wanneer inlogd.

[Verwijderd]

TrailBlazer schreef op woensdag 14 november 2007 @ 09:50:
stealth is gewoon de optie dat een router alle binnenkomende connecties die niet mogen gewoon droppeden geen FYN stuurt of iets dergelijks. Is een marketing term.

Ooooh, een DROP ipv een REJECT dus Nahja, niet zo boeiend, het frustreert alleen mensen die niet weten hoe ze met portscanners moeten omgaan

@echie: Stel je deze situatie ff voor. Je zit bij een internet cafe en je wilt gaan portknocken. Je beheerst de router waar je achter zit niet. Vervolgens ga je portknocken. De admin van de router vist je sequence op, en zodra je wegbent probeert ie de sequence uit. Hee, poort 22 gaat open Tevens, in dit geval zit je ook achter een nat device, waar $veel anderen ook opzitten. Omdat je portknocking toestaat op basis van extern ip adres krijgt iedereen in 't cafe toegang tot je bak. Leuker wordt dit als je het doet op een lan party / hacking party ofzo... Portknocking is als een soort grote sirene die aangeeft dat er iets te vinden is op $bepaald ip adres en mensen die erin geintereseerd zijn gaan je daardoor als target zien...

[icyx]

eghie schreef op woensdag 14 november 2007 @ 10:05:
Houd er ook rekening mee dat je firewalls hebt op verschillende niveau's, namelijk: applicatie filter, packet filter en host filter. Je zou een applicatie filter op alle clients kunnen installeren, zodat ze toestemming moeten geven als een applicatie verbinding maakt met het internet. Packet filter en host filter op je firewall. Als het kan alle hosts uit aziatische landen filteren en rusland en andere landen die bekend staan om de vele hacks/spamruns. Gebruik hiervoor misschien ook dezelfde lijst als peerguardian.

Daarnaast zou je kunnen zorgen dat je alleen via een VPN verbinding, je servers kunt overnemen.

Ook heb je nog iets als port knocking. Je zou dat ook kunnen gebruiken om de boel wat af te schermen. Dit misschien voor als je geen VPN verbinding kunt gebruiken.

Je kunt een pakket als Nagios enzo gebruiken om je servers in de gaten te houden.

Om SSH tegen bruteforce te beveiligen zou je een pakket als fail2ban kunnen gebruiken. Wat je daarnaast ook nog zou kunnen doen, is met een log filter (bijv. swatch) je /var/log/auth.log filteren op successvolle logins via SSH, en die laten mailen, zodat je weet wie wanneer inlogd.

Dat met swatch klinkt wel interessant, daar zal ik eens naar kijken . Verder; is een VPN veiliger dan een secure key-based ssh-tunnel? Het lijkt me dat je beter SSH kan hebben icm fail2ban inderdaad.

En reboot, ik deel inderdaad je port-knock mening, dat je verder 'interessant' word. Echter, je kan het dan nog tijdelijk uitzetten. Al zit je bij de gemiddelde huis-tuin-keukengebruiker thuis, haalt het namelijk totaal niet uit, die weten toch niet wat je ermee moet doen. Verder kan je het natuurlijk bij dat soort evenementen even tijdelijk uitzetten.

[eghie]

Verwijderd schreef op woensdag 14 november 2007 @ 12:02:
[...]

Ooooh, een DROP ipv een REJECT dus Nahja, niet zo boeiend, het frustreert alleen mensen die niet weten hoe ze met portscanners moeten omgaan

@echie: Stel je deze situatie ff voor. Je zit bij een internet cafe en je wilt gaan portknocken. Je beheerst de router waar je achter zit niet. Vervolgens ga je portknocken. De admin van de router vist je sequence op, en zodra je wegbent probeert ie de sequence uit. Hee, poort 22 gaat open Tevens, in dit geval zit je ook achter een nat device, waar $veel anderen ook opzitten. Omdat je portknocking toestaat op basis van extern ip adres krijgt iedereen in 't cafe toegang tot je bak. Leuker wordt dit als je het doet op een lan party / hacking party ofzo... Portknocking is als een soort grote sirene die aangeeft dat er iets te vinden is op $bepaald ip adres en mensen die erin geintereseerd zijn gaan je daardoor als target zien...

Je moet niet je complete authenticatie regelen via port knocking. Dan kan er dus nog niemand bij, tenzij diegene de gebruikernaam en wachtwoord/key heeft. Het voordeel van port knocking is bijvoorbeeld dat over het algemeen beschermd bent tegen bruteforcende bots, die zien je poort in het begin als closed/stealth. Die gaan niet verder proberen dan. Je moet er niet 100% op gaan vertrouwen en dat maar als voldoende authenticatie gaan zien.

Je wordt inderdaad als "interessant" doelwit gezien, door de beheerder die dat door krijgt. Maar jah, als je de boel voor de rest goed beveiligd, hoef je je niet veel zorgen te maken. Of je bent al standaard bereikbaar via SSH (zonder portknocking), dan kan de beheerder ook zien dat je SSH gebruikt en staat die poort voor hem al open, of hij ziet je sequence en probeerd die en dan pas is je SSH open. Zie het als een stukje extra beveiliging, maar niet als enige top beveiliging.

icyx schreef op woensdag 14 november 2007 @ 12:30:
[...]

Dat met swatch klinkt wel interessant, daar zal ik eens naar kijken . Verder; is een VPN veiliger dan een secure key-based ssh-tunnel? Het lijkt me dat je beter SSH kan hebben icm fail2ban inderdaad.

En reboot, ik deel inderdaad je port-knock mening, dat je verder 'interessant' word. Echter, je kan het dan nog tijdelijk uitzetten. Al zit je bij de gemiddelde huis-tuin-keukengebruiker thuis, haalt het namelijk totaal niet uit, die weten toch niet wat je ermee moet doen. Verder kan je het natuurlijk bij dat soort evenementen even tijdelijk uitzetten.

Mwah, VPN en key-based ssh is vergelijkbaar qua veiligheid. Ligt een beetje aan de situatie wanneer je wat wil gebruiken. Beheer je meerdere servers in het zelfde netwerk, dan is VPN misschien handig. Plus dat ook met VPN je poorten niet open hoeven te staan voor het grote publiek.

[Verwijderd]

eghie schreef op woensdag 14 november 2007 @ 13:22:
[...]
Het voordeel van port knocking is bijvoorbeeld dat over het algemeen beschermd bent tegen bruteforcende bots, die zien je poort in het begin als closed/stealth.

Daar heb ik een tarpit daemon icm wat pf rules voor. Dat zorgt ervoor dat de kiddies, die lijsten met ip's gaan trollen, flink veel tijd spenderen aan het opvangen van mn version string (zelfgeschreven in python, prelude-enabled, support= zie de source, patches zijn welkom)

Je wordt inderdaad als "interessant" doelwit gezien, door de beheerder die dat door krijgt. Maar jah, als je de boel voor de rest goed beveiligd, hoef je je niet veel zorgen te maken. Of je bent al standaard bereikbaar via SSH (zonder portknocking), dan kan de beheerder ook zien dat je SSH gebruikt en staat die poort voor hem al open, of hij ziet je sequence en probeerd die en dan pas is je SSH open. Zie het als een stukje extra beveiliging, maar niet als enige top beveiliging.

Duss... Waarom doe je het dan uberhaupt? Als je in de moms&pops netwerken zit is het nutteloos en als je in hostile netwerken zit (waar dit nu precies voor bedoelt zou moeten zijn) dan sta je als een rooie boei boven water als je portknocking gebruikt. En heb je dit niet ook opgelost door je sshd op een andere poort dan 22 te draaien? (het voorkomen dat je gebruteforced wordt dan he)

Mwah, VPN en key-based ssh is vergelijkbaar qua veiligheid. Ligt een beetje aan de situatie wanneer je wat wil gebruiken. Beheer je meerdere servers in het zelfde netwerk, dan is VPN misschien handig. Plus dat ook met VPN je poorten niet open hoeven te staan voor het grote publiek.

Beide zijn crypto tunnels en beide zijn zo veilig als de endpoints en de gebruikte algoritmen.

[Boudewijn]

leuk r3boot, kun je daar wat meer over vertellen?
ziet er namelijk best interessant uit

[VisionMaster]

Verwijderd schreef op woensdag 14 november 2007 @ 12:02:
[...]

Ooooh, een DROP ipv een REJECT dus Nahja, niet zo boeiend, het frustreert alleen mensen die niet weten hoe ze met portscanners moeten omgaan

@echie: Stel je deze situatie ff voor. Je zit bij een internet cafe en je wilt gaan portknocken. Je beheerst de router waar je achter zit niet. Vervolgens ga je portknocken. De admin van de router vist je sequence op, en zodra je wegbent probeert ie de sequence uit. Hee, poort 22 gaat open Tevens, in dit geval zit je ook achter een nat device, waar $veel anderen ook opzitten. Omdat je portknocking toestaat op basis van extern ip adres krijgt iedereen in 't cafe toegang tot je bak. Leuker wordt dit als je het doet op een lan party / hacking party ofzo... Portknocking is als een soort grote sirene die aangeeft dat er iets te vinden is op $bepaald ip adres en mensen die erin geintereseerd zijn gaan je daardoor als target zien...

Ik bouw mijn firewall regels zo op dat er altijd een DROP volgt ipv een reject. Bij een REJECT krijgt de portscannende partij niet direct een negatief antwoord en blijft nog even bungelen tot er een time-out volgt. Dus ik vreet een beetje van de resources.

Maar port knocking alleen is niet voldoende om je te authenticeren bij een server. Als het om SSH toegang gaat, dan kan je stellen dat die fase daar gebeurt. Heb je dat niet, dan heb je simpelweg enkelt de simpelste probes ontlopen op je service achter de portknocking firewall.

De sequence moet op te vangen zijn door mensen, zonder succes. Je kan het port knocking idee uitbreiden door een token of ticket mee te sturen in het bericht. Dit zou dan snel en in 1 slag gecontrolleerd kunnen worden aan de kant van de firewall.

[SCIxX]

Voor prive maken mensen zich iig vaak veeel te druk, vooral als ze iets als zonealarm installeren. Dan zie je elke 5minuten wel weer een gevaarlijke attack op je pc plaatsvinden, terwijl je zonder die firewall nergens last van hebt.

[Boudewijn]

uhh ja sowieso heb je weinig zorgen als je een nette bastionfirewall hebt
zeker als je geen windows draait, heb je geen zonealarm voor nodig ....

[SCIxX]

Boudewijn schreef op woensdag 14 november 2007 @ 21:38:
uhh ja sowieso heb je weinig zorgen als je een nette bastionfirewall hebt
zeker als je geen windows draait, heb je geen zonealarm voor nodig ....

Ik gebruik gewoon mn windows firewall en een virusscanner. Ik zit dan ook nog achter een router maar ook zonder router kan ik me dan niet druk maken.

[TrailBlazer]

waarom nou weer die term bastionfirewall. Het is gewoon een firewall niet meer en niet minder. Het kan ook nooit kwaad om een firewall te draaien op welk systeem dan ook. Unix of windows alles heeft vulnerabilities. Wil je geen firewall draaien op je machine zorg dan dat het segment achter een firewall zit. Tegelijkertijd moet je dan ook zorgen dat je je switches inricht met private VLANS. Zo voorkom je dat je client/server met andere machines op dat LAN kan praten. Enkel communiceren met de default gateway is meer dan genoeg.

[Boudewijn]

goed zo, en wat is nou die default gateway aka 'firewall': een bastionfirewall.
dit omdat hij verkeer doorlaat als zijnde router.

offtopic:
ik vind persoonlijk de hele windows discussie hier niet echt relevant.

[TrailBlazer]

De term bastion firewall ben ik serieus nog nooit tegengekomen in de 7 jaar dat ik nu met networking bezig ben. Iedere firewall routeert en laat een deel van het verkeer door. Dat je als client als jeverkeer naar een firewal stuurt doet daar niks aan af.

[CyBeR]

TrailBlazer schreef op donderdag 15 november 2007 @ 07:27:
De term bastion firewall ben ik serieus nog nooit tegengekomen in de 7 jaar dat ik nu met networking bezig ben. Iedere firewall routeert en laat een deel van het verkeer door. Dat je als client als jeverkeer naar een firewal stuurt doet daar niks aan af.

Ik wel. Da's een Microsoft ISA Server term. Buiten dat heb ik 't ook nog nooit gehoord.

[Boudewijn]

er is gewoon een wiki-artikel over.
ik heb hem wel @ HBO gehad trouwens, en niet in de windows sfeer.

[CyBeR]

Boudewijn schreef op donderdag 15 november 2007 @ 08:54:
er is gewoon een wiki-artikel over.
ik heb hem wel @ HBO gehad trouwens, en niet in de windows sfeer.

Overigens is dat een Bastion Host. En da's dan weer geen firewall.

Kort gezegd wij zouden het op prijs stellen als je de juiste terminologie gebruikte.

[Boudewijn]

waar komt de term halverwege deze page dan vandaan?
http://www.onlamp.com/pub/a/bsd/2000/07/05/OpenBSD.html

Kort gezegd: ik zou het op prijs stellen als je niet zo mierenneukt.

[CyBeR]

Boudewijn schreef op donderdag 15 november 2007 @ 09:20:
waar komt de term halverwege deze page dan vandaan?
http://www.onlamp.com/pub/a/bsd/2000/07/05/OpenBSD.html

Kort gezegd: ik zou het op prijs stellen als je niet zo mierenneukt.

Omdat één artikel het woord twee keer gebruikt is 't opeens algemeen geaccepteerde terminologie? Ik dacht 't niet..

[VisionMaster]

Boudewijn schreef op donderdag 15 november 2007 @ 09:20:
waar komt de term halverwege deze page dan vandaan?
http://www.onlamp.com/pub/a/bsd/2000/07/05/OpenBSD.html

Kort gezegd: ik zou het op prijs stellen als je niet zo mierenneukt.

Ik lees deze term voor het eerst. Wat er staat is dat een bastion firewall werkt zoals ik het van een NAT box kan verwachten. In dit geval met het doel om selectieve porten te forwarden naar de services die je aanbiedt. In dit geval dus om het onmogelijk te maken dat iemand je andere services misbruikt op die hosts.

Op zich komt het wel erg in de buurt van de term bastion. Volgens mij was dat de oude term voor een bode met koets en paard. Die bekijkt ieder pakketje en beslist of het door gegeven moet worden of de prullenbak in kan. Het verschil is dat de OpenBSD oplossing niet om te kopen is, zoals de oude bastions

Bottomline: zullen we voor zo'n scenario niet gewoon stellen dat het om een NAT opstelling gaat?

[ Voor 12% gewijzigd door VisionMaster op 15-11-2007 11:09 ]

[Boudewijn]

prima
@CyBeR, op mijn HBO (hogere inf.) gebruikte men de term ook. lijkt me redelijk betrouwbaar.

laten we deze discussie maar niet voortzetten, zal namelijk nergens toe leiden.

[Verwijderd]

Beetje kansloze discussie dit. Sterker nog, als we het zo gaan trekken is "firewall" uberhaupt een verkeerde term voor waar het er over het algemeen in deze discussie voor gebruikt wordt, want het is een packetfilter

Boudewijn: er is geen verschil tussen een "default gateway firewall" en een "end node firewall", beide draaien packetfilters en het is onnodig om hier een aparte term voor te gebruiken. Ik denk dat de term "default gateway" de lading meer dan voldoende dekt

edit:

Overigens, om tarpitd te gebruiken moet je al je binnenkomend verkeer op poort 22 wat niet vanaf een bepaalde lijst met ip's afkomt redirecten naar je tarpitd, en da's de enige hint die ik erover ga geven Support = zie de source, remember

[ Voor 21% gewijzigd door Verwijderd op 15-11-2007 11:35 ]

[VisionMaster]

Verwijderd schreef op donderdag 15 november 2007 @ 11:34:
Beetje kansloze discussie dit. Sterker nog, als we het zo gaan trekken is "firewall" uberhaupt een verkeerde term voor waar het er over het algemeen in deze discussie voor gebruikt wordt, want het is een packetfilter

Boudewijn: er is geen verschil tussen een "default gateway firewall" en een "end node firewall", beide draaien packetfilters en het is onnodig om hier een aparte term voor te gebruiken. Ik denk dat de term "default gateway" de lading meer dan voldoende dekt

edit:
Overigens, om tarpitd te gebruiken moet je al je binnenkomend verkeer op poort 22 wat niet vanaf een bepaalde lijst met ip's afkomt redirecten naar je tarpitd, en da's de enige hint die ik erover ga geven Support = zie de source, remember

Na wat meer speurwerk op het web blijkt deze term relatief nieuw te zijn. Waar het op neer komt is dus dat je een bepaalde host als default (en enige) gateway naar voren schuift buiten je interne en DMZ. Dus, dit is de eerste/laatste host waar je internet verkeer doorheen/vandaan vliegt.

Dit moet de first-line of defence voorstellen. Ik heb het hier nog effe na gevraagd en niemand kende de term in de netwerk beschermingshoek. Een bastion was blijkbaar iets anders vroeger dan ik dacht. Het is een fortificatie techniek uit de oudheid om buiten de stadsmuren bijv. je eerste verdediging op te zetten, maar als het te heet onder de voeten werd, dan kon je de life-line met je bastion door knippen en dan was de oude stad veilig.

[Boudewijn]

I know, ik kan de source ook lezen en vindt het wel aardig, maar ik weet niet of iedereen het kan.
ideaal om een leuke discussie aan te wakkeren

ik wil binnenkort mijn backups eens goed gaan beveiligen, het gaat momenteel om veel databases (niet echt groot, meg of 10) die met mailx via https verstuurd worden naar mijn mailserver over het internet. Ga hier denk ik ook eens een veilig alternatiefje voor zoeken, dat stand houdt als de client gehackt wordt (itt gewone FTP, zonder verdere maatregelen).

[Verwijderd]

VisionMaster schreef op donderdag 15 november 2007 @ 11:44:
[...]

Na wat meer speurwerk op het web blijkt deze term relatief nieuw te zijn. Waar het op neer komt is dus dat je een bepaalde host als default (en enige) gateway naar voren schuift buiten je interne en DMZ. Dus, dit is de eerste/laatste host waar je internet verkeer doorheen/vandaan vliegt.

Dit moet de first-line of defence voorstellen. Ik heb het hier nog effe na gevraagd en niemand kende de term in de netwerk beschermingshoek. Een bastion was blijkbaar iets anders vroeger dan ik dacht. Het is een fortificatie techniek uit de oudheid om buiten de stadsmuren bijv. je eerste verdediging op te zetten, maar als het te heet onder de voeten werd, dan kon je de life-line met je bastion door knippen en dan was de oude stad veilig.

Precies, daar komt de term ook vandaan. Overigens, de enige referentie die ik ernaar gezien heb komt uit Building Internet Firewalls van O'Reilly.

[Boudewijn]

daar heb ik hem dan ook vandaan meen ik

zullen we langzamerhand weer eens ontopic gaan btw?

[serkoon]

Ik denk dat het belangrijkste is dat beveiliging consistent op alle lagen binnen een bedrijf wordt aangepakt (maar laten we ons maar beperken tot technische systeem-beveiliging). Binnen een prive-situatie is dat net iets anders, maar houdt je alsnog dat je het op alle facetten van je netwerk en systemen moet doen.

Binnen een bedrijfsomgeving zou ik groot voorstander zijn van standaardisatie, waar mogelijk. Bijvoorbeeld door het definieren van standaard services, zoals 'webserver', 'autoritatieve nameserver', 'database-server', enz. Op basis van een server-rol kun je dan bepaalde instellingen toepassen die daarbij horen. Ook de installatie van het OS zelf zou je dus moeten standaardiseren, zodat je een uniforme set van beveiligingsmaatregelen kunt nemen.

Wat die dan inhouden? Bijvoorbeeld:

- Een kernel waar alleen de benodigde drivers in aanwezig zijn (in zoverre dit beheersmatig fatsoenlijk mogelijk is). Dit kan gecombineerd worden met systeem-specifieke kernel-modules, eventueel.
- Standaard geen daemons draaien, tenzij die nodig zijn voor hardware-ondersteuning.
- Alleen de daemons draaien die voor de gekozen server-rol(len) nodig zijn.
- Deze daemons zo strikt mogelijk configureren:
- Standaard geen queries of requests toestaan, behalve de typen die je wil (in DNS bijv alleen queries voor de domeinen waarvoor je master bent, voor webservers alleen GET en POST)
- Geen versie-informatie lekken als dat niet nodig is
- Geen uitgebreide foutmeldingen tonen indien dat niet nodig is
- SSH alleen vanaf management-netwerken toestaan, mogelijk alleen op een management interface laten luisteren. Root-logins niet toestaan, en voor beheerders specifieke accounts maken die via su of sudo naar root mogen.
- Bij webservers standaard files en directories verwijderen, directory indexes uit, zo min mogelijk modules laden (incase of Apache).
- Bij PHP zo veel mogelijk van de beveiligingsfeatures gebruiken (misschien met uitzondering van auto quotes).
- Bij klant-sites elke klant een eigen user-account geven en dit ook zo scheiden in Apache (zul je wel moeten patchen, of moeten CGIen)
- Bij databases specifieke users maken voor specifieke mogelijkheden en alleen die rechten geven die deze users nodig hebben. Standaard stored procedures die je niet gebruikt uitschakelen e.d.
- Zoveel mogelijk daemons chrooted draaien en onder een eigen, voor de desbetreffende daemon specifieke username en groep.
- Datafiles die alleen gelezen hoeven worden door daemons dergelijke permissies geven. De directories van deze daemons en users dichtzetten zodat andere users er niet in kunnen.
- Beheersoftware op beheerinterfaces configureren en alleen toegankelijk maken vanaf specifieke management-adressen. Vooral hier uitkijken voor beveiligingsproblemen (als er brakke software is, dan is het wel beheersoftware); dus zo min mogelijk als root draaien en zoveel mogelijk dichttimmeren.
- Zo min mogelijk suid en sgid-executables laten rondslingeren.
- Data-partities noexec en nosuid mounten.
- Sterke wachtwoorden kiezen en sterke regels enforcen middels PAM. Eventueel alleen keys gebruiken om in te loggen.
- User classes aanmaken (onder BSD dan) om limieten op te kunnen leggen qua memory usage, aantal processen, etc. Dit vnl om te voorkomen dat een losgeslagen proces het hele systeem neerhaalt.
- Centrale syslogging op een syslog-server en daar monitoring op uitvoeren om problemen te kunnen detecteren.
- Anderssoortige monitoring: load, aantal requests per seconde, enz.
- Qua netwerk-instellingen zo stealthy mogelijk, ga gerust tegen de oudere RFCs in door geen RSTs of ICMP unreachables te sturen.
- SYN-cookies gebruiken (sommige Linux-distros hebben dat by default uit)
- IP-options en bepaalde ICMP-types droppen
- Eventueel host-firewalling doen, als dit centraal gemanaged kan worden. Hier limitering in doen van aantal connects per seconde en gelijktijdig naar TCP-services en aantal packets per seconde naar UDP-services.
- Automagisch overzichten genereren van niet meer secure software op alle systemen en updates op een standaard en gestructureerde manier testen en uitrollen.

Nouja, zo zijn er nogal wat dingen te verzinnen. Sleutel blijft dat je dit moet standaardiseren, anders lukt het simpelweg niet om systemen strikt en consistent te configureren. Standaardisatie heeft natuurlijk ook nog voordelen buiten security, mgoed.

[VisionMaster]

serkoon schreef op donderdag 15 november 2007 @ 17:15:
- Bij PHP zo veel mogelijk van de beveiligingsfeatures gebruiken (misschien met uitzondering van auto quotes).

Gebruik je ook de privilege seperation voor het uitvoeren van de PHP scripts? Hoe heb je dat opgelost?

- Zo min mogelijk suid en sgid-executables laten rondslingeren.

suexec is er zo een volgens mij, gebruik je die wel/niet? En wat voor andere set{u|g}id executables heb je allemaal weg gesmeten?

- Centrale syslogging op een syslog-server en daar monitoring op uitvoeren om problemen te kunnen detecteren.
- Anderssoortige monitoring: load, aantal requests per seconde, enz.
- Automagisch overzichten genereren van niet meer secure software op alle systemen en updates op een standaard en gestructureerde manier testen en uitrollen.

Heb je hier zelf scripts voor geschreven om de logs te parsen en in overzichtjes te vertalen?

- SYN-cookies gebruiken (sommige Linux-distros hebben dat by default uit)

Voor welke verbindingen gebruik je dit? Ik dacht dat dit alleen goed werkte tussen twee SYN-cookie enabled TCP stacks (client en server).

[serkoon]

VisionMaster schreef op donderdag 15 november 2007 @ 20:50:
Gebruik je ook de privilege seperation voor het uitvoeren van de PHP scripts? Hoe heb je dat opgelost?

Veel van de dingen die ik noem gebruik ik zelf niet omdat ik het voor mijn prive-systemen niet nodig vindt. Maar veel hosters scheiden PHP-sites van verschillende klanten middels (een oplossing als) suPHP.

suexec is er zo een volgens mij, gebruik je die wel/niet? En wat voor andere set{u|g}id executables heb je allemaal weg gesmeten?

Ik ken suexec niet goed genoeg om daar iets nuttigs over te zeggen. In principe kun je van de meeste executables deze vlaggen afpakken omdat ze ofwel alleen gebruikt worden wanneer je bijv. rsh gebruikt, of opie, of NIS. Andere tools hoeven weer niet per se door iedere user uitgevoerd te kunnen worden en kunnen dan ook de vlaggetjes afgepakt worden. Overigens zijn dit soort executables doorgaans wel goed geaudit om problemen teniet te doen, maar er zijn nog steeds software-bouwers die hier hele basale fouten in maken helaas.

Heb je hier zelf scripts voor geschreven om de logs te parsen en in overzichtjes te vertalen?

Ik heb in het verleden wel het een en ander aan log-parsers getest, met name Swatch en Sec. Deze passen door de gebruiker te definieren regels toe om te matchen op bepaalde regels en daar acties aan te hangen. Sec is daarbij redelijk complex te configureren, doordat het state toevoegt tussen matches; zodoende kun je dus triggeren op iets als 'iemand probeert op SSH in te loggen, lukt niet, daarna op FTP, lukt niet' in plaats van deze twee events als op zichzelf staand beschouwen. Dit soort systemen dienen echt op de omgeving te worden toegespitst en kosten daarom ook aardig wat werk. Er zijn ongetwijfeld (commerciele) oplossingen die hiervan het een en ander uit handen nemen, wat dan weer het risico in zich heeft dat het ten koste gaan aan inzichtelijkheid..

Voor welke verbindingen gebruik je dit? Ik dacht dat dit alleen goed werkte tussen twee SYN-cookie enabled TCP stacks (client en server).

Nee, SYN-cookies houden geen wijziging op het protocol in en zouden tussen 'normale' TCP-implementaties gewoon moeten werken. Op FreeBSD staan ze standaard dan ook aan.

Overigens zijn er ook eventueel nog wat TCP timeouts te tunen, maar dat neigt al snel naar zwarte magie waar de kans op 'foot shooting' wat te groot wordt

[eghie]

Wat ook een leuke optie is, is LCAP. Hiermee kun je bepaalde dingen op kernel niveau uitschakelen, binnen Linux. Vind deze link ook wel handig om de kernel dicht te spijkeren: http://www.linux-sec.net/Kernel/

Daarnaast raad ik ook aan Snort icm SnortSam te installeren. Met SnortSam maakt je van Snort een IPS, wat inhoud dat je de hosts ook blokkeerd. Met een goede ruleset, bijvoorbeeld: http://www.bleedingthreats.net/ kom je een aardig eind.

Volgens mij kun je overigens PHP opzichzelf wel redelijk afschermen met FastCGI. Ik weet het niet helemaal zeker. Nog niet echt gebruikt. Wil het nog wel een keer proberen. Daarnaast kun je PHP ook nog dichtstoppen, met: http://www.hardened-php.net/

[Pantagruel]

Niet dat ik nu zo'n beveiligingsexpert ben, maar leuk om er een draadje over te lezen.

Zelf draai ik al flink wat jaren prive een server op basis van een linux distro's (standaard onzin, http/smtp/ssh/nntp/torrent/etc).

In den beginnen was ssh dmv password challenge voldoende. Inmiddels is private/public key (incl. een goed gekozen wachtwoord of security token) in combinatie met een 'brute force denial' script (FailToBan) een absolute must. Dit houdt script runners buiten de deur en geeft mij de ruimte om vanaf ieder IP de server in te komen (lang leve PuTTY). File up- en download was voorheen ftp, maar dat is na wat mislukkingen ook volledig omgezet op sftp (WinSCP bijv.), bij komend voordeel is dat t verkeer versleuteld is en je als admin behoorlijke controle hebt over de gang van zaken.
Diverse 'diensten' die een http frontje hebben zijn geleidelijk van http, achter .htaccess en inmiddels achter SSL verkeer gezet. Bij komend voordeel is dat je een stuk minder gelegenheids hackers krijgt (mensen die dus de moeite nemen handmatig dan wel via script de login op de pagina proberen uit te vinden).
SysLog gaat inmiddels naar een andere machine ipv lokaal en voegt dus een extra horde toe mocht de extern bereikbare machine overgenomen worden.
Daarnaast is het gewoonweg vrij simpel, dat wat aan moet staan is beschikbaar, de rest gaat snoeihard uit, service niet nodig, uit die hap. Verder is de server misbaar, geen belangrijke gegevens zullen er op belanden (of iemand moet interresse in mijn nntp/torrents hebben), dus een scrubbing of re-install is jammer van de verloren tijd maar een hacked server is geen optie.
En zoals altijd, patch, pacth, patch