BetterCAP: útok MITM

BetterCAP je moderní framework pro útoky na síť technikou Man in the middle (MITM). Standardně je obsažen třeba v Kali Linuxu a jeho použití je velmi jednoduché.

Příkazem
bettercap
se spustí základní režim bettercap který pomocí ARP dotazů oskenuje síť a nabídne seznam IP adres možných obětí.

Méně agresivní je pasivní odposlech, kdy jen "visíme" na lokálním subnetu:
bettercap -X --no-spoofing

Samozřejmě, daleko účinější je aktivní sniffing. Útok na oběť 192.168.X.Y se spustí příkazem
bettercap -T 192.168.X.Y --proxy -P POST
kdy vytvoříme falešnou výchozí bránu a tu pomocí nevyžádané ARP zprávy pošleme naší oběti (tzv. ARP spoofing). Oběť si ničeho nemusí všimnout, protože IP adresa výchozí brány (kterou pravděpodobně dostala z DHCP serveru) se nemění, mění se jen MAC adresa z té legitimní na naši falešnou.

Ukázka ARP tabulky na straně oběti 192.168.88.254:

První výpis arp -a ukazuje tabulku před útokem. IP adresa 192.168.88.1 má přiřazenou legitimní MAC adresu výchozí brány. Druhý výpis arp -a ukazuje situaci po spuštění útoku, kdy útočník se zařízením 192.168.88.252 zároveň vystupuje jako výchozí brána. Došlo tedy k modifikaci záznamu ARP tabulky na straně oběti.

Veškerý provoz oběti nyní prochází přes naši falešnou proxy dále do internetu. Vše je relativně nenápadné, protože oběť má "fungující internet" a nemá sebemenší podezření o našem konání. Nic už nebrání odchytávat nezabezpečené přenosy typu FTP, HTTP, POP3,...ale i HTTPS.

Následuje ukázka útoku s pomocí SSLSTIPPu, kdy donutíme uživatele k přechodu ze zabezpečeného HTTPS na nezabezpečený HTTP protokol s cílem odposlechnout jeho přihlašovací údaje.

Standardní otevření www.idnes.cz v prohlížeči:

iDNES.cz nemá automatické přesměrování na HTTPS na úvodní stránce. To se děje, až když klikneme na Přihlásit vpravo nahoře. To by byl standardní průběh. Ale, díky tomu, že vystupujeme jako falešná transparentní proxy, BetterCAP použije funkci SSLSTRIPP a místo HTTPS vrátí oběti nezabezpečenou stránku. To je v Chromu indikováno vlevo nahoře v adresním řádku všeříkajícím "Nezabezpečeno". (Kdo z běžných uživatelů si toho ale všimne?)

Nyní uživatel zadá svoje přihlašovací údaje a v domnění, že je posílá na server iDNESu je nezabezpečeně odešle:

V konzoli BetterCAPu se následně objeví odchycené údaje z těla HTTP požadavku:

Podobně funguje útok například na Google Images. Standardní výsledek vyhledávání s HTTPS:

Stejný výsledek hledání, ale se zapnutou MITM proxy:

A na straně útočníka lze pomocí příkazu
driftnet -i eth0 
rovnou vidět i odchycené obrázky:

Další pokusy na webech Seznam.cz a Facebook.com byly neúspěšné. U Seznamu se BetterCAP nedokázal vypořádat se zpětným přesměrováním při přihlašování. U Facebooku se nedařilo docílit přesměrování na HTTP i přes zjevně aktivní SSLSTRIPPing. Podvrhnout přihlášení do Google účtu se také nepodařilo, protože Google využívá HTTP Strict Transport Security (HSTS), kdy prohlížeč od serveru přijme informaci, že vzájemná komunikace bude využívat HTTPS a nic jiného.

Obranou proti MITM na lokální síti je například ARP inspekce na síťových přepínačích. Cisco tomu říká Dynamic ARP Inspection. Ve zkratce řečeno, switch si udržuje vazbu port-MAC adresa-IP adresa a tím zamezí situaci, kdy port na kterém není legitimní MAC adresa brány přijde podvržená ARP odpověď s MAC adresou falešné brány.

Teploměr Papouch TM - RS232 v Linuxu a server tmep.cz

Úvod

Cílem tohoto návodu je zprovoznit teploměr Papouch TM - RS232 v Linuxu, vyčítat z něj hodnoty teploty a ty následně zasílat na server tmep.cz který nám bude hostovat data z čidla, kreslit z nich grafy a uchovávat historii. Ukázka webového GUI například na roudnice.eu.

Implementace

Připojíme čidlo přes sériový port k počítači s Linuxem. Pokud nemáme přímo port na desce, použijeme převodník.

Příkazem dmesg | grep tty zjistíme název sériové linky v systému. Pokud máme USB převodník, hledejte označení ttyUSB0. Port na desce je většinou označen jako ttyS0.

Vyzkoušíme komunikaci s čidlem pomocí příkazu cat /dev/ttyUSB0. Pokud vše funguje jak má, tak teploměr vrátí následující řádek:
+022.7C 

