How to Juniper SRX static route failover

Za normalnych okolnosti by sa routing failover mal realizovat na urovni dynamickych protokolov v sieti a nie na endpointoch. Niekedy sa vsak takemuto stavu nevyhneme a vtedy nam pride vhod funkcia RPM na SRX boxoch.

V nasom prostredi sa hodi na failover staitckeho routingu medzi lokalimtami BA-KE. Ked spadne konekt niekde po ceste a endpointy maju interfacy stale hore nevieme vyuzit funkcionalitu qualified-next-hop nakolko povodna cesta bude stale v routovacej tabulke a zariadenie nevie o vypadku po ceste. Pomocou RPM nastavime monitoring linky (ICMP) medzi boxami a ked na primarnej linke nebudu schopne komunikovat prehodia staticke cesty na backup linku.

Nastavime potrebne staticke cesty cez primarnu linku.

#route 192.168.0.0/24 next-hop 192.168.254.9;
#route 192.168.201.0/24 next-hop 192.168.254.9;

Vytvorime RPM probe ktory monitoruje druhu stranku IPsec tunela a ked neprejdu 3 ping v ramci casovych intervalov je test vyhodnoteny ako FAILED. V nasom pripade to bude 35s.

# run show configuration services rpm probe BA-KE-LINK 
test PRIMARY {
    target address 192.168.254.9;
    probe-count 3;
    probe-interval 5;
    test-interval 10;
    source-address 192.168.254.10;
    thresholds {
        successive-loss 3;
        total-loss 3;
    }
}

Tento stav je monitorovany serviceom ip-monitoring, ktoru pri FAILED stave prida staticku cestu cez backup linku.

# run show configuration services ip-monitoring 
policy BA-KE-PRIMARY {
    match {
        rpm-probe BA-KE-LINK;
    }
    then {
        preferred-route {
            route 192.168.0.0/24 {
                next-hop 192.168.254.1;
            }
            route 192.168.201.0/24 {
                next-hop 192.168.254.1;
            }
        }
    }
}

A mozeme skontrolovat

# run show services ip-monitoring status 

Policy - BA-KE-PRIMARY (Status: PASS)
  RPM Probes:
    Probe name             Test Name       Address          Status   
    ---------------------- --------------- ---------------- ---------
    BA-KE-LINK             PRIMARY         192.168.254.9    PASS     
  Route-Action:
    route-instance    route             next-hop         state
    ----------------- ----------------- ---------------- ------------- 
    inet.0            192.168.0.0/24    192.168.254.1    NOT-APPLIED  
    inet.0            192.168.201.0/24  192.168.254.1    NOT-APPLIED  

How to configure DNSSEC with BIND

DNSSEC
DNSSEC jednoducho povedané zabraňuje podvrhnutiu falošných informácií v rámci doménovej infraštruktúry internetu, a teda zabraňuje spojeniu Vášho prehliadača s falošnou webstránkou s inou skutočnou IP adresou. Takáto by od vás na princípe phishingu mohla vylákať osobné, prihlasovacie či iné citlivé údaje (napr. sa bude tváriť ako webstránka vašej banky). DNSSEC poskytuje dodatočnú úroveň bezpečnosti, vďaka ktorej si webový prehliadač môže overiť, či je odpoveď na jeho DNS dopyt správna a teda či nebola niekde po ceste útočníkom pozmenená. Používateľ si viditeľnosť tohto overenia môže do všetkých najpoužívanejších webových prehliadačov buď pridať alebo ju už rovno priamo podporujú.

DNSSEC Resource Records
DNSSEC vyžaduje niekoľko RR.

• DNSKEY Drží verejný kľúč, ktorý prekladatelia používajú na overenie.
• RRSIG Existuje pre každý RR a obsahuje digitálny podpis záznamu.
• DS – Delegation Signer – tento záznam existuje v nameserveroch TLD. Ak je doménou sitel.sk názov domény, TLD je „sk“ a jej menné servery sú a.gtld-servers.net., B.gtld-servers.net. až do m.gtld-servers.net . Účelom tohto záznamu je overiť pravosť samotného DNSKEY.

 

