Vad är poängen med SSH över VPN-anslutning?

Jag ser många säga att exponering av SSH-porten mot internet är olämpligt även om endast nyckelbaserad autentisering används och att det bör köras över VPN/Wireguard istället.

  • Vad är poängen med detta ifall SSH-nyckeln och Wireguard-kryptering erbjuder jämförbara säkerhetsnivåer och det inte är som du kan förvänta dig att en angripare kan knäcka vare sig? Vilka är vanliga användningsområden för Wireguard?

  • Bör du köra alla vanliga tjänster över Wireguard eller finns det fall där du inte bör?

  • Gör detta att saker som Fail2ban/Crowdsec blir överflödiga (om jag har förstått det rätt, Wireguard använder UDP så kommer det bara svara på oönskade anslutningar)? Skulle Fail2ban/Crowdsec erbjuda några fördelar för portar som inte är öppna?

  • Finns det andra generella regler för att förbättra en brandvägg förutom standarden att neka all inkommande anslutning förutom nödvändiga portar?

Alla SSH-servrar som är exponerade på internet blir ständigt attackerade av botnät. Du behöver bara titta i loggarna för att se det.

En VPN förhindrar sannolikt detta, vilket sparar dig kraft/CPU från att bli attackerad hela dagarna samt risken att de faktiskt hittar vägen in. Eller åtminstone skulle de först behöva kompromissa din VPN.

SSH ger ett säkert skal, WireGuard ger en nätverksanslutning till ett privat nätverk. De är olika användningsområden som kan användas oberoende av varandra. Du skulle inte vilja ha något mindre säkert för något av dem, av risken att de missbrukas på egen hand.

Säkerhet är lager på lager.

För mig är en VPN enklare. Sätt upp VPN:en och du kan begränsa allting till LAN-only. Enklare att konfigurera och mindre att oroa sig för.

Ur ett praktiskt perspektiv, när jag vill skriva ut hemma, eller hämta en fil från NFS, kolla min intranetsdokumentation, surfa med Pi-hole svartlistat, fjärrskrivbord till min arbetsstation, … varför försöka göra allt detta via SSH om du kan bara sätta upp Wireguard och göra det hela på distans som att du är hemma?

Utöver säkerhet, förstår inte varför man ska exponera SSH ärligt talat. :wink:

Vad är poängen med detta ifall SSH-nyckel och Wireguard-kryptering erbjuder jämförbara säkerhetsnivåer och det inte är som du kan förvänta dig att en angripare kan knäcka vare sig? Vilka är vanliga användningsområden för Wireguard?

SSH är mycket mer sannolikt att bli attackerad och har en större attackyta, särskilt om du använder standardportar. Detta innebär också att din server kommer att bli bombarderad med attacker även om ingen av dem lyckas.

Som andra inlägg har nämnt, är det ofta en bra idé att använda flera säkerhetslager.

Jag använder Wireguard av två anledningar:

  1. Fjärr-VPN för att dölja trafik från operatör/ISP eller ändra den upplevda geolokaliseringen.
  2. VPN in i hemnätverket för att få tillgång till lokala nätverkstjänster, många av vilka jag verkligen inte vill exponera för internet eftersom jag inte litar på deras säkerhet lika mycket.

Finns det några andra generella regler för att förbättra en brandvägg förutom standarden att neka all inkommande anslutning förutom nödvändiga portar?

Jag skulle leta upp några SSH-härdningsguider - särskilt de för tjänster som är publika (kanske Linode eller DigitalOcean - båda har SSH-härdningsguider men jag kommer inte ihåg exakt vad som täcks i varje). Men det finns mycket jag förmodligen vill spärra upp i din sshd_config som att använda en icke-standardport (de flesta bots riktar in sig på port 22 specifikt, så att välja något annat hjälper att undvika detta), inaktivera root-åtkomst, inaktivera lösenordsautentisering (eftersom lösenord annars kan brute-forceas), whitelist-åtkomster för användare/IP om möjligt, spärra cipher/algoritmer (ikraft att inaktivera ECDSA - den är både teoretiskt sårbar för kvantdatorer och enligt Arch Wiki finns det också antydningar om att NSA kan bryta den. Om du använder RSA, se till att använda minst 3072 bits nyckelstorlek, etc).

Det finns också mer avancerad teknik. En av de saker jag såg när jag forskade om min egen SSH-härdning var port knocking. Idén är att inte bara nyckelbaserad autentisering krävs, utan även före detta måste klienten begära en specifik sekvens av portar innan den ens är tillåten att prata med SSH-tjänsten och börja autentiseringen (som ett hemligt knackning mot en dörr).

Jag såg också minst en guide som talade om att sätta upp SSH som en Tor-doltjänst.

Ursäkta bristen på länkar… Jag är på telefon. Men jag kan nog gräva fram några senare om du är intresserad men har svårt att hitta. Låt mig veta

Fail2ban

Det finns också en alternativ tjänst kallad sshguard som sägs fungera liknande. Det kan vara bättre. Kan vara samma. Har ännu inte utforskat det tillräckligt men det är på min “ting att titta på om jag får ledig tid och inte slösar den på att doomscrolla Reddit”-lista.

Jag använder SSH + IP-whitelistning. Struntar i VPN:er. Missar jag något?

Inget dåligt alls med att ha SSH öppet. Så länge lösenordsautentisering INTE är möjlig, är det mycket, mycket osannolikt att ett intrång sker.

Nackdelen: Loggarna kommer att bli översvämmade. Men det är i stort sett allt.

