Vraag Welke stappen onderneemt u om een ​​Debian-server te beveiligen? [Gesloten]


Ik installeer een Debian-server die rechtstreeks is verbonden met internet. Uiteraard wil ik het zo veilig mogelijk maken. Ik zou graag willen dat jullie / jullie ideeën om het te beveiligen en welke programma's je ervoor gebruikt.

Ik wil dat een deel van deze vraag behandelt wat u als een firewall gebruikt? Net iptables handmatig geconfigureerd of gebruik je een soort software om je te helpen? Wat is de beste manier? Alles blokkeren en alleen toestaan ​​wat nodig is? Zijn er misschien goede tutorials voor beginners over dit onderwerp?

Verandert u uw SSH-poort? Gebruik je software zoals fail2ban om brute kracht aanvallen te voorkomen?


66


oorsprong


Er is veel overlap met serverfault.com/questions/42/securing-a-fresh-ubuntu-server en - Zoredache
Ubuntu heeft ufw Debian niet;) Ik was aan het twijfelen of mensen zelf iptables configureerden of software zoals fireHOL gebruikten - Thomaschaaf
Ik heb altijd de neiging om zelf iptables regels te schrijven. Ik heb een ketelplaat die dingen doet zoals alle fragmenten, xmas-pakketten, enz. Laten vallen. Verder dan dat is systeemspecifiek en meestal behoorlijk klein. Ik kan niet genoeg benadrukken dat ik fragmenten laat vallen bij gebruik van iptables, trouwens. Om de een of andere reden die ik nog niet heb onderzocht, controleert iptables alleen het eerste fragment, en blindelings passeert de rest zonder te controleren. Volgens mij maakt dat fragmenten een verantwoordelijkheid. - Scott Pack
Uhm ... Debian heeft ufw. packages.debian.org/ufw - womble♦


antwoorden:


Verplicht:

  • installatie van systeem met expertmodus, alleen pakketten die ik nodig heb
  • met de hand geschreven firewall met standaardbeleid op de invoer van iptables: drop, toegang tot SSH, HTTP of wat dan ook, de andere server is actief
  • fail2ban voor SSH [en soms FTP / HTTP / andere - afhankelijk van de context]
  • schakel root-aanmeldingen uit, forceer de normale gebruiker en sudo
  • aangepaste kernel [gewoon oude gewoonte]
  • geplande systeemupgrade

Afhankelijk van het niveau van paranoia bovendien:

  • beleid neerzetten op uitvoer, behalve een aantal toegestane bestemmingen / poorten
  • integrit om te controleren of sommige delen van het bestandssysteem niet zijn gewijzigd [met controlesommen die buiten de machine worden bewaard], bijvoorbeeld Tripwire 
  • geplande scan minstens met nmap van systeem van buitenaf
  • geautomatiseerde logboekcontrole voor onbekende patronen [maar dat is meestal om hardwarestoringen of enkele kleine crashes te detecteren]
  • geplande run van chkrootkit
  • onveranderlijk attribuut voor /etc/passwd dus het toevoegen van nieuwe gebruikers is iets moeilijker
  • / tmp gemonteerd met noexec
  • poortkloppers of andere niet-standaard manieren om SSH-poorten te openen [bijv. het bezoeken van een 'geheime' webpagina op een webserver maakt een inkomende SSH-verbinding voor een beperkte tijd mogelijk vanaf een IP-adres dat de pagina heeft bekeken. Als je verbonden raakt, -m state --satete ESTABLISHED zorgt voor het toestaan ​​van pakketstroming zolang u een enkele SSH-sessie gebruikt]

Dingen die ik niet zelf doe, maar zinvol zijn:

  • grsecurity voor kernel
  • syslog op afstand zodat logs niet kunnen worden overschreven wanneer het systeem wordt gehackt
  • waarschuwen over eventuele SSH-aanmeldingen
  • configureren rkhunter en stel het in om van tijd tot tijd te draaien

50



