[SEC] Hoe beveilig jij jouw server?

[MrPepper]

Sinds kort draai ik met veel plezier een windows server bak, welke verschillende taken voor mij vericht. Aangezien een groot deel van de tweakers hier ook een server heeft staan ben ik benieuwd wat jullie allemaal doen om jullie bak te beveiligen, ik trap af!

OS: Windows server 2003 R2 enterprise X64
Functies: Mail, backup, printer, DNS en file server
Op deze server heb ik Avast server edition draaien en Windows Defender. Verder maak ik wekelijks een image van het systeem zodat ik deze altijd terug kan zetten. Qua externe communicatie heb ik alleen poortje 25 & 443 open staan de mails en OWA.

Hoe hebben jullie jullie thuisserver beveiligd?

[Zwelgje]

for starters: ik gebruik geen 2003 meer maar alles op 2008 x64.

verder: firewalling, ipsec rules om te connecteren vanaf de clients. en de SCW gebruiken om je attacksurface te verminderen. (zo min mogelijk services draaien immers)

[opblaashaas]

Je vergeet de even belangrijke sleutel op de deur.
Zul je zien dat je alles netjes afgegrendeld hebt, gaat er een eikel met je fysieke server vandoor.
Ook handig als je kinderen hebt die denken even een spelletje te kunnen doen op je server en hem herstarten omdat hij "gelockt" lijkt.
Verder sluit ik me aan bij powershell

[Voor 26% gewijzigd door opblaashaas op 15-12-2009 14:46. Reden: deel vergeten.]

[MrPepper]

opblaashaas schreef op dinsdag 15 december 2009 @ 14:45:
Je vergeet de even belangrijke sleutel op de deur.
Zul je zien dat je alles netjes afgegrendeld hebt, gaat er een eikel met je fysieke server vandoor.
Ook handig als je kinderen hebt die denken even een spelletje te kunnen doen op je server en hem herstarten omdat hij "gelockt" lijkt.
Verder sluit ik me aan bij powershell

Haha, ik geniet hier het recht om het "kind" te zijn en mijn ouders deinzen al weg als ze een led'tje zien brandne op een PC kast, die kan dus open en bloot blijven branden!

Maar hebben jullie geen virusscanner draaien?

[Voor 0% gewijzigd door MrPepper op 15-12-2009 14:58. Reden: typo]

[mcDavid]

MrPepper schreef op dinsdag 15 december 2009 @ 14:55:
[...]


Haha, ik geniet hier het recht om het "kind" te zijn en mijn ouders deinzen al weg als ze een led'tje zien brandne op een PC kast, die kan dus open en bloot blijven branden!

Maar hebben jullie geen virusscanner draaien?

Een virusscanner voor de server zelf zou je in principe niet nodig moeten hebben. Er wordt toch niets geïnstalleerd als het ding eenmaal draait.
Een virusscanner om bijv. bijlages uit het mailverkeer te checken kan wel nuttig zijn, maar ik heb er zelf geen ervaring mee..

[Zwelgje]

MrPepper schreef op dinsdag 15 december 2009 @ 14:55:
[...]


Haha, ik geniet hier het recht om het "kind" te zijn en mijn ouders deinzen al weg als ze een led'tje zien brandne op een PC kast, die kan dus open en bloot blijven branden!

Maar hebben jullie geen virusscanner draaien?

applocker.. verminder de behoefte aan een viruscanner alleen apps welke een signature hebben mogen uitvoerd worden.. virussen dus per definitie niet

[swbr]

Debian, met alleen poort 443 open aan de 'buitenkant'. Ben nog aan het bedenken of ik port-knocking ga proberen aan de gang te krijgen zodat het lijkt alsof de boel echt helemaal dicht zit.

[MrPepper]

mcDavid schreef op dinsdag 15 december 2009 @ 15:21:
[...]


Een virusscanner voor de server zelf zou je in principe niet nodig moeten hebben. Er wordt toch niets geïnstalleerd als het ding eenmaal draait.
Een virusscanner om bijv. bijlages uit het mailverkeer te checken kan wel nuttig zijn, maar ik heb er zelf geen ervaring mee..

Dat is toch ook puur afhankelijk van de server functies? Stel dat je de server ook gebruikt als Download server welke automatisch de rar bestanden uitpakt, dan is het toch zeker wel gewenst lijkt mij...

[KatirZan]

Win server 2003 SBE

Internet beveiligd met softwarematige linux firewall
Server + netwerk beveiligd dmv symantec av corporate ed.
daarnaast alle poorten dicht...met exception van eigen netwerk en subnet

Dat is dan thuis....op mijn werk is het nog leuker, maar daar gaat het hier niet om

[Blonde Tux]

pfSense + SeLinux + sandboxes voor mijn Debian servert
pfSense + OpenBSD voor mijn OpenBSD servert
alle poorten dicht, met de een paar exeptians

Plus de uitleg voor mijn huisgenoten dat als aan de server/modem/router zitten, ze meteen geen films of andere content kunnen krijgen

[LuckY]

Op de hyperV host draai ik De forefront antivirus van microsoft, en heb wel wat firewalll regeltjes met de blockades e.d. echter wil ik er wel overal bij kunnen met mijn laptop en aangezien ik nooit een vast ip ergens heb. Ben ik voor mijn RDP connectie maar NLA+Certs gaan doen... dit houd de meeste mensen al buiten of iig automated tooltjes.


Tevens heb ik sinds kort de SCW toegepast om een kleinere attacksurface te krijgen.
Verder doet mijn router aan outbound firewalling en inbound staan alleen SMTP en RDP open.

Alle servers draaien Forefront antivirus.

[Voor 29% gewijzigd door LuckY op 24-12-2009 14:39]

[bobsquad]

Momenteel een astaro firewall voorstaan die alleen vanaf bepaalde dns hosts en poorten netwerkverkeer door laat. Hiermee connect ik ook door middel van OpenVPN & SSH naar de firewall zodat mijn servers bereikbaar zijn evenals de rest van het netwerk. Hierbij geld ook alleen bepaalde users hebben bepaalde rechten op het netwerk.

Geen firewall op mijn servers & computers aangezien alles door de proxy gaat en die door 2 verschillende virusscans gaat voordat er uberhaupt wat op mijn netwerk komt.

Betreft fysiek aan virussen backups van laptops worden weekelijks automagisch gedaan en deze blijven 8 weken staan dus mocht daar iets mis mee zijn wordt er een backup teruggezet. In de servers wordt er voor de rest toch niet gespeeld met usb & cd.

[ik222]

Heb zelf ook Windows Server 2008 x64. Daarop heb ik dus wel een virusscanner draaien ondanks dat het eigenlijk niet nodig is.

Maar heb er een clarkconnect firewall voorzitten (die virtueel draait maar het netwerkverkeer kan enkel op de fysieke server komen via die firewall). Daarnaast nog een virtuele webserver die dus ook achter die virtuele firewall zit en daarvoor staat op de firewall enkel poort 80 open.

Tekening is misschien wat duidelijker in dit geval:

[Voor 7% gewijzigd door ik222 op 15-12-2009 23:13]

[d1ng]

pfSense met snort voor algemeen verkeer

FreeBSD Squid Cache proxy + HAVP
Verders draaien er een paar services (mail,http enz.) op de FreeBSD bak die straks in een Jail gaan draaien.

[Voor 6% gewijzigd door d1ng op 15-12-2009 23:33]

[Gomez12]

MrPepper schreef op dinsdag 15 december 2009 @ 16:12:
[...]


Dat is toch ook puur afhankelijk van de server functies? Stel dat je de server ook gebruikt als Download server welke automatisch de rar bestanden uitpakt, dan is het toch zeker wel gewenst lijkt mij...

Waarom? Doet je server iets met die uitgepakte bestanden?

Zolang al je clients maar een AV hebben draaien is er niets aan de hand, veelal heb je op client / server zelfde AV draaien, dus als je client het virus mist mist je server hem ook.

Zolang winrar geen rare exploits gaat bevatten ( waardoor hij ineens dingen zou gaan uitvoeren ) loop je geen tot zeer weinig risico ( als je enkel winrar erbij hebt ).

Enkel is het zo hoe meer services ( en hoe vagere services ( bijv sabnzbd etc ) ) je erop zet hoe groter de kans op exploits en ook hoe groter de kans op virii imho.

Maar als jij enkel MS mail / backup / printer / dns / file server met enkel je eigen clients draait dan is er imho geen reden om een virus scanner te draaien.
Gooi jij er echter een webserver / python / perl / losse scripts ( uit mijn hoofd wat sabnzb voor windows installeert ) op dan heb je imho redelijk wat kans op exploits en is een virus scanner dus wel weer gewenst...

[LuckY]

Gomez12 schreef op dinsdag 15 december 2009 @ 23:30:
[...]

Waarom? Doet je server iets met die uitgepakte bestanden?

Zolang al je clients maar een AV hebben draaien is er niets aan de hand, veelal heb je op client / server zelfde AV draaien, dus als je client het virus mist mist je server hem ook.

Zolang winrar geen rare exploits gaat bevatten ( waardoor hij ineens dingen zou gaan uitvoeren ) loop je geen tot zeer weinig risico ( als je enkel winrar erbij hebt ).

Enkel is het zo hoe meer services ( en hoe vagere services ( bijv sabnzbd etc ) ) je erop zet hoe groter de kans op exploits en ook hoe groter de kans op virii imho.

Maar als jij enkel MS mail / backup / printer / dns / file server met enkel je eigen clients draait dan is er imho geen reden om een virus scanner te draaien.
Gooi jij er echter een webserver / python / perl / losse scripts ( uit mijn hoofd wat sabnzb voor windows installeert ) op dan heb je imho redelijk wat kans op exploits en is een virus scanner dus wel weer gewenst...

Mits je sabnzbd+ openstaat voor de wereld, echter is het toch slim om een AV op je server te hebben. Wat als $random persoon komt die ff op internet wil met zijn laptop

Met mijn technet heb ik toch gratis de Forefront, maar anders kan je ook nog andere dingen draaien. Een Server zonder AV (ook thuis) is niet echt slim lijkt me.

[Gomez12]

LuckyY schreef op dinsdag 15 december 2009 @ 23:46:
[...]


Mits je sabnzbd+ openstaat voor de wereld, echter is het toch slim om een AV op je server te hebben. Wat als $random persoon komt die ff op internet wil met zijn laptop

Ach, als jij van alle scripts etc die dat ding bevat alle regels handmatig doorloopt om er zeker van te zijn dat die geen calling home functie hebben die weer gratis "extra" functionaliteit openzet dan heb je er genoeg aan om hem niet open te zetten voor de rest van de wereld.
Wmb zijn het iets te veel scripts die iets te los samenhangen maargoed.

