Unomaly efter införandet

Unomaly är på plats efter en lyckad PoC.
I dagsläget hivar 20 system in loggar i Unomaly som puttrar på och analyserar. Den har lärt sig hur vår miljö vanligtvis ser ut och jag brukar gå in en gång om dagen och se om något sticker ut, gränssnittet är föredömligt tydligt på den punkten.

Integration mot Nagios finns tyvärr inte i dagsläget men det ska tydligen komma, någon dag...

För de system där vi inte behöver analysera våra loggar har jag helt sonika tryckt upp en Synology NAS som bara tuggar i sig loggarna med inbyggda programvaran. Skulle någon efterfråga loggar kan man exportera dem från den och få ut dem i originalformatet och eventuellt då peta in i annat verktyg som förhoppningsvis lämpar sig bättre för analys av loggdata. Synologyn samlar alltså in det som det ska men det finns inget analysverktyg i lådan - något vi inte heller hade krav på.

NAS:en har 4 6TB-diskar och kommer lagra alla loggar vi slänger på den - åtminstone till jag går i pension. Skulle datamängden öka katastrofalt av någon aneldning kan man hänga på ett kabinett till med 4 diskar och fördubbla kapaciteten.

Vår logglösning blev alltså tudelad - loggar vi måste spara går in i Synology, loggar vi analyserar går in i Unomaly. Båda systemen är tacksamma, efter att man installerat dem behöver de sällan handpåläggning.

Om er verksamhet har krav på logghantering kan jag rekommendera den här lösningen.

Unomaly

Logghantering har seglat upp på agendan det senaste året. Vi har inte haft någon klar policy kring frågan, dels beroende på komplikationer om någon skulle begära ut datat med hjälp av offentlighetsprincipen och dels beroende på att organisationen inte varit mogen för logghantering. En del av det som samlas in i systemens loggar kan potentiellt vara integritetskränkande och behöver tvättas från persondata om det ska behållas t.ex.

Så loggandet har hållits till ett minimum, den enda loggen vi har riktigt bra kontroll över är i dagsläget är den i brandväggen och inte ens där sparar vi loggar särskilt länge - vi sparar givetvis statistik som vi drar ut från brandväggen men vi låter loggarna bara rulla och bli överskrivna.

Eftersom vi inte är bemannade för att analysera loggar är det egentligen "lönlöst" att samla in dem. Men eftersom verktygen för logghantering blir allt smartare och numera utlovar att analysera dem åt en tyckte vi det kunde vara värt att testa. Och valet föll på Unomaly som vi ska inleda pilotförsök med.

På papperet ser Unomaly ut som en magisk produkt: du skickar in vilka loggdata du vill, oavsett format varpå det analyseras, när liknande data dyker upp ska Unomaly sedan avgöra om det är "normalt" respektive "onormalt".
Unomaly integrerar även med vår övervakningsplattform Nagios så vi slipper att sitta och stirra på ett verktyg till. Om Unomaly upptäcker att något är fel larmar den helt enkelt till Nagios.

Ledtrådslöst

På jobb gör vi oss färdiga att upphandla nytt trådlöst nätverk.

Problemet (av i-landskaraktär) med trådlöst nuförtiden är att alla spelare är likvärdiga. Det finns ingen som riktigt sticker ut med någon killer feature. Man kan tycka att behoven då kan styra i högre grad när vi skriver kravspecifikation men i kommunernas värld stirrar man en hel del på kostnaden - och det är ju för all del inte helt fel. Men ibland stirrar man lite väl mycket på just den komponenten och glömmer bort det andra.

Vi kör Cisco idag och vi är väldigt, väldigt nöjda med driftsäkerheten. Vi vet att sätter vi upp en accesspunkt och den av någon anledning inte byts ut på 5 år så är det inget problem. De bara tuffar och går. Problem vi ser med Cisco är främst två: Ciscos managementverktyg kan få vem som helst att bryta ihop. Fult, otympligt och svårdechiffrerat. Och sen har vi priset. Vi har haft tre andra trådlösa aktörer hos oss som visat sina lösningar och gett prisindikation och hittills har bara en av dem kommit med en lösning som närmar sig hälften av vad Ciscos kostar.

