Nätverk

En av de viktigaste funktionerna för vår server är nätverket. Det dominerande protokollet för nätverk idag är TCP/IP. TCP/IP är egentligen två protokoll, ett för transporten av datapaket (TCP) och ett för adresseringen av nätverk och noder i nätverk (IP). Det är den här protokollstacken vi använder hemma, i skolan och på företaget. När vi surfar på webben använder vi protokollet Hyper Text Transfer Protocol (HTTP) och ibland är det HTTPS. HTTPS är HTTP som skickas över en krypterad förbindelse, tidigare SSL - numera TLS. När vi skickar epost använder vi oss av ett protokoll som heter Simple Mail Transfer Protocol (SMTP) och när vi hämtar epost använder vi oss av POP3- eller IMAP-protokollen. Även om tjänster som GMail och Outlook.com har tagit över mycket av epostandet idag är det fortfarande SMTP och POP3/IMAP som ligger där och arbetar bakom webbsidorna.

Under alla dessa protokoll (det finns många fler) skickar vi våra datapaket över kablar, radiovågor och ljus (fiber). Den standard som är vanligast förekommande för överföring av datapaket heter Ethernet. Ethernet delas upp i olika standarder (eller versioner om man så vill), där IEEE 802.3 är Ethernet över partvinnad kopparkabel (TP-kabel) och IEEE 802.11 som är Ethernet över radiovågor (WiFi). Dessa standarder delas också in i undergrupper, där vi kan hitta 10 megabit Ethernet, 100 megabit Ethernet, 1000 megabit Ethernet och 10 000 megabit Ethernet under 802.3. Hastigheten är inte allt, undergrupperna definerar också om det är koppartråd, koaxialkabel eller fiber vi använder och hur lång kabeln får vara. Under den trådlösa standarden 802.11 hittar vi undergrupper som 802.11b, 802.11g, 802.11n och 802.11a.

Det finns andra typer av nätverk också, som Token Ring, FDDI och ATM. Här kommer vi bara gå igenom Ethernet, eftersom det är det vanligast förekommande.

För att en enhet (dator) skall kunna kommunicera i ett TCP/IP-nätverk behöver den ha minst två saker konfigurerade: en unik IP-adress och en nätmask. Nätmasken används av enheten för att identifiera vilket nätverk enheten finns på. IP-adressen och nätmasken tillsammans berättar vilken enhet (host) och vilket nätverk (net) enheten befinner sig på.

Vi brukar konfigurera två saker till när vi konfigurerar TCP/IP för en enhet: en default gateway och DNS-server. Default gateway använder vi för att berätta för enheten hur den skall komma ut ur sitt egna nätverk, till exempel när vi vill titta på kattfilmer på Youtube, eller titta på Facebook, så vi vet vad vår kompis åt till lunch idag. DNS-servrar använder vi för att göra om domännamn som youtube.com och facebook.com till IP-adresser som 142.250.74.110 och 31.13.72.36 .

De fyra saker vi behöver för att ha en fungerande enhet på ett TCP/IP-baserat nätverk är:

• IP-adress
• Nätmask
• Default Gateway
• DNS-server (eller flera)

För att se vilken IP-adress och nätmask vi har konfigurerat på vår dator använder vi kommandot ip address (eller ip addr eller ip a som är förkortningar av kommandot).

Här ovanför ser vi att vi har två nätverksgränssnitt (network interface): lo och eth0 . Gränssnittet lo är speciellt och heter local loopback. Det har alltid IP-adressen 127.0.0.1 och IPv6-adressen ::1. Det är ett gränssnitt som bara går att komma åt från vår egen dator, alltså inte utifrån.

Det andra gränssnittet, eth0, är vårt nätverkskort som sitter i datorn. Vi kan ha flera sådana och då visas de också med kommandot ip address. I det här exemplet har vårt nätverkskort IP-adressen 10.0.1.196 och nätmasken /24. Adressen skrivs enligt en standard som kallas Classless Inter-Domain Routing (CIDR) (uttalas cider) och anger hur många bitar av IP-adressen som är nätverksidentiteten. I det här exemplet är det 24 bitar som används för att identifiera nätverket enheten befinner sig i.

