Det här är inte roligt längre ☍
Hur mycket tid lägger du på att hålla ordning på ditt “digitala” liv? Hur många timmar i veckan sitter du och raderar spambrev, analyserar konstiga SMS, håller koll på dina lösenord, sätter upp två-faktorautentiseringar mot de tjänster du använder oftast, oroar dig för om du kan installera en viss applikation i din telefon eller dator och, givetvis, tar emot samtal från släkt och vänner som behöver din hjälp när de skickats till en webbsida som meddelat att deras dator har virus?
Massor, gissar jag.
Det här är inte roligt längre. Det är inte roligt när det datorföretag man haft störst förtroende för, i mitt fall Apple, inte ens klarar av att släppa nya versioner av sina operativsystem utan att ställa till det, det är verkligen inte kul att känna att man hela tiden är på gränsen att bli lurad av webbsajter och tjänster man investerat tid, pengar eller både-och i.
Ta exemplet Reddit. En webbsajt jag tillbringar en del tid på ibland. Det finns mycket kul att läsa där och man kan lära sig massor om man tar sig tid till det. En dag får jag ett meddelande att jag måste mata in en e-postadress som ska användas “i nödfall” så jag inte blir utelåst från Reddit om jag exempelvis glömmer mitt lösenord. Ett rimligt förslag, kan åtminstone jag tycka, så jag matade in min e-postadress.
Sen får jag se det ovanstående på Reddits hemsida. Syftet med att de vill ha min e-postadress blev just aningen mer tydligt – de vill maila mig i tid och otid för att driva mig tillbaka till Reddit så ofta som möjligt, för att på så sätt generera mer trafik och på så sätt visa fler annonser. Reddit kunde givetvis ha berättat det rakt ut, men då skulle ju i princip ingen mata in sin e-postadress.
Facebook har kört liknande manövrar genom åren – senast då de bad folk mata in sina mobiltelefonnummer för att kunna återställa sina konton om de blev utelåsta. Telefonnumrena skulle absolut inte användas till något annat, lovade Facebook. Det tog inte många veckor förrän folk började få SMS med meddelande om att de just nu missade en intressant diskussion på Facebook. Nu senast har Facebook meddelat att det är okej för politiker och deras partier att köra annonskampanjer med falskt innehåll – det finns många slutsatser man kan dra av detta men den slutsats jag själv landade i för två år sedan var enkel: jag raderar mitt Facebook-konto. Det finns ingenting på den plattformen som rättfärdigar hur man som användare på Facebook blir behandlad av företaget, och ju fler som inser det desto bättre.
Jag har bestämt mig för att flytta mitt webbsurfande till Firefox istället för kombinationen Safari / Chrome. Så jag reggade ett konto hos Firefox för att synkronisera lösenord mellan mina datorer. Det tog, givetvis, inte mer än två timmar så hade det första spambrevet landat i min brevlåda från Firefox…
En gång i tiden (ja, det är gammel-Jocke som talar här…) så var företag hyfsat öppna med vilka deras intentioner var. Numera är det i praktiken “helt ok” att luras, vilseföra och bluffa för att komma åt dig och så mycket information om dig som möjligt. Numera utlovas saker och sedan hålls de inte. “Vi tar din integritet på stort allvar” brukar det ju stå på var och varannan hemsida numera, men vad det egentligen betyder är det nog inte många som faktiskt tar reda på.
Det här är inte roligt längre. Det är okej att företag vill försöka tjäna pengar på mig, men det ska också vara okej för mig slippa det, men med Internet så är det uppenbarligen så att alla som använder Internet är fritt för andra att försöka utnyttja och lura så mycket de bara kan.
Har man inte ledsnat redan så kan man sätta sig och titta på alla de exploits som ständigt upptäcks i applikationer, operativsystem och produkter. Molntjänster läcker ständigt information om sina kunder, det hittas ständigt nya säkerhetshål i de applikationer du använder dagligen och vi har blivit immuna mot det, ungefär som att man rycker på axlarna åt att ännu en bomb exploderat i Malmö – det är vardagsmat.
Teknik är till för att hjälpa oss. Teknik är till för att våra liv ska bli lite enklare, inte för att vi ska bli slavar under den. Mina mål för den återstående delen av år 2019 är att genomföra en andra “digital detox”:
- Minska beroendet av Apples produkter. De bryr sig inte längre om kvalitet i sina produkter och det märks. Löften som inte hålls skapar stress och osäkerhet och det kan jag sannerligen leva utan.
- Hitta en ersättare till Macos. Linux eller Windows? Vet inte ännu – jag har gjort den här resan förut men det känns som att jag är bättre förberedd denna gång.
- Minska mängden molntjänster jag är beroende av. Dropbox, Google och Facebook är borta sedan länge. Det finns en och annan kvar att rensa bort och det ska bli skönt att få det gjort.
- Dra ner på hur mycket jag använder datorer och mobiltelefoner på fritiden. Det finns viktigare saker att göra än att sitta framför en dator hela tiden.
- Rensa ut gamla datorer och prylar. Av någon anledning hittar saker hem till mig hela tiden och nu är det dags att rensa igen.
Man skulle kunna hoppas att år 2020 inte bara blir året då amerikanerna sparkar ut Donald Trump ur Vita huset utan också att det blir året då folk sätter ner foten i större utsträckning och säger ifrån. Kasta ut Chrome från din dator och kör Firefox istället, välj dator och mobiltelefon som inte ständigt blir hackade eller är i riskzonen för att bli det och ge molntjänster, webbsajter och portaler långfingret när de har missbrukat ditt förtroende.
Som en Microsoft Exchange – fast gratis ☍
Man kan givetvis diskutera det lämpliga, eller olämpliga, i att köra en egen e-postserver. De allra flesta nöjer sig med att ha sin e-post på webbhotellet, eller i en molntjänst som iCloud eller hos Google. Det finns också de som är av åsikten att e-post är viktigt och något privat och därför ska man ha kontroll över den och då kan man väl utan omsvep konstatera att företag som Google faller bort tämligen omgående.
Hur som haver är det inte svårt att hitta en programvara att hantera sin e-post med. Det är heller inte svårt att hitta en programvara som gör det gratis. Vad som däremot kan vara lite knivigt är att hitta en e-postserver som är modern och trevlig att använda, inte enbart för dig som administratör utan också för de som faktiskt ska använda den i slutändan.. du vet… svärmor, dina barn och några kompisar. För det brukar bli så med tiden – man har en e-postserver och vips så har det flyttat in 20 personer med sin e-post på den.
Detta är inte en guide till hur du väljer e-postserver. Vissa går all in och bygger den från grunden på en Linux eller FreeBSD-server där varje inställning och justering görs för hand. Andra köper en programvara eller laddar ner ett gratis paket som ger dig hela tjolabaletten uppsatt och klart. Jag har valt att göra ett sorts mellanting mellan de två men det återkommer jag till senare. Detta är inte heller en guide till hur du håller skräppost borta från din e-postserver, för där kan jag varmt rekommendera att du antingen kör ett eget filter för ändamålet (det finns flera att välja mellan, jag rekommenderar helhjärtat EFA) eller så använder du en molntjänst som exempelvis Inumbo som drivs av vännerna på Halon Security.
Jag tänkte sätta igång och pensionera min gamla e-postserver. Den kör programvaran Kerio Connect, och det är egentligen inget fel på Kerio Connect i sig men min licens är från 2015, fortfarande helt laglig att köra, men det innebär också att jag kör en e-postserver från år 2015 som inte är patchad sedan år 2015. Anledningen till att jag aldrig förnyade licensen efter det året var enkelt: företaget som då ägde Kerio Connect gick över till en prenumerationsmodell för att stödja synkronisering av e-post via ActiveSync-protokollet. Stannade man kvar på den version jag kört fram tills idag så ingick det i licensen vilket sannolikt kostade Kerio, som bolaget då hette, ordentliga pengar i form av licensavgifter till Microsoft som i sin tur äger ActiveSync-protokollet. Den version av Kerio Connect jag kör vägrar dessutom låta sig installeras på något nyare än exempelvis CentOS 6.9, vilket är en version av CentOS som är ganska gammal. Kort sagt: det är läge att uppgradera.
Jag satte därför tänderna i Zimbra. Detta är en e-postplattform som har ett antal år på nacken, vilket dels märks i form av dess webbaserade administrationsgränssnitt som inte ens kan göra en mor glad, och dels för att hela klabbet är skrivet i Java. Jodå – du läste rätt: Java. Bortsett från det, och en del annat, så är Zimbra en ganska trevlig e-postplattform. Betalar man för sig får man tonvis med lull-lull som exempelvis nyss nämnda ActiveSync. Kör man gratisvarianten får man det inte.
Varför är då ActiveSync så viktigt? Framförallt handlar det om hur mobila klienter, både iOS och Android, ansluter sig till e-postservrar över Internet. Ska man stödja kalendersynk via Caldav, adressbokssynk via Carddav, IMAP och SMTP till klienter över internet innebär det ett antal portar som ska öppnas i en brandvägg och inte sällan kan det strula eftersom ett protokoll som IMAP gärna kan se lite annorlunda ut beroende på vem som programmerat servern i fråga. Det är som man brukar säga: det som är så bra med standarder är att det finns så många av dem.
ActiveSync löser allt detta. Anslutningen är krypterad över SSL och därmed är det en port, 443, som öppnas. Det är allt. Kalender, kontaktbok, anteckningar och givetvis e-post synkroniseras över detta protokoll och som sylt på pannkakan blir det också enklare för en slutanvändare att faktiskt ansluta sig.
Zimbra i sin gratisversion vill inte prata ActiveSync. Det är i sig inte så konstigt – det måste ju finnas flera goda anledningar till att betala för programvaran och de tjänster som kommer med en betald licens. Men om man inte, eller kan, eller ens måste så kan man få Zimbra att prata ActiveSync, och det är egentligen inte så fasligt svårt.
Installera och konfigurera
Jag förutsätter att du gjort det enda civiliserade valet och installerat Zimbra på CentOS. När detta skrivs har CentOS 7.7 precis landat, när du läser detta kan det vara CentOS 8 eller 9 som gäller. Oavsett vad finns det gott om guider om hur man installerar Zimbra på CentOS så hitta en sådan som är skriven så pass nära i tiden från när du läser den – en guide från 2015 innehåller garanterat saker och ting som inte fungerar längre.
Logga sedan in på din Zimbra-server och skriv följande som root:
wget -O z-push.tar.gz http://download.z-push.org/final/2.3/z-push-2.3.7.tar.gz
mkdir -p /var/www/z-push
tar cf z-push.tar.gz --strip-components=1 -C /var/www/z-push
Nu har du laddat ner och packat upp z-push och lagt filerna på rätt ställe.
Dags att installera Z-push backend för Zimbra så du får synkronisering av inte enbart e-post utan också kalender och adressbok:
wget -O zpushzimbra.tar.gz https://sourceforge.net/projects/zimbrabackend/files/latest/download
mkdir -p /var/www/z-push/backend/zimbra
tar xf zpushzimbra.tar.gz -C /var/www/z-push/backend/zimbra
Z-push är skrivet i PHP. Därför måste vi (tyvärr) installera PHP:
yum install -y php-pecl-memcached php-cli php-soap php-process php-mbstring php-fpm -y
När detta aningen obehagliga installationsmoment är ur vägen är det “bara” lite småsaker kvar. Först skapar vi lite kataloger:
mkdir -p /var/log/z-push /var/lib/z-push
chown apache: /var/log/z-push /var/lib/z-push
Nu börjar vi komma till den roliga delen: dags att konfigurera Z-push. Öppna /var/www/z-push/config.php med din favoriteditor och leta fram följande rad:
define('USE_X_FORWARDED_FOR_HEADER', false);
Ändra denna rad till:
define('USE_X_FORWARDED_FOR_HEADER', true);
Därefter ska vi redigera filen /var/www/z-push/backend/zimbra/config.php. Leta fram följande rad:
define('ZIMBRA_URL', 'https://YourZimbraInstallationURL.com');
Denna rad ska ändras till adressen till din Zimbra-server, och notera mycket noga vad du skriver här för det är helt avgörande om det ska fungera. Jag kommer strax till varför. I mitt fall ser raden ut såhär:
define('ZIMBRA_URL', 'https://mail01.fidonet.io');
Bara några ändringar kvar, och detta måste du göra som användaren zimbra. Öppna filen /opt/zimbra/conf/nginx/templates/nginx.conf.web.https.default.template och gör följande ändringar:
location ^~ /Microsoft-Server-ActiveSync
{
# Begin stray redirect hack
......
# End stray redirect hack
- # Proxy to Zimbra Upstream
- proxy_pass ${web.upstream.target};
- proxy_read_timeout ${web.upstream.polling.timeout};
- proxy_buffering off;
+ # Z-PUSH start
+ include /etc/nginx-php-fpm.conf;
+ # Z-PUSH end
# For audit
.......
}
Där det är ett minustecken till vänster ska raden raderas, plustecken ska raden läggas till.
Som root skapar du sedan filen /etc/nginx-php-fpm.conf med följande innehåll:
fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;
fastcgi_param REQUEST_URI $request_uri;
fastcgi_param DOCUMENT_URI $document_uri;
fastcgi_param DOCUMENT_ROOT $document_root;
fastcgi_param SERVER_PROTOCOL $server_protocol;
fastcgi_param GATEWAY_INTERFACE CGI/1.1;
fastcgi_param SERVER_SOFTWARE nginx/$nginx_version;
fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_PORT $remote_port;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_NAME $server_name;
fastcgi_param HTTPS $https;
# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param REDIRECT_STATUS 200;
fastcgi_param HTTP_PROXY "";
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME /var/www/z-push/index.php;
client_max_body_size 20m;
client_body_buffer_size 128k;
keepalive_timeout 65;
# max_execution_time is 900
proxy_read_timeout 910;
fastcgi_read_timeout 910;
sendfile on;
Därefter bygger du om Zimbras konfiguration:
sudo -u zimbra /opt/zimbra/bin/zmconfigdctl restart
Aktivera PHP-FPM:
systemctl enable php-fpm
systemctl start php-fpm
… och slutligen startar du om Zimbras proxy:
sudo -u zimbra /opt/zimbra/bin/zmproxyctl restart
Klart? Jodå. Minns du hur jag lite tidigare gav dig rådet att noga lägga på minnet vilken adress du angav till Zimbra-servern i filen /var/www/z-push/backend/zimbra/config.php? Om du lägger upp flera e-postdomäner i Zimbra, vilket är högst sannolikt att du gör, så är det oerhört viktigt att alla dessa kopplas till samma värdnamn
I mitt exempel ovan har jag skapat domänen fidonet.io och kopplar den till mail01.fidonet.io. Skapar jag en domän i Zimbra som heter melin.org måste även den i Zimbras domänkonfiguration i fältet Public service host name kopplas till det namn din Zimbra-server har, inget annat.
Nu kan du testa att koppla upp din iOS- eller Android-enhet mot din Zimbra-server genom att skapa ett nytt Exchange-konto i enheten. Du kan få mata in servernamn manuellt om du inte skapat DNS-records med autodiscovery och dylikt, och du behöver inte ange något på raden för domän när du skapar Exchange-kontot manuellt i iOS. Har du väldigt många brev i din brevlåda kommer din server att gå på knäna ganska omgående – jag har gett min Zimbra-server fyra processorkärnor och 16 gigabyte minne men när 3-4 stycken ActiveSync-klienter börjar hamra på servern och ska synkronisera sina brevlådor så kommer du snart märka att Zimbra med ActiveSync är som IT-världens Kakmonster och bara vill ha mer.. och mer…
Det var det hela. Lycka till!
ESXi 6.5 och UPS-hantering via NUT ☍
För galningar som jag som kör ett mindre datacenter hemma och dessutom bor på landet (med allt vad det innebär i form av ett elnät som både ger och tar…) kan det vara trevligt att ha batteribackuper till sina servrar och lagringsenheter, en så kallad UPS. Enligt alla former av gängse tradition och standard köper man givetvis UPS:er från APC när sånt ska göras och jag har tre stycken sådana kopplade till mina servrar. APC är trevliga eftersom de fungerar med i princip allt, från macOS till Linux och FreeBSD stödjer dem utan minsta bråk.
Det finns dock en plattform som är lite bråkig när det gäller att prata med UPS:er via USB-anslutning och det är VMware:s virtualiseringsplattform ESXi. Inte för att VMware är elaka på något sätt (åtminstone inte i detta avseende) men de tar sina grejer på allvar och därför anser de att man ska prata via sina UPS:er via nätverkskablage istället för USB. Lite underligt kanske med tanke på att du faktiskt kan tappa nätverket vid ett strömavbrott, men den diskussionen lämnar vi till ett annat tillfälle.
Det finns dock vägar runt detta. Systemet heter Network UPS Tools, NUT, och fungerar i praktiken som en brygga mellan dina UPS:er, som du ansluter till en dator (det kan vara en lagringsserver som kör FreeNAS eller en Raspberry Pi med Linux på, för att ta två exempel) via USB och sedan pratar andra enheter, exempelvis din brandvägg som kör PFSense, lagringsenhet som kör FreeNAS, valfri server som kör Windows eller Linux eller vad du vill, med denna NUT-server via en klientprogramvara. Känner NUT-servern av att din UPS körs på batterier kommer den tala om det för alla NUT-klienter som pratar med denna server och sedan kan de agera utifrån de inställningar du gett dem. I praktiken är detta det VMware vill göra med nätverksanslutna UPS:er men det går via en tredje part i form av en separat serverdator.
I mitt fall har jag valt att ansluta en av mina UPS:er till en av mina servrar som kör FreeNAS. På denna server har jag sedan konfigurerat upp en master för NUT. Detta finns väl dokumenterat så det är inget jag tänker gå in på närmare här (förutom att du inte ska glömma att ange LISTEN IP-adress-till-freenas-servern i fältet för Auxilary Parameters (upsd.conf)).
Nä, det roliga kommer när vi ska få igång detta på ESXi 6.5, som jag kör. Anledningen till att jag inte kör något nyare är dels för att mina servrar är till åren komna och inte stödjer något nyare, och dels gillar jag att ligga några versioner bakom för stabilitetens skull. Webbgränssnittet i ESXi 6.5 är så pass bra så det fungerar utan Flash eller nåt annat trams även i webbläsaren på en Mac eller i Linux vilket är uppskattat så jag har i praktiken ingen anledning att uppgradera till något nyare.
Det första man gör är att ladda ner programvaran för ESXi i form av klienten för NUT. Jag har lagt den på min server så du hittar den här. Som filnamnet antyder så är denna VIB, som insticksprogrammen för ESXi kallas, skriven för ESXi 5.0 men den fungerar utmärkt även med ESXi 6.5 med ett par förbehåll som jag återkommer till. Slå på SSH i din ESXi-server och sedan laddar du upp filen via SCP till /tmp. Packa upp med <br /> tar -xvzf NutClient-ESXi-2.1.0.tar.gz.
I paketet finns det ett script som installerar NUT-klienten, men det är saker du behöver göra innan du kör igång det.
Först och främst finns ett antal parametrar att mata in via esxcfg-advcfg-kommandot. Innan du gör det så måste du tala om för ESXi att du accepterar tredjepartsprogram med detta kommando:
esxcli software acceptance set --level=CommunitySupported
Därefter kan du sätta igång och skicka in följande kommandon:
esxcfg-advcfg -A NutUpsName -T string -E 'upsmon' -F [email protected]
esxcfg-advcfg -A NutUser -T string -E 'upsmon@stor05' -F upsmon
esxcfg-advcfg -A NutPassword -T string -E 'upsmon' -F upsmon
esxcfg-advcfg -A NutFinalDelay -T int -E '120' -N 0 -M 120 -F 60000
esxcfg-advcfg -A NutMailTo -T string -E 'ange-mail-adress' -F ange-mail-adress
esxcfg-advcfg -A NutSendMail -T int -E 'NUT send mail notification (1=yes 0=no)' -N 0 -M 1 -F 0
Dessa kommandon kan du givetvis också mata in i scriptet som du ska köra nedan om du ska göra denna installation på flera servrar.
Därefter kör du installationsscriptet:
sh upsmon-install.sh
Om du som jag gillar att spara på el så kanske du inte har några hårddiskar i din ESXi-server utan kör den från ett USB-minne. Det kan, givetvis, diskuteras hur smart detta är med tanke på att USB-minnen knappast har en obegränsad livslängd vid återkommande skrivningar men om man som jag skickar alla loggar till en Syslog-server och i praktiken aldrig skriver på USB-stickan så håller det ganska länge. I mitt fall var det dock en av mina ESXi-servrar som gav följande felmeddelande:
[root@vh02:/tmp] sh upsmon-install.sh
Installation Result
Message: WARNING: Only live system was updated, the change is not persistent.
Reboot Required: false
VIBs Installed: Margar_bootbank_upsmon_2.7.4-2.1.0
VIBs Removed:
VIBs Skipped:
```
Detta innebär i praktiken att det du "skrivit" till ditt USB-minne kommer vara borta vid nästa omstart. Dags att installera om med andra ord.
<img src="https://www.melin.org/assets/article_images/service.png" width="650px">
Om du däremot haft en lyckad installation av detta kommer tjänsten dels dyka upp som en tjänst i ESXi:s webbgränssnitt och dels, efter omstart, kan du också in och pilla på inställningarna för tjänsten under avancerade tjänster (System -> Advanced Settings) där du kan leta efter strängar som UserVars.Nut... så hittar du allt.
<img src="https://www.melin.org/assets/article_images/advanced.png" width="650px">
Vi är dock inte klara där.
<img src="https://www.melin.org/assets/article_images/nutserviceenable.png" width="650px">
Glöm inte att se till att NUT-tjänsten också startas när din ESXi-server startas.
Du behöver skapa filen <code>/etc/ups/upsmon.conf</code>. Denna ska skapas vid installation av tjänsten men det sker inte, inte heller katalogen <code>/etc/ups</code> skapas. Filen ser ut så här och skapas enklast med vi:
MONITOR [email protected] 1 upsmon upsmon slave
Syntaxen är alltså monitor upsnamn@upserver nummer på UPS (oftast 1), användarnamn, lösenord och att detta är en slav.
Om allt är som det ska kan du nu testa kommunikationen med UPS:en. Gå till katalogen <code>/opt/nut/bin</code> och kör <code>./upsc [email protected]</code>.
Fungerar allt kommer du få uppföljande:
[root@vh03:/opt/nut/bin] ./upsc [email protected]
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.mfr.date: 2006/11/11
battery.runtime: 540
battery.runtime.low: 120
battery.temperature: 38.7
battery.type: PbAc
battery.voltage: 27.1
battery.voltage.nominal: 24.0
device.mfr: American Power Conversion
device.model: Smart-UPS 1000
device.serial: AS0646123225
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: /dev/ugen1.3
driver.parameter.synchronous: no
driver.version: 2.7.4
driver.version.data: APC HID 0.96
driver.version.internal: 0.41
input.sensitivity: high
input.transfer.high: 253
input.transfer.low: 208
input.voltage: 236.1
output.current: 1.70
output.frequency: 50.0
output.voltage: 236.1
output.voltage.nominal: 230.0
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.firmware: 652.13.I
ups.firmware.aux: 7.3
ups.load: 48.7
ups.mfr: American Power Conversion
ups.mfr.date: 2006/11/11
ups.model: Smart-UPS 1000
ups.productid: 0002
ups.serial: AS0646123225
ups.status: OL
ups.test.result: No test initiated
ups.timer.reboot: -1
ups.timer.shutdown: -1
ups.timer.start: -1
ups.vendorid: 051d
Har du kommit så här långt så har du nu en fungerade UPS-lösning för ESXi 6.5. Glöm inte att faktiskt *testa* det hela också genom att helt sonika dra strömkabeln på UPS:en och kontrollera så allt stängs ner ordentligt.
Apple borde skämmas ☍
Efter att det i särklass värsta säkerhetshålet i iOS historia avslöjats har mer fokus lagts på hur det hanterats av de inblandande snarare än de som faktiskt drabbats av det. Tondövheten hos både Google och Apple är talande, men det är främst Apple som skämmer ut sig i den här affären.
Först kanske vi ska reda ut vad det hela egentligen handlar om. Ett allvarligt säkerhetshål som funnits i Apples operativsystem iOS från version 10 till och med 12 har gjort det möjligt för mindre trevliga aktörer att skjuta in skadlig kod i iOS-enhetens nyckelhanterare, Keychain, vilket i sin tur gjort det möjligt att avlyssna meddelanden och trafik till applikationer som exempelvis Whatsapp, Telegram, Imessage och lokaliseringsinformation – helt enkelt var den hackade enheten befann sig vid en viss tidpunkt. Attacken kunde injeceras i en iOS-enhet genom att besöka en webbsida där den skadliga koden trycktes in i enheten helt i tysthet.
Efter att Googles säkerhetsforskare i Project Zero rapporterat problemet till Apple, utan att offentliggöra uppgifterna vilket är kutym och god stil eftersom buggen ännu inte var fixad, kunde Apple åtgärda problemet i februari i år efter tio dagar. Gott så.
När Google i slutet på augusti publicerade all information om säkerhetsbuggen, vilket också är kutym eftersom säkerhetshålet då var fixat sedan ett halvår, kan man utan att överdriva säga det blev en aning infekterat mellan bolagen. Apple svarade via sin pr-sida med ett inlägg där de ömsom kritiserar Project Zero-rapporten och ömsom försöker avdramatisera hur allvarligt säkerhetshålet var. Extra tydligt var också det totala utelämnandet av vilka som låg bakom attacken och mot vilka det främst var riktad. Att Apple dessutom anser detta var en “smal” och “riktad” attack är så långt från sanningen man kan komma – den enda anledningen till att den inte drabbade fler var ju att den inte var allmänt känd, vilket också var varför det tog två år innan den upptäcktes.
I Googles rapport om buggen kan man nämligen lätt få intrycket av att det endast var iOS-användare som var måltavlan för denna typ av bugg. Det var det inte, och innan du funderar över hur det kan vara fallet eftersom buggen ju fanns i iOS så får vi ta lite mer bakgrund. Det har visat sig att det med största sannolikhet var den kinesiska säkerhetstjänsten som låg bakom attacken, som var riktad mot en folkgrupp kallad Uigurer som bland annat bor i Hunanprovinsen i södra Kina. Uigurerna är ofta muslimer och det kan vara en av anledningarna till att Kineserna förföljer denna folkgrupp och bland annat sätter dem i “utbildningsläger”.
Attacken mot Uigurerna var nämligen riktad mot Windows Phone, Android- och iOS-enheter, men det nämnde inte Google i sin rapport. Apple, å sin sida, försöker avdramatisera det hela med att uppge att det var ett “dussintal” webbsajter som låg bakom attacken och de nämner inte med ett enda ord vem eller vilka som låg bakom det hela, sannolikt för att inte riskera att stöta sig med Kinas regim där Apple sedan årtionden har förlagt i princip all montering av sina produkter.
Man kan givetvis fundera över Googles tajming. En vecka, drygt, innan Apple ska presentera nya konkurrerande produkter i form av nya iPhones valde de att släppa rapporten. Det efterföljande debaclet med den debatt som följde i media och där Apple gör allt de kan för att avdramatisera och ta udden av Googles avslöjande säger något om hur knivskarp konkurrensen är från båda håll – Apple är under enorm press och det syns.
Den här typen av säkerhetshål är värda stora pengar, och då pratar vi åtskilliga miljoner dollar, varför det inte är orimligt att anta att de som låg bakom attacken sparade på den tills de hade ett tillräckligt saftigt mål att använda det på. Kineserna, om det nu var de som låg bakom detta, kunde enkelt ha köpt en annonsplats på en större webbsajt i exempelvis USA och skyfflat ut attacken via skadlig kod imbäddad i annonsen och kunnat ta sig in i betydligt fler iOS-enheter än de faktiskt gjorde, men det blev inte så och det ska vi vara glada för.
Det ska också nämnas att bland alla de källor som nämns i Apples buggfixningsrapporter är Project Zero ofta källa till att hjälpa Apple göra sina produkter säkrare. Project Zero finansieras helt av Google och har rapporterat in hundratals allvarliga säkerhetshål till Apple som annars kunde ha orsakat enorma problem för Apples kunder.
Apple visade ingen större tacksamhet för detta när de gav sig på rapporten om detta säkerhetshål utan uppför sig som Apple fortfarande, tyvärr, gör i sina sämsta stunder när de blir trängda – att de känner en enorm press inför lanseringen av nya iPhone-modeller råder det givetvis ingen tvekan om med tanke på hur försäljningen går stadigt nedåt men någon jäkla stil måste man ändå ha. Apple borde skämmas.
Haproxy med Let’s Encrypt ☍
Det kan verka som voodoo att få vissa saker att fungera men genom att mecka, mecka och mecka lite till har jag fått fram en fungerande modell för hur man får Let’s Encrypt att fungera med Haproxy. Värt att notera är att jag baserar denna guide på Haproxy v2.0.5 kompilerad på CentOS 7.6.1810. Det finns saker jag gör i min konfigurationsfil som kommer tas bort i framtida versioner av Haproxy (i synnerhet användandet av ‘reqadd’) så det kommer jag behöva skriva om, men det är då det.
Det första du gör är, givetvis, att installera Haproxy. Hur din konfiguration ser ut varierar givetvis från fall till fall men det finns ett par saker du kan ha med som gör livet lite enklare. Som jag sa så har jag kompilerat upp Haproxy på CentOS 7 från källkoden. Jag använde följande parametrar för det för att få in stöd för SystemD och lite annat:
make -j 4 TARGET=linux-glibc USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1 USE_CRYPT_H=1 USE_LIBCRYPT=1 USE_SYSTEMD=1
I övrigt finns det guider för hur du gör installationen på bästa sätt med CentOS 7, och det är varmt rekommenderat att göra installationen från källkod då den version som finns i CentOS 7-repot är gammal som gatan och saknar stöd för en hel del roliga saker, exempelvis stöd för http/2 vilket kom i version 1.8 av Haproxy, vilket är trevligt i kombination med SSL.
Väl att notera är också att Haproxy gärna vill använda /var/run/haproxy/ när den startar för sin socket. Det går givetvis att ändra i /etc/haproxy/haproxy.cfg om man vill det men som standard kan denna inställning finnas i konfigurationsfilen.
Under inställningarna för global kan du lägga in inställningarna för hur SSL-certen ska hanteras av Haproxy. Mina ser ut så här:
tune.ssl.default-dh-param 4096
ssl-default-bind-ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AE
S128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-
DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
ssl-default-bind-options no-sslv3 no-tls-tickets
ssl-default-server-ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-
AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDS
A-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
ssl-default-server-options no-sslv3 no-tls-tickets
Genom att använda ACL:er kan du göra redirects redan i Haproxy för att skicka trafiken från http till https.
Under avsnittet för frontend sätter du följande (hämtat från min egna konfiguration):
acl is\_joacimmelin hdr\_end(host) -i www.melin.org
acl is\_joacimmelin hdr\_end(host) -i melin.org
Därefter lägger du in följande i samma kodavsnitt:
redirect scheme https if { hdr(Host) -i www.melin.org } !{ ssl_fc }
redirect scheme https if { hdr(Host) -i melin.org } !{ ssl_fc }
Vill du ändå tillåta både http och https-trafik kan du lägga in följande i samma kodavsnitt:
use\_backend nginx if is\_joacimmelin
Namnet "nginx" är namnet på min backend där alla webbservrarna ligger inlagda. Du kan givetvis döpa den till vad du vill.
Nu kommer vi till det lite knepigare avsnittet, frontend för https.
Jag börjar det så här:
frontend https_front
compression algo gzip
compression type text/html text/plain text/javascript application/javascript application/xml text/css
bind *:443 ssl crt-list /etc/ssl/crt-list.txt alpn h2,http/1.1
reqadd X-Forwarded-Proto:\ https
acl is\_joacimmelin hdr\_end(host) -i www.melin.org
acl is\_joacimmelin hdr\_end(host) -i melin.org
use\_backend nginx if is\_joacimmelin
Den kanske viktigaste raden av den alla är rad fyra där vi binder en fil som heter <code>/etc/ssl/crt-list.txt till ssl-hanteringen i Haproxy. Där finns för övrigt också en parameter som heter h2 som slår på http/2, vilket varmt rekommenderas.
Certifikathantering i Let’s Encrypt
Filen jag nämnde ovan (crt-list.txt) ser i mitt fall ut så här:
/etc/letsencrypt/live/melin.org/melin.org
Sökvägen till filen är väl ganska tydlig, men filnamnet (melin.org)? För att detta ska fungera måste man göra ett kombinerat cert av de filer man får från Let’s Encrypt och det gör man på detta sätt:
DOMAIN='melin.org' bash -c 'cat /etc/letsencrypt/live/$DOMAIN/fullchain.pem /etc/letsencrypt/live/$DOMAIN/privkey.pem > /etc/letsencrypt/live/$DOMAIN/melin.org'
I filen /etc/ssl/crt-list.txt kan jag sedan lista hur många certifikat jag vill för hur många domäner eller subdomäner jag vill och Haproxy kommer kolla i filen varje gång när den https-request ska hanteras och därmed skyffla över certifikatet och ladda sidan. Eftersom jag terminerar certifikatet i Haproxy kan jag skicka webbtrafiken bakåt till backend över port 80 och förutom att WordPress behöver lite smisk för att det ska fungera (löses enklast i form av en plugin, givetvis…) så är det riktigt smidigt att bygga sin webbplattform på detta sätt.
Eftersom man skapar sina certifikat med Let's Encrypt och certbot på Haproxy-maskinen kan man hantera den biten på lite olika sätt. Det enklaste, men kanske inte snyggaste, är att lägga in ett script i Crontab som var tredje-femte dag eller så helt sonika stoppar Haproxy, exekvererar Certbots renew-funktion, sedan kör man sammanslagningen av certifikatfilerna till ett kombinerat cert (som jag visade tidigare) och slutligen startar man Haproxy igen. Ungefär så här kan det se ut:
# !/bin/bash
systemctl stop haproxy
/usr/bin/certbot renew –standalone
DOMAIN='melin.org' bash -c 'cat /etc/letsencrypt/live/$DOMAIN/fullchain.pem /etc/letsencrypt/live/$DOMAIN/privkey.pem > /etc/letsencrypt/live/$DOMAIN/melin.org'
systemctl start haproxy
Lycka till!