Na test to stačí, ale problémem je, že program cat neustále čeká na vstup, takže se aktuální teplota po čase přepíše další, to není použitelné pro další zpracování. Proto použijeme jiný způsob.

Vytvoříme skript (např logovani.sh). První je příkaz:
read teplota < /dev/ttyUSB0 && echo -n $teplota | tr -d "\r"
který otevře sériovou linku, načte teplotu (pořád jako kompletní textový řetězec) a uloží do stejnojmenné proměněné . Text je poslán na vstup programu tr který odstraní "neviditelný" ASCII znak na konci řádku.

Následně pomocí curl pošleme na server tmep.cz. Před odesláním je ale ještě potřeba uříznout písmeno C a tím dostaneme pouze kladné nebo záporné číslo s jednou desetinou hodnotou:
curl http://subdomena.tmep.cz/?nazevteplomeru=${teplota::-1} 

subdomena a nazevteplomeru jsou proměnné, které si nastavíme sami po registraci na tmep.cz

Skript je ke stáhnutí zde: http://pastebin.com/en2gtwzd
 
Měřit teplotu chceme pravidelně, takže do Crontabu uložíme (příkaz crontab -e) řádek
*/5 * * * * bash /home/uzivatel/teplomer/logovani.sh &>/dev/null 

Skript se bude pouštět každých 5 minut (měřit častěji mi přijde zbytečné, ale samozřejmě každý podle svého gusta). Server tmep.cz má přehledné a logické nastavení, popř. doporučuji jejich wiki.

P.S.: Pokud nejsme root, je nutné příkazy spouštět se sudo na začátku.

Zdroje

• https://www.papouch.com/cz/shop/product/tm-rs232-teplomer/

• http://www.abclinuxu.cz/poradna/linux/show/241310

• http://wiki.tmep.cz/doku.php?id=zarizeni:vlastni_hardware

Unbound: resolvující DNS server s podporou DNSSEC

Unbound je snadno konfigurovatelný resolvující DNS server s dalšími funkcemi, jako je kešování záznamů, DNSSEC a záznamy ve vlastní zóně.

Konfigurace je standardně v
/etc/unbound/unbound.conf.

Síť

Ve výchozím stavu server naslouchá jen na localhostu. Aby byl server dostupný i pro další stanice v síti, je nutné přidat IP adresu nakonfigurovaného síťového rozhraní a nebo povolit naslouchání na všech adresách. Přidáme i IPv6 adresy pokud máme v síti.
interface: 0.0.0.0
interface: ::0

Není od věci zapnout IPv6 a také TCP na portu 53. Standardně je DNS samozřejmě na UDP 53 již povoleno.
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes

Server umí i klasické access listy. Pravděpodobně chceme, aby náš DNS server obsluhoval jen klienty v naší lokální síti a ne v celém internetu. Pro překlad "uvnitř" serveru povolíme IPv4/IPv6 loopback.
access-control: 10.0.0.0/24 allow
access-control: 2a00:..../64 allow
access-control: fe80::/64 allow
access-control: ::1 allow

DNSSEC

Podpora DNSSECu by měla být již zapnutá ve výchozím nastavení. Pokud tomu tak není, tak odkomentujeme, nebo přidáme tento řádek:
auto-trust-anchor-file: "/var/lib/unbound/root.key"

Soubor /var/lib/unbound/root.key vypadá nějak takto:
; autotrust trust anchor file
;;id: . 1
;;last_queried: 1476288795 ;;Wed Oct 12 18:13:15 2016
;;last_success: 1476288795 ;;Wed Oct 12 18:13:15 2016
;;next_probe_time: 1476292286 ;;Wed Oct 12 19:11:26 2016
;;query_failed: 0
;;query_interval: 3600
;;retry_time: 3600
.       172800  IN      DNSKEY  257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6
v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg3
7NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQp
zW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ip
AdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
;{id = 19036 (ksk), size = 2048b} ;;state=2 [  VALID  ] ;;count=0 ;;lastchange=1476036425 ;;Sun Oct  9 20:07:05 2016  

Nejdůležitější je samozřejmě veřejný klíč (červeně), kterým je ověřen kořen DNS stromu. Pokud klíč nemáte, nebo nechcete ten to přišel s instalací Unboundu, lze jej získat jako jakýkoli jiný zónový záznam nástrojem dig.

Dotaz:
dig . dnskey +multiline

Odpověď:
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> . dnskey +multiline
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60959
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;.                      IN DNSKEY