Met mijn technet heb ik toch gratis de Forefront, maar anders kan je ook nog andere dingen draaien. Een Server zonder AV (ook thuis) is niet echt slim lijkt me.

Ach wmb heeft de AV op de ene virtuele server enkel nadelen, hij is secure en bevat nog wel wat dingetjes die een AV triggert. Op de andere virtuele server staat hij wel weer, maar weer geen FW. Dat is aparte virtuele server, ik heb het niet zo op client-side firewalls die gewoon door het stoppen van een service uit te zetten zijn...

[LuckY]

Gomez12 schreef op dinsdag 15 december 2009 @ 23:56:
[...]

Ach, als jij van alle scripts etc die dat ding bevat alle regels handmatig doorloopt om er zeker van te zijn dat die geen calling home functie hebben die weer gratis "extra" functionaliteit openzet dan heb je er genoeg aan om hem niet open te zetten voor de rest van de wereld.
Wmb zijn het iets te veel scripts die iets te los samenhangen maargoed.

Maar dan is geen enkele opensource meuk meer te vertrouwen, en wie zegt niet dat MS iets van de NSA heeft toegevoegd (/alu hoedje)

[...]

Ach wmb heeft de AV op de ene virtuele server enkel nadelen, hij is secure en bevat nog wel wat dingetjes die een AV triggert. Op de andere virtuele server staat hij wel weer, maar weer geen FW. Dat is aparte virtuele server, ik heb het niet zo op client-side firewalls die gewoon door het stoppen van een service uit te zetten zijn...

Tjah de applicaties kunnen dat ook verbieden (kaspersky doet dit bijvoorbeeld), echter heb je wel gelijk. Dit kan je echter weer monitoren en dan weet je dat er wat mis is

Echter je kan moeilijk al je servers achter een hardware firewall stoppen. Vaak worden AD Domains vaak beschreven als : Though on the outside and soft and chewy on the inside.

[MrPepper]

LuckyY schreef op dinsdag 15 december 2009 @ 23:00:
...
Verder gewoon een sterke lock policy... ik wil echter nog wel naar VPN en wat Powershell zegt

Wat bedoel je met een sterke lock policy?

[LuckY]

Nou Maximaal 3x een fout wachtwoord en dan een lock van XX minuten

Dus dat ze niet echt goed kunnen bruteforcen

@ TheVMaster

Maar hoe, ip based hardware firewall, of een vpn server of toch alleen maar een account met een heel sterk password.

[Voor 36% gewijzigd door LuckY op 16-12-2009 22:37]

[TheVMaster]

Hmm...... 'k heb op mijn 'server' alleen AVast Home Server Edition draaien en verder hebben natuurlijk alleen mensen toegang tot de machine die er ook echt iets op te zoeken hebben

[LuckY]

Kickje, voor het interessante topic

[Sallin]

Ik heb een debian fileserver/router/firewall, die is dichtgezet met shorewall. Alleen poort 2222 is open voor ssh toegang, en een paar poorten staan geforward voor torrent en world of warcraft updates. Ssh toegang is alleen mogelijk met keys, en alleen voor mijn eigen user.

De zwakke plek in mijn beveiligingssetup zit eigenlijk in het LAN waar ik mijn wireless accesspoint van telenet heb zitten. Dat accesspoint is alleen met wep beveiligd / kan alleen met wep beveiligd worden... In principe krijgen alle apparaten in mijn netwerk een vast ip van de dhcp server, en ik bekijk regelmatig de dhcp.leases file om te kijken of iemand het gehackt heeft. Tot dusver nog niet het geval. Verder check ik /var/log/auth.log regelmatig.

[Snake]

Sallin schreef op donderdag 24 december 2009 @ 14:34:
Ik heb een debian fileserver/router/firewall, die is dichtgezet met shorewall. Alleen poort 2222 is open voor ssh toegang, en een paar poorten staan geforward voor torrent en world of warcraft updates. Ssh toegang is alleen mogelijk met keys, en alleen voor mijn eigen user.

De zwakke plek in mijn beveiligingssetup zit eigenlijk in het LAN waar ik mijn wireless accesspoint van telenet heb zitten. Dat accesspoint is alleen met wep beveiligd / kan alleen met wep beveiligd worden... In principe krijgen alle apparaten in mijn netwerk een vast ip van de dhcp server, en ik bekijk regelmatig de dhcp.leases file om te kijken of iemand het gehackt heeft. Tot dusver nog niet het geval. Verder check ik /var/log/auth.log regelmatig.

Nieuw AP zetten? Of heb je een Nintendo DS in het netwerk?

[Sallin]

Snake schreef op donderdag 24 december 2009 @ 14:39:
[...]

Nieuw AP zetten? Of heb je een Nintendo DS in het netwerk?

Doh, nooit aan gedacht . Kan ik inderdaad weleens doen ja.

[Snake]

Sallin schreef op donderdag 24 december 2009 @ 14:47:
[...]


Doh, nooit aan gedacht . Kan ik inderdaad weleens doen ja.

Ik was eigelijk serieus, had je een reden om te blijven steken op WEP bedoelde ik?

[CH4OS]

mcDavid schreef op dinsdag 15 december 2009 @ 15:21:
Een virusscanner voor de server zelf zou je in principe niet nodig moeten hebben. Er wordt toch niets geïnstalleerd als het ding eenmaal draait.
Een virusscanner om bijv. bijlages uit het mailverkeer te checken kan wel nuttig zijn, maar ik heb er zelf geen ervaring mee..

Ik hoef maar 1 woord te zeggen: Blaster.

[Sallin]

Snake schreef op donderdag 24 december 2009 @ 14:49:
[...]

Ik was eigelijk serieus, had je een reden om te blijven steken op WEP bedoelde ik?

Sorry, ik ben ook serieus, heb er eerlijk waar niet eerder aan gedacht.

[Kees]

Ik vraag mij af hoe mensen hun netwerk beveiligen tegen DDoS attacks. En dan met name:

- SYN-floods vanaf random source IP's
- TCP/UDP/ICMP floods om de lijn dicht te trekken, zonder legitiem UDP/ICMP verkeer tegen te gaan
- SYN/ACK floods om zoveel mogelijk legitieme conencties te openen en zodoende de connectie limit te halen zodat mensen nauwelijks nieuwe conencties kunnen maken.

[LuckY]

GJtje schreef op donderdag 24 december 2009 @ 14:52:
[...]
Ik hoef maar 1 woord te zeggen: Blaster.

Is af te vangen met een firewall , echter een Antivirus is vaak toch wel erg handig.
Zelf ben ik wel een voorstander van forefront. (vooral omdat technet hem meeleverd ).
En hij draait op 2003/2008 en 2008r2 (deze kan echter wel issues geven).

Kees schreef op donderdag 24 december 2009 @ 15:10:
Ik vraag mij af hoe mensen hun netwerk beveiligen tegen DDoS attacks. En dan met name:

- SYN-floods vanaf random source IP's
- TCP/UDP/ICMP floods om de lijn dicht te trekken, zonder legitiem UDP/ICMP verkeer tegen te gaan
- SYN/ACK floods om zoveel mogelijk legitieme conencties te openen en zodoende de connectie limit te halen zodat mensen nauwelijks nieuwe conencties kunnen maken.

Dat handeld mijn livebox af waar ik redelijk wat aan getweaked had, echter moet je daar bij een thuis netwerkje denk ik niet te veel zorgen over maken.

[Voor 40% gewijzigd door LuckY op 24-12-2009 15:15]

[gertvdijk]

Sallin schreef op donderdag 24 december 2009 @ 14:34:
De zwakke plek in mijn beveiligingssetup zit eigenlijk in het LAN waar ik mijn wireless accesspoint van telenet heb zitten. Dat accesspoint is alleen met wep beveiligd / kan alleen met wep beveiligd worden... In principe krijgen alle apparaten in mijn netwerk een vast ip van de dhcp server, en ik bekijk regelmatig de dhcp.leases file om te kijken of iemand het gehackt heeft. Tot dusver nog niet het geval. Verder check ik /var/log/auth.log regelmatig.

Waarom zet je niet wireless uit en sluit je niet een fatsoenlijk AP aan op dat doosje?
En de DHCP leases checken zegt helemaal niets over of het netwerk is gehackt of niet, je kan immers ook prima toegang tot een netwerk hebben met een statisch IP, dus buiten een DHCP request te doen. Gewoon 'luisteren' welke IP range andere clients in zitten is voldoende info.

Mijn home server heb ik als volgt beveiligd:

                                                    Gigabit Switch + AP
                                                             |
WAN+INTERLOKAAL (FttH)                                      LAN
       |                                                     |
 +-----+-----------------------------------------------------+-----+
 |     |                                                     |     |
 | +---+---XenBridge: interlokaal+ +--XenBridge: thuisnet----+---+ |
 | |   |                         | |                         |   | |
 | | peth0                       | |                       peth1 | |
 | |                             | |                             | |
 | |              vif1.0         | |  vif2.0  vif2.X             | |
 | |                |            | |    |       |                | |
 | +----------------+------------+ +----+-------+------------+---+ |
 |                  |                   |       |            |     |
 |                  |              +----+       |            |     |
 |                  |              |            |            |     |
 | Dom0        +----+--------------+----+  +----+----+       |     |
 | Debian 5.0  |    |              |    |  |    |    |       |     |
 | 2x 1.5TB    |  eth0--ppp0-+   eth1   |  |  eth0   |       |     |
 | RAID0+RAID1 |    |        |     |    |  |    |    |       |     |
 | mixed + LVM |    |   +----+-+   |    |  |  +-+-+  |     +-+-+   |
 |             |    +---|FW+NAT|---+    |  |  |   |  |     |   |   |
 |             |        +------+   |    |  | bla bla |    ssh nfs  |
 |             |                 dhcp   |  |         |             |
 |             |         Dom1-FW        |  |  DomU's |    Dom0     |
 |             +------------------------+  +---------+             |
 |                                                                 |
 +-----------------------------------------------------------------+

In woorden:
Ik heb te maken met een lokaal (dormitory) netwerk van een studentenhuisvesting waarop het 'intranet' zich bevindt. Op diezelfde ethernet kabel moet je PPPoE doen om op internet te kunnen en daarbij gaan veel huis-tuin-en-keuken routers de mist in: ze routeren het intranet niet meer. Nu heb ik mijn oude desktop ingezet als Xen server en heb een domU ingericht als router met Shorewall en ik maak gebruik van Xen bridges om de boel aan elkaar te knopen. Voordeel is nu dat als men mijn router zou hacken dat je nog geen toegang hebt tot de andere (virtuele) machines zoals wel het geval zou zijn in een gebruikelijkere opstelling waarbij de routering en firewall zich in de dom0 afspeelt. Ik vind dit zelf een heel elegante oplossing.