Ako prvé zapneme DNSSEC v konfiguračnom súbore /etc/named.conf v sekcii Options

dnssec-enable yes;
dnssec-validation yes;

Vytvoríme Zone Signing Key(ZSK)

#dnssec-keygen -a NSEC3RSASHA1 -b 2048 -n ZONE dubnik.sk

Vytvorime Key Signing Key(KSK)

#dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE dubnik.sk

V adresári v ktorom sme generovali kľúče budeme mať teraz 4 súbory. Privátny/verejný pár kľúčov ZSK a KSK. Teraz pridáme verejné kľúče do zónového súboru.

for key in `ls Kdubnik.sk*.key`
do
echo "\$INCLUDE $key">> /var/named/data/external/dubnik.sk.zone
done

Teraz môzeme podpísať zónu. Ako prvé si pripravíme salt pre crypto sifry. Vygenerovaný salt následne použijeme pri podpisovaní zónového súboru.

# head -c 1000 /dev/random | sha1sum | cut -b 1-16
a40157365d69a80d

Ako posledny krok vramci konfiguracie DNSSECU je podpísanie našej domeny.

# dnssec-signzone -A -3 a40157365d69a80d -N INCREMENT -o dubnik.sk -t /var/named/data/external/dubnik.sk.zone 

Výsledkom podpisania zóny je nový zónový súbor sitel.sk.zone.signed. Upravíme teda konfiguračný súbor bindu aby používal tento podpísaný zonový súbor.

zone "dubnik.sk" IN {
                 type master;
                 file "data/external/dubnik.sk.zone.signed";
                 also-notify { 192.168.200.66; };
                 allow-transfer { 192.168.200.66; };
                 allow-update { none; };};

A reloadneme bind server.

#rndc reload

Pre konfiguráciu slave servera stačí zapnúť dnssec v súbpre named.conf a zmeniť pôvodný zónový súbor na signed súbor a reloadnúť bind. Slave si potiahne config z mastra a DNSSEC bude funkčný aj na slave servery.

Posledným krokom je konfigurácia na strane registrátora. Je potrebné pridať DS záznamy. Záznamy sa nám vygenerujú pri podpisovaní zóny do aktuálneho adresára a stači ich len pridať na stránke SK-NIC. DS záznamy si pozrem následovne.

# cat dsset-dubnik.sk. 
dubnik.sk.  IN DS 16248 7 1 6455A604C2F55D42649CD044171136277B43A2A3
dubnik.sk.  IN DS 16248 7 2 64C4E824E33DC65D0788CA93AEFA216F035FF354ED434EDAA4B77E57 0E26F397

 
Správnosť a dôveryhodnosť konfigurácie si môžem overiť na stránke https://dnssec-analyzer.verisignlabs.com/

Este nesmieme zabudnut ze dlzka platnosti podpisanej zony je 30 dni. Preto je vhodne imlpementovat skript na automaticke podpisovanie zony. Ja pouzivam ansible play v awx ktory podpisuje zonu kazdy den.

- hosts: ns-01
  remote_user: root
  vars:
    date: "{{ lookup('pipe', 'date +%Y%m%d') }}"
  tasks:

  - name: resign keys"
    command: /bin/bash /root/scripts/dnssec-resign.sh

  - name: update internal serial
    replace:
      dest: /var/named/data/external/{{ item  }}.zone
      regexp: '.*serial*'
      replace: '\t\t\t\t\t\t\t{{ date }}01 ; serial'
    with_items:
    - dubnik.sk
    - dubnik.com
    - dubnik.it
    
  - systemd:
       name: named
       state: reloaded


- hosts: ns-02
  remote_user: root
  tasks:

  - systemd:
       name: named
       state: reloaded

A samotny dnssec-resign.sh skript

#!/bin/bash
zones="$(ls /root/keys)"
for line in $zones; do
cd /root/keys/$line
/usr/sbin/dnssec-signzone -A -3 $(head -c 1000 /dev/urandom | sha1sum | cut -b 1-16) -N increment  -o $line -t /var/named/data/external/$line.zone;
done