;; ANSWER SECTION:
.                       172786 IN DNSKEY 256 3 8 ( AwEAAcCsATzyk1Hj1xabagAGWi9sZSbB+igdzDM8CMZ5                             fPcOb314yP9/lmvidoBuApPlMVwlz0lXaj6gzyjoOKBv                               eoDD0VyHTqjCDg9UrcDoClNZciR2sHZoaMZp2yVNFyaC                              +7MkA8lsrCShieYPEowSjQdkvY5ONlEib/ATXdmAhfgB

) ; key id = 46551
.                       172786 IN DNSKEY 256 3 8 (AwEAAYbinauHA9oUb4aGNtJIrepyGoYy0OL01rvIhvo                               RWN/Ch8p2C4ZEkpvUYkx74r9JpgrOsjKOv+JQdKtT2u8                              AxGjUoH8x8HdpDiMV7XnpWJo9wAxlFtDtbMnPwRQ3dWs                               T1p5myrGcm7EFJ9j7KmiAEG5hGsevZqcnqMOW9QFkmp/                               zM0TFYXYWq6AsAof2uZqLUyd+nHIW0TGsaHMzcTNfA8W                               w+OYV7R4bcR/8edCEo6OAh9j48R1hRtuO1e2MQdnkITc                              9DJljB4Cq1gQKwv/ku7mAvmFuWkRotMZIFN3vDhpmpmy                                7M0C1EHSRAgP+HkblLRQKOPnwI/VksJEU4fmnhk=

) ; key id = 39291
.                       172786 IN DNSKEY 257 3 8 (
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ                               bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh                              /RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA                        
 JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp                            oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3                              LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO                               Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc                              LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=

) ; key id = 19036

;; Query time: 21 msec
;; SERVER: ::1#53(::1)
;; WHEN: Wed Oct 12 18:28:41 2016
;; MSG SIZE  rcvd: 714

Funkčnost DNSSECu na našem serveru se ověří například opět digem.
Dotaz:
dig . +dnssec @localhost | grep ad

Odpověď:
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

Příznak ad značí aktivní DNSSEC validaci.

root.hints

Unbound má standardně předkonfigurované některé kořenové DNS servery, resp. jejich IP adresy, takže funguje tzv. "out of box". Pokud chceme mít kontrolu nad IPv4 a IPv6 adresami root DNS serverů, je potřeba si stáhnout  jejich seznam z důvěryhodného zdroje. Například z InterNICu (spadá pod Verisign), což je provozovatel jednoho z root DNS serverů:
wget -S -N https://www.internic.net/domain/named.cache -O /etc/unbound/root.hints

A pak jen na tento soubor odkázat v konfiguraci Unboundu:
root-hints: "/etc/unbound/root.hints"

Statické záznamy a vlastní doména

Unbound sice není plnohodnotným autoritativním serverem, nicméně umožňuje definovat vlastní zónu, ve které si vytvoříme patřičné záznamy pro naši doménu.

Nejprve definujeme zónu (příklad pro doménu .home použitou pouze v lokální síti):
local-zone: "home." static

Definice A záznamu:
local-data: "pc1.home. IN A 10.0.0.1"

Podobně lze definovat další záznamy jako AAAA, MX, atd...
Reverzní, tzv. PTR záznam má syntaxi:
local-data-ptr: "10.0.0.1 pc1.home"

Zdroje

• https://www.unbound.net/documentation/howto_setup.html
• https://www.unbound.net/documentation/unbound.conf.html
• https://wiki.alpinelinux.org/wiki/Setting_up_unbound_DNS_server
• https://www.nic.cz/page/563/jak-zprovoznit-dnssec/

Podpora DNSSEC na rekurzivních DNS serverech O2

~ $ dig @194.228.41.65 +dnssec +multiline
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @194.228.41.65 +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55629
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4000
;; QUESTION SECTION:
;.                      IN NS

;; ANSWER SECTION:
.                       171551 IN NS c.root-servers.net.
.                       171551 IN NS d.root-servers.net.
.                       171551 IN NS e.root-servers.net.
.                       171551 IN NS f.root-servers.net.
.                       171551 IN NS g.root-servers.net.
.                       171551 IN NS h.root-servers.net.
.                       171551 IN NS i.root-servers.net.
.                       171551 IN NS j.root-servers.net.
.                       171551 IN NS k.root-servers.net.
.                       171551 IN NS l.root-servers.net.
.                       171551 IN NS m.root-servers.net.
.                       171551 IN NS a.root-servers.net.
.                       171551 IN NS b.root-servers.net.
.                       171551 IN RRSIG NS 8 0 518400 20160716050000 (
                                20160706040000 46551 .
                                m/BhqRYcn0mgkx3NqtyFw/OJUiNyn7nvP6HcqxOZCZSc
                                RVFvPoWYDzL7kdJcOwNOqc1cWZR33fb89QWFLzmYDhr+
                                4NDcaLZjrapoT6hyvxv9SAWVFobKZP+cFlvdppa6jqaq
                                2Rwz/oOb4m58zAxdjJnqkCxWSALT2hyEjS/E7Kg= )

;; ADDITIONAL SECTION:
a.root-servers.net.     328157 IN A 198.41.0.4
a.root-servers.net.     389646 IN AAAA 2001:503:ba3e::2:30
b.root-servers.net.     601363 IN A 192.228.79.201
c.root-servers.net.     601327 IN A 192.33.4.12

;; Query time: 31 msec
;; SERVER: 194.228.41.65#53(194.228.41.65)
;; WHEN: Wed Jul  6 11:46:06 2016
;; MSG SIZE  rcvd: 473


~ $ dig @194.228.41.113 +dnssec +multiline
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @194.228.41.113 +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53280
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4000
;; QUESTION SECTION:
;.                      IN NS

