torsdag 24 april 2014

TFTPD

Jag har under en längre tid använt mig av Solarwinds "gratis" TFTPD, men har egentligen aldrig tyckt att den känts helt hundra. Jag kan inte riktigt sätta fingret på varför men det har gått så långt att jag sett mig om efter alternativ.

Och en google-sökning senare hittade jag TFTPD32, en enkel, fri TFTPD-server för Windows som namnet till trots finns i både 32-bitars och 64-bitars versioner.

Jag har precis hårdkört den i och med att jag uppgraderat certifikatet på alla våra controllers för trådlöst nätverk och den har fungerat klockrent.

tisdag 22 april 2014

MobaXterm

När allt man har är en hammare ser alla problem ut som en spik har någon som är klokare än mig sagt.

Alla som använder Windows och behöver tillgång till telnet, SSH och/eller seriekommunikation brukar använda sig av det utmärkta verktyget Putty. Putty är väl beprövad, fungerar alltid och är en utmärkt arbetshäst för allehanda saker man kan tänkas göra.

Den saknar dock en komponent som i de allra flesta fall är oviktig men när man väl behöver den, ja, då behöver man den: X11. MobaXterm fyller den nischen väl. Den fungerar precis som man tror, du behöver bara logga på ett system med SSH så tunnlar den automagiskt X11. Den har inbyggd window manager som får X11 att se ut ungefär som Windows-program och har i övrigt samma egenskaper som Putty: den bara fungerar.

Precis som Putty är den gratis men om man vill ha support kan man köpa en licens. Licensen är inte heller speciellt dyr (€50 i dagsläget), jag har faktiskt inte hittat någon kommersiell X11-server för Windows som är billigare.

Det finns ju också fria X11-servrar till Windows men de brukar vara väldigt meckiga att få igång (eller var det för något år sedan när jag genast gick igenom dem). Se t.ex. Xming eller Cygwin/X.

Om du behöver X11 på Windows och vill ha något som bara fungerar kan jag varmt rekommendera MobaXterm.

onsdag 16 april 2014

Ubiquiti

Om du är en avancerad hemanvändare som gillar att knappa på saker kan Ubiquitis produkter kanske passa.

Jag har deras EdgeRouter Lite, en billig men väldigt kapabel router med inbyggd brandvägg vars kodbas rör sig snabbt. Den får hela tiden snyggare gränssnitt och mer funktionalitet.



I kombination med deras UniFi-accesspunkt täcker det alla mina nätverksbehov hemma.


Ubiquiti ger support via sitt communityforum och är fortfarande så pass små att deras programmerare verkligen hänger på forumet. De tar emot förslag på nya features och rättar buggar med riktigt bra fart.

Deras produkter, framförallt EdgeRouter, är ingenting för nybörjare. Det gäller att ha tungan rätt i mun och ha bra koll på TCP/IP innan man konfigurerar. Men har man grunderna kommer man långt.

Dustin har produkterna i Sverige om du känner dig sugen.

tisdag 15 april 2014

Eftersläntare

Saker som föll av radarn i mitt förra inlägg:
Roku 2 XS, med inbyggt stöd för såväl Netflix som Plex var det ett enkelt val.
Sedan jag skaffade den har jag rekommenderat den vitt och brett men jag har hört rapporter på sistone att Netflix inte går att installera på den om man kommer från en svensk IP-adress. Det går ju att komma runt men det är ju irriterande.
Om någon ny AppleTV dyker upp med stöd för Plex kommer jag förmodligen byta, annars inte.

En Mac mini server är också inkopplad i TVn, ibland finns det innehåll som bara en dator kan spela upp. Den börjar dock bli till åren och en uppgradering borde göras inom ett till två år. Ena hårddisken i den är utbytt (på garanti) den andra dog efter garantitiden men jag har inte orkat byta den. Slutsats, köp en ny Mac mini med SSD, inte hårddisk.

Jag antar att jag missade dem eftersom dem är så självklara.

måndag 14 april 2014

Utrustning

Inlägget där jag försöker sammanfatta allt på (och av) nätverket här hemma.


All trafik som ska in och ut från mitt nätverk kommer passera en Ubiquiti EdgeRouter Lite. En kraftfull men billig router för trådat nätverk. Försöker man komma åt min websajt kommer man också behöva passera en Palo Alto Networks PA-200. Inte fullt så billig men ack så kraftfull.

