Du har 40 föremål i din kundvagn
Summa: 310700.0 kr
Brandväggsregler är A och O. Oavsett om det är första gången du beställer en server eller om du är erfaren servertekniker är det viktigt att först av allt ta itu med brandväggsregler. Innan du gör någonting annat.
Brandväggar & deras brandväggsregler kan man rent generellt dela in i två kategorier;
1. Den lokala brandväggen som i regel sitter i varje enskild dator, server osv.
2. Den externa brandvägg som skyddar varje nätverk och ansvarar för hur trafik dirigeras på det lokala nätverket samt till och från andra nätverk.
Våra externa brandväggar är "Riktiga brandväggar" dvs ej en delad mjukvarubrandvägg. (I regel syftar man med "brandvägg" som enhet/funktion inte på en mjukvarubrandvägg utan i regel en eller flera hårdvarubrandväggar (eller i vissa sammanhang virtuella brandväggskluster med dedikerade systemresurser som fungerar lika tillförlitligt som fysiska hårdvarubrandväggskluster).
Oavsett vilken av våra serverhostingtjänster du har så har du tillgång till skydd (och avlastning) från våra brandväggskluster och du har, vare sig du vet om det eller inte, en uppsättning brandväggsregler som skyddar er server, dess tjänster och er information.
Dessa brandväggsregler anpassas efter era behov och i så kallade accesslistor (förkortas ofta ACL, vilket syftar på engelskans Access List) styrs hur trafik kan blockeras eller släppas fram.
Varje enskilt paket, dvs den trafik som skickas till er server, utvärderas och så snart en brandväggsregel matchar så att trafik ska släppas igenom till er server på en port så kommer vi till nästa steg, nämligen den lokala brandväggen i er server.
Börja alltid med att konsultera vår kundservice för att få tips och hjälp med inställningar av de externa brandväggsreglerna!
I er server finns en lokal brandvägg. Beroende på vilken operativsystem ni valt och hur ni bett oss anpassa det eller hur ni själva anpassat det så kan det vara olika brandväggsfunktioner som används.
Använder ni ett operativsystem som är Linux-baserat är det troligt att ni har tillgång till funktioner som:
- Iptables
- UFW
- Ipchains (rekommenderas ej!)
..eller någon av de andra många olika, väl fungerande och säkra brandväggsfunktioner som finns i Linux.
Den kanske vanligaste är iptables och även om många tycker att den kan vara lite krånglig att bekanta sig med så är den ofta enklare att hantera än många av de mindre vanliga brandväggsalternativen, en stor fördel är också att det är enkelt att hitta hjälp på Internet.
Bland många lite mindre vana användare är UFW populär. Det är inget som helst fel på UFW. Den är enklare och mer överskådlig vid en första anblick. Är du ovan vid att konfigurera brandväggar i Linux kan det vara värt att prova på den! (på debian-baserade operativsystem installerar du den med: apt-get install ufw).
En sak som är viktig att tänka på är att även om du har en extern brandvägg som skyddar dig så är det alltid viktigt att också ha en lokal brandvägg. Båda brandväggarna bör vara så restriktiva som möjligt (öppna inte en port för alla i hela världen, öppna den för de som behöver nå den så att porten är otillgänglig för alla som inte ska nå den!).
Det enda som skyddar dig mot såväl lokala attacker, fel och brister som mot externa attacker är just brandväggarna. Det är ett kraftfullt första försvar som rätt använt kommer skydda er mot 99.999% av alla hot ni kommer utsättas för! Stäng för guds skull aldrig av brandväggen!
I de externa brandväggarna är det bra att ha så restriktiva regler som möjligt. Allt som kan blockeras redan här betyder mer systemresurser i er server. Varje paket som skickas fram till er server och ska utvärderas och eventuellt blockeras tar resurser från er server.
..Beskrivs av Ubuntu som en okomplicerad brandvägg med syntax liknande OpenBSD's paketfiltreringssystem som av många anses vara ett av de säkraste i världen. Netfilter är den underliggande brandväggskomponenten som hanteras med UFW-gränssnittet (som låter dig skicka kommandon för att uppdatera brandväggsregler, se status mm).
Det är enkelt att utan grafisk miljö hantera UFW, tex via SSH kan du på distans göra allt du behöver med några få enkla kommandon. Inget större fotavtryck även i mycket hårt belastade system och lämpar sig aldeles utmärkt för de flesta sorters servrar som webbservrar på VPS:er och liknande!
Så här skapar du enkelt en regel för att tillåta trafik på port 22 (SSH) från en på förhand känd klient:
sudo ufw allow from 192.168.0.4 to any port 22
Ovanstående kommando talar om för UFW att tillåta trafik till alla lokala interface (dvs localhost (127.0.0.1) och alla andra lokala anslutningar) på port 22 men trafik släpps bara in ifall den härrör från 192.168.0.4 (byt ut till din egen IP-adress).
Har du en helt ny server, börja med att kontrollera om UFW körs:
sudo ufw status verbose
Är UFW inte aktiverat så aktiverar du den med:
sudo ufw enable
(är ufw inte installerat får du börja med detta, via emerge, yum eller apt-get eller det sätt som du installerar mjukvaror i ditt linux-system behöver du installera paketet ufw, tex: sudo apt-get install ufw)
Om du skulle vilja stänga av UFW gör du det på detta sätt:
sudo ufw disable
Syntaxen är mycket enkel, så här tillåter du exempelvis all trafik på port 53:
sudo ufw allow 53
Både TCP och UDP tillåts i exemplet ovan, du behöver således inte skapa separata regler för de två olika protokollen!
Vill du specifikt bara släppa in trafik för tex TCP så kan du göra det på detta vis:
sudo ufw allow 53/tcp
..eller för UDP:
sudo ufw allow 53/udp
Princpen är alltså denna:
sudo ufw allow from to port
Läs mer på Ubuntus (eller ditt operativsystems) manualsidor eller man ufw för fler tips!
Den kanske allra vanligaste ändpunktsbrandväggen för servrar och olika enheter idag är IP Tables. Ända sedan man i tidernas begynnelse hittade allvarliga brister i den tidigare vanliga brandväggsmjukvaran ipchains har IP Tables dominerat och används i de flesta Linux-baserade operativsystem idag på något vis. Det kan fungera lite olika, ibland har man reglerna i en textfil som är enkel att redigera, ofta ligger denna i /etc/iptables.rules*. Ibland hanterar man regler via grafiska gränsnitt, ibland med kommandon direkt till iptables. Inte sällan en kombination av alla dessa.
En stor styrka med IP Tables är att många andra produkter integrerar fint med den. Tex fail2ban, en populär metod för att automatiskt svartlista klienter som beter sig illa upprepade gånger (tex för att blockera alla som misslyckas att logga in via SSH, FTP, Htaccess osv), fungerar utmärkt med IP Tables och kan smidigt och helt automatiskt blockera oönskad trafik utan att du ens behöver bry dig om det eller ens veta det. Självfallet kan du såklart också få veta det om du skulle vilja det.
Men hur som helst så är det inte otroligt att du på just din server har IP Tables. Det är inget att frukta utan det är faktiskt enkelt att komma igång och bekanta sig med den. En första anblick kan vara lite svåröverskådlig så istället för att börja läsa manualsidorna och titta på konfigurationsexempel tycker vi att du ska börja med att som root undersöka om du har några brandväggsregler som tillämpas med IP Tabels, det gör du såhär:
sudo iptables -L
Använder du inte iptables kan du installera den med tex apt-get install iptables.
Principen bakom iptables är att man jobbar med chains, dvs kedjor av regler. Det finns tre olika typer av chains som du behöver känna till:
1. input
2. forward
3. output
Rubrikerna talar ganska mycket för sig själva men som du kanske förstår så vet ju inte iptables om din server är en router mitt i ett nätverk, en ändpunkt, en klient, en server eller lite av allt sammans. Input hanterar såklart inkommande trafik, forward handlar om att ta emot inkomande trafik som inte ska terminera lokalt utan skickas vidare någonannanstans.
Kontrollera nu status för iptables igen, fast såhär:
sudo iptables -L -v (-v betyder verbose, dvs mer utförlig information)
Du borde se rubriker för olika typer av trafik, även om du inte har några definierade chains alls. Har du inte iptables installerat framgår det tydligt i svaret som ditt operativsystem ger dig.
Output handlar om utgående anslutningar.
Du kan skapa regler på olika sätt och vi går inte in i det i detalj här men principen är att du kan välja olika beteenden för iptables i olika sammanhang;
DROP - betyder inte "tacka nej" utan det betyder strunta i trafiken, slösa inga systemresurser utan bara glöm allt som om inget hänt.
REJECT - betyder "tacka nej", dvs skicka tillbaks information om att porten inte är nåbar.
ACCEPT - innebär att trafiken ska tas emot.
Som du säkert förstår är det i många situationer smartare att använda DROP än REJECT, inte minst för att det kostar mindre för dig och minimalt med systemresurser går åt i din server. Skulle du tex få en attack där någon skickar väldigt mycket ovälkommen trafik och du hanterar den med REJECT så måste din server ändå för varje enskilt paket skapa och skicka ett svar och "tacka nej". Attackeraren ser tydligt att det finns någonting där och att den tackar nej. Man kan dessutom i många situationer utifrån hur REJECT-svaret skickas börja gissa ganska mycket om hur ditt system är konstruerat och konfigurerat. Vi rekommenderar att man så långt som möjligt bara använder DROP istället för REJECT.
Får du mycket oönskad trafik från en viss klient kan du enkelt skapa en regel för att neka den trafiken;
iptables -A INPUT -s 10.10.10.10 -j DROP
Vill du blockera all trafik från ett helt nät (helt spann av IP-adresser) kan du blockera med CIDR-beteckning på detta vis:
iptables -A INPUT -s 10.10.10.0/24 -j DROP
Vill du bara blockera viss trafik från en specifik klient kan du göra så här:
iptables -A INPUT -p tcp --dport ssh -s 10.10.10.10 -j DROP
I exemplet ovan skulle man alltså kunna tänka sig att adressen 10.10.10.10 skulle kunna få komma fram på en annan port som tex port 80 (webbserver) men just port 22, dvs ssh är explicit blockerad så det finns ingen möjlighet för 10.10.10.10-användare att kunna logga in eller ens se information om ssh-servern på din server.
Vill du spara dina brandväggsregler kan du i de flesta system använda detta kommando (i de flesta debian-baserade systemen ska det fungera felfritt utan modifikation):
sudo /sbin/iptables-save
I RedHat/CentOS/Fedora-baserade system behöver man i regel göra så här istället:
/sbin/service iptables save
Ofta fungerar även:
/etc/init.d/iptables save
Släppa in SSH för en viss klient:
iptables -A INPUT -p tcp --dport ssh -s 10.10.10.10 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -d 10.10.10.10 -m state --state ESTABLISHED -j ACCEPT
--dport betyder destination port, dvs destination port 22 (ssh) på din server.
--sport betyder source port, dvs källans port.
STATE är ett kapitel i sig, när du kommit såhär långt rekommenderar vi att du läser manualsidan och sätter dig in i:
A) vad ni vill släppa in
B) att ni vill blockera allt utom det ni vill släppa in.
Ta gärna hjälp av vår supportpersonal som gärna ger er tips och råd kring hur både regler i externa brandväggar och lokala brandväggsregler kan kombineras på bästa sätt och hur ni med hjälp av accesslistor på ett enkelt sätt kan hantera åtkomst och blockera all oönskad trafik på ett säkert och effektivt sätt.
Många Unix-baserade system som OpenBSD, FreeBSD mfl använder PF. PF står för packet filter och är en mjukvara som ursprungligen tagits fram av openbsd. OpenBSD är ett UNIX-baserat operativsystem som är fokuserat på säkerhet i första hand och är mer eller mindre vedertaget det officiellt säkraste alternativet. Typ. Prestanda är dock inte något man fokuserat på, tvärt om är det säkerhet som går före i alla led. Därför är det vanligt att man har en dedikerad lösning (ofta ett kluster) med OpenBSD-brandväggar/routrar och andra, dedikerade, system för tex webbservrar.
Oavsett hur du använder PF så fungerar det på samma sätt. Det är, som allt annat, enkelt när du satt dig in i det.
Beroende på vilket operativsystem du har och vilken version du använder så fungerar det lite olika. Vi rekommenderar den senaste versionen av OpenBSD, FreeBSD, NetBSD om du använder BSD Unix men det finns andra miljöer där du kan använda PF också, bland annat linux.
Du börjar med att aktivera PF om du inte redan gjort det;
pfctl -e
pfctl är ett praktiskt kommando om du använder SSH eller på annat sätt (VNC-konsoll tex) ansluter till en icke grafisk miljö. växeln -e betyder "enable".
För att deaktivera säger du istället:
pfctl -d
..Så långt inte så konstigt.
Huvudkonfigurationen ligger i regel i /etc/pf.conf - börja med att titta om du har en default-konfiguration här.
När pf körs anger man i regel sökvägen till konfigurationsfilen (tex: pf -f /etc/pf.conf) så du kan med 'ps auwx | grep pf' se ifall pf redan körs och om du har en annan sökväg på ditt system. (ps auwx fungerar inte på alla unix-baserade system, ibland kan du behöva ange andra växlar som oef).
Börja med att bekanta dig med pfctl (man pfctl) - det finns många bra anvädningsområden för pfct, du kan tex testa utan att ladda regler osv för att utvärdera och hitta konfigurationsfel utan att störa trafiken (pfctl -nf /etc/pf.conf), visa aktuella regler: pfctl -sr osv.
För att se ALLT kan du börja med att testa pfctl -sa.
PF är lite mer sofistikerad än tex iptables (anser många, därmed inte sagt att det är bättre eller sämre) och funktionerna och möjligheterna är många, du kan i regel läsa en manualsida för pf.conf (man pf.conf) - gör det.
En av huvudfunktionerna är paketfiltrering, dvs brandväggande och routande av IP-paket men du kan faktiskt göra så pass avancerade saker som att inspektera paket, titta efter fragmenterade paket - försöka laga dem och identifiera trafik som härrör från särskilda operativsystem och hantera dem olika beroende på vilken klient som skickar trafik. Det är så komplicerat du vill och så enkelt som du vill.
Trafikprioritering är en annan anledning att många använder pf. Du kan skapa olika köer, prioritera olika protokoll på olika sätt (tex låta SIP-trafik få högre prioritet än DNS-trafik eller precis hur du vill).
Eftersom du skapar regler som har att göra med interface, dvs fysiska eller virtuella nätverkskort så underlättar alias oerhört mycket. Du kommer ganska snart få mycket hjälp med alias. Hela accesslistor kan dölja sig bakom ett alias och du kan tex byta den faktiska IP-adressen på dit WAN-interface och låta det slå igenom i alla regler helt sömlöst genom att inte hårdkoda ipadressen för WAN-interfacet utan istället använda ett alias och bara referera till aliaset och låta eventuella förändringar automatiskt uppdatera allt.
Tänk dig att du ansluter via VPN och kommer från någon adress inom ett definerat spann av IP-adresser. Du vet inte vilken av alla klienter som är din hemdator men du vill släppa in just din dator - men ingen annan - till din arbetsdator. Genom att skapa statisk DHCL, fasta VPN-regler och kombinera med brandväggsregler är det enkelt att låsa alla ute som grundregel men därefter göra ett undantag för just din adress men ingen annan.
Just utgångspunkten "blockera allt" och öppna därefter upp (restriktivt) är en mycket bra grundförhållning för all form av nätverkssäkerhet men i PF är det tankesättet liksom inbyggt och det är enkelt att snabbt sätta sig in i och utnyttja effektiviteten och styrkan i hur smart PF faktiskt är konstruerat.
Dessvärre finns det inte många bra gränssnitt utan du är i regel utelämnad till att faktiskt, på rikrigt, sätta dig in i hur det fungerar och prova dig fram för att lära dig. På gott och ont. Tanken är nog att det faktiskt brli bättre om du på djupet förstår vad du gör. Brandväggande på den här nivån är faktiskt väldigt viktigt och att skapa ett "dumt" gränssnitt hade kanske inneburit att många tar genvägar.
För att vara lite taskig kan man med IP Tables på en Linuxburk göra de genvägarna men PF är inte lika förlåtande.
Precis som i andra brandväggsmjukvaror kan du välja mellan att neka trafik med svar block (reject) - dvs du skickar faktiskt ett svar till avsändaren "nej det här släpps inte in" (och slösar lite systemresurser och blir lite mer sårbar för tex dos-attacker) men du kan även väjla att tyst neka trafik med drop.
Att acceptera trafik gör du med pass (eller match)
Du kan "forwarda" trafik med rdr.
Genom att lägga till argumentet quick på en regel så kan du tala om för brandväggen att om denna regel uppfylls så behöver inte fler regler utvärderas utan trafiken ska omedelbart hanteras på det sätt som regeln säger (tex släppas in med pass). Detta är smart eftersom reglerna utvärderas "uppifrån och ned", dvs om första regeln är "block all" - dvs blockera ALL trafik och nästa regel är ett undantag som säger släpp in "just precis det här under de här förutsättningarna" osv så kan vissa relger hamna ganska långt ned.
För att undvika att mycket trafik behöver passera genom många många lager av regler kan man för viss trafik - kanske särskilt vanligt förekommande och kostsam trafik att utvärdera - snabbt säga: "strunta i att titta på fler regler utan har du kommit hit så vet vi att den här trafiken vill vi släppa vidare".
Tips på program du kommer vilja ha när du felsöker och testar dina brandväggsregler:
- telnet (tex telnet 192.168.1.1 80 för att testa om port 80 är nåbar på 192.168.1.1)
- nc (netcat) kan testa både tcp och udp och en massa annat.
- curl (läs manualen, tex testa trafik och fejka http-headers mm)
- lynx för att snabbt testa webbsidor och liknande
- wget (klarar även saker som ftp så du slipper använda ftp eller telnet för att testa detta)
- ping, traceoute och tracepath
- dig, host och dig -x för att kontrollera DNS-namn.
- arp, arping, iptraf, snort, iperf och vnstat samt iftop
- netstat -rn, netstat -afinet / netstat -antpu
- tcpdump, nmap/zenmap och wireshark
- top, atop, htop, iotop, sysstat och uptime
- route, ifconfig, iftop, ifquery, driftnet, mtr
Tips: ab (apache benchmark) kan användas för att generera stora strömmar av trafik för att utvärdera hur regler fungerar i praktiken och enkelt generera lite stress under en begränsad tid. Du ska aldrig få några tappade paket. Börjar du se paketförluster är något allvarligt fel!
Ta gärna hjälp av vår kundservice som har flera tips och råd kring vad som brukar fungera och gärna sätter sig in i hur just era förutsätningar ser ut och är med och felsöker från vårt håll för att kontrollera att trafik skickas på rätt sätt osv.!
Lycka till och tänk på att det är alltid bäst att börja med att neka all trafik och sedan restriktivt öppna upp får några undantag, aldrig tvärt om!
Faktum är att i många produkter från Apple så är brandväggen avstängd som standard. Detta är ett förkastligt beteende och absolut inte säkert. Många lever i en villfarelse att Mac OS X ska vara så säkert så man inte behöver vare sig brandvägg eller antivirusprogram - detta är naturligtvis inte sant. I alla typer av datorer kan problem med tex virus och intrång ske. Om man inte skyddar sig så vet man bara inte om när det sker. Med ett gott grundskydd slipper man många - men inte alla - problem.
Eftersom vi inte rekommenderar Mac OS X som ett serveroperativsystem går vi inte inte på detaljer här kring konfiguration men i regel kan du i alla BSD-baserade operativsystem använda exempelvis PF om du vill ha full kontroll på säkerheten.
Windows används ibland som serveroperativsystem, även om det enligt de senaste mätningarna utgör en mycket liten del procentuellt sett av alla servrar på Internet så är det oerhört viktigt att skydda sitt windows-system med både antivirus och brandvägg. Inte minst de många olika och frekvent förekommande säkerhetsbristerna i operativsystemet Windows gör att din server blir mottaglig för intrång om du inte skyddar den.
I Windows ingår en egen brandvägg som du kan anpassa. Det finns även massvis av olika tredjepartsverktyg från inte minst alla antivirus-tillverkare som går att använda. I många fall är en mycket restriktiv extern brandvägg i kombination med Windows-brandväggen ett gott nog val. Det fungerar ypperligt och är snabbt och effektivt.
Glöm inte att regelbundet söka igenom alla dina windows-system efter virus också!
Konfiguration av brandväggar i Windows sker i regel uteslutande med grafiska verktyg. Olika versioner av Windows Server ser ut och fungerar lite olika, konsultera dokumentationen för just ditt system och tänk på att även om du inte lokalt kan blockera vissa sorters trafik utan tvingas släppa in ALL trafik av ett visst slag så kan du fortfarande i de externa brandväggarna använda accesslistor.
Det finns ingen som helst anledning att släppa in ALL på hela Internet på port 3389 bara för att din hemarbetsplats behöver komma in där - skapa en accesslista och släpp ENBART in din hemarbetsplats - droppa all annan trafik även på "godkända" portar.
Så fort du släpper in ALL trafik på en port så är det bara en tidsfråga innan någon listar ut hur man loggar in, gissar lösenord osv. Du måste kombinera en öppen port med en accesslista och helst även en funktion på servern som detekterar brute force attacker som lösenordsgissning.
Släpper du tex in obegränsat antal misslyckade inloggningsförsök på en säker applikation som körs på port 80 på er server så är det enkelt för vem som helst att när som helst börja gissa sig fram till rätt lösenord. Det finns tonvis av färdiga kit på nätet att hämta hem även för inte så kunniga "hackers" som man kan köra mot en server och på ganska kort tid bryta sig in.
Att släppa in obegränsat antal misslyckade inloggningsförsök är därför totalt förkastligt.
Du måste ha både säkra externa brandväggsregler, acceslistor som enbart släpper in de du vill och stänger alla andra ute - även för betrodda portar - men desutom i varje ändpunkt måste du ha en lokal brandvägg och på applikationsnivå måste du utvärdera misslyckade inloggningar. Självfallet kan du aldrig använda användarnamn som "admin" och lösenord som "password" men även om du har ett säkert lösenord så kan man med obegränsade misslyckade försök på några minuter gissa rätt och komma in. Fördröjning vid misslyckad inloggning och blockering efter 3 eller max 5st misslyckade försök är ett minimum.