;; ANSWER SECTION:
.                       103405 IN NS g.root-servers.net.
.                       103405 IN NS h.root-servers.net.
.                       103405 IN NS i.root-servers.net.
.                       103405 IN NS j.root-servers.net.
.                       103405 IN NS k.root-servers.net.
.                       103405 IN NS l.root-servers.net.
.                       103405 IN NS m.root-servers.net.
.                       103405 IN NS a.root-servers.net.
.                       103405 IN NS b.root-servers.net.
.                       103405 IN NS c.root-servers.net.
.                       103405 IN NS d.root-servers.net.
.                       103405 IN NS e.root-servers.net.
.                       103405 IN NS f.root-servers.net.
.                       103405 IN RRSIG NS 8 0 518400 20160715050000 (
                                20160705040000 46551 .
                                ET+4fwEpkJP58IQCerr9SJAmwmvzyBpyR/MIBUHOrehe
                                5urx7fz/3KSwDqXYxxDnvr+UsEysOOq83h9J1f289R76
                                YQdMaM0hfIUfe4TSUxTqWwraWqAZVUsibTGhSbW+LKOx
                                pS2qOwRxrm1H3NlEaw2AlEm6vXuduAcl1QQHOds= )

;; ADDITIONAL SECTION:
a.root-servers.net.     499437 IN A 198.41.0.4
a.root-servers.net.     331875 IN AAAA 2001:503:ba3e::2:30

;; Query time: 28 msec
;; SERVER: 194.228.41.113#53(194.228.41.113)
;; WHEN: Wed Jul  6 11:46:23 2016
;; MSG SIZE  rcvd: 441


~ $ dig @160.218.161.54 +dnssec +multiline
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @160.218.161.54 +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28522
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4000
;; QUESTION SECTION:
;.                      IN NS

;; ANSWER SECTION:
.                       169953 IN NS m.root-servers.net.
.                       169953 IN NS a.root-servers.net.
.                       169953 IN NS b.root-servers.net.
.                       169953 IN NS c.root-servers.net.
.                       169953 IN NS d.root-servers.net.
.                       169953 IN NS e.root-servers.net.
.                       169953 IN NS f.root-servers.net.
.                       169953 IN NS g.root-servers.net.
.                       169953 IN NS h.root-servers.net.
.                       169953 IN NS i.root-servers.net.
.                       169953 IN NS j.root-servers.net.
.                       169953 IN NS k.root-servers.net.
.                       169953 IN NS l.root-servers.net.
.                       169953 IN RRSIG NS 8 0 518400 20160716050000 (
                                20160706040000 46551 .
                                m/BhqRYcn0mgkx3NqtyFw/OJUiNyn7nvP6HcqxOZCZSc
                                RVFvPoWYDzL7kdJcOwNOqc1cWZR33fb89QWFLzmYDhr+
                                4NDcaLZjrapoT6hyvxv9SAWVFobKZP+cFlvdppa6jqaq
                                2Rwz/oOb4m58zAxdjJnqkCxWSALT2hyEjS/E7Kg= )

;; ADDITIONAL SECTION:
a.root-servers.net.     326557 IN A 198.41.0.4
a.root-servers.net.     556788 IN AAAA 2001:503:ba3e::2:30

;; Query time: 24 msec
;; SERVER: 160.218.161.54#53(160.218.161.54)
;; WHEN: Wed Jul  6 11:46:44 2016
;; MSG SIZE  rcvd: 441

Seznam českých NTP serverů

Stratum 1

DNS: ntp.nic.cz
IP: 217.31.202.100
Síť: AS25192
Referenční zdroj času (Stratum 0): GPS
Provozovatel: CZ.NIC, z.s.p.o.
Umístění: Praha
Podrobnosti: https://www.nic.cz/page/329/cz.nic-prinese-do-ceskych-pocitacu-presny-cas/

DNS: tik.cesnet.cz
IP: 195.113.144.201
Síť: AS2852
Referenční zdroj času (Stratum 0): GPS
Provozovatel: CESNET z.s.p.o.
Umístění: Praha
Podrobnosti: https://www.cesnet.cz/sluzby/casove-sluzby/

DNS: tak.cesnet.cz
IP: 195.113.144.238
Síť: AS2852
Referenční zdroj času (Stratum 0): GPS
Provozovatel: CESNET z.s.p.o.
Umístění: Praha
Podrobnosti: https://www.cesnet.cz/sluzby/casove-sluzby/

DNS: ntp2.ufe.cz
DNS aliasy: time.ufe.cz, ntp.ufe.cz
IP: 147.231.2.6
Síť: AS2852
Referenční zdroj času (Stratum 0): atomové hodiny
Provozovatel: Ústav fotoniky a elektroniky, Akademie věd ČR, v.v.i.
Umístění: Praha
Podrobnosti: http://www.ufe.cz/cs/tym/laborator-statniho-etalonu-casu-frekvence

DNS: lxn.ujf.cas.cz
IP: 147.231.100.11
Síť: AS2852
Referenční zdroj času (Stratum 0): GPS
Provozovatel: Ústav jaderné fyziky AV ČR, v. v. i.
Umístění: Řež (Praha-východ)
Podrobnosti: http://ujf.cas.cz/