Actieve beveiligingsmaatregelen:

• in dom0 en dom1 (FW) zo weinig mogelijk draaien
• alles per default dicht in firewall
• Shorewall documentatie lezen en toepassen op situatie
• voor de services die wel openstaan een limit op auth retries met fail2ban
• SSH daemons via WAN op niet-standaard poort (security by obscurity)
• Upnp niet actief.

[Voor 4% gewijzigd door gertvdijk op 24-12-2009 15:25]

[Smiley]

In een thuisnetwerk kun je je imo beter druk maken om het feit dat die aanvallen niet vanaf jouw netwerk plaats zullen vinden. Zelf tracht ik dit te voorkomen door de Windows firewall van de Windows Vista en Windows 7 clients zowel inbound als outbound verkeer te laten whitelisten. MSE draait op de clients om bescherming te bieden tegen virussen en andere malware.

Om terug te komen op het onderwerp, mijn server draait Vmware ESXi waarbij het management verkeer over een aparte netwerkinterface gaat die -wanneer noodzakelijk- direct aan mijn laptop zit. De virtuele machines hebben elk een eigen los netwerkje en slechts één heeft er toegang tot het internet. De beveiliging zelf geschied op dezelfde manier als bij de clients, whitelisten van netwerkverkeer met de Windows firewall.

Op netwerkniveau doet de linksys router nog de nodige filtering. Ook heb ik upnp uitgeschakeld op de netwerkapparatuur, dan maar geen webcam functionaliteit in live messenger .

[gertvdijk]

Freerk schreef op donderdag 24 december 2009 @ 15:31:
In een thuisnetwerk kun je je imo beter druk maken om het feit dat die aanvallen niet vanaf jouw netwerk plaats zullen vinden. Zelf tracht ik dit te voorkomen door de Windows firewall van de Windows Vista en Windows 7 clients zowel inbound als outbound verkeer te laten whitelisten. MSE draait op de clients om bescherming te bieden tegen virussen en andere malware.

Ik draai geen Microsoft software in mijn huis, misschien dat ik daarom de focus verleg.

Freerk schreef op donderdag 24 december 2009 @ 15:31:
Op netwerkniveau doet de linksys router nog de nodige filtering. Ook heb ik upnp uitgeschakeld op de netwerkapparatuur, dan maar geen webcam functionaliteit in live messenger .

Kan je ook handmatig instellen: vaste poort en zelf portforwarding instellen per client. In elk geval lukt mij dat voor aMSN om te webcammen en fast file transfer te doen.

[Smiley]

gertvdijk schreef op donderdag 24 december 2009 @ 15:38:
Ik draai geen Microsoft software in mijn huis, misschien dat ik daarom de focus verleg.

Dat eerste stukje moet je niet interpreteren als een reactie op jouw post, maar op het stukje van Kees .

gertvdijk schreef op donderdag 24 december 2009 @ 15:38:
Kan je ook handmatig instellen: vaste poort en zelf portforwarding instellen per client. In elk geval lukt mij dat voor aMSN om te webcammen en fast file transfer te doen.

Zelf gebruik ik geen webcam, maar er is wel een poort voor open gezet voor het geval mijn broer er gebruik van maken wil. Al schijnt dit niet altijd even stabiel te functioneren.

[serkoon]

Kees schreef op donderdag 24 december 2009 @ 15:10:
Ik vraag mij af hoe mensen hun netwerk beveiligen tegen DDoS attacks. En dan met name:

- SYN-floods vanaf random source IP's
- TCP/UDP/ICMP floods om de lijn dicht te trekken, zonder legitiem UDP/ICMP verkeer tegen te gaan
- SYN/ACK floods om zoveel mogelijk legitieme conencties te openen en zodoende de connectie limit te halen zodat mensen nauwelijks nieuwe conencties kunnen maken.

In mijn ervaring zijn DDoS-attacks die niet de pijp vullen niet echt een issue voor moderne machines met een 100mbit-verbinding. Gigabit vol met kleine packets wordt wel vervelend. Attacks die wel de pijp vullen zijn voor mij niet echt af te slaan. Daarvoor zou ik bij de provider aan moeten kloppen.

Wel heb ik ooit een protocol gebouwd waarmee zelfs onder zeer zware packet loss (getest tot 90% ofzo) toch gecommuniceerd kan worden over een tunnel. Mocht er dus 500mbit op een 100mbit poortje afkomen, kan ik via die tunnel toch nog inloggen over SSH.

Ik bescherm mijn colobak tegen bovengenoemde aanvallen met behulp van:

• SYN-cookies (standaard aan op FreeBSD)
• Rate-limiting op ICMP en TCP RST's (standaard aan op FreeBSD)
• TCP/UDP blackholing door het OS: als de firewall een poort open heeft, maar het OS zelf niet, dan worden alsnog geen TCP RST's of ICMP dest. unreach. packets gestuurd.
• Connection ratelimiting op enkele specifieke poorten, per afzender IP-adres.
• Default deny policy op de firewall.

Niet alle poorten zijn beschermd met ratelimiting-filters, en als er maar genoeg afzender-adressen zijn, dan werken die filters niet meer. Bij een echt slimme attack (die ik nog nooit heb gezien) wordt het dus handmatig ingrijpen.

Voor handmatig ingrijpen heb ik serial console toegang. In mijn ervaring zijn vaak een beperkt aantal IP-adressen verantwoordelijk voor de grootste zooi, dus ik zou dan tcpdump een minuutje mee laten draaien, kijken welke adressen het meeste last veroorzaken en primair die filteren. Filteren gaat gewoon met een pf table. Als het niet teveel adressen zijn, gaan ze gewoon allemaal in de tabel.

[alt-92]

LuckyY schreef op woensdag 16 december 2009 @ 09:49:
Nou Maximaal 3x een fout wachtwoord en dan een lock van XX minuten

Ah, een DOS dus

[Kees]

serkoon schreef op donderdag 24 december 2009 @ 16:03:
[...]


In mijn ervaring zijn DDoS-attacks die niet de pijp vullen niet echt een issue voor moderne machines met een 100mbit-verbinding. Gigabit vol met kleine packets wordt wel vervelend. Attacks die wel de pijp vullen zijn voor mij niet echt af te slaan. Daarvoor zou ik bij de provider aan moeten kloppen.

Mijn ervaring is dat een goed uitgevoerde SYN flood met random sources vrijwel altijd mijn servers plat kan leggen en ik heb nog niet een afdoende bescherming er tegen gevonden. En zo groot hoeft een DDoS niet te zijn, een goede SYN flood met ~150k pps doet zo'n 75 mbit aan verkeer, maar legt vrijwel elke site plat (en ook switches als je niet oppast). Ik ben er nu mee aan het testen, en het kan erg vervelend zijn, tot nu toe is het me niet gelukt om mijn eigen ddos af te slaan puur met iptables/syn_cookies waarbij de webserver ook nog bereikbaar blijft.

Wel heb ik ooit een protocol gebouwd waarmee zelfs onder zeer zware packet loss (getest tot 90% ofzo) toch gecommuniceerd kan worden over een tunnel. Mocht er dus 500mbit op een 100mbit poortje afkomen, kan ik via die tunnel toch nog inloggen over SSH.

Het nadeel aan de ddos'ses die ik nu aan het testen ben is dat in bijna alle gevallen de packetloss oploopt tot 100% als ik mijn best doe. Zodra ik echter ga blocken en packets drop, kan ik zonder pingloss op een normale manier de lijn gebruiken.

Niet alle poorten zijn beschermd met ratelimiting-filters, en als er maar genoeg afzender-adressen zijn, dan werken die filters niet meer. Bij een echt slimme attack (die ik nog nooit heb gezien) wordt het dus handmatig ingrijpen.

Voor handmatig ingrijpen heb ik serial console toegang. In mijn ervaring zijn vaak een beperkt aantal IP-adressen verantwoordelijk voor de grootste zooi, dus ik zou dan tcpdump een minuutje mee laten draaien, kijken welke adressen het meeste last veroorzaken en primair die filteren. Filteren gaat gewoon met een pf table. Als het niet teveel adressen zijn, gaan ze gewoon allemaal in de tabel.

Tja, dat is het grote probleem. De laatste DDoS'en die ik gezien heb hadden random source ip's. Waarbij het met gemak in de miljoenen verschillende ip's liep en er op een gegeven moment dik 150k verschillende SYN's per seconde binennkwamen. Gelukkig was het wel te blocken omdat het niet helemaal random was, maar tcpdumps e.d. (die ik uiteraard maakte) hadden eigenlijk geen nut vanwege de random source. Gelukkig zijn de DDoS'en met een beperkt aantal source ip's inderdaad wel zeer gemakkelijk te blocken.

Freerk schreef op donderdag 24 december 2009 @ 15:31:
In een thuisnetwerk kun je je imo beter druk maken om het feit dat die aanvallen niet vanaf jouw netwerk plaats zullen vinden. Zelf tracht ik dit te voorkomen door de Windows firewall van de Windows Vista en Windows 7 clients zowel inbound als outbound verkeer te laten whitelisten. MSE draait op de clients om bescherming te bieden tegen virussen en andere malware.

Hmjah, het was dan ook niet echt specifiek op thuisnetwerken gericht. Vrijwel elke huislijn is zo dicht te zetten met een DDoS, maar het ging mij meer specifiek over aanvallen op servers die met minimaal 100mbit aan het internet hangen, liefst meer.

[Typnix]

Filesystems zo laten mounten dat alleen het noodzakelijke ook echt alleen benaderd kan en/of beschreven worden.
Gebruikersaccounts waar je toch niets mee doet weggooien.
motd uitgeschakeld
SSHd zo configgen dat root niet in kan, 4 retries plus timeout van 15 sec en op een aparte poort.
Firewall met alles dichtgegooid met natuurlijk een paar uitzonderingen na.
Snort

[serkoon]

Kees schreef op donderdag 24 december 2009 @ 17:00:
Mijn ervaring is dat een goed uitgevoerde SYN flood met random sources vrijwel altijd mijn servers plat kan leggen en ik heb nog niet een afdoende bescherming er tegen gevonden. En zo groot hoeft een DDoS niet te zijn, een goede SYN flood met ~150k pps doet zo'n 75 mbit aan verkeer, maar legt vrijwel elke site plat (en ook switches als je niet oppast). Ik ben er nu mee aan het testen, en het kan erg vervelend zijn, tot nu toe is het me niet gelukt om mijn eigen ddos af te slaan puur met iptables/syn_cookies waarbij de webserver ook nog bereikbaar blijft.
[...]
Het nadeel aan de ddos'ses die ik nu aan het testen ben is dat in bijna alle gevallen de packetloss oploopt tot 100% als ik mijn best doe. Zodra ik echter ga blocken en packets drop, kan ik zonder pingloss op een normale manier de lijn gebruiken.