Cisco är otvivelaktigt bra och de är odiskutabelt störst på trådlöst men när startfältet numera är så utjämnat som det är kan jag inte se att det längre är försvarbart att betala premium för dem.

Det hela tog en lite oväntad vändning när HP annonserade sitt uppköp av Aruba, hur det utvecklar sig återstår att se. Vi kör all trådad trafik på HP ProCurve idag så det finns definitivt fördelar med att välja HP (och i förlängningen Aruba).

Som vanligt när man upphandlar köper man grisen i säcken. Man kan skriva hur mycket kravspecifikation man vill, om någon svarar att de klarar av något måste man acceptera det - även om man vet att det inte är sant. Och ska man fokusera på annat än pris i en upphandling blir det ofta svårtolkat och vidöppet för överklagande. Förutom att man förstås inte vill jobba med någon som överklagar ens beslut fördröjer det upphandlingen och kan om det vill sig illa helt ta död på den om pengarna fryser inne över ett budgetår.

Men trådlöst, vi står i valet och kvalet och har en spännande tid framför oss.

Batteritid

Jag var i Sälen under sportlovet och provade samtidigt iPhone 6 Plus. Jag hade gått en vecka eller två och tyckt att iPhone 6 hade dålig batteritid och en av (få) fördelar med en gigantisk 6 Plus är att den har större batteri och längre batteritid.

Och det har den. Batteritiden är med iPhone-mått mätt riktigt, riktigt bra.

Men det gick inte. När jag kom tillbaka till jobb bytte jag tillbaka till min iPhone 6, Plus är helt enkelt för stor för mig. En värdefull läxa var också att efter en vecka med Plus tycker jag inte längre att mindre modellen är så gigantisk längre. Visst kan jag sakna den smidigare 5:an men världen spinner ju vidare oavsett om jag går och blir nostalgisk över den eller inte.


I kväll ska jag uppdatera brandväggen med en ny PAN-OS-version. En av de verkliga fördelarna med Palo Alto Networks är definitivt uppgraderingsproceduren. Väldigt straightforward.

Raspberry Pi-introduktion

Jag har blivit publicerad i Data3:s medlemstidning. På (första) sidan 21 hittas artikeln som introducerar till Raspberry Pi. Jag hoppas det blir den första av en rad artiklar i ämnet.

Och ja, pressläggningstiden gjorde att både Raspberry Pi 2 och nyheten att de sålt 5 miljoner maskiner hann komma ut under tiden. Men RPi2 är ju ett ämne jag förmodligen kommer ha mycket att säga om framöver.

Cisco trådlöst, autentiserade användare och PAN-OS

Efter att ha läst Palo Alto Networks egen Alberto Rivals presentation på lösning för att fånga upp autentiserade användare på Ciscos trådlösa controllers bestämde jag mig för att implementera den lösningen istället för den jag själv snickrat ihop.

Den jag själv snickrat ihop fungerade men led av en del allvarliga brister.

För den nya lösningen behöver man en Windowsserver med Kiwi Syslog Server (som numera ägs av Solarwinds). Man ställer helt sonika in Kiwi Syslog Server som SNMP trap-receiver i inställningarna (ingår inte i presentationen ovan men är bara en kryssruta att bocka i) och vidarebefodrar innehållet i syslog-format till Palo Alto-brandväggen. I brandväggen filtrerar man ut autentiserings-händelser och petar in användare och IP-adress på det sättet. Träffsäkerheten är mycket högre än min gamla lösning och nu kan man dessutom köra den mot de svagare Cisco 4400-kontrollerna som inte mäktade med att bli pollade på det gamla sättet.