DNS: netopyr.hanacke.net
IP: 193.85.174.5 
Síť: AS5588 
Referenční zdroj času (Stratum 0): GPS
Provozovatel: Hanacke.net
Umístění: ?
Podrobnosti: http://netopyr.hanacke.net/

DNS: ntpm.fit.vutbr.cz
IP: 147.229.9.10
Síť: AS197451 
Referenční zdroj času (Stratum 0): GPS
Provozovatel: FIT VUT v Brně
Umístění: Brno
Podrobnosti: http://ntpm.fit.vutbr.cz/cgi-bin/main

Stratum 2

DNS: lx.ujf.cas.cz
IP: 147.231.100.5 
Síť: AS2852
Referenční zdroj času (Stratum 1): lxn.ujf.cas.cz
Provozovatel: Ústav jaderné fyziky AV ČR, v. v. i.
Umístění: Řež (Praha-východ)
Podrobnosti: http://ujf.cas.cz/

DNS: ns.muni.cz
DNS alias: ntp.muni.cz
IP: 147.251.4.33  
Síť: AS2852
Referenční zdroj času (Stratum 1): tak.cesnet.cz
Provozovatel: Masarykova univerzita
Umístění: Brno
Podrobnosti:  https://wiki.ics.muni.cz/dalsi_podpurne_technologie/time_server

DNS: nora.ics.muni.cz
DNS alias: ntp2.muni.cz
IP: 147.251.4.37   
Síť: AS2852
Referenční zdroj času (Stratum 1): tik.cesnet.cz 
Provozovatel: Masarykova univerzita
Umístění: Brno
Podrobnosti:  https://wiki.ics.muni.cz/dalsi_podpurne_technologie/time_server

DNS: pyrrha.fi.muni.cz
DNS alias: time.fi.muni.cz
IP: 147.251.48.140   
Síť: AS2852
Referenční zdroj času (Stratum 1): tik.cesnet.cz 
Provozovatel: Fakulta informatiky, Masarykova univerzita
Umístění: Brno
Podrobnosti: https://www.fi.muni.cz/tech/unix/time.xhtml

DNS: titan.zcu.cz
DNS alias: clock1.zcu.cz
IP: 147.228.57.10
Síť: AS2852
Referenční zdroj času (Stratum 1): tik.cesnet.cz 
Provozovatel: Západočeská univerzita v Plzni 
Umístění: Plzeň
Podrobnosti: http://support.zcu.cz/
 
DNS: ori.zcu.cz
DNS alias: clock2.zcu.cz
IP: 147.228.52.11  
Síť: AS2852
Referenční zdroj času (Stratum 1): ? 
Provozovatel: Západočeská univerzita v Plzni
Umístění: Plzeň
Podrobnosti: http://support.zcu.cz/

DNS: ntp.feec.vutbr.cz
IP: 147.229.9.11  
Síť: AS197451
Referenční zdroj času (Stratum 1): ntpm.fit.vutbr.cz 
Provozovatel: FEKT/FIT VUT v Brně
Umístění: Brno
Podrobnosti: http://www.feec.vutbr.cz/OSIS/site.php

Poznámky

• Všechny uvedené servery jsou veřejně přístupné odkudkoli.
• Některé servery neodpovídají na ping, i když jsou plně funkční.
• U serverů, kde je to uvedeno, je doporučeno používat DNS aliasy.
• Seznam stratum 1 serverů obsahuje všechny servery které se podařilo dohledat z veřejných zdrojů.
• Seznam stratum 2 serverů obsahuje jen vybrané servery velkých organizací. Rozhodně není kompletní. Většina veřejně dostupných NTP serverů je zařazena do NTP poolu.
• Statistiky offsetu pro určitý server lze získat na adrese http://www.pool.ntp.org/scores/<IP nebo DNS>

Aktualizace:

• 19.12.2015 - doplněny dva servery VUT

Převodník Prolific USB-to-Serial pod Windows 8.1

Update 22.11.2015 - Našel jsem ještě jednu metodu. Na webu http://www.ifamilysoftware.com/news37.html je instalační soubor s ovladači ve verzi 3.3.2.102. Dle autora webu jde o "nejstabilnější" verzi, která by měla fungovat se všemi převodníky ve kterých je čip Prolific. Osobně jsem provedl instalaci a převodník se opravdu jeví jako funkční, nicméně nemám z dlouhodobého hlediska vyzkoušeno, jestli to řeší problém s BSOD.

Update 3.11.2015 - Jak se zdá, tak níže popsaný postup není vždy úplně bez problémů. Starší verze ovladače je sice systémem Windows přijata, ale poté, co připojíte zařízení na převodník, tak dříve či později nastane modrá smrt (BSOD) a počítač se restartuje. Toto chování pozoruji na převodníku od společnosti Wiretek, který vypadá takto. Příčina je zřejmě ve starých ovladačích. Nevím, jak jsou na tom jiné převodníky a je možné, že se tento problém vyskytuje jen při určité kombinaci hardwaru (USB řadič a převodník).