Er zijn eigenlijk twee factoren die een DDoS (die niet je link volgooit) effectief maken:

• Puur het aantal packets per seconde en de daarbij behorende interrupts
• De mate van verwerking van elke packet afzonderlijk

Als je systeem per packet veel verwerking moet doen, komt het niet meer toe aan nuttige dingen als applicaties draaien (livelock genoemd). Hetzelfde zie je met routers die puur en alleen packets heen en weer sturen. Met behulp van interrupt moderation kun je het aantal interrupts per seconde beperken, zodat er nog wat tijd overblijft voor andere dingen. Linux zal dit ongetwijfeld standaard al doen, maar het is vast te tunen.

Verder moet je dus de verwerking per afzonderlijke packet zoveel mogelijk beperken. Als je op 150kpps aan SYNs loopt te SYN/ACK'en, gaat de SYN door de hele TCP/IP-stack heen en wordt er ook nog es een SYN/ACK gebouwd en helemaal door output-pad gestuurd. Als je er dan ook nog es een stateful filter voor hebt hangen, die voor elke SYN state aanmaakt, wordt het helemaal niet meer te harden. Hetzelfde geldt natuurlijk voor UDP, ICMP en anderssoortige TCP-packets. Bij stomme aanvallen waarbij men een mix van verkeer stuurt, ICMP pingfloods, TCP ACK floods, enz, kun je die packets gewoon stoppen. Bij SYN-floods is dat dus wat moeilijker..

Ratelimiting op inkomende SYN-pakketten kan er dan voor zorgen dat je systeem in ieder geval bereikbaar blijft zodat je verdere maatregelen kan treffen. Het snel classificeren en droppen van packets is DE manier om te voorkomen dat je systeem in livelock terecht komt. Helaas is dat classificeren met miljoenen source IP's lastiger, zoals je gezien hebt..

Overigens nog de opmerking dat stateful filtering en SYN-floods een slechte combo zijn. Statetables van die krengen zijn meestal veel te klein en bij genoeg random source IP's kunnen ze SYN-floods niet detecteren en moet er dus wel state bijgehouden worden.

Tja, dat is het grote probleem. De laatste DDoS'en die ik gezien heb hadden random source ip's. Waarbij het met gemak in de miljoenen verschillende ip's liep en er op een gegeven moment dik 150k verschillende SYN's per seconde binennkwamen. Gelukkig was het wel te blocken omdat het niet helemaal random was, maar tcpdumps e.d. (die ik uiteraard maakte) hadden eigenlijk geen nut vanwege de random source. Gelukkig zijn de DDoS'en met een beperkt aantal source ip's inderdaad wel zeer gemakkelijk te blocken.

De laatste keer dat ik DDoS-attacks kreeg deed men het nog met Stacheldraht. Dat tooltje spoofde OF het laatste octet van het IP, OF het gehele IP-adres. Als je daarvan een aanval binnen kreeg, zag je dus op zich wel miljoenen unieke IP-adressen, maar uiteindelijk bleek het meerendeel van de gespoofde packets alleen op laatste octet gespoofd te zijn. Jij hebt ongetwijfeld meer en grotere DDoS-attacks gezien, dus ik ben benieuwd naar wat voor analyses je zoal gedaan hebt op je tcpdumps. In mijn geval was het blocken op /24 erg efficient gezien het spoofgedrag van Stacheldraht. Bij analyse van tcpdumps moet je dan wel eerst ff sorteren op PPS per IP en netwerk natuurlijk..

[Stacheldraht]

serkoon schreef op donderdag 24 december 2009 @ 21:11:
De laatste keer dat ik DDoS-attacks kreeg deed men het nog met Stacheldraht. Dat tooltje spoofde OF het laatste octet van het IP, OF het gehele IP-adres. Als je daarvan een aanval binnen kreeg, zag je dus op zich wel miljoenen unieke IP-adressen, maar uiteindelijk bleek het meerendeel van de gespoofde packets alleen op laatste octet gespoofd te zijn. Jij hebt ongetwijfeld meer en grotere DDoS-attacks gezien, dus ik ben benieuwd naar wat voor analyses je zoal gedaan hebt op je tcpdumps. In mijn geval was het blocken op /24 erg efficient gezien het spoofgedrag van Stacheldraht. Bij analyse van tcpdumps moet je dan wel eerst ff sorteren op PPS per IP en netwerk natuurlijk..

Yep

[blaataaps]

Typnix schreef op donderdag 24 december 2009 @ 17:29:

motd uitgeschakeld

Wat is het grote gevaar van motd?

[serkoon]

Stacheldraht schreef op donderdag 24 december 2009 @ 21:31:
Yep

Ik heb je DNA (C-code) gelezen, dat was eh.. best slecht (er zat zelfs een bufferoverflow in, geloof ik)

[LuckY]

blaataaps schreef op donderdag 24 december 2009 @ 21:39:
[...]

Wat is het grote gevaar van motd?

Security trough obscurity. Ook al komt een nmap scan achter het ware product. Het houd wat scriptkiddie's tegen..
Dus als jij VSFTPD gebruikt en je zegt in je banner ProFTPD te gebruiken, en mensen passen proftpd exploits toe zou het weinig nut hebben

Typnix schreef op donderdag 24 december 2009 @ 17:29:
SSHd zo configgen dat root niet in kan, 4 retries plus timeout van 15 sec en op een aparte poort.
Firewall met alles dichtgegooid met natuurlijk een paar uitzonderingen na.
Snort

Maak je geen gebruik van bijvoorbeeld fail2ban of denyhost? na X probeersels een bann van X minuten.

alt-92 schreef op donderdag 24 december 2009 @ 16:54:
[...]

Ah, een DOS dus

Het is zeker een mogelijk heid tot een DoS maar wat moet er anders gebeuren, natuurlijk kan ik wel het Nederlandse Ip block toestaan, maar wordt vaak genoeg gescanned door nederlandse ip's.
Maar wat als ik via een proxy of buitenlands ip op mijn thuis server wilt .

IIRC heeft die lock policy alleen een lock op de Remote login, en niet op de lokale installatie. Mocht het wel het geval zijn kan ik het altijd nog terug vinden in mijn router logs (mits die niet geflood worden) van welke Ip de service werd gestart. Dan kan ik se'yank ethernet toepassen en checken wat er mis gaat.

Het nadeel van security een combinatie vinden van toegankelijkheid en veiligheid.
Immers wil je het veilig is het niet toegankelijk, en wil je het toegankelijk is het niet veilig

[Typnix]

LuckyY schreef op donderdag 24 december 2009 @ 23:24:
Security trough obscurity. Ook al komt een nmap scan achter het ware product. Het houd wat scriptkiddie's tegen..
Dus als jij VSFTPD gebruikt en je zegt in je banner ProFTPD te gebruiken, en mensen passen proftpd exploits toe zou het weinig nut hebben

Klopt

Maak je geen gebruik van bijvoorbeeld fail2ban of denyhost? na X probeersels een bann van X minuten.

Fail2ban inderdaad. Works like charm imo.

[blaataaps]

LuckyY schreef op donderdag 24 december 2009 @ 23:24:
[...]

Security trough obscurity. Ook al komt een nmap scan achter het ware product. Het houd wat scriptkiddie's tegen..
Dus als jij VSFTPD gebruikt en je zegt in je banner ProFTPD te gebruiken, en mensen passen proftpd exploits toe zou het weinig nut hebben

Ik dacht dat de motd het laten zien van /etc/motd bij het inloggen was, zoals de naam suggereert, de informatie daarin staat bij mij meestal niet in de banner van een ftpd

[mphilipp]

Een site waar je een goede hardeningsguide voor je OS en applicaties kan downloaden (gratis) is te vinden op Center for Internet Security (CIS).

The CIS Benchmarks are the ONLY consensus best practice security configuration standards both developed and accepted by government, business, industry, and academia.

The Benchmarks are:
* Recommended technical control rules/values for hardening operating systems, middleware and software applications, and network devices;
* Unique, because the recommendations are defined via consensus among hundreds of security professionals worldwide;
* Downloaded approximately 1 million times per year;
* Distributed freely by CIS in .PDF format (some are available to CIS Members only in XML format via the CIS Members web site);
* Used by thousands of enterprises as the basis for security configuration policies and the de facto standard against which to compare them.

[HaveBlue]

M'n Windows Server 2008 Standard Edition doet files serveren, evenals mail (Kerio Mailserver), DNS, DHCP, SABnzbd+, PS3 Media Server/DLNA en FTPS. De machine staat achter slot en grendel dus een inbreker zal er niet snel mee vandoor gaan tenzij hij er specifiek voor komt.

Voor de email draait ClamAV 0.95. Deze doet twee keer in de week ook een scan van de filesystems waarvan de log file per mail naar me toe worden gestuurd wanneer er onregelmatigheden zijn. Verder draaien services die van buiten te bereiken (email, SABnzbd+ 0.5.0, FTPS) secure middels SSL én niet op de standaard poorten. Andere poorten dan deze zijn middels de Security Configuration Wizard dichtgetimmerd.

De server deelt alleen IP adressen uit aan MAC adressen die vooraf zijn vrijgesteld hoewel deze filtering functionaliteit in m'n router zit. Wanneer er via wireless ondanks WPA2 en MAC filtering een IP adres wordt uitgedeeld wat niet gespecificeerd is krijg ik een mailtje.

Backup gebeurt tweemaal daags incrementeel op een USB harddisk waarna deze gegevens om 03.00 via rdiff-backup over SSH worden overgepompt naar een 2TB NAS die bij m'n broer 120km verderop staat.

[LuckY]

blaataaps schreef op vrijdag 25 december 2009 @ 10:32:
[...]

Ik dacht dat de motd het laten zien van /etc/motd bij het inloggen was, zoals de naam suggereert, de informatie daarin staat bij mij meestal niet in de banner van een ftpd

Nee ok, maar die dingen worden vaak vergist

De server deelt alleen IP adressen uit aan MAC adressen die vooraf zijn vrijgesteld hoewel deze filtering functionaliteit in m'n router zit. Wanneer er via wireless ondanks WPA2 en MAC filtering een IP adres wordt uitgedeeld wat niet gespecificeerd is krijg ik een mailtje.

Maar als je Mac authenticatie hebt kom je toch niet op het netwerk zonder het mac adress te hebben ingevoerd (behalve bekabeld dan). Maar als iemand jou mac adress spoofed krijg je er geen mailtje over. (immers het mac adres is al bekend)