En licens för Kiwi Syslog Server kostade oss i runda slängar 2700 kronor och arbetsinsatsen med presentationen ovan tillgänglig var minimal. Det tog mig mindre än en eftermiddag att få igång och verifiera det, från deployment av Windows 2012R2-server till fungerande lösning.

Jag kör fortfarande 6.0.x av PAN-OS och inte 6.1.x som i presentationen, men funktionaliteten är densamma.

Kort sagt, det här är en bättre lösning som fungerar även på äldre kontrollers. Rekommenderas.

Raspberry Pi 2, Geekbench 2

Geekbench 2.4.2 : http://www.primatelabs.com/geekbench/

System Information
  Operating System      Linux 3.18.5-v7+ armv7l
  Model                 N/A
  Motherboard           N/A
  Processor             ARM BCM2709 @ 900 MHz
                        1 Processor, 4 Threads
  Processor ID          ARM implementer 65 architecture 7 variant 0 part 3079 re
vision 5
  L1 Instruction Cache  0.00 B
  L1 Data Cache         0.00 B
  L2 Cache              0.00 B
  L3 Cache              0.00 B
  Memory                745 MB

Integer
  Blowfish
    single-threaded scalar    341 |
    multi-threaded scalar    1464 |||||
  Text Compress
    single-threaded scalar    419 |
    multi-threaded scalar    1147 ||||

  Text Decompress

    single-threaded scalar    304 |

    multi-threaded scalar     760 |||

  Image Compress

    single-threaded scalar    473 |

    multi-threaded scalar    1869 |||||||

  Image Decompress

    single-threaded scalar    361 |

    multi-threaded scalar    1449 |||||

  Lua

    single-threaded scalar    689 ||

    multi-threaded scalar    2751 |||||||||||

Floating Point

  Mandelbrot

    single-threaded scalar    324 |

    multi-threaded scalar    1317 |||||

  Dot Product

    single-threaded scalar    738 ||

    multi-threaded scalar    3127 ||||||||||||

  LU Decomposition

    single-threaded scalar    181 

    multi-threaded scalar     373 |

  Primality Test

    single-threaded scalar    864 |||

    multi-threaded scalar    1373 |||||

  Sharpen Image

    single-threaded scalar   1495 |||||

    multi-threaded scalar    6042 ||||||||||||||||||||||||

  Blur Image

    single-threaded scalar   1929 |||||||

    multi-threaded scalar    7793 |||||||||||||||||||||||||||||||

Memory

  Read Sequential

    single-threaded scalar    611 ||

  Write Sequential

    single-threaded scalar   1180 ||||

  Stdlib Allocate

    single-threaded scalar    438 |

  Stdlib Write

    single-threaded scalar    514 ||

  Stdlib Copy

    single-threaded scalar   1023 ||||

Stream

  Stream Copy

    single-threaded scalar   1245 ||||

  Stream Scale

    single-threaded scalar    562 ||

  Stream Add

    single-threaded scalar    349 |

  Stream Triad

    single-threaded scalar    324 |

Benchmark Summary

  Integer Score              1002 ||||

  Floating Point Score       2129 ||||||||

  Memory Score                753 |||

  Stream Score                620 ||

  Geekbench Score            1308 |||||

Av någon anledning kan jag inte ladda upp resultatet men de kanske slutat acceptera resultat från Geekbench 2, version 3 har ju funnits ute länge vid det här laget.

Men man kan ju ändå jämföra 1308 mot annat.

Och ja, jag skrev det här inlägget på en Raspberry Pi 2.

En knapp vecka senare - cache-uppdatering

Efter en initial ”cache-chock” rullar det på fint. Ska bli kul att kolla bandbreddsutnyttjande över tid i brandväggen.

Apelsinpaj

Jag lade till Orange Pi och Intel Galileo under Enkortsdatorer här till höger ------>
Jag har en Galileo på ingång men är lite kluven inför Orange Pi. Vi får se.

Ny hallonpaj

Raspberry Pi 2 modell B offentliggjordes idag. Mer när jag fått hem mitt ex.

Cache-tjänst