Na het uitvoeren van al deze BASTILLE draaien tegen het systeem om te zoeken naar iets anders. Ik zou ook aanraden om een ​​volledige, onveilige Nessus-scan van het systeem ook uit te voeren; repareer vervolgens wat het alarmeert. - Scott Pack
Het compileren van een aangepaste kernel biedt geen beveiligingsvoordelen, tenzij je echt weet wat je doet. U zult ook nalaten het up-to-date te houden tenzij u het in het pakketbeheersysteem plaatst, wat zou resulteren in een slechtere beveiliging. - Adam Gibbins
-1 voor beveiliging door onduidelijkheid. Anders fatsoenlijk antwoord. - dwc
@Adam - ja, dat weet ik, toch heb ik liever een monolithische kernel die alleen uit onderdelen bestaat die ik nodig heb. dat is waarschijnlijk erg achterlijk, maar toch doe ik het. @dwc - het is slechts een extra stap die alleen maar een glazuur is of zoals we zeggen kers op de top van stapel onaangename stinkende dingen. - pQd
En je bedoelt sudo niet su - - LapTop006


Gewoon een opmerking over het firewallen van uw machine ...

  • Gebruik een witte lijst, geen zwarte lijst, d.w.z. blokkeer alles, en laat alleen toe wat je nodig hebt, ontken alles anders.
  • Gebruik geen GUI's / ncurses of anderszins software die de taak van het schrijven van uw firewall voor u probeert uit te voeren. Als je dat doet, sta je toe dat de software aannames voor je doet - je hoeft dat risico niet te nemen en zou dat ook niet moeten doen. Configureer het zelf, als u het niet zeker weet, schakel het dan uit - u komt het snel genoeg te weten als het nodig is. Als het al een up-and-running systeem is en je het verkeer niet kunt verstoren (door het per ongeluk te blokkeren), voer dan tcpdump (dump to file) uit en neem monsters - bestudeer ze later, en bedenk wat geldig is en wat niet.
  • Ik zie persoonlijk geen enkel nut in het uitvoeren van een service op een niet-standaard poort, tools zijn tegenwoordig niet zo dom om te veronderstellen dat omdat iets op poort 22 draait, dan moet het ssh zijn, en niet anders - voor voorbeeld amap, en nmap's -A keuze. Dat gezegd hebbende, kunt u (en waarschijnlijk moet u zich zorgen maken) uw diensten aanpassen om zich te verbergen voor nieuwsgierige blikken, bijvoorbeeld, het volgende zou de aanvaller de exacte versie van OpenSSH die u gebruikt, kunnen ze vervolgens naar exploits zoeken voor die exacte versie. Als je dergelijke dingen verbergt, zou je het moeilijker maken voor hen.
    [root @ ud-olis-1 uhtbin] # telnet localhost 22
    Trekt 127.0.0.1 ...
    Verbonden met localhost.localdomain (127.0.0.1).
    Escape-karakter is '^]'.
    SSH-2.0-OpenSSH_3.9p1
  • Houd al uw openbare services up-to-date en patched met de nieuwste beveiligingspatches.
  • Sla GEEN DATA op de gateway-server zelf op, in ieder geval koop je tijd wanneer ze erin slagen om in te breken op deze machine, en je verliest een service of twee, en enige tijd, maar geen data.

Waar het op neer komt is dat het je nooit lukt om iets 100% veilig te maken - dat is gewoon niet mogelijk - dus het doel is om het zo veilig mogelijk te maken - als het gewoon te veel moeite kost om je systeem te verbreken, is het goed genoeg en de meeste lamer script-kiddies zullen naar het volgende systeem gaan.

  • iptables is de weg voor elk Linux-systeem - maar configureer het zelf.

Gebruik nooit "beveiligingssoftware" die niet is gebaseerd op open standaarden - ze zijn gedoemd slecht geschreven te zijn en worden gehackt (geen kwestie van "als", maar "wanneer"). Open source en open protocollen staan ​​open voor publiek toezicht en komen samen in een volwassen en betrouwbaar product; closed-source software is grotendeels afhankelijk van het zelfvertrouwen van de auteur over hoe goed / veilig een product is ze denk dat het is - dat wil zeggen een klein aantal ogen versus een aarde - vol ogen.

Hoop dat het helpt :)