[Voor 43% gewijzigd door LuckY op 25-12-2009 12:00]

[HaveBlue]

LuckyY schreef op vrijdag 25 december 2009 @ 11:56:
[...]
Maar als je Mac authenticatie hebt kom je toch niet op het netwerk zonder het mac adress te hebben ingevoerd (behalve bekabeld dan). Maar als iemand jouw mac adress spoofed krijg je er geen mailtje over. (immers het mac adres is al bekend)

Klopt, nieuwe PC's moeten eerst moeten worden toegevoegd door een bestaande client. Ik maak me geen illusies over de veiligheid en het ging me meer om het maken van het mechaniekje om te mailen wanneer er een bepaalde activiteit plaatsvindt. Als iemand per sé je gegevens wil hebben krijgt 'ie ze toch wel

[d1ng]

HaveBlue schreef op vrijdag 25 december 2009 @ 12:17:
[...]

Als iemand per sé je gegevens wil hebben krijgt 'ie ze toch wel

Lijkt me toch echt een verkeerde uitgangspunt om je servers te beveiligen
Ik besef natuurlijk ook, als iemand echt heel heel heeeel graag wilt, alles op alles zet en er zijn levenswerk van maakt om je gegevens te krijgen dan zou het weleens kunnen lukken idd.

Maar de mate van beveiliging die je toepast kan ervoor zorgen dat die persoon er 2 minuten over doet .... of bv. 35 jaar. Na 35 jaar is die persoon vast wat serieuzer geworden en/of heeft hij wel wat beters te doen

[C.Mongler]

Waar te beginnen

Op al mijn servers natuurlijk al het standaard spul; incoming packet filters etc etc. Ook heb ik een OpenVPN tunnel tussen alle servers zodat alle communicatie veilig is. Daarnaast draai ik verschillende Tor exit nodes zodat al mijn internet verkeer mixed met het verkeer van anonieme Tor gebruikers, en zelf gebruik ik ook vaak Tor als dat nodig is.

Ook aan fysieke beveiliging is gedacht, alle hardeschijven zijn encrypted met lange passphrases en zitten goed dicht zodat een cold boot attack moeilijk is.

Alle SMTP servers ondersteunen StartTLS en voor IMAP is TLS zelfs verplicht. Nu maar hopen dat alle mailservers maar snel allemaal StartTLS ondersteunen

Nog tips?

[Voor 12% gewijzigd door C.Mongler op 26-12-2009 12:49]

[LuckY]

C.Mongler schreef op zaterdag 26 december 2009 @ 12:47:
Waar te beginnen

Op al mijn servers natuurlijk al het standaard spul; incoming packet filters etc etc. Ook heb ik een OpenVPN tunnel tussen alle servers zodat alle communicatie veilig is. Daarnaast draai ik verschillende Tor exit nodes zodat al mijn internet verkeer mixed met het verkeer van anonieme Tor gebruikers, en zelf gebruik ik ook vaak Tor als dat nodig is.

Ook aan fysieke beveiliging is gedacht, alle hardeschijven zijn encrypted met lange passphrases en zitten goed dicht zodat een cold boot attack moeilijk is.

Alle SMTP servers ondersteunen StartTLS en voor IMAP is TLS zelfs verplicht. Nu maar hopen dat alle mailservers maar snel allemaal StartTLS ondersteunen

Nog tips?

Disk encryption op een server lijkt me eng
mijn ervaring is puur op werken met Full disk encryption op een laptop.. maar ik moet er niet aan denken dat Mijn server gereboot is. En ik er niet direct bij kan dat die leuk staat te wachten met een password prompt, en ik die via ILO moet invoeren oid.

Tevens vind ik een nadeel van TOR de sloomheid en ik vind het zelf iets teveel overkill voor de thuis server. Ik encrypt waar nodig, maar tor is ook niet veilig. MITM's en dan uiteindelijk nog uitkomen bij een china ISP dat je achter een land filter zit

[QuaQu]

LuckyY schreef op donderdag 24 december 2009 @ 23:24:
Maak je geen gebruik van bijvoorbeeld fail2ban of denyhost? na X probeersels een bann van X minuten.

Ik heb een hobby-server aan het internet hangen die alleen te bereiken is met ssh, maar daar draai ik geen fail2ban of denyhost oid op, ik gebruik de limit-burst van iptables: max 5 pogingen per uur, daarna reageert hij helemaal niet meer op requests. Door een foutje van mij had het een dag uitgestaan en dan krijg ik echt duizenden pogingen per dag! Maar met de limit en limit-burst max 5 pogingen per client en dan niks meer.
Aangezien niemand anders dit noemt: zijn hier nog aanzienlijke nadelen aan verbonden en wat is de meerwaarde van de eerder genoemde programma's? Ik heb nl het gevoel dat het zo best prima gaat, of zie ik iets over het hoofd?

[ik222]

QuaQu schreef op zaterdag 26 december 2009 @ 14:11:
[...]

Ik heb een hobby-server aan het internet hangen die alleen te bereiken is met ssh, maar daar draai ik geen fail2ban of denyhost oid op, ik gebruik de limit-burst van iptables: max 5 pogingen per uur, daarna reageert hij helemaal niet meer op requests. Door een foutje van mij had het een dag uitgestaan en dan krijg ik echt duizenden pogingen per dag! Maar met de limit en limit-burst max 5 pogingen per client en dan niks meer.
Aangezien niemand anders dit noemt: zijn hier nog aanzienlijke nadelen aan verbonden en wat is de meerwaarde van de eerder genoemde programma's? Ik heb nl het gevoel dat het zo best prima gaat, of zie ik iets over het hoofd?

Een niet standaard poort gebruiken voor ssh zal al veel inlogpogingen schelen

[LuckY]

QuaQu schreef op zaterdag 26 december 2009 @ 14:11:
[...]

, ik gebruik de limit-burst van iptables: max 5 pogingen per uur, daarna reageert hij helemaal niet meer op requests

Maar met de limit en limit-burst max 5 pogingen per client en dan niks meer.

Is het per IP 5 pogingen of in totaal?
Want anders creer je een DoS dan hoef ik maar 5 inlog pogingen te doen en kom jij er niet meer bij

[d1ng]

QuaQu schreef op zaterdag 26 december 2009 @ 14:11:
[...]

Ik heb een hobby-server aan het internet hangen die alleen te bereiken is met ssh, maar daar draai ik geen fail2ban of denyhost oid op, ik gebruik de limit-burst van iptables: max 5 pogingen per uur, daarna reageert hij helemaal niet meer op requests. Door een foutje van mij had het een dag uitgestaan en dan krijg ik echt duizenden pogingen per dag! Maar met de limit en limit-burst max 5 pogingen per client en dan niks meer.
Aangezien niemand anders dit noemt: zijn hier nog aanzienlijke nadelen aan verbonden en wat is de meerwaarde van de eerder genoemde programma's? Ik heb nl het gevoel dat het zo best prima gaat, of zie ik iets over het hoofd?

Dat gaat ook prima zo.
Tools als denyhosts en fail2ban doen eigenlijk hetzelfde, alleen die hebben als nadeel dat ze afhankelijk zijn van de logfiles. Dat betekent dat er pas actie ondernomen wordt ná dat er al naar de logfiles weggeschreven is.
Iptables detecteert per direct als er aan die 5x voorwaarde voldaan is en zal direct actie ondernemen.

Zelf hou ik de ssh poort alleen bereikbaar voor interne ipadressen en voor 'vertrouwde' ip-adressen.
Echter, mocht het ooit nodig zijn dat ik overal en altijd toegang zou moeten hebben tot mijn ssh-poort dan zou ik kiezen voor private/public keys en dan password authentication volledig uitschakelen evt. met onderstaande firewall rule.

Verder gebruik ik in FreeBSD pf packet filter de mogelijkheid om aantal connecties van hosts te limiteren/blokkeren.
voorbeeld:
pass in on $ext_if proto tcp from any to $ext_if port <poortnummer> synproxy state \
(max-src-conn 50, max-src-conn-rate 10/60, overload <abusive_hosts> flush)

Waarbij $ext_if mijn netwerkkaart is, en synproxy state zorgt voor een bescherming tegen gespoofte TCP SYN floods. Dit zal ook max 50 connecties hebben per source, 10 connecties per 60 seconden toelaten en wie die regel overtreed zal in de table <abusive_hosts> worden gegooid. Flush verwijdert gelijk alle 'states' van het betreffende ip-adres.

[moto-moi]

ik222 schreef op zaterdag 26 december 2009 @ 14:57:
Een niet standaard poort gebruiken voor ssh zal al veel inlogpogingen schelen

mjah, ik hoor dat vaker, maar ik zie persoonlijk toch geen enkel nut voor dat soort acties, als iemand echt wil gaan hacken zal 'ie toch gauw een portscan doen, waardoor hij ziet dat ssh op een andere poort draait. En voor day-to-day use is het alleen maar irritant om -p achter elk mogelijk ssh commando te moeten zetten. Verder zie ik er niet echt het voordeel van om je echt zorgen over dit soort dingen te maken, je zal eerder via een brak php script gehacked worden, of via een ddos op je knieën gebracht worden, dan door een ssh daemon die gewoon op poort 22 draait, waar 'ie thuishoort.

Ook het blokkeren van logins vanaf andere ip's dan een vertrouwde set vind ik twijfelachtig. Als ik in wil loggen omdat er *insert issue* aan de hand is, wil ik niet via stomme trucjes als portknocking, via andere systemen in hoeven te loggen, nee, dan wil ik zo snel mogelijk op een van mijn machines komen.

[LuckY]

moto-moi schreef op zaterdag 26 december 2009 @ 19:14:
[...]

mjah, ik hoor dat vaker, maar ik zie persoonlijk toch geen enkel nut voor dat soort acties, als iemand echt wil gaan hacken zal 'ie toch gauw een portscan doen, waardoor hij ziet dat ssh op een andere poort draait. En voor day-to-day use is het alleen maar irritant om -p achter elk mogelijk ssh commando te moeten zetten. Verder zie ik er niet echt het voordeel van om je echt zorgen over dit soort dingen te maken, je zal eerder via een brak php script gehacked worden, of via een ddos op je knieën gebracht worden, dan door een ssh daemon die gewoon op poort 22 draait, waar 'ie thuishoort.

Ook het blokkeren van logins vanaf andere ip's dan een vertrouwde set vind ik twijfelachtig. Als ik in wil loggen omdat er *insert issue* aan de hand is, wil ik niet via stomme trucjes als portknocking, via andere systemen in hoeven te loggen, nee, dan wil ik zo snel mogelijk op een van mijn machines komen.