Vi har också en link/ether adress, i exemplet: 04:92:26:d4:b1:63 . Det är en adress som kallas MAC-adress. Varje nätverkskort som tillverkas får en egen, 48 bitar lång, adress som används för att kommunicera med nätverkskortet.

För att se vilken default gateway vi använder skriver vi kommandot ip route (eller bara ip r):

Här ser vi att default går via IP-adressen 10.0.1.1 . Det betyder att all nätverkstrafik som skall ut ur vårt egna IP-nätverk till, till exempel internet, skall skickas till IP-adressen 10.0.1.1 . Där finns förhoppningsvis en nätverksenhet som kallas router. Routern skickar trafiken vidare till nästa nätverk, som skickar till nästa nätverk och så vidare tills vi har nått vårat mål (till exempel Youtube.com). Målet skickar tillbaka ett svar som skickas till en router, som skickar till nästa router, och så vidare tills vi når målet (vår dator).

Vår default gateway (router) måste vara i samma nätverk som vår enhet är. Det vill säga, inom samma IP-adress- område. Syftet med en default gateway är att skicka ut (och in) trafik till andra nätverk. Vi måste alltså ha den i samma nätverk.

Datorer kommunicerar med andra enheter med hjälp av IP-adresserna, men vi använder domännamn som facebook.com och youtube.com. För att datorerna skall kunna göra om facebook.com till en IP-adress frågar de en DNS-server. Det fungerar lite som nummerupplysningen på internet. Vi kan fråga vilket telefonnummer Jonas har, och så får vi veta det. Känner vi till ett telefonnummer kan vi också använda tjänster på internet för att ta reda på vem det numret går till. DNS fungerar likadant, fast för IP-adresser.

Vi kan använda kommandot dig för att ta reda på vilken IP-adress till exempel facebook.com har:

Här ovanför ser vi att facebook.com går till IP-adressen 157.240.9.35 . Låt oss titta på aftonbladet.se också, vi gör samma sak med kommandot dig:

I exemplet ovanför ser vi att vi får två IP-adresser som svar. Det innebär att vår webbläsare kommer använda en av dem för att ansluta till aftonbladet.se om vi vill titta på deras nyheter. Att det är två (eller flera) IP-adresser konfigurerade för en domän heter DNS Round Robin och är en enklare form av lastbalansering.

Vi kan också använda kommandot host för att fråga våra DNS-servrar:

Här får vi också veta IPv6-adressen till facebook.com och vilken server som hanterar deras inkommande epost. Denna information finns i en posttyp (record) som heter MX (Mail eXchange) och används varje gång vi vill skicka epost till någon.

Nu gör vi samma sak för aftonbladet.se :

Här ser vi att Aftonbladet använder Google för sin epost (GMail).

Varje gång vi använder kommandot dig, host eller något annat kommando som pratar DNS frågar vår dator den DNS-server som vi konfigurerat. I Linux är det filen /etc/resolv.conf som innehåller informationen om vilka DNS-servrar vi vill använda:

Valet nameserver anger vilken DNS-server vi vill fråga. Här skall vi alltid ange en IP-adress! I Ubuntu används systemd-resolved som DNS-server. Det är en tjänst som hanterar namnuppslag (frågor till DNS-servrar) och vi använder kommandot resolvectl för att hantera tjänsten.

Sist i utmatningen kan vi se de fyra DNS-servrar systemet är konfigurerat att använda:

• 4.2.2.1
• 4.2.2.2
• 208.67.220.220
• 192.168.122.1

Vill vi bara veta vilka DNS-servrar som används skriver vi:

Vi kan använda kommandot resolvectl för att fråga DNS-servrarna:

För att ställa in så att servern frågar Googles DNS-server skriver vi följande kommando:

För att göra ändringarna permanenta (så det är inställt vid varje omstart) behöver vi redigera filen /etc/systemd/resolved.conf :

I filen skriver vi:

Efter att vi ändrat i filen och sparat den laddar vi om systemd-resolved :