Dostal se ke mě převodník USB na sériový port, který na první pohled nemá žádné označení. Po zapojení do počítače se ve Správci zařízení hlásí jako Prolific USB-to-Serial Comm Port.

Popis problému

Správce zařízení signalizuje, že je problém s hardwarem: Kód 10 - Toto zařízení nelze spustit a u ikonky zařízení je žlutý vykřičník. Ovladače nejsou součástí služby Windows Update, takže je potřeba dodat je z externího zdroje. To ale není tak jednoduché, jak by se mohlo zdát. Na internetu je velké množství návodů a zaručených postupů jak přimět tento konkrétní převodník fungovat. Nicméně, žádný nefungoval. Tedy alespoň u mě ne.

Co jsem tak mohl vyčíst na různých stránkách. Tak problémy jsou de fakto dva:

1. Některé Prolific převodníky obsahují elektronické čipy, které Windows 8/8.1 (a taktéž nové Windows 10) již nepodporují.
2. Od určité verze ovladačů pro Windows 8/8.1/10 výrobce Prolific schválně blokuje napodobeniny/ levné kopie čipů, které se jen tváří že jsou od společnosti Prolific. Společnost Prolific převodníky jako celek (tedy USB kabel+sériový konektor se zataveným čipem) neprodává. Běžný uživatel nemá šanci poznat napodobeninu čipu.

Řešení

Řešení prvního problému je de fakto metoda pokus omyl. Z oficiálních stránek: http://www.prolific.com.tw/US/ShowProduct.aspx?p_id=225&pcid=41
si stáhněte ZIP soubor, kde jsou jednak ovladače (PL2303_Prolific_DriverInstaller_v1.11.0.exe) a také aplikace na kontrolu verze čipu v převodníku (checkChipVersion_v1006.exe). Na stránkách uvedených výše jsou typy čipů které již nejsou podporovány a je tak pravděpodobné, že převodník s touto verzí ovladačů nebude fungovat. Pokud naopak máte podporovaný čip, tak nainstalujte ovladače.

Pokud předchozí postup nebyl úspěšný, máte s největší pravděpodobností napodobeninu a nelze tedy použít nové ovladače. Nicméně nic není ztraceno a je zde řešení:

Řešení druhého problému je celkem jednoduché a to použít starší verzi "obecných" Prolific ovladačů, které ještě nemají ochranu proti napodobeninám čipům.

Postup je tedy následující:

1. Zde stáhneme ovladače. Rozbalíme a nainstalujeme soubor PL2303_Prolific_GPS_1013_20090319.exe.
2. Nyní máme ovladače v systému.
3. Otevřeme Správce zařízení (např. pravý klik na ikonu Tento počítač -> Vlastnosti -> Správce zařízení)
4. Ve Správci zařízení pravý klik na název převodníku (Prolific USB-to-Serial...)
5.  A dále: Vlastnosti -> Aktualizovat ovladač -> Vyhledat ovladač v počítači ->
   -> Vybrat ovladač ze seznamu.
6. Nyní vidíte okno kde jsou na výběr dva nainstalované certifikáty, viz obrázek 1.
   
7. Vybereme ten kde je uvedena verze 3.3.2.105 a na konci datum 27.10.2008.
8. Pokračujeme tlačítkem Další.
9. Ve správci zařízení zkontrolujeme zda zmizel žlutý vykřičník. Hotovo.
   

   

   Obrázek 1.: Výběr ovladačů

   Ve výchozím stavu se pravděpodobně přidělí číslo portu jiné než 1, např. COM3 nebo COM4. Pokud chcete číslo změnit na jiné, tak to lze, viz dále.
   
   Postup:
   

   1. Ve Správci zařízení pravý klik na název převodníku (Prolific USB-to-Serial...)
   2. Vlastnosti -> Nastavení portu -> Upřesnit... -> Číslo portu COM: (vybrat)
   3. Potvrdíme OK a pak ještě jednou OK.

   
   Další poznámky:
   

   • Pokud používáte PuTTY, je potřeba jej spouštět jako správce systému, jinak systém neotevře port.

   • Uvedený postup byl vyzkoušen na Windows 8.1 Pro 64-bitová verze. Nicméně, postup by měl fungovat i na Windows 7, 8 popř. 1.
     
     

   Zdroje:
   

   • http://wp.brodzinski.net/hardware/fake-pl2303-how-to-install/
   • http://www.pc-help.cz/viewtopic.php?t=140114 

Network Time Protocol v kostce

Teorie

