Cisco IOS: vypnutí slabých šifer u SSH

Cisco IOS umožňuje od verze 15.2 nastavit konkrétní šifrovací a hašovací algoritmy u vestavěného SSH serveru který se používá k managementu zařízení. Následující postup byl ověřen na modelu WS-C2960X-48TD-L s verzí IOS 15.2(5)E2. Verze 15.0 a 12.X toto nastavení neumožňují.

Například OpenVAS reportuje následující algoritmy jako zastaralé a slabé:

3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc.

Necháme si vypsat nabízené algoritmy ve výchozí konfiguraci:
Switch#show ip ssh | inc Encryption|MAC

A dostaneme:
Encryption Algorithms:aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
MAC Algorithms:hmac-sha1,hmac-sha1-96

Z nabízených šifer je nejsilnější šifra AES256 v módu CRT. Povolíme tedy jen tuto jedinou:
Switch(config)#ip ssh server algorithm encryption aes256-ctr

Nejvyšší hašovací algoritmus je HMAC-SHA1. Opět, povolíme jen tento:
Switch(config)#ip ssh server algorithm mac hmac-sha1

Pro kontrolu znovu vypíšeme nabízené algoritmy:
Switch#show ip ssh | inc Encryption|MAC

A výstup pro kontrolu by měl ukazovat toto:
Encryption Algorithms:aes256-ctr
MAC Algorithms:hmac-sha1

Po připojení skrz SSH je možné vidět aktuální sezení a použité šifry:
Switch#show ssh

Connection Version Mode Encryption  Hmac         State                 Username
0          2.0     IN   aes256-ctr  hmac-sha1    Session started       user
0          2.0     OUT  aes256-ctr  hmac-sha1    Session started       user


Zdroje:

• https://supportforums.cisco.com/document/12338141/guide-better-ssh-security
• http://linux.uits.uconn.edu/2014/06/25/ssh-weak-ciphers-and-mac-algorithms/

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