IP-adress, nätmask och default gateway brukar vi konfigurera tillsammans. I Ubuntu görs det med hjälp av netplan . Till att börja med så finns det två olika sätt att konfigurera IP-adressen med: dynamisk- (DHCP) och statisk konfiguration. Hemma brukar vi använda dynamisk konfiguration (DHCP), då det är smidigast. Vi ansluter vår laptop eller mobiltelefon, ansluter den till wifi med ett lösenord och sedan kommer vi ut på internet. Enheten fick IP-adress, nätmask, default gateway och DNS-servrar från nätverket helt automatiskt.

När vi konfigurerar servrar vill vi oftast att de skall ha samma IP-adress hela tiden och för att säkerställa det använder vi statisk konfiguration.

Tänk på att vara försiktig med att ändra IP-adress, nätmask och default gateway på en server som du ansluter till över internet. Konfigurerar du den fel kommer du inte komma åt den.

Netplan konfigureras i katalogen /etc/netplan/ där vi hittar filen 01-netcfg.yaml . För att ställa in vårt nätverkskort att använda dynamisk konfiguration redigerar vi filen med texteditorn vi:

Filen är skriven i ett format som kallas YAML. Det är ett vanligt format för konfigurationsfiler för moderna applikationer. Viktigt att tänka på när det gäller YAML är att man använder indrag (indentering) för att skapa avsnitt i konfigurationen. De här indragen skall skapas med mellanslag (två mellanslag) och inte tabbtangenten! Det är också viktigt att filen följer formatteringen, annars kommer det bli fel när vi skall aktivera ändringarna. Var nogrann!

eth0 är namnet på nätverkskortet vi vill konfigurera, vi kan använda kommandot ip address för att ta reda på namnet på nätverkskortet. dhcp4: true anger att vi vill använda DHCP (dynamisk konfiguration) och nameservers är en lista med IP-adresser till DNS-servrar vi vill använda. Det här behöver vi inte ange, eftersom vårt nätverk kommer tillhandahålla information om vilka DNS-servrar vi skall använda. I exemplet ovanför visar vi hur vi sätter Googles DNS-servrar för nätverkskortet.

När vi är klara med ändringarna i filen 01-netcfg.yaml skall vi aktivera den nya konfigurationen, det gör vi med kommandot netplan apply :

För att ställa in en statisk IP-adress behöver vi ändra i filen 01-netcfg.yaml igen, men först behöver vi veta vilken IP-adress, nätmask, default gateway och DNS-server vi vill använda. I exemplet nedanför kommer vi använda:

• IP-adress: 192.168.1.100
• Nätmask: /24
• Default gateway: 192.168.1.1
• DNS-server: 8.8.8.8 och 8.8.4.4 (Googles DNS-servrar)

Då öppnar vi filen och redigerar den enligt nedanstående:

När vi är klara med ändringarna aktiverar vi dem med kommandot netplan apply :

Nu kan vi konfigurera TCP/IP på vår server. Vi kan ändra IP-adress, nätmask, default gateway och DNS-servrar.

I linuxkärnan finns en inbyggd brandvägg som heter Netfilter. Vi kan hantera Netfilter med ett kommando som heter iptables . Netfilter jobbar med tre huvudflöden: INPUT för paket som kommer in till vår dator, OUTPUT för paket som lämnar vår dator och skall ut på nätverket och FORWARD som är paket som kommer in till vår dator och sedan skickas vidare ut (routing).

För att se vilka regler vi har aktiverade i brandväggen kan vi skriva iptables -L :

Vill vi se reglerna för en specifik kedja anger vi helt enkelt dess namn till kommandot också, till exempel för INPUT:

Vi kan också välja FORWARD eller OUTPUT.

När vi tittar på utmatningen från kommandot iptables -L står det (policy ACCEPT) , det betyder att policyn är satt till ACCEPT vilket innebär att om ingen regel matchar paketet som kommer så gäller policyn. ACCEPT innebär att paketet kommer accepteras. Policyn kan sättas till antagligen ACCEPT eller DROP , vilket innebär att paketet blockeras.

Om vi sätter regler som blockerar inkommande nätverkstrafik på en server som vi bara når över internet måste vi tänka till. Om vi stänger av inkommande trafik till ssh (port 22) kommer vi inte kunna logga in på servern längre.

För att sätta policy på en kedja använder vi kommandot iptables -P :