En wil je dan ook nog het liefst als root direct inloggen
Maarja ik begrijp je punt wel, meestal connect je bij de grotere server farms via vpn naar een intern netwerk waarvandaan je de connecties maakt.
Tevens kan je security toch wel in 2 hoofdgroepen in delen waar je je tegen kunt beveiligen.

De Hackers: mensen die echt portscannen en op je systeem willen. Daar heeft het inderdaad geen nut om je ssh op een andere port te draaien.

En de automated attacks: gewoon scannen en kijken wat er gevonden wordt op de default poorten.

Voor de automated attacks is het port change/ portknocking wel handig. Echter belemmerd dit wel in het snelle handelen.

En dan kom je weer op het volgende issue:

Het nadeel van security een combinatie vinden van toegankelijkheid en veiligheid.
Immers wil je het veilig is het niet toegankelijk, en wil je het toegankelijk is het niet veilig

[gertvdijk]

moto-moi schreef op zaterdag 26 december 2009 @ 19:14:
mjah, ik hoor dat vaker, maar ik zie persoonlijk toch geen enkel nut voor dat soort acties, als iemand echt wil gaan hacken zal 'ie toch gauw een portscan doen, waardoor hij ziet dat ssh op een andere poort draait. En voor day-to-day use is het alleen maar irritant om -p achter elk mogelijk ssh commando te moeten zetten.

Daarom kan je voor elke host eenmalig de juiste configuratie parameters in je ~/,ssh/config zetten.

[moto-moi]

gertvdijk schreef op zaterdag 26 december 2009 @ 19:31:
[...]

Daarom kan je voor elke host eenmalig de juiste configuratie parameters in je ~/,ssh/config zetten.

Da's nog steeds vervelend als je bij een vriend zit en opeens een sms krijgt dat de zut down is
Sowieso is het, zoals ik al hierboven uitleg, een schijnbeveiliging.

[CyBeR]

moto-moi schreef op zaterdag 26 december 2009 @ 20:01:
[...]

Da's nog steeds vervelend als je bij een vriend zit en opeens een sms krijgt dat de zut down is
Sowieso is het, zoals ik al hierboven uitleg, een schijnbeveiliging.

^-- met hem. Het wordt mij ook af en toe gevraagd, waarom ik ssh op poort 22 draai zonder IP-filtering of watdanook. Het antwoord is vrij simpel: omdat 't nergens tegen helpt en alleen maar lastig is. Het enige dat 't voorkomt is een zooi inlogpogingen in de logs. Nou, boeiend. Uiteraard staan grapjes zoals 'PermitRootLogin' wel uit.

Grappige is ook dat iedereen dezelfde non-standaard poort gebruikt voor ssh Een service op poort 2222, hmm interesting. Kijken wat er gebeurt. Oh hij kondigt zichzelf aan als ssh! Wat leuk.

[Voor 17% gewijzigd door CyBeR op 26-12-2009 20:09]

[Anoniem: 26306]

CyBeR schreef op zaterdag 26 december 2009 @ 20:04:

^-- met hem. Het wordt mij ook af en toe gevraagd, waarom ik ssh op poort 22 draai zonder IP-filtering of watdanook. Het antwoord is vrij simpel: omdat 't nergens tegen helpt en alleen maar lastig is. Het enige dat 't voorkomt is een zooi inlogpogingen in de logs. Nou, boeiend.

Inderdaad. Tot zover ben ik het met je eens.

Uiteraard staan grapjes zoals 'PermitRootLogin' wel uit.

En hierbij wil ik altijd een opmerking maken. PermitRootLogin uit/aanzetten maakt vrijwel niets uit als je maar één gebruiker hebt die root kan worden. Het is een instelling die je gebruikt als je meerdere gebruikers hebt die root moeten kunnen worden. Je laat ze dan normaliter als gewone gebruiker inloggen en via bijvoorbeeld su - of sudo root worden. Voordeel is dan dat je kunt terugvinden wie er is ingelogd en superuser rechten nodig had. Dat is veel fijner dan in logs te moeten lezen dat er iemand is ingelogd vanaf een ip adres, en dat je zelf moet gaan navragen wie dat nou was.

Grappige is ook dat iedereen dezelfde non-standaard poort gebruikt voor ssh Een service op poort 2222, hmm interesting. Kijken wat er gebeurt. Oh hij kondigt zichzelf aan als ssh! Wat leuk.

Ik hoorde iemand weleens over poort 774, dat bleek te zijn omdat je dat krijgt als je "SSH" op een telefoon zou intoetsen. Leuk gevonden, maar inderdaad weinig nuttig

[peak]

Anoniem: 26306 schreef op zaterdag 26 december 2009 @ 20:30:


En hierbij wil ik altijd een opmerking maken. PermitRootLogin uit/aanzetten maakt vrijwel niets uit als je maar één gebruiker hebt die root kan worden. Het is een instelling die je gebruikt als je meerdere gebruikers hebt die root moeten kunnen worden. Je laat ze dan normaliter als gewone gebruiker inloggen en via bijvoorbeeld su - of sudo root worden. Voordeel is dan dat je kunt terugvinden wie er is ingelogd en superuser rechten nodig had. Dat is veel fijner dan in logs te moeten lezen dat er iemand is ingelogd vanaf een ip adres, en dat je zelf moet gaan navragen wie dat nou was.

Tuurlijk maakt het wel uit.
Je moet dan eerst weten welke usernames er op het systeem staan, daarna het wachtwoord.
Als je dan ingelogd bent moet je ook nog eens de root wachtwoord zien te kraken.

Extra werk...

[CyBeR]

Anoniem: 26306 schreef op zaterdag 26 december 2009 @ 20:30:
[...]
En hierbij wil ik altijd een opmerking maken. PermitRootLogin uit/aanzetten maakt vrijwel niets uit als je maar één gebruiker hebt die root kan worden. Het is een instelling die je gebruikt als je meerdere gebruikers hebt die root moeten kunnen worden. Je laat ze dan normaliter als gewone gebruiker inloggen en via bijvoorbeeld su - of sudo root worden. Voordeel is dan dat je kunt terugvinden wie er is ingelogd en superuser rechten nodig had. Dat is veel fijner dan in logs te moeten lezen dat er iemand is ingelogd vanaf een ip adres, en dat je zelf moet gaan navragen wie dat nou was.

Da's een ander punt, maar zoals gezegd wordt: 'root' is om twee redenen interessant:
• Het bestaat vrijwel altijd op een systeem dat SSH heeft
• Het is de superuser die alles kan

Op zich kun je de combinatie username/wachtwoord zien als een key, en met 'root' heb je de helft van die key al in handen en hoef je alleen de tweede helft nog te raden.

Ik hoorde iemand weleens over poort 774, dat bleek te zijn omdat je dat krijgt als je "SSH" op een telefoon zou intoetsen. Leuk gevonden, maar inderdaad weinig nuttig

Heh, grappig inderdaad. Maar zolang ssh daemons een banner hebben (en die verplicht is in het protocol) schiet 't niet echt op.

[Anoniem: 26306]

peak schreef op zaterdag 26 december 2009 @ 20:39:

Tuurlijk maakt het wel uit.

Als de hoeveelheid tijd die nodig is om een sterk wachtwoord te bruteforcen oneindig nadert, maakt het niet meer uit. Gebruik een sterk wachtwoord en je hoeft je totaal niet druk te maken om brute force SSH aanvallen. Het is onzin om dan nog extra maatregelen te nemen.

Als er dan nog iemand binnendringt is het iemand die het wachtwoord kent en hebben andere maatregelen zoals een apart gebruikersaccount of een andere TCP poort waarschijnlijk geen zin omdat de kans groot is dat die ook bekend zijn.

[d1ng]

SSH op een andere poort staat idd gelijk aan "logs een beetje schoon houden", maw dat is géén beveiliging.
Alhoewel een sterk wachtwoord 'goed genoeg' is, password authenticatie uitschakelen en public key authenticatie gebruiken blijft toch 'veiliger' tegen bruteforce gevallen. (omdat die het oneindige nadert )

peak schreef op zaterdag 26 december 2009 @ 20:39:
[...]
Tuurlijk maakt het wel uit.
Je moet dan eerst weten welke usernames er op het systeem staan, daarna het wachtwoord.
Als je dan ingelogd bent moet je ook nog eens de root wachtwoord zien te kraken.

Extra werk...

Username moet je eerst weten, dat klopt ... maar om root te worden met sudo heb je het root-wachtwoord niet voor nodig.

[Anoniem: 26306]

d1ng schreef op zaterdag 26 december 2009 @ 20:49:
SSH op een andere poort staat idd gelijk aan "logs een beetje schoon houden", maw dat is géén beveiliging.
Alhoewel een sterk wachtwoord 'goed genoeg' is, password authenticatie uitschakelen en public key authenticatie gebruiken blijft toch 'veiliger' tegen bruteforce gevallen. (omdat die het oneindige nadert )

Het kan, ja. Maar in feite moet je ergens een grens trekken. Als je gaat kijken naar de kans dat iemand via SSH inlogt met een random password, is die kans extreem klein. Als je public key authenticatie gaat gebruiken is die waarschijnlijk inderdaad nog kleiner gezien het aantal bits in de key die correct geraden moet worden. Het komt er allebei op neer dat je boven een bepaalde ondergrens wilt zitten.

Ik leg die ondergrens bij een wachtwoord van 12 karakters. Dat betekent dat ik zelf vind dat alles daarboven prima is, maar niet strict noodzakelijk. Public key authenticatie zou ik dus niet gebruiken als "extra" beveiligingsmaatregel, maar om het simpele feit dat dat ruim wordt ondersteund en kan worden gebruikt door bijvoorbeeld remote scripts, voor backups en dergelijke. Hetzelfde geldt voor Kerberos, daarbij worden er ook keys verspreid per service die ik wil aanbieden. Dat is voor gemak, niet voor extra veiligheid

Username moet je eerst weten, dat klopt ... maar om root te worden met sudo heb je het root-wachtwoord niet voor nodig.

Precies. En gewone toegang via SSH kan al genoeg zijn in het geval van een zero day exploit.

[peak]

d1ng schreef op zaterdag 26 december 2009 @ 20:49:
SSH op een andere poort staat idd gelijk aan "logs een beetje schoon houden", maw dat is géén beveiliging.
Alhoewel een sterk wachtwoord 'goed genoeg' is, password authenticatie uitschakelen en public key authenticatie gebruiken blijft toch 'veiliger' tegen bruteforce gevallen. (omdat die het oneindige nadert )


[...]


Username moet je eerst weten, dat klopt ... maar om root te worden met sudo heb je het root-wachtwoord niet voor nodig.

We halen wat dingen door elkaar. Root inloggen, gewone gebruiker...

