Příspěvky

271

Sítě / Re:IPv6 gateway v jinym /64 subnetu

« kdy: 18. 01. 2017, 16:24:12 »

Pravděpodobně máte na mysli příspěvek Role síťové masky v IPv6. Zkuste si ho přehrát ještě jednou.

Nejde o to, že by mohla být brána v jiné podsíti, to nedává smysl, protože brána slouží pro přístup k jiným podsítím. Jde o to, že brána v IPv6 standardně používá Link-Local adresy, které jsou stále dostupné a vždy na lince, takže žádné jiné adresy na lince už být nemusí a je tedy možné vynutit konfiguraci, kdy komunikace veškerých zařízení, i v rámci jedné společné /64, bude probíhat pouze prostřednictvím brány. To pak umožní izolovat klienty na spojové vrstvě a tím eliminovat spoustu zranitelností vyplývajících ze sdílené spojové vrstvy.

272

Server / Re:Bind 9 občas vrací chyby

« kdy: 12. 01. 2017, 15:08:36 »

S IPv6 to s největší pravděpodobností nesouvisí. Podle záznamu z wiresharku to vypadá, jako by v tu dobu BIND „zapomněl“, že existuje lokální zóna a hledal její obsah na Internetu.

273

Sítě / Re:IPv6 a přístup na web bez AAAA

« kdy: 12. 01. 2017, 10:50:51 »

Tak doufam ze to byl jen muj omyl pri cteni a majorita ipv6 zarizeni s pristupem na web ma a v budoucnu stale bude mit pristup do ipv4 site.

Weby tedy timto zpusobem nejspis neprichazeji o navstevniky?

Trochu ano. První velká nasazení DS-lite v Německu se potýkala se spoustou problémů, zejména plynoucích z přetížení AFTR, což jsou brány provádějící odpouzdření tunelované IPv4 a centrální NAT. Údajně se stávalo, že ve špičkách přestala IPv4 fungovat, zatímco IPv6 běžela normálně. Poskytovatelé obsahu, kteří měli IPv6, byli ve výhodě protože jejich obsah byl dostupný. Ostatní IPv6 narychlo zaváděli. Byl to prý zatím největší impluz k zavádění IPv6 u obsahu.

Stejně tak je IPv6 na straně obsahu oblíbené u bankovních institucí; jejich systémy na předcházení podvodů totiž pracují s IP adresou klienta jako jedním z klíčových faktorů. Pokud je adresa sdílena mezi stovkami zákazníků, účinnost detektoru podvodů klesá. Samozřejmě, aby toto mělo nějaký smysl, musí to být v zemi, kdy platí, že klient má doma buď veřejnou IPv4 adresu, nebo natovanou IPv4 adresu a IPv6. Pokud je to jako u nás, kdy mají lidi doma taky třeba jen NATovanou IPv4, zavedením IPv6 banka nic nezíská.

O provozování IPv6-only sítí jsem kdysi psal: https://www.root.cz/clanky/ipv4-jako-sluzba-aneb-jak-sit-zbavit-dual-stacku/
Od té doby se (bohužel) moc nezměnilo, snad jen Skype už začíná na IPv6 fungovat a 464XLAT je součástí moderních Androidů.

274

Sítě / Re:IPv6 a přístup na web bez AAAA

« kdy: 12. 01. 2017, 10:35:25 »

Ovšem problém vcelku jednoduše řešitelný.

Zas tak jednoduše nikoli. Zvlášť v případě, kdy se pro NAT64 používá jiný než dobře známý prefix 64:ff9b::/96.

Ale pro každého majitele domény, koho by tento problém skutečně trápil, existuje jednoduchá pomoc – zavést IPv6, tím se DNS64 vyřadí z činnosti a stane se zcela transpartentním.

275

Sítě / Re:Veřejné botnet adresy

« kdy: 05. 01. 2017, 16:07:05 »

Seznamy zlobivých IP adres publikuje třeba CZ.NIC jako výstup projektu Turris:

https://www.turris.cz/cs/greylist

276

Odkladiště / Re:Neustálé odsouhlasování cookies mi pije krev

« kdy: 31. 12. 2016, 23:28:29 »

Tak zaprvé by mě zajímalo, jestli se shodneme na tom, že v prohlížečích dnes nelze explicitní souhlas vyjádřit.

Já si naopak myslím, že nastavení prohlížeče je to jediné místo, kde je možné souhlas či nesouhlas vyjádřit. Protože všechny ty lišty, co se všude objevují, obsahují pouze jedno tlačítko, pojmenované „Souhlasím,“ nebo „Zavřít“, a všechny webové stránky, co jsem zatím viděl, fungovaly naprosto stejně (a pravděpodobně i používaly cookies) i v případě, kdy jsem na žádné z těch tlačítek neklikl.

Ani to technicky nedává smysl, stránka neví, kdo se ptá, takže pošle hlavičku instruující k nastavení Cookie. Jen nastavení prohlížeče dokáže reflektovat souhlas uživatele s uložením takové Cookie a případným (ne-)předáním zpět službě při příštím požadavku.