När vi jobbar med brandväggsregler i Netfilter måste vi ha kunskap om nätverksprotokoll och portar. Med Netfilter kan vi bygga mycket avancerade nätverksregler där vi i den enklaste formen kan blockera, eller acceptera, nätverkstrafik och i mer avancerade konfigurationer hålla koll på hur många anslutningar en klient gör mot vår server, logga misstänkta anslutningar med mera.

En bra första konfiguration att aktivera på en server som står mot internet med en publik IP-adress, vilket innebär att den är nåbar för alla, är att begränsa åtkomsten till SSH. Så det bara är vi själva som kommer åt den. Ett stort problem med detta blir att vi behöver ha en IP-adress som inte ändrar sig på vår klient, eftersom vi kommer tillåta en specifik IP-adress att ansluta till SSH-tjänsten.

-s 212.213.214.215/32 anger vilken source regeln gäller för. All trafik som kommer från den här IP-adressen kommer träffa regeln om -p tcp protokollet är TCP och --dport 22 destinationsporten är 22. Det är tjänsten SSH som lyssnar på port 22/tcp och trafik från IP-adressen 212.213.214.215 som skall till SSH på vår server matchar regeln. När vi får en match kommer vi antagligen acceptera inkommande trafik (ACCEPT) eller neka den (DROP). I det här fallet, -j ACCEPT, accepterar vi trafiken. Vi tillåter IP-adressen att ansluta till SSH-tjänsten.

Nästa regel vi behöver sätta är policyn för inkommande trafik. Som det är nu tillåter vi all trafik (policy ACCEPT):

För att sätta policyn till DROP (neka all trafik) skriver vi:

Det här innebär att våra regler ser ut så här:

Policyn är satt till DROP, vilket innebär att om vi inte hittar en matchande regel kommer vi neka trafik in till servern. Vi har en regel, den för IP-adressen 212.213.214.215 som tillåter trafik till SSH. Det här betyder att om vi kommer från den IP-adressen och försöker ansluta till SSH-tjänsten så kommer vi tillåtas ansluta, medan all annan inkommande trafik kommer nekas.

Om vi gör en anslutning från servern ut mot internet, eller en annan maskin i vårt nätverk, kommer svaret att komma in genom brandväggen. Vi behöver alltså inte sätta regler på INPUT för sådan trafik som initeras från oss själva.

Vi har inte sparat reglerna permanent, så om vi skulle låsa oss ute från servern kan vi starta om servern med hjälp av en kontrollpanel om vi har tillgång till en sådan. För att spara reglerna permanent använder vi kommandot iptables-save och skickar utmatningen till en fil :

För att läsa in reglerna igen använder vi kommandot iptables-restore tillsammans med filnamnet på den fil (som vi skapat med iptables-save) vi vill läsa in :

Att administrera Netfilter med hjälp av iptables är ganska krångligt och i Ubuntu finns det ett kommando som heter ufw (Uncomplicated FireWall) som gör administrationen av brandväggen enklare.

Kommandot ufw status visar status för brandväggen. När den är avstängd ser det ut så här:

Många av servertjänsterna vi installerar i Ubuntu kommer också lägga till profiler som innehåller information om hur brandväggen skall konfigureras. Eftersom vi har installerat SSH finns det en sådan profil att se:

För att se information om profilen använder vi kommandot ufw app info OpenSSH, där OpenSSH är namnet på profilen som vi får fram med ufw app list:

För att aktivera (tillåta) nätverkstrafik enligt profilen OpenSSH använder vi ufw allow:

Här använder vi ssh, men vi skulle kunna använda OpenSSH (som tjänsten heter i listan) också.

Nu sätter vi policyn för inkommande trafik till deny:

För att aktivera brandväggen använder vi kommandot ufw enable:

Nu kan vi se status för brandväggen med kommandot ufw status:

Brandväggen är aktiverad och tillåter inkommande trafik till tjänsten ssh.

Vartefter vi installerar nätverkstjänster i Ubuntu (som till exempel webbservern Apache httpd) kommer vi få in fler policies i ufw app list som vi kan aktivera.

Om vi vill öppna upp för trafik på en specifik port på vår server lägger vi till den med kommandot ufw, låt oss lägga till port 80 med tcp-protokollet och port 53 med udp-protokollet:

Med kommandot ufw status verbose kan vi se att port 80/tcp och port 53/udp är öppna (allow in).

I filen /etc/service kan vi se alla kända portar och vilka protokoll de kör och vilka applikationer de tillhör.

Ibland vill vi öppna upp för en serie med nätverksportar. Låt oss säga port 20000 - 21000, då skulle vi kunna skriva så här:

I exemplet använder vi protokollet tcp, vill vi istället använda udp skriver vi 10000:20000/udp. Vill vi lägga till både tcp och udp får vi göra det med två kommandon: ett för tcp och ett för udp.

Säg att vi har en specifik IP-adress som vi vill tillåta komma åt alla på portar på vår server, till exempel vår fasta IP- adress på kontoret. Då kör vi kommandot ufw allow from och den IP-adress som vi vill tillåta:

Om det är en specik port, tjänst, som vi vill tillåta för IP-adressen lägger vi till to any port , till exempel för ssh- tjänsten:

Om vi vill tillåta ett helt subnät kan vi ange det också. Säg att vi har ett kontorsnätverk - 192.168.1.0/24 - som vi vill tillåta ansluta till ssh-tjänsten. Då skriver vi följande kommando:

Om vi vill neka trafik till en specifik port (eller tjänst), eller en specik IP-adress använder vi deny istället för allow. Det kan se ut så här:

Vill vi ta bort regler vi skapat kan vi använda ufw delete, tillsammans med tjänstens namn (ssh) eller port (22) :

Med kommandot ufw status numbered får vi fram en lista över alla regler som är satta, dessa regler blir också numrerade:

Säg att vi vill ta bort blockeringen av port 80 för IP-adressen 1.2.3.4 i exemplet ovanför. Vi ser att det står [ 6] i början av den raden. Det är regel nummer 6 och vi tar bort den genom att skriva:

Tittar vi på listan med regler igen, ser det ut så här:

Regeln för att blockera IP-adressen 1.2.3.4 från att komma åt port 80 är borttagen.

Om vi skulle vilja radera alla våra regler vi skapat i brandväggen kan vi köra kommandot ufw reset, som tömmer regellistan:

När vi kör reset kommer brandväggen också inaktiveras. För att starta den igen använder vi kommandot ufw enable. Tänk på att vi inte har regeln för att komma åt ssh (port 22) som standard, så om vi aktiverar brandväggen på en server i en cloudtjänst kommer vi inte längre kunna ansluta till den servern med ssh.

Om vi vill behålla våra regler, men inaktivera brandväggen, kan vi använda kommandot ufw disable. Det stänger ned brandväggen och tillåter all trafik in till servern, men behåller reglerna vi skapat - så nästa gång vi aktiverar brandväggen (ufw enable) kommer reglerna att vara aktiverade.

När vi jobbar med brandväggar är en bra policy att vi låser ned allt (sätter policyn till deny eller drop) och öppnar upp så lite vi kan. SSH till exempel, är till för att vi skall kunna ansluta till servern och köra kommandon. Det behöver inte hela internet ha tillgång till. En webbserver däremot, där vi kör vår webbplats, behöver hela internet ha tillgång till. Så port 80 (http) och 443 (https) kanske behöver vara öppna på servern.

Kanske använder vi en jumpstation, en maskin som är uppsatt enbart för att vi skall kunna ansluta till den och sedan hoppa vidare, för att ansluta till ett privat nätverk i vår molntjänst eller i vårt datacenter. Därifrån kan vi sedan komma åt ssh på webbservern.

Även om vi använder en extern brandvägg, så som en hårdvaruappliance i datacentret eller en mjukvarubaserad i en molntjänst, är det bra att använda den lokala brandväggen på linuxservern också. Om någon kommer in i ditt privata nätverk (som körs i datacentret eller i molnet) behöver vi ju inte bjuda på full åtkomst överallt.

Ett exempel på konfiguration för en webbserver, där vi också vill kunna ansluta med ssh för att till exempel uppgradera Linux. I exemplet tänker vi oss att vi har IP-adressen 201.202.203.204 på vår egen maskin, så det är bara den som skall kunna ansluta till ssh.

Notera hur vi inaktiverar (disable) brandväggen först. Sedan ser vi till att vi öppnar upp för trafik mot port 22 (ssh) och webbservern (http och https) för att slutligen aktivera brandväggen (enable). Det här är en bra grundläggande konfiguration för en webbserver.

När vi har nätverksportar öppna ut mot internet kommer andra hitta oss. Det finns tusentals datorer ute på internet som letar efter öppna maskiner som de kan attackera och ta över. För att göra det lite svårare för dem kan vi använda ett program som heter fail2ban, som är mycket effektivt på att stoppa intrångsförsök. fail2ban kan till exempel titta på misslyckade inloggningsförsök mot ssh-tjänsten och blockera IP-adressen som försöker logga in.

För att installera fail2ban använder vi kommandot apt:

Konfigurationen av fail2ban görs i katalogen /etc/fail2ban/, där vi hittar en fil som heter jail.conf. Eftersom den filen kan skrivas över av uppdateringar av fail2ban skapar vi en egen fil, jail.local i samma katalog och där gör vi vår konfiguration. Allt som står i jail.local-filen kommer gå över det som står i jail.conf-filen.

Vi kan titta i filen jail.conf för att se vad vi kan konfigurera, allt som står i filen kan vi skriva i vår jail.local-fil. Filen har en global inställning som gäller för alla tjänster vi konfigurerar i fail2ban, den globala inställningen hittar vi under [default]. Sedan kommer olika avsnitt med konfiguration för en mängd olika tjänster som vi skulle kunna köra på vår server, nu är vi mest intresserade av [sshd].

Här kommer vi titta på hur vi kan skydda ssh-tjänsten från inloggningsförsök. Vårt mål blir att låsa ute alla som misslyckas logga in på ssh tre gånger under en timme och vi vill att de skall låsas ute 24 timmar.

Till att börja med kanske vi vill hindra oss själva från att bli utlåsta och det vill vi nog för alla tjänster vi kan skydda med fail2ban, så vi skapar en ny fil jail.local och skriver in följande i den:

Vi behöver också berätta för fail2ban att vi vill använda ufw för att hantera de blockerade IP-adresserna, det gör vi genom att ställa in actionban och actionunban:

Filen ufw.conf kan vi titta i om vi vill se vad den gör, öppna i så fall filen /etc/fail2ban/action.d/ufw.conf.

Sedan är det dags att skapa konfigurationen för ssh. Här ser vi till att kontrollen av ssh är aktiverad (enabled) och vi anger vilken port vi skall kontrollera (port). Vi anger också ett filter som innehåller de mönster fail2ban skall leta efter för att identifera misslyckade försök att komma åt tjänsten ssh. Vårt mål var låsa ute alla som misslyckats logga in på ssh tre gånger under en timme och vi skall låsa ut dem i 24 timmar. När vi anger tid till fail2ban är det i enheten sekunder. Så en timme blir 3600 sekunder och vi konfigurerar det med findtime. Antalet försök som är tillåtna konfigurerar vi med maxretry. Slutligen konfigurerar vi hur länge de skall vara utlåsta med bantime, i vårt fall sätts det till 86400 sekunder som är 24 timmar.

När vi är klara skall filen jail.local se ut så här:

För att läsa in konfigurationen startar vi om tjänsten fail2ban med kommandot systemctl:

För att se att tjänsten är igång kan vi använda följande kommando:

Vi kan också titta i systemloggen efter meddelanden från fail2ban:

fail2ban loggar också till filen /var/log/fail2ban.log där vi kan se lite mer vad som händer, till exempel med kommandot tail:

För att se status på fail2ban använder vi kommandot fail2ban-client:

Här kan vi se att vi har ett jail (varje applikation vi övervakar kallas jail) aktivt och att det är sshd. Vill vi se status för ett specifikt jail, till exempel sshd ovanför, skriver vi så här:

Under Actions ser vi hur många IP-adresser vi har som är blockerade (banned), i det här fallet har vi inga alls. De kommer dyka upp om de gör tre misslyckade inloggningsförsök till tjänsten ssh under en och samma timme. Precis som vi konfigurerade fail2ban.