18



"... een klein aantal ogen versus een aarde - vol ogen." - Ik wens dat "bedrijven" dit weten, maar veiligheid door onbekendheid lijkt de trend die het meest volgt. Ja, het uitvoeren van een service, zoals ssh, op een niet-standaard poort zal een vastberaden aanvaller niet weghouden. Het zal echter de scriptkiddies weghouden - iemand die een woordenboek uitvoert, valt aan op een reeks ip-adressen op poort 22. - L0neRanger


  • schakel rootaanmelding uit
  • login uitschakelen met wachtwoord (alleen inloggen met public-key toestaan)
  • verander de SSH-poort
  • gebruik denyhosts (of vergelijkbaar)

  • schrijf je eigen iptbles-script (zodat je precies kunt bepalen wat je moet toestaan ​​en de rest kunt laten vallen)

  • het gebruik van beveiligde SSL / TLS-communicatie afdwingen en zorgen voor geldige, niet-verlopen en ondertekende certificaten

  • strenge certificaatverificatie inschakelen voor alle externe services (bijvoorbeeld bij authenticatie van gebruikers met een LDAP-server op een andere machine)

12



U krijgt een upvote voor het uitschakelen van wachtwoordauthorisatie. - derobert


Begin hier:

http://www.debian.org/doc/manuals/securing-debian-howto/


9



De Debian Security Manual is een fantastische hulpbron. - kce


Als algemeen startpunt volg ik de benchmark / handleidingen van de Centrum voor internetbeveiliging, die uitgebreide compilaties zijn van best practices voor beveiliging. Het ziet er niet naar uit dat hun Debian-benchmark in enige tijd is bijgewerkt, maar een algemeen overzicht van de stappen is:

  • Pas de nieuwste OS-patches / pakketten toe
  • Systeem / kernel / procesadministratie inschakelen.
  • Schakel MAC in (bijv. SELinux of AppArmor).
  • Host-gebaseerde firewall inschakelen (iptables).
  • Controleer APT sources.list (sleutels zijn correct, bronnen worden vertrouwd).
  • Minimaliseer netwerkdiensten, schakel alles uit wat niet vereist is en firewall wat is.
  • Gebruik TCPWrappers om de systeemtoegang verder te beperken.
  • Gebruik alleen gecodeerde netwerkprotocollen, schakel niet-versleutelde services (telnet, ftp, enz.) Uit.
  • Configureer alleen externe toegang tot SSH.
  • Gebruikerswachtwoorden uitschakelen en key-based authenticatie vereisen.
  • Bestandsysteem delen uitschakelen (NFS, SMB).
  • Externe / gecentraliseerde systeemlogboeken inschakelen (en logboeken regelmatig controleren!).
  • Stel een wachtwoord voor het BIOS / firmwareniveau in.
  • Stel een bootloader-wachtwoord in.
  • Configureer systeemback-ups, heb een noodherstelplan en TEST dat de back-ups geldig zijn en dat personeel procedures voor noodherstel kent!

Er zijn veel bronnen op al deze verschillende instellingen, inclusief de specifieke opdrachten en configuratiebestanden die op het systeem moeten worden geïmplementeerd in de benchmarks van CISecurity.


6





Ik zou willen voorstellen om een ​​machine niet rechtstreeks op internet aan te sluiten. Plaats een soort firewall tussen de machine en internet. Hiermee kunt u beveiliging en netwerkmonitoring uitvoeren zonder de server meer te belasten. Persoonlijk vind ik dat netwerk- en functiesegmentering vaak het oplossen van netwerkproblemen vereenvoudigt, hoewel de aanvullende complexiteit soms de analyse bemoeilijkt.

Het veiligste, maar meest irritante te beheren firewallbeleid is om alles te weigeren en alleen het verkeer toe te staan ​​dat u moet toestaan. Dit is vervelend, omdat je regelmatig het firewallbeleid moet bijwerken als het netwerk moet worden gewijzigd.