Wie zegt dat de gebruiker waaronder is gehacked in de sudo file staat.
Wellicht gebruikt diegene geen sudo en doet alles via de root ( su na inloggen )

[Voor 43% gewijzigd door peak op 26-12-2009 21:16. Reden: verkeerd gelezen]

[peak]

Anoniem: 26306 schreef op zaterdag 26 december 2009 @ 20:46:
[...]

Als de hoeveelheid tijd die nodig is om een sterk wachtwoord te bruteforcen oneindig nadert, maakt het niet meer uit. Gebruik een sterk wachtwoord en je hoeft je totaal niet druk te maken om brute force SSH aanvallen. Het is onzin om dan nog extra maatregelen te nemen.

Als er dan nog iemand binnendringt is het iemand die het wachtwoord kent en hebben andere maatregelen zoals een apart gebruikersaccount of een andere TCP poort waarschijnlijk geen zin omdat de kans groot is dat die ook bekend zijn.

Sjah... je kunt het op allerlei manieren bekijken en vertellen.

Ik denk, de opties zijn er.. waarom maak je er niet gelijk gebruik van.
Het is gewoon weer 1 optie minder voor een hacker om binnen te komen.

Stel je moet iets op de server doen, maar je hebt niet je eigen laptop of er is een keylogger op terecht gekomen.. dan heb je niks meer aan je sterke wachtwoord. Stel je zou een key gebruiken, dan heb je het alweer lastiger gemaakt.

Deze discussie kan eindeloos door gaan.

[ik222]

moto-moi schreef op zaterdag 26 december 2009 @ 19:14:
[...]

mjah, ik hoor dat vaker, maar ik zie persoonlijk toch geen enkel nut voor dat soort acties, als iemand echt wil gaan hacken zal 'ie toch gauw een portscan doen, waardoor hij ziet dat ssh op een andere poort draait. En voor day-to-day use is het alleen maar irritant om -p achter elk mogelijk ssh commando te moeten zetten. Verder zie ik er niet echt het voordeel van om je echt zorgen over dit soort dingen te maken, je zal eerder via een brak php script gehacked worden, of via een ddos op je knieën gebracht worden, dan door een ssh daemon die gewoon op poort 22 draait, waar 'ie thuishoort.

Ik bedoelde het ook niet als beveiliging maar als reactie op iemad die zegt dat hij zoveel inlogpogingen per dag krijgt. Het aantal pogingen kun je met een andere poort in ieder geval flink verlagen omdat veel aanvallers domme bots zijn die op de standaard poort scant. Maar meer als logfiles "schoon" houden is het inderdaad niet.

Beveiligng zou ik inderdaad gewoon doen met een sterk wachtwoord en dan wordt het al heel heel lastig om in te loggen op het account.

[Voor 6% gewijzigd door ik222 op 26-12-2009 21:30]

[d1ng]

peak schreef op zaterdag 26 december 2009 @ 21:12:
[...]
We halen wat dingen door elkaar. Root inloggen, gewone gebruiker...

Wie zegt dat de gebruiker waaronder is gehacked in de sudo file staat.
Wellicht gebruikt diegene geen sudo en doet alles via de root ( su na inloggen )

Het ging er in eerste instantie over als er maar 1 gebruiker zou zijn, die kan natuurlijk altijd root worden, hetzij via sudo of via su. En ik had het dus over als je sudo gebruikt
Maar idd, dat zijn wel dingen die je van tevoren zou moeten weten.

[Anoniem: 26306]

peak schreef op zaterdag 26 december 2009 @ 21:20:

Deze discussie kan eindeloos door gaan.

Nee hoor, helemaal niet. Je moet gewoon een bepaalde ondergrens aanhouden, namelijk een sterk wachtwoord en een beveiligde verbinding. De rest is alleen maar extra. En extra beveiliging betekent meestal minder gebruiksgemak. Ik beveilig daarom liever niet teveel.

[LuckY]

Ondergrens aanhouden en toch ook wel logs in de gaten houden. Alleen of dat nog overzichtelijk is bij zulke hoge attack rates als bij tweakers.net

[Rukapul]

CyBeR schreef op zaterdag 26 december 2009 @ 20:44:
Op zich kun je de combinatie username/wachtwoord zien als een key, en met 'root' heb je de helft van die key al in handen en hoef je alleen de tweede helft nog te raden.

Dit argument voegt in vrijwel geen enkele omgeving wat toe. Stel de gemiddelde username bestaat uit 6 alfanumerieke karakters. Stel dat je dit beschouwt als geheim: 6x ca 3 bits entropie (=gemiddelde voor Engelse taal, 5 bits indien random) = 18 bits. Dat valt weg bij elk enigszins fatsoenlijk wachtwoord.

Daarnaast lekken usernames zo veelveeldig door diverse toepassingen en zijn ze vaak zodanig te gokken dat je er nauwelijks consistent een maat voor kunt geven hoeveel security je er mee wint.

[CyBeR]

Rukapul schreef op zondag 27 december 2009 @ 23:53:
[...]

Dit argument voegt in vrijwel geen enkele omgeving wat toe. Stel de gemiddelde username bestaat uit 6 alfanumerieke karakters. Stel dat je dit beschouwt als geheim: 6x ca 3 bits entropie (=gemiddelde voor Engelse taal, 5 bits indien random) = 18 bits. Dat valt weg bij elk enigszins fatsoenlijk wachtwoord.

Daarnaast lekken usernames zo veelveeldig door diverse toepassingen en zijn ze vaak zodanig te gokken dat je er nauwelijks consistent een maat voor kunt geven hoeveel security je er mee wint.

Mja ik weet niet hoor, maar 't maakt gewoon de hoeveelheid combinaties die je moet proberen veel groter. Het geheel blijft altijd bruteforceable, het duurt alleen langer.

[Anoniem: 26306]

CyBeR schreef op zondag 27 december 2009 @ 23:57:

Mja ik weet niet hoor, maar 't maakt gewoon de hoeveelheid combinaties die je moet proberen veel groter. Het geheel blijft altijd bruteforceable, het duurt alleen langer.

Het duurt langer ja, maar dat zal je toch amper interesseren als je wachtwoorden sterk genoeg zijn?

Ik snap niet dat er mensen paranoïde blijven in plaats van gewoon te vertrouwen op de cijfers. Stel dat het 100 miljard jaar zou duren voor een wachtwoord zou kunnen worden gebruteforced. Is het dan belangrijk om ook nog een "onbekende" username te hebben? Als je dat vindt zul je dus usernames zoals "gfonmgksnrf" moeten gebruiken. Of kies je gewoon voor iets meer gemak en maintainability en kies je voor makkelijke usernames en voeg je simpelweg wat karakters to aan het wachtwoord?

Als je niet kunt vertrouwen op de basis, duidt dat dan niet simpelweg op een gebrek aan inzicht? Anders zou dat vertrouwen er wél zijn.

[alt-92]

usernames zijn vergelijkbaar met public secrets wat dat betreft.

[Epic12]

Hiero heb ik Gentoo Linux, IPtables met Fail2ban, en af en toe paludis --report om et zien of pakketten een security hole bevatten Houdt ze al 2 jaar buiten de deur.

[Voor 4% gewijzigd door Epic12 op 28-12-2009 13:20]

[Q]

Ik zie hier een discussie over SSH toegang.

1. Sleutels geen wachtwoorden.
2. Alleen toegestaan vanuit een vertrouwde omgeving (Kantoor).
3. Niet rechtstreeks naar servers maar via een stepping stone server / console server of / opstap server. Hoe je het ook noemt. De servers zelf zijn niet via SSH via het Internet toegankelijk. Eventueel oob mm via iLo oid.
4. Mobiele toegang alleen via een VPN via kantoor naar de console server.
5. Alleen toegang vanaf een encrypted zakelijke werkplek die aan knappe beveiligingseisen voldoet, nooit met privé spul.

Maar thuis zou ik niet zo ver gaan.

[Voor 11% gewijzigd door Q op 28-12-2009 14:29]

[CyBeR]

Anoniem: 26306 schreef op maandag 28 december 2009 @ 10:42:
[...]

Het duurt langer ja, maar dat zal je toch amper interesseren als je wachtwoorden sterk genoeg zijn?

Ik snap niet dat er mensen paranoïde blijven in plaats van gewoon te vertrouwen op de cijfers. Stel dat het 100 miljard jaar zou duren voor een wachtwoord zou kunnen worden gebruteforced. Is het dan belangrijk om ook nog een "onbekende" username te hebben?

Ja. Want dan duurt 't voor root dus 100 miljard jaar, want root ken je. En voor 'pietjevanderzult' komt er een paar miljard jaar bij.

Ik begrijp dat usernames makkelijker te 'vinden' zijn, maar je moet voor elke mogelijke username ook alle mogelijke wachtwoorden bruteforcen. Het voegt iets toe, en dat is goed. Ik zeg niet dat je daarmee alle bruteforcers direct laat stoppen, ik zeg dat 't iets toevoegt. Net zoals elke bit extra keylengte in een crypto key het twee keer zo moeilijk maakt.

[Voor 4% gewijzigd door CyBeR op 28-12-2009 14:42]

[LuckY]

Q schreef op maandag 28 december 2009 @ 14:21:
Ik zie hier een discussie over SSH toegang:
1. Sleutels geen wachtwoorden.
2. Alleen toegestaan vanuit een vertrouwde omgeving (Kantoor).
3. Niet rechtstreeks naar servers maar via een stepping stone server / console server of / opstap server. Hoe je het ook noemt. De servers zelf zijn niet via SSH via het Internet toegankelijk. Eventueel oob mm via iLo oid.
4. Mobiele toegang alleen via een VPN via kantoor naar de console server.
5. Alleen toegang vanaf een encrypted zakelijke werkplek die aan knappe beveiligingseisen voldoet, nooit met privé spul.
Maar thuis zou ik niet zo ver gaan.

Maar dan kom je op het punt moto-moi uit.
Als shit de fan raakt moet je snel kunnen werken. dan moet je niet eerst vpn leggen naar kantoor en dan naar de stepping stone en dan pas naar de normale server... een VPN moet genoeg zijn imho.
Want als de vpn niet werkt kom je er niet bij... wat als de stepping stone problemen heeft.

Hoe kijken jullie tegen de password renewal aan? om de hoeveel dagen/weken/maanden veranderen jullie het password?

[Voor 11% gewijzigd door LuckY op 28-12-2009 14:53]

[Sorcerer]

Over het algemeen zijn hier, een public key login voor sudo-accounts en ip-filter voldoende. Er zijn voor jouw als beheerder niet genoeg plekken waarvandaan je inlogt, dat ip-filteren geen voordelen oplevert. Mits je natuurlijk gebruikers hebt die niet met security in het achterhoofd op je systemen werken en wel wachtwoorden gebruiken.

