středa 12. října 2016

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

středa 6. července 2016

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

sobota 14. listopadu 2015

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

pondělí 21. září 2015

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:

středa 19. srpna 2015

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:
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

čtvrtek 2. dubna 2015

Vytvoření a nastavení běžného uživatele na linuxovém serveru

Úvod

Krátký článek věnující se vytvoření účtu pro "běžného" uživatele na linuxovém serveru (postup byl otestován na Debianu a Ubuntu). Postup předpokládá funkční server s Apache2, OpenSSH a vsftpd jako FTP server.

Co chceme aby bylo výsledkem:
  • uživatel bez možnosti shellu
  • uživatel se nemůže připojit přes SSH k serveru
  • uživatel má přístup přes FTP/FTPS ale je zamknutý v domovském adresáři
  • uživatel má vyhrazený adresář pro svoje soukromá data
  • uživatel má svoji veřejnou složku pro www stránky

Postup

Vytvoření uživatele se jménem "uzivatel" + domácí složku.
useradd -d /home/uzivatel -m uzivatel
Přiřadíme nově vytvořeného uživatele do skupiny "uzivatele", kteří nebudou mít přístup k SSH.
usermod -g uzivatele uzivatel
 "Vypneme" uzivateli shell.
usermod -s /bin/false uzivatel
 Nyní nastavíme SSH server. Otevřeme konfigurační soubor.
nano /etc/ssh/sshd_config
A např. na konec přidáme:
DenyGroups uzivatele
 uložíme (Ctrl+X a poté Y).

Restartujeme SSH server
 service ssh restart
Nyní povolíme funkci chroot na FTP serveru.Otevřeme konfiguraci:
nano /etc/vsftpd.conf
 a zde odkomentujeme (odstraníme # na začátku) řádek
chroot_local_user=YES
uložíme (Ctrl+X a poté Y). Restart FTP serveru:
/etc/init.d/vsftpd restart
Změníme vlastníka domácí složky z "uzivatele" na "root" (pro fungující chroot).
chown root:root /home/uzivatel/
 Nyní nám ale nefunguje přihlášení (uživatel totiž nevlastní adresář do kterého se standardně přihlašuje), proto je potřeba následující "trik".

Vytvoříme složku "data" kam si bude uživatel ukládat svoje privátní soubory.
 mkdrir /home/uzivatel/data
A této složce již nastavíme jako vlastníka uživatele "uzivatel".
chown uzivatel:uzivatele /home/uzivatel/data
 Vytvoříme složku "public_html" kam si bude uživatel ukládat svoje veřejné soubory (např. webové stránky)
mkdir /home/uzivatel/public_html
chown uzivatel:uzivatele /home/uzivatel/public_html
Výsledkem je, že "uzivatel" nemůže zapisovat přímo do /home/uzivatel, což je trochu divné, ale na druhou stranu má dvě složky, které jasně oddělují co je veřejné a co ne.

U webového serveru Apache2 aktivujeme modul userdir.
a2enmod userdir
Restartujeme Apache2.
service apache2 restart
Hotovo.  Uživatel má svoje veřejné soubory na adrese http://nazevserveru.domena/~uzivatel. Adresář "data" vidí jen on sám přes FTP.

Podobné články:
Aktualizace:
  • 6.4.2015 - doplněno nastavení vsftpd.
Zdroje:
  1.  http://www.linuxsoft.cz/article.php?id_article=248
  2.  http://forum.ubuntu.cz/index.php?topic=71916.0;prev_next=next#new
  3.  http://www.linuxexpres.cz/praxe/sprava-linuxoveho-serveru-prakticke-rady-pro-zabezpeceni-ssh
  4.  http://www.cyberciti.biz/tips/vsftp-chroot-users-limit-to-only-their-home-directory.html
  5.  http://ubuntuserverguide.com/2012/10/how-to-enable-and-configure-apache2-userdir-module-in-ubuntu-server-12-04.html
  6. http://www.howtogeek.com/howto/ubuntu/add-a-user-on-ubuntu-server/ 

středa 28. ledna 2015

Monitorování mobilní sítě aplikací PhoNetInfo

Další aplikací, kterou lze využít k zobrazení informací z mobilní sítě je PhoNetInfo. Kromě parametrů sítě aplikace umožňuje zobrazit mnoho dalších informací o telefonu samotném (např. číslo firmwaru, kapacitu baterie, číslo IMEI a další). Zde se zaměřím jen na informace ze sítě. V článku je zobrazeno prostředí Symbian Belle (Nokia N8). PhoNetInfo je dostupné i pro Windows Mobile 8.

Parametry sítě lze nalézt v záložce Network.


Popis jednotlivých řádků je následující:
  1. Úroveň přijímaného signálu v dBm.
  2. Plný název sítě.
  3. Zkrácený název sítě.
  4. Tag sítě
  5. Stav telefonu vůči síti. Přihlášený nebo nepřihlášený, domácí nebo roamingová síť.
  6. Kód země (MCC). Kompletní seznam např. zde.
  7. Kód sítě (MNC). Hodnota je zde opravdu číselná, tedy 02, tož je shodou okolností kód pro operátora O2.
  8. Typ sítě z pohledu "generace". 3G = WCDMA (UTRA FDD). 2G = GSM.
  9. Typ přístupové metody. 3G = UTRAN. 2G = GSM.
  10. Kód místní oblasti (LAC). První hodnota decimálně, v závorce hexadecimálně.
  11. Identifikace buňky. V GSM klasické Cell ID (CID). V UMTS se používá kombinace RNC ID (2 bajty) a Cell ID (4 bajty), to dohromady dává tzv. UTRAN Cell ID (LCID). Na obrázku výše je RNC ID 3803 a Cell ID 50098. Obvykle bývá Cell ID stejné pro GSM i UMTS. Prvek RNC je záležitost jen sítí UMTS.
  12. "Domácí zóna". Nemám bližší informace o co se jedná.
  13. Dostupnost GPRS. Informace zda síť nabízí GPRS. (Teoreticky to platí i pro EDGE.)
  14. Dostupnost GPRS z hlediska toho jestli je telefon připojen a jsou mu vyhrazeny přenosové prostředky.
PhoNetInfo nenabízí logování v údajů v čase. Nicméně umožňuje aktuální hodnoty z obrazovky uložit do textového souboru.