Ik zou ook willen voorstellen om een ​​soort firewallinterface op de server te gebruiken - verdediging diepgaand is de sleutel. Het gebruik van niet-standaard poorten voor administratiegerelateerde services doet geen pijn. fail2ban is prima. Volg de meer specifieke vragen over beveiligingstoepassingen op Serverfault om meer ideeën te vinden.

Beveiliging is als de grap over de twee wandelaars en de beer - terwijl je nooit een perfecte beveiliging kunt bereiken, is het handig om een ​​moeilijker doelwit te zijn dan de andere jongens.


5



+1 voor leuk antwoord. Ik moet erop wijzen dat het standaard weigeren niet vervelend is om te beheren als je het goed aanpakt. Je moet toch wel weten wat je toelaat, toch? Dit moet in feite worden opgeschreven in een duidelijke taal als beleidsverklaring. Als je dat niet als normale routine doet, dan doe je je werk als beheerder niet. Als dat zo is, is het eenvoudig om de firewallregels bij te werken. - dwc
Zeer goede punten. Elke organisatie moet een duidelijke verklaring over het beveiligingsbeleid hebben. Naarmate de behoeften van de organisatie veranderen, moet de beleidsverklaring worden bijgewerkt. Al was het alleen voor de beheerder om de implementatie van de firewallregel en CYA te plannen, zou een slimme beheerder een dergelijke beleidsverklaring handhaven, zelfs als het organisatiemanagement niet de moeite kan nemen om na te denken over beveiliging. - pcapademic


Sommige mensen hebben gewezen op de Debian-handleiding beveiligen. Dit zou perfect geschikt moeten zijn voor alles behalve militaire vereisten.

Veel mensen denken dat belachelijk paranoïde zijn cool of professioneel is of zoiets. Haar niet, het is slechts vervelend voor andere beheerders en ronduit onderdrukkend voor uw gebruikers. De meeste dingen die je zult zien, zijn gewoon nepdrukwerk om je nuttig te voelen voor de paranoïde beheerder, maar niet echt nuttig, omdat de echte beveiligingsinbreuk waarschijnlijk veroorzaakt wordt door een niet voldoende bijgewerkt systeem en / of een interne bron.

Dat gezegd hebbende, beschouw ik het als een van mijn principes om niets op het lokale netwerk te vertrouwen net zo min als alles van internet. Daarom configureer ik alles om verificatie te vereisen, zelfs op het lokale netwerk. Ik codeer en authenticeer alle verkeer tussen elke computer met IPsec.

Ik ben bezig met het converteren naar volledige schijfversleuteling voor al mijn servers.

Ik installeer alleen de services die ik gebruik. Ik heb geen firewall; Ik configureer de services waarvoor ik verificatie nodig heb of beperk deze (via de eigen configuratie van het programma of door TCP-wrappers) tot bepaalde IP's. Het enige dat ik ooit moest blokkeren met iptables was memcached, omdat het geen configuratiebestand had en geen TCP-wrappers gebruikte.

Ik gebruik goed, willekeurig gegenereerd wachtwoorden voor mijn accounts en vertrouw op mijn SSH-server (en alle andere services) om diegenen te houden die het wachtwoord niet kennen. fail2ban is alleen voor mensen met beperkte ruimte voor logbestanden, IMO. (Je moet goed genoeg wachtwoorden hebben om ze te kunnen vertrouwen.)


4





Ga door met deze leuke how-to op www.debian.org/doc/manuals/securing-debian-howto/

Ik verander persoonlijk de ssh-poort en gebruik fail2ban + denyhosts. En ik blokkeer alles wat niet nodig is. Hoe meer je blokkeert, hoe minder je je zorgen hoeft te maken.


3



Ugh. Je had me tot "verander SSH-poort". Het heeft geen zin. Vooral niet wanneer een Joe Schoeman met voldoende tijd aan zijn handen je kan scannen en direct kan achterhalen op welke poort SSH draait. Het declareert de servicenaam (en serverversie) zodra u verbinding maakt. - Matt Simmons
Ja, ik weet dat iedereen je kan scannen en de juiste poort kan vinden. Maar de meeste aanvallen zijn op standaardpoort. Probeer gewoon wat statistieken te krijgen door de poort te wijzigen. - Vihang D