Network Time Protocol je protokol pro synchronizaci času v internetu. Na straně klienta běží deamon (služba) který se podle různých pravidel dotazuje na patřičný server, za účelem zjištění přesného času. Samozřejmě je nutné počítat se zpožděním v síti. Počátek protokolu sahá až do roku 1979, kdy bylo znatelné zpoždění celkem běžný jev. Server i klient využívají port UDP/123.
Algoritmus určení přesného času funguje tak, že klient vypočítá vůči serveru tzv round-trip delay time, což je čas který uplyne mezi odesláním požadavku a jeho přijetím na serveru a zároveň časem, který uplyne mezi odeslání odpovědi ze serveru a jeho přijetím u klienta. Zjednodušeně tedy "cesta tam a zpět". Round-trip delay time se jednoduše spočítá z časových značek které jsou přenášeny v datagramech.
 Dále je potřeba vypočítat odchylku mezi hodnotou času při odeslání a hodnotou času při přijetí přesného času. Uvažujme, že server odešle zprávu kde je hodnota přesného času. Klient tuto zprávu obdrží, ale až za nějaký čas, protože se zpráva zpozdila vlivem zpoždění v každé reálné počítačové síti. Klient tedy vždy obdrží hodnotu "přesného času" ale ta již reálně neplatí, protože odkazuje na čas v minulosti, kdy byla zpráva vytvořena a odeslána ze serveru. Toto řeší výpočet odchylky (offset) z hodnot round-trip delay time, konkrétní vzorce lze nalézt v [1].

Ukázka odesílaných dat z NTP serveru.

Architektura NTP serverů počítá s dělením na tzv. strata. Stratum úroveň označuje "blízkost" k referenčnímu zdroji času. Dělení je následující:

• stratum 0 - jde o velmi přesné hodiny. Buď přímo atomové hodiny, nebo se používá signál od nich odvozený, nejčastěji signál GPS. Stratum 0 není server.
• stratum 1 - první server v řetězci ke kterému jsou připojeny hodiny (stratum 0). Stratum 1 většinou provozují výzkumné instituce, vysoké školy nebo velké korporace. Vzhledem k omezeným výpočetním a síťovým kapacitám v minulosti se nedoporučovalo připojovat klienty přímo k stratum 1 serverů, dnes už to příliš neplatí. 
• stratum 2 - server, jehož přesný čas je odvozen od času serveru stratum 1
• stratum 3 - server, jehož přesný čas je odvozen od času serveru stratum 2.

A takto to jde dál až k stratum 15, který je poslední synchronizovaný server. Stratum 16 označuje nesynchronizovaný server. Server stratum n odkazuje vždy jen na server stratum n+1, tedy nadřazený. Tím jsou eliminovány smyčky, kdyby např. několik serverů ve stejné úrovni strata odkazovalo mezi sebou navzájem.
Čas přenášený v NTP zprávách je tzv. koordinovaný světový čas (UTC). V České republice je UTC+01 (zimní čas) nebo v UTC+02 (letní čas). Začlenění do příslušné časové zóny se děje v rámci nastavení na straně koncové stanice.

Linux

Zřejmě nejrozšířenější je referenční implementace zvaná ntpd. Referenční odkazuje na to, že je vyvíjena přímo lidmi kteří navrhli NTP protokol. Ntpd je možné nainstalovat jako deamona do UNIXu/Linuxu a nebo jako službu běžící na pozadí ve Windows (podrobnosti k tomu zde).

Ve většině distribucí není ntpd předinstalované. takže je potřeba doinstalovat:

apt-get install ntp

Deamon nyní běží. Nyní se podíváme do konfiguračního souboru, který je umístěný v /etc/ntp.conf. To hlavní co nás předně zajímá, jsou přednastavené NTP servery. Např. v Ubuntu nebo Debianu jsou přednastaveny servery z tzv. NTP Poolu. Jde o službu kdy servery, které provozují dobrovolníci, jsou začleněny do společné množiny, ze které si klient sám vybírá nejvýhodnější server. Pokud tedy nechceme využít přednastavené servery lze doplnit do konfiguračního souboru server podle vzoru:

server [IP adresa nebo doménové jméno]

Nic nebrání si přidat více serverů, dokonce si myslím, že je to rozumné. Klient se už sám rozhodne který je nejvhodnější (viz dále). Zde přikládám seznam NTP serverů které používám. Prvních 6 adres jsou přímo dedikované NTP servery. Poslední čtyři řádky využívají NTP pool, který vybírá různé servery podle aktuálních podmínek. Na pořadí v konfiguračním souboru nezáleží:

server ntp.nic.cz
server tik.cesnet.cz
server tak.cesnet.cz
server ntp.muni.cz
server ntp2.muni.cz
server ntp.active24.cz
server 0.cz.pool.ntp.org
server 1.cz.pool.ntp.org
server 2.cz.pool.ntp.org
server 3.cz.pool.ntp.org

Dále nás samozřejmě zajímá, zda vše funguje jak má. K tomu slouží utilita ntpq, která monitoruje činnost ntpd. Výstup do konzole lze získat pomocí příkazu (další možnosti lze nalézt v [4]):

ntpq -p

Tímto jsme dostali výpis používaných NTP serverů s dalšími užitečnými informacemi:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+ntp.nic.cz      .GPS.            1 u  219  256  377    6.199    0.276   0.136
+tik.cesnet.cz   .GPS.            1 u    4  256  377    6.936    0.263   0.157
*tak.cesnet.cz   .GPS.            1 u  140  256  377    6.407   -0.043   0.285
+ns.muni.cz      195.113.144.201  2 u  150  256  377    9.927    0.246   0.210
+nora.ics.muni.c 195.113.144.201  2 u  150  256  377    9.778    0.191   0.124
+ntp.active24.cz 195.113.144.201  2 u  127  256  377    6.155    0.319   0.170
+netopyr.hanacke .GPS.            1 u  168  256  377   14.144    0.218   0.123
+lx.ujf.cas.cz   195.113.144.238  2 u  142  256  377    6.745    0.159   0.137
+pyrrha.fi.muni. 195.113.144.201  2 u  138  256  377    9.999    0.037   0.114

Zkusím vypsat to nejpodstatnější a nejzajímavější, co lze z výše uvedené tabulky vyčíst:

• První sloupec (remote) je jasný. Doménové jméno NTP serveru (může se lišit od adres které jsme zadávali do konfiguračního souboru, protože se může jednat o DNS aliasy). Pokud chceme výpis s IP adresami stačí použít příkaz ntpq -pn.
• Znak který je před DNS názvem určuje v jakém stavu je server vůči klientovy. * značí, že byl tento server vybrán jako preferovaný, např. na základě nejmenšího zpoždění. Znak + označuje další vhodné servery. Znak - označuje servery které nejsou vhodné a pravděpodobně by ani nebyly použity.
• Druhý sloupec (refid) je velmi zajímavý. Označuje jaký referenční zdroj času využívá konkrétní server. Např. ntp.nic.cz má přímo připojené zařízení které získává čas pomocí GPS. Naopak u serverů MUNI a Active24 vidíme, že jako referenční zdroj využívají nadřazený NTP server, tudíž jde o stratum 2 servery.
• Třetí sloupec (st) označuje úroveň, tedy číslo strata.
• Čtvrtý sloupec (t) označuje typ komunikace. Ve většině případů se jedná o unicast, označený jako u. Možnosti jsou ještě b jako broadcast a m jako multicast.
• Pátý sloupec (when) označuje dobu která uplynula od poslední synchronizace se serverem. Hodnota narůstá až do hodnoty poll (viz dále), následně je vynulována, proběhne synchronizace a opět narůstá.
• Šestý sloupec (poll) je proměnlivá hodnota označující jak často bude potřeba zjišťovat přesný čas. Deamon ji určuje podle offsetu. Pokud při předchozím měření odchylky byla zjištěna velká nepřesnost, nastaví se pool na nízkou hodnotu, díky tomu dojde k častější synchronizaci. Hodnota pool je nízká také po startu deamona.
• Sedmý sloupec (reach) poskytuje další možnost jak zkontrolovat zda máme přesný čas. Jde o počítadlo úspěšných pokusů kontaktovat daný NTP server. Začíná se na 0 a postupně, pokud jsou další a další pokusy v řadě úspěšné, se dojde k hodnotě 377. Tudíž pokud vidíte tuto hodnotu, je spojení se serverem stabilní a funkční. 
• Osmý sloupec (delay [ms]) je zpoždění mezi vámi a serverem.
• Devátý sloupec (offset [ms]) je rozdíl vašeho lokálního času a času přijatého ze serveru.
• Desátý sloupec (jitter [ms]) ukazuje kolísání zpoždění.

Z praktického hlediska nás asi nejvíce zajímá zda je nějaký server označen * a několik +. Zbytek hodnot je více méně jen pro specifické účely debugu. Ještě je možné se podívat jestli u některého serveru není příliš velké zpoždění.

SNTP

Simple Network Time Protocol je (jak už název napovídá) zjednodušení protokolu NTP, pro případy kdy je potřeba znát přesný čas, ale ne tak často a nebo ne "tak přesně". SNTP je součástí NTPv4, využívá stejné datagramy. Hlavní rozdíl je v tom, že SNTP neuvažuje zpoždění v síti a předchozí výsledky synchronizace času. V praxi je SNTP klient spuštěn jednorázově (např. pouze jednou za den) a po přijetí času od serveru je ukončen. SNTP je běžně přítomno v levných domácích routerech kde je často jediným způsobem jak nastavit co nejpřesněji čas.

Domácí routery 

Mnohé obyčejné routery, které jsou určeny pro domácí podmínky má v sobě NTP/SNTP klienta. Většinou je potřeba hledat spojení Time Setting nebo Time Config, popř. jen Time ve webové konfiguraci. Náhodně jsem vybral běžný router TP-LINK TL-WDR4300, díky tomu, že je na webu emulace jeho konfigurace. Nastavení času je opravdu jednoduché a v přehledném menu je snadno k nalezení. Je sice možné zadat jen dva servery, ale pro běžné uživatele myslím dostatečné.

Podobné články:

• Synchronizovaný čas z NTP serverů na přepínači TP-LINK TL-SG3210

Zdroje:

1. https://en.wikipedia.org/wiki/Network_Time_Protocol
2. http://www.linuxjournal.com/article/6812 
3. http://www.eecis.udel.edu/~mills/ntp/html/warp.html
4. http://doc.ntp.org/4.1.2/debug.htm 
5. http://www.eecis.udel.edu/~mills/ntp/html/ntpq.html