277

Odkladiště / Re:Neustálé odsouhlasování cookies mi pije krev

« kdy: 31. 12. 2016, 18:27:01 »

Díky za zajímavou diskuzi. A ty útoky ad hominem si prosím nechte od cesty.

To, že žádný prohlížeč neumožňuje vyjádřit explicitní souhlas, vůbec nevadí. Protože požadavek na vyjádření explicitního souhlasu v prohlížeči je čistě váš výmysl. Směrnice říká, že explicitní souhlas je možné nahradit vhodným nastavením prohlížeče.

V tom textu směrnice, ale není slovo „nahradit“. Je tam slovo „vyjádřit“:

Je-li to technicky možné a efektivní, může být v souladu s příslušnými ustanovení­mi směrnice 95/46/ES souhlas uživatele se zpracováním údajů vyjádřen vhodným nastavením prohlížeče nebo jiné aplikace.

Čistě jazykovědně mi nepřipadá, že by věta

souhlas uživatele může být vyjádřen vhodným nastavením prohlížeče nebo jiné aplikace

měla zcela totožný význam jako věta

souhlas uživatele může být nahrazen vhodným nastavením prohlížeče nebo jiné aplikace

A pak je skutečně na místě se ptát, zda nastavením prohlížeče, který je nastaven od výroby k ukládání cookies jsem skutečně vyjádřil explicitní souhlas s ukládáním cookies. Pamatuju si, že kdysi se takhle choval jen lynx, který u každé cookie zobrazoval dotaz, zda ji přijmout nebo ne.

278

Odkladiště / Re:Je přístup do online bankovnictví bezpečný?

« kdy: 14. 12. 2016, 20:13:15 »

-podvrhnout IP  adresu webu me banky (zapis do host) -takze i pri kontrole URL  je vse v poradku, ikdyz misto na web banky pristupuji na webovy server utocnika
-certifikat si pro svuj web muze vystavit sam a do meho operacniho systemu dat svou certifikacni autoritu jako duveryhodnou
Takze ja pri kontrole pristupu na korektni URL pres validni HTPPS jsem spokojeny, presto ze pristupuji na web utocnika?

Tohle je zbytečně složitá cesta. Mnohem jednodušší spočívá v MitB, tedy instalaci zlomyslného rozšíření typu Adblock Super, kterému dá uživatel v dobré víře oprávnění číst a měnit data na všech navštívených webech. Pak uživatel otevře adresu banky, načte se mu ze správné URL se správným certifikátem internetové bankovnictví, jen po přihlášení rozšíření jednak odešle přihlašovací údaje útočníkovi, jednak zobrazí autenticky vypadající výzvu bankovní instituce k instalaci speciální bankovní aplikace pro dvoufaktorovou autentizaci. Ještě nejlépe s výhružkou, že bez takovéto aplikace se už příště nepřihlásí. Uživatel si tedy nainstaluje aplikaci, jejímž hlavním smyslem je přeposílat autentizační SMSky útočníkovi.

Takovýto útok je možné provádět plošně a dlouhodobě, nejlépe tak, že zmíněné zlomyslné rozšíření bude plnit svůj původní účel a stane se mezi uživateli oblíbené. Teprve po analýze je možné injektovat cílené útoky na jednotlivé bankovní instituce.

279

Odkladiště / Re:Kampaně proti Let's Encrypt

« kdy: 29. 11. 2016, 00:16:29 »

nejsou vubec pri vyssich nastaveni secure a taky to sifrovani nemaj 2048bit.

Můžeš tohle trochu rozvést? Certifikáty samozřejmě používají 2048bitové RSA a umějí i větší, případně ECDSA. Nastavení síly šifry nezáleží na certifikátu, ale na nastavení serveru.

vono napriklad ten comodo wildcard certifikat za 60 usd je vsade green - full valid a taky bezpecnej.

Tím jako myslíš, že je v něm EVIL bit nastavený na nulu a proto nejde zneužít?

280

Odkladiště / Re:Platební karty s NFC

« kdy: 07. 11. 2016, 16:12:06 »

BTW, nepremysleli jste nekdo o tom, jak znici v bezkontatktni karte ten RFID chip, ale tak, aby zbytek karty zustal funkcni? Musim rici, ze bezkontaktni platby, i kdyz maji omezenou vysi, se mi moc nelibi.

https://www.youtube.com/watch?v=c9vTvbHgi2M

Debetní karty už dneska NFC čipy mají prakticky všechny. Nevyplatí se vyrábět dvě verze. Ale zatím mi tedy vždy obě banky (ČS i RB) na požádání možnost platit bezkontaktně zablokovaly. Možná jen paní na přepážce netušila, jak tu žádost vyplnit.

Komerční banka i mBank se ptala před vydáním, zda si přeji bezkontaktní, nebo ne.

"Ta pani v bance" mi dokonce rikala, ze karty s nejakym jistym datem platnosti budou vymeneny predcasne za nove bezkontaktni. Cili ze normalne fungujici kontaktni karty s jeste platnym datem budou vymenovany za bezkontaktni.

Nevím o tom, že by se něco takového vůbec někde dělalo, a to ani při zavádění kontaktních čipů. Platnost karet je do 5 let, obmění se automaticky (všechny nové karty dnes již NFC mají). Plošné výměny se dělají při bezpečnostních problémech nebo rebrandování, kdy se mění bankovní ID (Citi → Raiffeisen), ale ne kvůli novým platebním metodám.

Poštovní spořitelna takhle nedávno plošně vyměnila všechny MaxKarty (neembossované Visa Electron s kontaktním čipem) za embossované bezkontaktní karty MasterCard Debit. Uprostřed platnosti. Zřejmě MasterCard nabídl takovou nabídku, že to za to stálo.

281

Sítě / Re:Verejna IP adresa /32

« kdy: 06. 10. 2016, 16:20:15 »

Zkus parametr src u definice záznamu ve směrovací tabulce:

Kód: [Vybrat]

# ip rou replace default via 10.10.10.1 src <veřejná adresa>

282

Sítě / Re:Blokování přístupu k ARES z prefixu 2001:470::/32 (HE IPv6)

« kdy: 17. 09. 2016, 22:14:30 »

Proč ta agresivita? Meritum věci přece spočívá v tom, že provozovatel systému zjistil aktivitu, která byla v rozporu s jím stanovenými pravidly a přijal opatření, aby této aktivitě zabránil. Původce aktivity změnil postup, následovala další reakce provozovatele atd. až k finálnímu řešení.
Docela by mne zajímalo, jak jinak by měl provozovatel REÁLNĚ postupovat, aby byli zdejší diskutéři spokojení - prosil bych bez emocí, konkrétní návrhy.

Bohužel, blokování celého prefixu /32, který je sdílen uživateli z celého světa, je naprosto nepřiměřené protiopatření. Je to asi jako, kdyby odhalili zneužívání prostřednictvím mobilních dat jednoho operátora a na základě toho odstřihli všechny zákazníky daného operátora. To už můžou rovnou službu vypnout kompletně.

283

Server / Re:Ako vytvorit CNAME zaznam v bind?

« kdy: 26. 08. 2016, 22:44:48 »

Jednoduše do souboru přidáte řádek:
ABCDEF.WWW    IN CNAME XYZ.example.com.
A zvednete sériové číslo v SOA záznamu, aby si toho všiml i případný slave server.


Jinak ten žolíkový záznam ( * IN A 192.168.1.1) není z nejrůznějších důvodů vhodný; vždy je lepší vyjmenovávat jednotlivá doménová jména a vyvarovat se duplicitním A záznamům (raději používat CNAME aliasy).

284

Hardware / Re:Pobočková ústředna

« kdy: 01. 08. 2016, 12:13:53 »

Pokud neni vyzadovano pouzivani vice nez 2 telefonu, popr. pri >2 ks by nevadilo, pokud budou vsechny mluvit navzajem spolu, pak neni potreba ustredna a staci pripojit founy na ss napeti, driv podle normy 60V, typicky u pobockovych ustreden 48V.…

60V v dobe analogu, dnes na JTS 48V. Vyjimkou jsou dlouha venkovska vedeni ktera jsou vyjimecne nastavena nad 48V. 24V bohate na pobockove telefony staci.

Především, telefonní linka je proudová smyčka řádově 20 mA, nikoli napěťový zdroj. Pokud telefon připojíte k tvrdému zdroji napětí, ať už 24 V, nebo 48 V, pravděpodobně unikne magický kouř, který dokud byl uvnitř, zajišťoval telefonnímu aparátu funkčnost. Je tedy potřeba použít jakýkoli zdroj stejnosměrného proudu, který při vyzvedutí protlačí vedením a přístrojem/přístroji nejvýše několik desítek mA.  Na napětí naprázdno nezáleží v podstatě vůbec. A na vyzvánění je potřeba střídavé napětí aspoň tak 80 V (klidně více), ideálně s kmitočtem 25 Hz (50Hz většinou funguje také).

Ideální je tedy sehnat starou vyřazenou pobočkovou ústřednu, nebo třeba VoIP bránu se dvěma FxS porty.

285

Sítě / Re:IPv6 a základní fakta

« kdy: 29. 07. 2016, 14:08:30 »

(případně současné služby budou přes IPv6 nějak lepší)

Taková služba již existuje - jmenuje se YouTube Na šestkové síti ty HD videa prostě načítají rychleji a nikdy se mi nestalo, že by se v průběhu přehrávání objevil buffering.

Tohle je bohužel relativní. Slyšel jsem naopak stížnosti, že se videa z YouTube nenačítají a vypnutí IPv6 pomáhá. Je to proto, že snad všechny Google Content Cache, co jsou v ČR instalované, mají pouze IPv4, takže IPv6 je odbavována tranzitní konektivitou ze zahraničí.

Pak také často zlobí geolokace, například v síti CESNET/ČVUT jsem se už několikrát setkal s tím, že třeba VEVO videa přes IPv4 hrála bez problému, zatímco přes IPv6 „nebyla určena pro mou zemi“.