How to manual upgrade Cisco Aironet AP

By default by si malo AP stiahnut aktualny ios z controllera. V mojom pripade som vsak potreboval pripojit starsi kusok a na controllery nebol ios k dispozicii. Preto bolo potrebne manualne upgradenut ios na apcku.

Ako prve sa pripojim k AP cez konzolu.

AP70e4.22cf.124c#

A uvidim nasledovne hlasky, ze nie je mozne stiahnut ios z controllera

*Feb 19 11:04:17.447: %CAPWAP-6-AP_IMG_DWNLD: Required image not found on AP. Downloading image from Controller                                             .
*Feb 19 11:04:17.451: Loading file /ap1g3...

V tomto pripade je potrebne srpravit manualny upgrade. Pripravim si oblubeny tftp server s ios imageom.

AP70e4.22cf.124c# debug capwap console cli

A skuim nahrat software z tftp servera

AP70e4.22cf.124c# archive download-sw tftp://10.10.180.48/ap1g3-k9w8-tar.153-3.JF10.tar

Moze sa stat ze dostanem nasledovny error

Unable to create temp dir "flash:/update"

Vtedy je potrebne zmazat dany adresar z flashky

AP70e4.22cf.124c# delete /f /r flash:update

A skusit znova

AP70e4.22cf.124c# archive download-sw tftp://10.10.180.48/ap1g3-k9w8-tar.153-3.JF10.tar
Loading ap1g3-k9w8-tar.153-3.JF10.tar from 10.10.180.48 (via BVI1): !
extracting info (291 bytes)
Image info:
    Version Suffix: k9w8-.153-3.JF10
    Image Name: ap1g3-k9w8-mx.153-3.JF10
    Version Directory: ap1g3-k9w8-mx.153-3.JF10
....

Vidime ze v tomto pripade uz doslo k uspesnemu nahratiu sw na AP. Po skonceni dame reload a zariadenie bude uspesne upgradnute. Ak nechceme
drzat stary ios mozeme pouzit pri nahravani sw pouzit prepinac /overwrite

AP70e4.22cf.124c# archive download-sw /overwrite tftp://10.10.180.48/ap1g3-k9w8-tar.153-3.JF10.tar

rsync over ssh with specific port

#find /archiv/storage/* -type d -ctime +7 -exec /usr/bin/rsync  -av -e "ssh -p 22222" /mnt/archiv/$datum/ root@remote-ip:/mnt/storage/ {} \;

How to upgrade C3650/C3850 stack

Ako prve odmazeme “neporiadok” ktory zostal po starom sw.

# software clean 

Nakopirujeme novy balik na zariadenie. Je viacej moznsti ale najrychejsia je z USB ak je tato moznost.

#copy usbflash0:/cat3k_caa-universalk9.16.09.04.SPA.bin flash:/

Dobrym zvykom je overit md5sum ci sa subor spravne nakopiroval. Sum by mal byt totozny s USB.

#verify /md5 flash:/cat3k_caa-universalk9.16.09.04.SPA.bin
#verify /md5 usflash:0/cat3k_caa-universalk9.16.09.04.SPA.bin

V nejakom navode som videl ze pre upgrade major verzii v tomto pripade z 3.x.x -> 16.x.x je vhodne nanovo vygenerovat rsa kluce.

(config)#crypto key rsa general-keys modulus 1024

A mozeme spustut samotnu instalaciu. Instalator prekopiruje sw na zvysnych memberov v stacku a nasledne spustu instlaciu.

#software install file flash:/cat3k_caa-universalk9.16.09.04.SPA.bin switch 1-4 verbose new force

Na zaver rebootneme stack a ulozeme konfiguraciu

reload stack now?: yes
system configuration: save?: yes

Nasledne sa cely stack rebootne do novej verzie. Ak sme s novou verziou spokojny upraceme po sebe.

#request platform package clean switch all file flash: