Marec 4, 2017

Priama komunikácia zariadení pripojených na Microsoft Azure IoT Hub cez MQTT nie je podporovaná

Microsoft Azure poskytuje možnosť spustenia IoT Hub. To môže znieť ako dobrá správa pre autorov IoT riešení, pretože IoT Hub podporuje MQTT. Každopádne je veľmi dôležité poznamenať, že Azure IoT Hub funguje iným spôsobom než Mosquitto. Tento rozdiel má výrazný dopad na to, akým spôsobom sa musí postaviť architektúra IoT riešenia.

Poďme sa pozrieť na rozdiely.

Predvolený port:

  • Mosquitto používá port 1883, ktorý nie je zabezpečený. Zabezpečenie TLS je možné zapnúť.
  • IoT Hub používá port 8883 zabezpečený pomocou TLS/SSL. Nešifrovaná varianta nie je povolená.

Publikácia a odber správ:

Toto predstavuje zásadný rozdiel. V prípade Mosquitta môžete jednoducho vytvoriť sieť zariadení, ktorá dokážu priamo na seba navzájom reagovať. Ďaľšiu logiku je možné zapojiť pomocou technológie ako napríklad Node-RED. V prípade IoT Hubu musí byť celá interakcia riadená cloudom.

Pokiaľ máte v pláne experimentovať s IoT Hubom a MQTT, tak odporúčam článok, ktorý napísal Satish Pagare. V článku je vysvetlené, ako je možné komunikovať s IoT Hubom pomocou mosquitto_sub a mosquitto_pub.

Február 16, 2010

Drupal profesionálne

Drupal má modulárnu štruktúru, ktorá umožňuje flexibilne pridávať a odoberať funkcionalitu. Toto so sebou nesie určitú daň. Musíte sa jednoducho postarať o jednotlivé moduly pri upgradoch.

Drupalovký mainstream hlása, že Drupal sa upgraduje tak, že administrátor ako besný odklikáva a potom znova zaklikáva všetky moduly. Naviac k tomu ručne sťahuje nové verzie modulov. Keď som prvý krát videl tento “hrdinský” video návod, tak som sa skoro osypal. Toľko premrhaného času. Niekoľko rokov sa venujem rôznym optimalizáciam a vývoju automatizačných nástrojov. S tak neefektívnym prístupom jednoducho nemôžem súhlasiť. Tento návod volal po náhrade niečim jednoduchším.

Našťastie niekto už dostal dobrý nápad a vytvoril nástroj Drush. Pekne z príkazového riadku upgradnete všetko. Tak má vyzerať správna automatizácia. Tu je ukážka ako funguje Drush, z článku Drush – viac piva, menej makačky.

Tu je malý návod ako aktualizovať multi-site Drupal. V adresári, v ktorom sú kódy Drupalu zadajte:

drush -l moj-skvely-drupal update

Pokiaľ chcete vidieť, koľko bezpečnostných dier obsahuje váš Drupal, zadajte jednoducho:

drush -l moj-skvely-drupal status

Nezabudnite zálohovať.

Ďalším problémom, s ktorým sa “progresívne a flexibilné” web dizajnérske firmy stretnú sú warningy a chybové hlásenia. Je jasné, že návštevníkom webu nechceme zobrazovať všetky PHP warningy, tak je dobré ich skryť. To je ok, pokiaľ ich monitorujeme.

Mňa len tak niečo neprekvapí. Každopádne som narazil na jednu vec, pri ktorej som zostal v nemom úžase civieť na obrazovku. Praktiku so skrývaním hlásení, použili “odborníci” na zakrytie chýb v administračnom rozhraní. Zjavne sa onej firmičke nechcelo riešiť “prkotiny” a tak schovali všetky Drupalovské hlášky, aby ich klient-administrátor nevidel.

Klient zaplatil a v očiach mu bolo vidieť šťastný úsmev (tak to tvrdia marketingové materiály). Začal používať svoj nový Drupal, ktorý sa občas choval veľmi divotvorne. Napríklad nešli ukladať zmeny v nastaveniach modulov.

Po prehodení grafickej témy v administračnom rozhraní na základnú drupalovskú tému, sa zrazu objavilo na administrátorskej obrazovke more červených závažných upozornení. Hlášky jasne hovorili o tom, že Drupal je mierne chromý, kríva na ľavé CSS a z pravej tabuľky mu vyteká index.

Deti! Prosím, toto fakt klientom nerobte. Neskrývajte vitálne informácie! Napríklad: chýba 5 bezpečnostných aktualizácií.

Pokiaľ by ste potrebovali školenie na Drush, prípade konzultáciu na multi-site administráciu Drupalu, neváhajte a ozvite sa.

Január 10, 2010

Vaše CMS je deravé ako rešeto

Aktualizované: pridané ďalšie užitočné informácie.

Je to tak. Nuž, nič moc s tým nenarobíte. Nech si zvolíte akýkoľvek softvér, vždy obsahuje chyby. Ako zabrániť útočníkovi v zneužití chyby?

Prvá a najpodstatnejšia ochrana je záloha. Stále existuje prekvapujúce množstvo webov, ktoré sú bohaté na obsah a autori nemajú skonfigurovanú ani najjednoduhšiu zálohu. V naivnej viere sa ženú do budúcnosti a dúfajú, že ich neupgradovaný CMS nenájde žiadny škaredý robot. Věd určite sa nemôže stať, aby im niekto kompletne zmazal web.

Dobrá záloha vás ochráni aj pred veľkou chybou, ako je napríklad kompletný výmaz všetkých vašich dát. Nie raz som už videl, ako človek začal mazať. Bohužial mazal iný adresár, než si myslel.

Ďalším prvkom ochrany je správna konfigurácia web servera. PHP Safe Mode síce zďaleka nie je elegantné riešenie na všetko, ale ochráni váš web server pred jednoduchými spôsobmi zneužitia. Je až zarážajúca ignorancia PHP vývojárov, ktorí nie sú ochotní napísať aplikáciu tak, aby bežala so zapnutým Safe Mode. Toto svoje správanie prehlasujú za feature a náramne ich prekvapí, keď im cez ich skvelú aplikáciu vytiahnu zoznam všetkých účtov zo servera.

Tretím prvkom je sledovanie bezpečnostných chýb, ktoré sa objavia. Nejedná sa o nič komplikované. Zvládne to aj bežný používateľ, ktorý vie pracovať s RSS. Čítačku stačí nasmerovať na Open Source Vulnerability Database a sledovať RSS softvéru, ktorý používate.

Krátky prehľad zraniteľností:

Za odkazy na OSVDB ďakujem Pavlovi Ľuptákovi zo SOIT.

Update: Pôvodne bol tento článok zameraný len základné problémy s PHP. Pavol však napísal ešte ďalší kus užitočných informácii. Časť z nich nájdete aj v jeho prezentácii. Tu je citát z jeho príspevku:

PHP Safe mod nedoporucujem pouzivat (je to “deprecated v PHP 5.3” a kompletne sa to odstrani v PHP 6), zo strany programatorov treba striktne pouzivat len
prepared statements (parametrizovane ziadosti), vid:http://php.net/manual/en/pdo.prepared-statements.php
http://sk.php.net/manual/en/function.mysqli-bind-param.php
idealne nasadit 3rd layer architekturu aplikacie (stored procedury) vstupy/vystupy idealne whitelistovat (povolit len to, co je potrebne a zvysok zakazat), proti XSS pouzivat HTML entity
http://sk2.php.net/manual/en/function.htmlentities.php
Ak ako programatori neviete co od radosti, tak mozete skusit aj PHPIDS
http://php-ids.org/

Ak mate PHP aplikaciu, do ktorej nevidite a chcete ju ochranit, tak urcite treba PHP Suhosin http://www.hardened-php.net/suhosin/, na Apacheovi
mod_security http://www.modsecurity.org/, voci SQL injection nasadit Core GRASP http://grasp.coresecurity.com/ alebo GreenSQL http://www.greensql.net/
Virtualhosty striktne segregovat (suexec/suphp) a chrootovat pod  neprivilegovanym uzivatelom. A v ramci paranoie nasadit SELinux so zapnutym RBAC/DTE/MLS idealne v strict mode.

A po tomto vsetko si mozes povedat, ze to mas trochu bezpecne …