Trafik som ska in eller ut passerar också minst en och ibland två HP ProCurve. Min distributionsswitch är en 1810G-24 och jag har en 2510-24 och en 2610-24 bakom den.

Jag har VMware ESXi rullande på en HP ProLiant microserver N54L, den kör i dagsläget fyra virtuella maskiner, två linux-baserade och två Windows-baserade. Här har jag bland annat min vanliga websajt och min interna DNS.

Jag har en fysisk maskin med Core2Quad som kör Plex Server som står för utdelning av media både till mig, familj och vänner.  Filer ligger i sin tur på en NAS från Synology, 1812+.

Den vanligaste klienten här hemma är en iPad, alla i familjen har varsin men alla har olika modeller, iPad 4( frugan), iPad mini (min son) och iPad mini med retina (jag). Då och då syns även iPhones, Macbook Air, Thinkpad X61s, Wii U, en blurayspelare och diverse Android-enheter.

Det trådlösa kommer, även det, från Ubiquiti och är i dagsläget en UniFi. Det är alltså en dedikerad accesspunkt utan andra uppgifter.

Bland de mer exotiska grejorna på nätet är en HWg-STE som mäter temperaturen i mitt rack, en AdTrap som tvättar annonser för enheter som saknar Adblock, en Cubieboard 1, en Cubieboard 2 och några Raspberry Pi.

Saker jag har men som ännu inte är riktigt igång eller av andra skäl är avstängda: Wandboard Dual, Cubietruck, Beaglebone Black, Sun Ultra 10 (SPARC), HP c3750 (PA-RISC) och förmodligen någon grej jag glömt. :)

Pust, pes.

Heartbleed och en uppdatering om Smokeping

Nu är man allt lite orolig för all it-utrustning man har.


Här är Ciscos lista över produkter som påverkas/testas av buggen. Vi kör som bekant deras trådlösa lösning.
För trådat nätverk använder vi HP Procurve, här är deras lista.
Palo Alto Networks uttalande, de är inte påverkade. Detsamma gäller vår utgående Clavisterbrandvägg.
Microsoft friskriver IIS.

Och du, byt lösenord efterhand som sajterna begär det. Innan de patchat är det ingen ide.

Det visade sig att problemet med Smokeping jag stötte på är en känd bugg, i buggrapporten finns en smidig workaround som funkar.

fredag 11 april 2014

Två steg fram, ett steg bak

Jag installerade upp en ny Linux-kärra för att köra mitt script som puttar in användar-id från Cisco's WLC till Palo Alto Networks brandvägg. När jag kopierade över scriptet fungerade det helt plötsligt inte. Suck.

Jag hade glömt installera MIB:arna till SNMP, efter det var gjort funkade det igen. Nu kör jag scriptet var femte minut via cron.


Jag använder samma maskin för att köra MRTG mot vår core samt distributionsswitchar och, naturligtvis, Palo Alto:n.

Och allt det funkar bra.

Jag tänkte även använda maskinen för att köra Smokeping men efter installation stötte jag på patrull. Först vägrade Apache köra CGI, det var snabbt fixat med a2enmod men efter det renderar den Smokepingsidan utan bilder. Frustrerande nog räckte tiden inte till för att fixa till det felet idag så det blir till att jaga det igen på måndag.

torsdag 10 april 2014

PA-200

Jag fick ytterligare en brandvägg från Palo Alto Networks i morse: PA-200.

Det är den minsta brandväggen dem gör men hela deras sortiment från den här lilla saken till monstret som är PA-7050 använder samma programvara. PA-200 är naturligtvis långsammare men har i övrigt samma funktionalitet som vilken brandvägg som helst från Palo Alto Networks.


Jag har köpt in dem för att vi ska köra IPv6-trafik igenom dem. Men det projektet är en bit in i framtiden, under tiden använder jag den för att bli mer familjär med gränssnittet. Rakt ur lådan är den konfigurerad med två gränssnitt som "virtual wire" med trust- och untrust-sidor. Den agerar alltså som en transparent brandvägg direkt. Så jag har kopplat in den just så på min webserver här hemma, dels ger det mig gott om tid att utforska den och dels får den riktig trafik (iofs IPv4) att jobba med. Åtminstone till IPv6 rullar igång senare i år.

Cisco, Palo Alto Networks och användar-id: lösningen