Apple App Store är den fjärde största bandbredds-slukande nätverkstrafiken på jobb.

Vi är mitt upp i en upphandling för internetuppkoppling för de närmaste fem åren men eftersom vi slår i kapacitetstaket varje dag kände jag mig tvungen att göra något.

Eftersom App Store-trafik är något som stadigt ökat och vi faktiskt har en OS X Server-stående i datahallen tänkte jag börja där.
OS X Servers Cache-tjänst är delvis en ersättare för den gamla Software Update-funktionen. Software Update fungerade bara med Mac OS X-uppdateringar och mekanismen bakom var (förmodligen) föråldrad eftersom Apple kommit med den nya Cache-tjänsten.

Numera är det inte bara OS X-uppdateringar som cachas utan även recovery-images för OS X, tankar du om en maskin med OS X 10.8 och framåt får du en cachad kopia på din server för efterkommande maskiner. Men det slutar inte där, följande innehåll från Apple cachas:
För iTunes och iBooks:
iTunes 11.04 och senare, iOS-appar och uppdateringar samt iBooks-innehåll.

För OS X:
Förutom uppdateringar och hela operativsystem lagras också uppdateringar för OS X-applikationer som köpts via Mac App Store, extra nedladdningsbart data till Garageband, Java, skrivardrivrutiner och annat innehåll som kommer via det gamla Software Updates-systemet.

För iOS:
iOS- och AppleTV-uppdateringar, appar och uppdateringar till dem, kursmaterial från iTunes U samt Siri-röster och ordböcker.

Det verkar också finnas plats för framtida utbyggnad av caching-systemet, det är förberett för musik och video från iTunes:

 caching:CacheDetails:_array_index:4:BytesUsed = 0  
 caching:CacheDetails:_array_index:4:LocalizedType = "Movies"  
 caching:CacheDetails:_array_index:4:MediaType = "Movies"  
 caching:CacheDetails:_array_index:4:Language = "en"  
 caching:CacheDetails:_array_index:5:BytesUsed = 0  
 caching:CacheDetails:_array_index:5:LocalizedType = "Music"  
 caching:CacheDetails:_array_index:5:MediaType = "Music"  

Så hur funkar det? När man installerat OS X (som ju numera är gratis) och OS X Server (189 kronor i App Store) och startar Server-appen är Caching det första anspråkslösa valet under Services.

De aktiva val man kan göra i senaste versionen består av att kunna starta/stoppa funktionen, hantera "rättigheter" och ange var och hur stor cachen ska vara.
Den enda inställningen som kan vålla bekymmer är egentligen Permissions. Härunder listar man de nätverk man vill ska ha åtkomst till cachetjänsten. Har man ett enkelt nät (som typ hemma) med en utsidesadress och en insida med privata adresser är det bara att slå på funktionen, det funkar out of the box.

Har man som vi tre utsidesadresser för att särskilja trafik från "allmänheten", elever och anställda blev det lite mer komplicerat.
Jag fick välja Cache content for clients connecting from "only some networks" och ange mina IP-ranges för de privata adresserna vi använder på insidan.
Kryssrutan "Only cache content for clients on these networks" är ikryssad, valet Serve clients with public addresses är satt till "on other networks" och jag har lagt till våra tre utgående adresser där.

Tyvärr slutar det inte riktigt där, unikt för mitt scenario är att jag fick ändra i vår core så att klienter från publika och pedagogiska näten kommer åt servern och sedan är man allmänt tvingad att lägga till ett TXT-record i sin DNS. Om man klickar på "Client Configuration" på panelen får man strängen som ska in i TXT-recordet. Det är dina utsidesadresser som ska in TXT-recordet.

Vi kör DNS på Windows så mitt DNS-record där ser ut som följer:

Cachen har rullat i snart 5 dygn och har redan plockat på sig över 25GB data och cacheträffarna blir fler och fler. Det ska bli spännande att följa upp bandbreddsanvändningen de närmaste veckorna.