Zelfs als je iedere ip-range van elke kabel- en adslprovider in Nederland, je kantoor ranges en wat ip's van servers om via te 'hoppen' d'r in zet, houd je genoeg volk bij voorbaat al buiten de deur dat het weldegelijk nut heeft.

Als ik op een server die zonder ip-filter aan het internet hangt in de ssh logs kijk, zie ik zelfs voor de afgelopen 7 dagen geen enkele brute-force aanval van de bekende nationale isps. Genoeg uit azië, rusland, zuid-amerika, italië en duitsland overigens.

Ook op een stel andere servers waar fail2ban draait, is een minimale hoeveelheid verbannen ip's afkomstig uit Nederland.

[Voor 18% gewijzigd door Sorcerer op 28-12-2009 15:36]

[CyBeR]

Ook in Azie, Rusland, Zuid-Amerika, Italië en Duitsland moet ik zonder moeite vanaf welke verbinding dan ook kunnen inloggen om shit te doen als 't kapot is. En als er shit kapot is, is de kans vrij redelijk dat ik ook niet allerlei vpn-tunnelshit en stepping stone shit kan uithalen.

[Sorcerer]

CyBeR schreef op maandag 28 december 2009 @ 15:35:
Ook in Azie, Rusland, Zuid-Amerika, Italië en Duitsland moet ik zonder moeite vanaf welke verbinding dan ook kunnen inloggen om shit te doen als 't kapot is. En als er shit kapot is, is de kans vrij redelijk dat ik ook niet allerlei vpn-tunnelshit en stepping stone shit kan uithalen.

Als je netwerk/servers niet meer bereikbaar zijn op het moment dat iets stuk is, dan is het misschien belangrijker om je netwerk meer redundantie te geven. Of alternatief out-of-band toegang via een externe partij te regelen, zoals bv console toegang tot je servers/routers via een andere isp. Ik ga er hier van uit dat je het over je werk hebt.

Als je hobby server dermate belangrijk is dat een apc reboot het ding niet weer tot level wekt, dan is de kans vrij groot dat je er toch fysiek langs moet.

In beide gevallen zou ik persoonlijk niet simpele security maatregelen voor niets laten omdat het een klein beetje ongemakkelijk is. Maar dat is uiteraard een persoonlijke keuze.

[Stacheldraht]

Ik werk bij een organisatie waarbij wij een zogeheten non-cleartext password policy hebben.

- Alles gaat bij ons geencrypt over het lijntje: imaps, https, snmpv3, ldap over ssl enzovoort, enzovoort.

Verder:

- Ssh alleen door middel van keys.
- Firewalling zowel intern als extern.
- Verder sudo en ssh forced commands voor mensen die wat meer rechten nodig hebben.
- Router acl's en gescheiden vlans.
- Ssh vanaf buiten door middel van jumpboxen op een non-intel architectuur.
- Gescheiden Vlans en router acl's.

[Voor 3% gewijzigd door Stacheldraht op 28-12-2009 16:52]

[CyBeR]

Sorcerer schreef op maandag 28 december 2009 @ 15:50:
[...]


Als je netwerk/servers niet meer bereikbaar zijn op het moment dat iets stuk is, dan is het misschien belangrijker om je netwerk meer redundantie te geven. Of alternatief out-of-band toegang via een externe partij te regelen, zoals bv console toegang tot je servers/routers via een andere isp. Ik ga er hier van uit dat je het over je werk hebt.

Ligt eraan wat er kapot is.

In beide gevallen zou ik persoonlijk niet simpele security maatregelen voor niets laten omdat het een klein beetje ongemakkelijk is. Maar dat is uiteraard een persoonlijke keuze.

Sorry, maar ik noem dit niet eens een security maatregel maar een maatregel om de auth logs wat leger te houden.

[sjorsjuhmaniac]

Stacheldraht schreef op maandag 28 december 2009 @ 16:51:
- Ssh vanaf buiten door middel van jumpboxen op een non-intel architectuur.

Kan je me uitleggen waarom non-intel? Kan er niets over vinden via zoekmachines, en ik ben maar een een prutser als het gaat om bedrijfsnetwerken/systeembeheer.

[CyBeR]

sjorsjuhmaniac schreef op maandag 28 december 2009 @ 17:37:
[...]


Kan je me uitleggen waarom non-intel? Kan er niets over vinden via zoekmachines, en ik ben maar een een prutser als het gaat om bedrijfsnetwerken/systeembeheer.

Zodat als er een exploitable vulnerability is in de code van openssh, je vpn shit, whatever, een attacker daar niet met z'n standaard intel shellcode iets mee kan. 't is feitelijk security through obscurity, maar wel redelijk effectief. Plus dat code execution op niet-intel architecturen soms zodanig anders werkt dat de vulnerability wellicht helemaal niet exploitable is.

[sjorsjuhmaniac]

CyBeR schreef op maandag 28 december 2009 @ 17:50:
[...]


Zodat als er een exploitable vulnerability is in de code van openssh, je vpn shit, whatever, een attacker daar niet met z'n standaard intel shellcode iets mee kan. 't is feitelijk security through obscurity, maar wel redelijk effectief. Plus dat code execution op niet-intel architecturen soms zodanig anders werkt dat de vulnerability wellicht helemaal niet exploitable is.

Aah zo, afwijken van de meute zodat het minder waarschijnlijk is dat ze er direct iets mee kunnen. Ik snap m, thanks.

[sjaakwortel]

heeft een kleine ventrillo server ook extra bescherming nodig ?

[Stacheldraht]

Dus als je een aantal sparc's hebt staan is het best handig om ze voor dit soort dingen in te zetten

Wikipedia: SPARC

[CyBeR]

* CyBeR heeft een SPARC doosje als persoonlijke server.

[Alex)]

Ik heb hier een aantal VM's draaien, op een ESXi-host. De host heeft geen AV (ik zou niet eens weten welke ), de guests echter wel. Het is een mix van Win2003, Win2008 en Win2008 R2, en ook x86 en x64 zijn gemengd. Antivirus wordt geregeld door Forefront, maar op een enkele verdwaalde VM zul je nog McAfee Enterprise aantreffen.

Firewalls staan in principe ook aan, daarnaast zijn alle machines die onder mijn beheer vallen domainjoined en wordt er uitsluitend met domainaccounts gewerkt (weer wel lokale adminrechten). Er is een lockoutpolicy actief, na 5x foutief password wordt het account voor een kwartier gelockt.

Verder staat naar buiten best een hoop open: IIS (https), SMTP, een ISA-server als reverse proxy voor HTTP, FTP, en dan nog Remote Desktop en Citrix. Ik heb daarnaast nog een eigen CA draaien om mijn SSL-certificaat mee te ondertekenen, want ik ben gierig (en ik vind het onzin om meer dan € 200 te betalen zodat mijn smartphone niet gaat zeuren over een onbekend certificaat).

[KerberosX]

Alex) schreef op maandag 28 december 2009 @ 21:33:
IIk heb daarnaast nog een eigen CA draaien om mijn SSL-certificaat mee te ondertekenen, want ik ben gierig (en ik vind het onzin om meer dan € 200 te betalen zodat mijn smartphone niet gaat zeuren over een onbekend certificaat).

Beetje kort door de bocht natuurlijk. Indien je een ietwat recente smartphone hebt, ben je met een RapidSSL certificaatje van $10 klaar, heb je een ietwat oudere dan betaal je $50 voor een Geotrust certificaatje dat echt wel alles ondersteund.

Alles wat meer dan dat kost is eigenlijk weggesmeten geld. Je betaalt dan louter voor de naam of voor de grondigheid waarmee de uitgever van het certificaat verifieert of je wel bent wie je zegt dat je bent. Ook staat er een eventueel hogere waarborg tegenover, maar daar heb je als thuisgebruiker verder niets aan.

[Alex)]

Daarnaast vind ik het ook gewoon leuk om een eigen CA te hebben draaien.

[Anoniem: 26306]

Voor privégebruik is het natuurlijk ook onzin om een certificaat in te kopen dat is ondertekend door een van de standaard gevalideerde certification authorities. Je wilt dat alleen als je diensten aanbiedt aan een groot publiek. Anders kun je net zo goed een self-signed CA beheren zoals Alex) doet. Voor mijn eigen spullen doe ik dat ook.

[KerberosX]

Alex) schreef op dinsdag 29 december 2009 @ 13:51:
Daarnaast vind ik het ook gewoon leuk om een eigen CA te hebben draaien.

Zeg dat dan gewoon

Anoniem: 26306 schreef op dinsdag 29 december 2009 @ 13:58:
Voor privégebruik is het natuurlijk ook onzin om een certificaat in te kopen dat is ondertekend door een van de standaard gevalideerde certification authorities. Je wilt dat alleen als je diensten aanbiedt aan een groot publiek. Anders kun je net zo goed een self-signed CA beheren zoals Alex) doet. Voor mijn eigen spullen doe ik dat ook.

Je produceert dan waarschijnlijk ook je eigen hardware, ontwikkelt je eigen OS? Je gaat toch niets kópen voor privégebruik zeker...

[LuckY]

KerberosX schreef op dinsdag 29 december 2009 @ 15:32:

[...]

Je produceert dan waarschijnlijk ook je eigen hardware, ontwikkelt je eigen OS? Je gaat toch niets kópen voor privégebruik zeker...

Hoezo, linux hoef je toch niet te kopen
Maar het gaat er denk ik meer om als je iets thuis kan hosten wat even goed werkt, en je kan het zelf configureren... waarom niet? Ik draai thuis ook me eigen mail en webserver. Haal misschien iets minder uptime dan bij een provider. Maar heb wel alles in eigen beheer. En ik kan het up en of downgraden wanneer ik wil.

[Rukapul]

KerberosX schreef op dinsdag 29 december 2009 @ 15:32:
Je produceert dan waarschijnlijk ook je eigen hardware, ontwikkelt je eigen OS? Je gaat toch niets kópen voor privégebruik zeker...

Als je die troll nou eens achterwege laat

2 commando's intypen + $0 is niet alleen goedkoper maar ook minder werk dan online een stappenplan doorlopen + $10...

[Turdie]

Thuis heb ik alleen een paar VM's draaien in VMware Workstation, verder niet echt een heel lab. Mijn desktop gebruikt gewoon Windows Firewall en mijn router heeft zich min mogelijk poorten openstaan, gewoon zo'n standaard Linksys machine, die ik wel regelmatig update als er nieuwe firmware's uitkomen.

[Voor 97% gewijzigd door Turdie op 29-12-2009 19:11]