Jag har haft lite strul med att plocka ut användar-id från Cisco Wireless LAN Controllers och mata in det i Palo Alto Networks brandvägg.

Jag har dock knäckt det.

Det script jag använde har jag modifierat till följande:
--------- SNIP! ---------
#!/bin/bash
snmp_community="public"
snmp_host="1.1.1.1"
rm -f /tmp/wlc.txt
IFS=$'\n'
while [ "1" -ne "2" ]
do
 Unique_OID=($(snmpwalk -v 2c -O x -c $snmp_community $snmp_host 1.3.6.1.4.1.14179.2.1.4.1.1))
 Client_IP=($(snmpwalk -v 2c -c $snmp_community $snmp_host 1.3.6.1.4.1.14179.2.1.4.1.2))
 Client_Username=($(snmpwalk -v 2c -c $snmp_community $snmp_host 1.3.6.1.4.1.14179.2.1.4.1.3))
 count1=${#Unique_OID[@]}
 count2=${#Client_IP[@]}
 count3=${#Client_Username[@]}
 if [ "$count1" -eq "$count2" ]; then
                  if [ "$count2" -eq "$count3" ]; then
                                                                  break
         fi
 fi
done
wait
index=0
while [ "$index" -lt "$count1" ]
      do  
          id=$(echo ${Unique_OID[$index]} | cut -d "=" -f1 | awk -F "." '{print $8 "."$9 "." $10 "." $11 "." $12 "." $13 }')
          cIP=$(echo ${Client_IP[$index]} | grep $id | awk -F " " '{print $4}')
          cUser=$(echo ${Client_Username[$index]} | grep $id | awk -F " " '{print $4}' | sed s/\"//g)
          if [[ $cUser = TEST* ]] || [[ $cUser != "" ]] && [[ $cUser != host* ]] && [[ $cIP != "0.0.0.0" ]]; then
                if [[ $cUser = TEST* ]]; then                        
                    echo "SYSTEM=CISCO IP="$cIP "USER="$cUser >> /tmp/wlc.txt
                else                        
                    echo "SYSTEM=CISCO IP="$cIP "USER=TEST\\\\"$cUser >> /tmp/wlc.txt
                fi
          fi
     ((index++))
     done
logger -d -f /tmp/wlc.txt -n 172.17.1.101 -P 514
--------- SNIP! ---------

Det var väl inte så svårt?
Det jag gör är alltså att skapa en fil med innehållet Etikett (SYSTEM=CISCO), IP= (själva adressen) och USER= (användarnamnet), de två sistnämnda drar jag ut via SNMPWalk från WLC:n.
Problemet med att vissa användare inte dök upp var för att de inte hade vårt domännamn som prefix och brandväggen därför inte kunde slå upp dem via Active Directory. Så för dem användarnamn som saknar domännamn skjuter jag helt enkelt in det framför deras namn och skriver ner dem i filen.

Scriptet är testat och fungerar på Ciscos 5508. Det fungerar dock högst sporadiskt på Ciscos 4xxx men de börjar bli så gamla att de börjar fasas ut (vi gör det).

På Palo Alto:n ska du in under Device -> User Identification -> User Mapping -> Palo Alto Networks User ID Agent Setup (Klicka på kugghjulet (Edit)). I dialogen som kommer upp ska du till Syslog Filters. Där skapar du ett nytt filter enligt nedan:


Du är inte riktigt färdig ännu. Du ska också in under Device -> User Identification -> User Mapping -> Server Monitoring, klicka på Add.
Lägg till en ny enligt följande:

Märk väl att ditt filter heter Test om du följt mitt exempel enligt ovan istället för, som i mitt fall, LS-ID.
Glöm inte att köra en commit på dina ändringar. Sätt scriptet att köra med lämpligt intervall via cron och njut av att se när du kan identifiera de trådlösa användarna i din brandvägg.

Och ja, man kunde lika gärna tagit bort domännamnet i filen man genererar och skjuta in den i fältet Default Domain name i sista dialogen.

Verifierat och fungerar med PAN-OS 6.0.1.

onsdag 9 april 2014

Bra minne, men kort

För de som ännu inte memorerat hur man skriver ut en avbild på ett SD-kort från kommandoraden i Mac OS X finns PiWriter, något jag helt missat tills nu. Det är en grafisk, lätthanterad variant som naturligtvis kan skriva ut vilka SD-avbildningar som helst, inte bara dem som är gjorda för Raspberry Pi.


Som till exempel Volumio för Udoo.

tisdag 8 april 2014

Skicka SMS från en Raspberry Pi med en 3G-dongle

Genom att söka lite på Google kom jag snabbt fram till att gammu är rätt programvara, den finns i Raspberry Pi's repo så det är bara att installera som vanligt (sudo apt-get install gammu).


Jag råkade ha en 3G-dongle från Huawei liggande av modell E220.
Jag skapade filen /etc/gammurc med följande innehåll:
[gammu]
port = /dev/ttyUSB0
connection = at19200
startinfo = no
name = Huawei
synchronizetime = no
use_locking = no

Om man sedan kör kommandot:
gammu --identify
får man något som liknar:
Device               : /dev/ttyUSB0
Manufacturer         : Huawei
Model                : E220 (E220)
Firmware             : 11.117.09.00.00
IMEI                 : "nummer"
SIM IMSI             : "nummer"


Om du inte får ut något kan donglen sitta som en annan device kolla med:
dmesg|grep tty

Om din dongle stöds får du ut en rad som liknar den här:
[    0.000000] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708.boardrev=0xe bcm2708.serial=0x3e0ecc12 smsc95xx.macaddr=B8:27:EB:0E:CC:12 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
[    0.000000] console [tty1] enabled
[    0.530022] dev:f1: ttyAMA0 at MMIO 0x20201000 (irq = 83) is a PL011 rev3
[    0.872154] console [ttyAMA0] enabled
[    7.269799] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB0

Om ovan funkar kan sedan, till exempel, skicka meddelanden från Nagios.
Här är mina kommandodefinitioner till Nagios:
define command{
        command_name    host-notify-by-sms
        command_line    /usr/bin/printf "%b" "KATASTROF / Host: "$HOSTNAME$" / State: $HOSTSTATE$ / Info:$HOSTOUTPUT$ / Date:$SHORTDATETIME$" | /usr/bin/gammu --sendsms TEXT $CONTACTPAGER$
        }

define command{
        command_name    notify-by-sms
        command_line    /usr/bin/printf "%b" "KATASTROF / Host: "$HOSTALIAS$" / State: $SERVICESTATE$ / Info:$SERVICEOUTPUT$ / Date:$SHORTDATETIME$" | /usr/bin/gammu --sendsms TEXT $CONTACTPAGER$
        }

Alla variabler är interna för Nagios och just $CONTACTPAGERS$ är variabeln som innehåller telefonnummer att skicka SMS till. Den definieras i din contacts-fil i Nagios och det är även i den filen du lägger till de två raderna som ser till att du får SMS om något händer:
        service_notification_commands   notify-by-sms
        host_notification_commands      host-notify-by-sms

En Raspberry Pi med Nagios, en 3G-dongle och en UPiS är en kraftfull kombination som överlever strömbortfall i bortåt 4 timmar på det inbyggda batteriet och därmed har gott om tid att ge dig en heads-up att något är allvarligt fel.

Och ja, det är samma procedur om du hänger donglen på en Ubuntu/Debian som körs på en vanlig PC.

måndag 7 april 2014

Palo Alto Networks och Nagios, igen

Om du har Nagios och en brandvägg från Palo Alo Networks och vill övervaka din brandvägg knäpper du på SNMP på brandväggen och skapar kommandodefinitioner enligt följande:
define command {
        command_name    chk_sess
        command_line    /usr/lib/nagios/plugins/check_snmp -H $HOSTADDRESS$ -C public -o 1.3.6.1.4.1.25461.2.1.2.3.3.0 -P 2c
}

define command {
        command_name    chk_cpu_mgmt
        command_line    /usr/lib/nagios/plugins/check_snmp -H $HOSTADDRESS$ -C public -o .1.3.6.1.2.1.25.3.3.1.2.1 -P 2c -w 80 -c 95
}

define command {
        command_name    chk_cpu_data
        command_line    /usr/lib/nagios/plugins/check_snmp -H $HOSTADDRESS$ -C public -o .1.3.6.1.2.1.25.3.3.1.2.2 -P 2c -w 80 -c 95
}

Då har du kommando för att övervaka antalet sessioner som går genom brandväggen, CPU:n på Managementsidan samt CPU:n på data-sidan (där själva magin händer). Istället för public ovan (som ju är default för den mesta nätverksutrustningen) använder du ditt eget community-namn naturligtvis. I de två sista definitionerna får jag en varning (w) när CPU:n når 80% användningsgrad och ett kritiskt (c) larm vid 95%:s användning. Riktigt vad jag förväntas göra om brandväggen skulle nå den belastningen vet jag väl i nuläget inte.

Service-definitionen i Nagios ser ut såhär för mig:
define service{
        use                     generic-service
        host_name               PAN1,PAN2
        service_description     Active sessions
        action_url            /pnp4nagios/index.php/graph?host=$HOSTNAME$&srv=$SERVICEDESC$
        check_command           chk_sess
        }

define service{
        use                     generic-service
        host_name               PAN1,PAN2
        service_description     CPU Management
        action_url            /pnp4nagios/index.php/graph?host=$HOSTNAME$&srv=$SERVICEDESC$
        check_command           chk_cpu_mgmt
        }

define service{
        use                     generic-service
        host_name               PAN1,PAN2
        service_description     CPU Data
        action_url            /pnp4nagios/index.php/graph?host=$HOSTNAME$&srv=$SERVICEDESC$
        check_command           chk_cpu_data
        }


Som synes gör jag fina grafer i PNP4Nagios av det data som plockas ut. Men så enkelt är det alltså.

lördag 5 april 2014

Monitorering och (gratis) larm i Nagios

På jobb har jag två huvudsakliga sätt att skicka larm när något går snett i vår miljö: e-post och SMS.

Redan från start är e-post-larm konfigurerade i Nagios, så där behöver man inte lägga ner någon möda, SMS-larm är inte heller speciellt svårt att få till. På den virtuella maskinen med Nagios skickar jag ut SMS via en web-sida via en URL jag bygger utifrån Nagios larm. På Raspberry Pi-maskinen har jag en 3G-dongle och direkt åtkomst till telenätet och gör det den vägen.

Men SMS gör att man måste ha ett abonnemang och betala för så för min hemmiljö letade jag gratisalternativ och hittade ett i Pushover. Man registrerar sig på sajten och skaffar appen för sin telefon och/eller platta. Man får unika nycklar när man registrerar sig på Pushover och man använder dem i Nagios för att skicka meddelanden.


Kommando-definitionerna jag använder ser ut så här:
# 'pushover notification' command definition
define command {
        command_name    host-notify-by-pushover
        command_line    /usr/lib/nagios/plugins/notify_by_pushover.sh -u DinPushoverAnvändarnyckel -a DinPushoverApplikationsnyckel -t "Nagios" -m "$HOSTNAME$:$HOSTSTATE$"
}
define command {
        command_name    service-notify-by-pushover
        command_line    /usr/lib/nagios/plugins/notify_by_pushover.sh -u DinPushoverAnvändarnyckel -a DinPushoverApplikationsnyckel -t "Nagios" -m "$HOSTNAME$ - $SERVICEDESC$ : $SERVICESTATE$. Additional info: $SERVICEOUTPUT$"
}

Scriptet som utför magin hittade jag hos jedda.me som definitivt är läsvärd om man håller på med Mac OS X och/eller Nagios.

torsdag 3 april 2014

Cisco trådlöst nätverk med controller och Palo Alto Networks

Som jag tidigare nämnt fungerar User-ID med Palo Alto Networks brandvägg riktigt bra. Det förutsätter att man har en källa att hämta informationen ifrån, självklart, och på det trådade nätet är den källan självklart Active Directory.



På ett trådlöst nät med controller som autentiserar via Raduis-server mot AD finns det bara en källa som kopplar ihop användaren med IP-adressen: controllern.

Eftersom vi har Cisco slog jag på syslog på controllern och började kolla på vad den gav ifrån sig genom att mata in trafiken i Splunk. Det visade sig snart att autentiseringsmeddelanden inte loggas till syslog på en Cisco-controller. Istället skickar den SNMP-traps med den informationen, alternativt kan man polla ut informationen via SNMP.

Lyckligtvis kan den här informationen behövas i fler sammanhang så någon hade redan knåpat ihop ett bash-script som plockar ut den. Jag redigerade till det så det fungerade mot vår controller och vips hade jag informationen i en text-fil. Allt jag behövde göra var sända textfilen som syslog-meddelande till brandväggen.

Det finns ett kommando i Linux för det, logger, men just den versionen som följer med Ubuntu har en bugg som gör att den inte skickar meddelandena till en extern server. Eftersom jag varken kände för att kompilera en ny logger eller ge upp letade jag upp en nyare version av util-linux där logger följer med, extraherade den och ersatte den på mitt system. Det funkade fint.

Men, för det finns alltid ett men... Nu hade jag en fin kedja, ett bash-script jag kan köra via cron som plockar ut den information jag vill ha, skriver den till en fil och skickar över till brandväggen med logger. Och det funkade fint på vår nya controller. Vi har dock 7 controllers, varav bara en i dagsläget är ny. På den nya controllern där jag först testade att köra bash-scriptet plockade den ut informationen på strax över 2 sekunder.

På de gamla controllerna tog det evinnerlig tid. Så lång tid att jag trodde scriptet hängt sig och började debugga, till slut insåg jag att informationen från de gamla controllerna snudd på aldrig går jämnt upp, något scriptet måste uppnå för att bearbeta den data det tar emot. Det slutade med att jag körde scriptet med time när jag gick hem igår för att se om det någonsin gick jämnt upp.

Scriptet kördes i 31 minuter(!) och nådde förmodligen bara jämnvikt för att folk helt enkelt kopplade ner sig från det trädlösa.

Plan B blir att försöka ta emot SNMP-traps och omvandla dem till en log och skicka in i brandväggen men där är jag inte ännu.

onsdag 2 april 2014

Thinkpad X61s och Ubuntu, till slut.

Jag installerade upp OpenBSD på min Thinkpad X61s men när jag väl kom till programmen jag måste ha så föll det på Sublime Text. Jag känner att jag vill ha Sublime Text överallt just nu för jag har bestämt mig för att lära mig den. Jag har varit en vi-anhängare i många år så att lära sig en ny texteditor är inget litet företag och inget jag gör lättvindigt. Så jag gick tillbaka till det mer familjära Ubuntu.

PC-BSD då? Det blev mer och mer oklart varför jag skulle välja PC-BSD till slut. Jag behöver inte KDE (jag har aldrig gillat det) och skulle jag gå med BSD kändes till slut OpenBSD mer bekant och som om det skulle gå att få ut mer av det på den med dagens mått mätt ganska blygsamma hårdvaran.

Men en dag kanske...


Jag drog igång Fluxbox på Ubuntu men gick så småningom tillbaka till Unity. Unity är ingen favorit direkt men det funkar. Jag upplever performance som helt okej, den har ju SSD och 8GB RAM.

Jag har inte hunnit med Geekbench 3 ännu men det gamla resultatet under Windows finns att beskåda.

tisdag 1 april 2014

Uppgraderingar och andra utmaningar

Idag började vi uppgraderingen av vår VMware-miljö på jobb.
Virtual Center var först ut till version 5.5 update 1 och sedan följde en ESXi-server efter för att se att allt gick bra. Den nya tvingande Single Sign-On-tjänsten i VMware känns som brutal overkill i vår miljö och borde helt enkelt inte vara obligatorisk. Den är inte ett dugg intuitiv utan mest bara en jättekrånglig senväg fram till en lyckad autentisering.

Nåväl, det gick i alla fall igång. Det tog större delen av förmiddagen att upgradera enbart VC:n, det är en seg produkt att både installera och uppgradera. Troligen kommer vi gå mot VMwares paketerade virtuella maskin av programvaran i framtiden istället för att hålla på med Windows-varianten.

Det nya tänket att den feta Virtual Center-klienten på Windows ska sluta utvecklas och att man istället ska hantera allt via ett gränssnitt i Flash på en webbsida känns inte helt genomtänkt. Det är 2014, vi vill inte ha Flash längre.

På eftermiddagen installerade vi User-ID-agenten till Palo Alto Networks brandvägg och kopplade ihop den med brandväggen. Man installerar agenten på en server i domänen, sätter upp en användare som får läsa säkerhetsloggarna från domänkontrollanterna och vips(!) så får man in information om vilken användare som gömmer sig bakom vilken IP-address. Det kan förstås även anonymiseras i rapporter och liknande.



Det är hur som helst väldigt imponerande att se det hända, all nätverkstrafik, alla URL:er, alla SMTP-anrop, ja, allt på Lager 7, blir genomlyst och identifierat i realtid och användarna bakom trafiken identifieras. Applikationsbrandväggar är framtiden, inget snack om saken.