Analogen, dock begränsad, kanske är att ha en väldig noga skyddad dörr med sofistikerade lås och mekanismer, som gör att endast de med rätt nyckel (=SSH-server på port X, som använder allt för att säkert logga in) kan komma in eller ha ingenting alls synligt för de som tillfälligt eller till och med nära letar efter… dörrar av något slag (nämnd server, men inte körs på någon gränssnitt som är öppen för det bredare internet).

I den bilden är faktiskt existensen av dörren (när den ses utifrån) skillnaden. Och eftersom inget fancy lås skyddar mot exploater av mekanismerna som används är den säkrare satsningen, i relativa termer, att inte ens erbjuda en dörr i första hand.

Om allt det är värt besväret är förstås helt subjektivt. Enligt min mening, ju mindre erfaren man är, desto säkrare bör man göra sig för att ens en bräcklig lager (säg att det finns ett exploit i PKI-autentisering eller ett enkelt konfigurationsfel) kan fortfarande motverkas till viss del av de andra lagren som finns.

Eftersom de överliggande VPN:erna som ZeroTier eller Tailscale är så enkla att sätta upp och dessutom gratis, skulle jag säga att de är värda att titta på åtminstone: https://www.youtube.com/watch?v=6M8LIl4UzwI&t=209s

Men, ‘säkert,’ skulle du säga, ‘dessa exploit är sällsynta och de flesta saker är patchade efter flera års drift!’ Nja: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=OpenSSH

(ja, att hålla OpenSSH uppdaterad är en sak, men den har några beroenden, eller hur? Kort sagt: Lägg till lager, de misslyckas sällan alla samtidigt)

Vad är poängen med detta ifall SSH-nyckel och Wireguard-kryptering erbjuder jämförbara säkerhetsnivåer och det inte är som du kan förvänta dig att en angripare kan knäcka vare sig? Vilka är vanliga användningsområden för Wireguard?

SSH är ganska säkert i sig, om du följer alla riktlinjer (till exempel, inaktivera lösenordsinloggning, inaktivera alla inloggningar för användare som inte behöver ha detta (som tjänster använder när du installerar dem) etc)

Användningsfallet för Wireguard är att vara en VPN. När du ansluter via Wireguard är det som om du är direktansluten till nätverket av din server. Som om jag tracerouter IP-adressen till min server via Wireguard, är det bara ett hopp bort:

traceroute till 10.11.12.1 (10.11.12.1), 30 hopp max, 60 byte paket
 1  server.vpn (10.11.12.1)  221.807 ms  221.809 ms  221.784 ms

Jag är också på samma nätverk som andra Wireguard-klienter, så min mobiltelefon kan prata direkt med min stationära dator även när jag är bortrest hemifrån. Det här är vad en VPN används för, att göra ett Virtuellt Nätverk som är Privat.

Ska du köra alla typiska tjänster över Wireguard eller finns det fall där du inte ska?

Det beror. Om jag kör min vanliga webbserver över Wireguard, ja, ingen kommer att kunna se min hemsida! Men till exempel är min Jellyfin-server bara bakom Wireguard, det finns inget behov av att den ska exponeras till hela internet. Du kör saker bakom Wireguard om du vill att det ska vara privat.

Gör detta att saker som Fail2ban/Crowdsec blir överflödiga (om jag har förstått det rätt, Wireguard använder UDP så kommer den bara svara på oönskade anslutningar)? Skulle Fail2ban/Crowdsec erbjuda några fördelar för portar som inte är öppna?

Om du placerar en tjänst bakom Wireguard (eller någon annan VPN), ja, då är fail2ban och liknande överflödigt för den tjänsten. Men du kan aktivera Wireguard för att skapa loggar och konfigurera fail2ban att blockera IPs som försöker ansluta men inte ger en korrekt handshake. Det kommer att synas i loggarna så här:

Sat Mar  6 20:41:31 2021] wireguard: wg0: Ogiltigt handskakningsinitiering från 203.0.113.2:51820

Jag har aldrig sett någon göra detta, dock.

Finns det andra generella regler för att förbättra en brandvägg förutom standarden att neka all inkommande anslutning förutom nödvändiga portar?

En enkel brandvägg som UFW kan bara tillåta att blockera portar. Men du kan förbättra med annan programvara också. De brandväggar som utför DPI (Deep Packet Inspection) kan till exempel upptäcka viss trafik även om den inte använder standardportar. Så låt oss säga att du låser din SSH endast bakom en Wireguard och installerar en DPI-brandvägg som är konfigurerad för att blockera SSH-anslutningar på den offentliga IP:n. Och låt oss säga att du fått en bakdörr som skapar en SSH-server på en slumpmässig port. I det ögonblick en SSH-paket anländer, kommer DPI-brandväggen att märka det och blockera. Jag har aldrig använt sådan programvara, så jag kan inte hjälpa till med detta, förutom att veta att det finns.

En annan sak jag lagt märke till på min webbserver är att flera bots försöker hitta sårbarheter i viss webbprogramvara. Jag får flera träffar på /wp/admin och andra välkända sökvägar som naturligtvis ger 404 fel. Jag konfigurerade fail2ban för att fängsla de IPs som försöker göra detta. En vanlig brandvägg kan inte göra det eftersom jag bara skulle kunna öppna eller stänga port 443. Fail2ban kan å andra sidan övervaka mina webbserverloggar, och inkludera brandväggsregler för att blockera de IPs i realtid, och även hålla koll på vad som blockeras och hur länge, för att ta bort blockeringsregler efter en tid.