Viry a Červi

Crypto exchange Kraken accuses blockchain security outfit CertiK of extortion

The Register - Anti-Virus - 20 Červen, 2024 - 19:35
Researchers allegedly stole $3M using the vulnerability, then asked how much it was really worth

Kraken, one of the largest cryptocurrency exchanges in the world, has accused a trio of security researchers of discovering a critical bug, expoliting it to steal millions in digital cash, then using stolen funds to extort the exchange for more.…

Kategorie: Viry a Červi

Russia's cyber spies still threatening French national security, democracy

The Register - Anti-Virus - 20 Červen, 2024 - 14:27
Publishing right before a major election is apparently just a coincidence

A fresh report into the Nobelium offensive cyber crew published by France's computer emergency response team (CERT-FR) highlights the group's latest tricks as the country prepares for a major election and to host this year's Olympic and Paralympic Games.…

Kategorie: Viry a Červi

Qilin: We knew our Synnovis attack would cause a healthcare crisis at London hospitals

The Register - Anti-Virus - 20 Červen, 2024 - 12:29
Cybercriminals claim they used a zero-day to breach pathology provider’s systems

Interview  The ransomware gang responsible for a healthcare crisis at London hospitals says it has no regrets about its cyberattack, which was entirely deliberate, it told The Register in an interview.…

Kategorie: Viry a Červi

Analysis of user password strength

Kaspersky Securelist - 18 Červen, 2024 - 13:30

The processing power of computers keeps growing, helping users to solve increasingly complex problems faster. A side effect is that passwords that were impossible to guess just a few years ago can be cracked by hackers within mere seconds in 2024. For example, the RTX 4090 GPU is capable of guessing an eight-character password consisting of same-case English letters and digits, or 36 combinable characters, within just 17 seconds.

Our study of resistance to brute-force attacks found that a large percentage of passwords (59%) can be cracked in under one hour.

How passwords are typically stored

To be able to authenticate users, websites need a way to store login-password pairs and use these to verify data entered by the user. In most cases, passwords are stored as hashes, rather than plaintext, so that attackers cannot use them in the event of a leak. To prevent the password from being guessed with the help of rainbow tables, a salt is added before hashing.

Although hashes are inherently irreversible, an attacker with access to a leaked database can try to guess the passwords. They would have an unlimited number of attempts, as the database itself has no protection against brute-forcing whatsoever. Ready-made password-guessing tools, such as hashcat, can be found online.


Our study looked at 193 million passwords found freely accessible on various dark web sites. Kaspersky does not collect or store user passwords. More details are available here and here.

We estimated the time it takes to guess a password from a hash using brute force and various advanced algorithms, such as dictionary attacks and/or enumeration of common character combinations. By dictionary we understand here a list of character combinations frequently used in passwords. They include, but are not limited to real English words.

Brute force attacks

The brute-force method is still one of the simplest and most straightforward: the computer tries every possible password option until one works. This is not a one-size-fits-all approach: enumeration ignores dictionary passwords, and it is noticeably worse at guessing longer passwords than shorter ones.

We analyzed the brute-forcing speed as applied to the database under review. For clarity, we have divided the passwords in the sample into patterns according to the types of characters they contain.

  • a: the password contains only lowercase or only uppercase letters.
  • aA: the password contains both lowercase and uppercase letters.
  • 0: the password contains digits.
  • !: the password contains special characters.

The time it takes to crack a password using the brute-force method depends on the length and the number of character types. The results in the table are calculated for the RTX 4090 GPU and the MD5 hashing algorithm with a salt. The speed of enumeration in this configuration is 164 billion hashes per second. The percentages in the table are rounded.

Password pattern Share of passwords of this type in the dataset, % Share of brute-forceable passwords (by pattern, %) Maximum password length in characters by crack time < 60 s 60 s to 60 min 60 min to 24 h 24 h to 30 d 30 d to 365 d > 365 d 24 h to 30 d 30 d to 365 d > 365 d aA0! 28 0,2 0,4 5 0 9 85 — 9 10 a0 26 28 13 15 11 10 24 11 12 13 aA0 24 3 16 11 0 15 55 — 10 11 a0! 7 2 9 0 14 15 59 9 10 11 0 6 94 4 2 0 0 0 — — — a 6 45 13 10 9 6 17 12 13 14 aA 2 15 22 11 14 0 38 10 — 11 a! 1 6 9 11 0 11 62 — 10 11 aA! 0,7 3 2 12 10 0 73 9 — 10 0! 0,5 10 27 0 18 13 32 10 11 12 ! 0,006 50 9 10 5 6 19 11 12 13

The most popular type of passwords (28%) includes lowercase and uppercase letters, special characters and digits. Most of these passwords in the sample under review are difficult to brute-force. About 5% can be guessed within a day, but 85% of this type of passwords take more than a year to work out. The crack time depends on the length: a password of nine characters can be guessed within a year, but one that contains 10 characters, more than a year.

Passwords that are least resistant to brute-force attacks are the ones that consist of only letters, only digits or only special characters. The sample contained 14% of these. Most of them can be cracked within less than a day. Strong letter-only passwords start at 11 characters. There were no strong digit-only passwords in the sample.

Smart brute-force attacks

As mentioned above, brute force is a suboptimal password-guessing algorithm. Passwords often consist of certain character combinations: words, names, dates, sequences (“12345” or “qwerty”). If you make your brute-force algorithm consider this, you can speed up the process:

  • bruteforce_corr is an optimized version of the brute-force method. You can use a large sample to measure the frequency of a certain password pattern. Next, you can allocate to each variety a percentage of computational time that corresponds to its real-life frequency. Thus, if there are three patterns, and the first one is used in 50% of cases, and the second and third in 25%, then per minute our computer will spend 30 seconds enumerating pattern one, and 15 seconds enumerating patterns two and three each.
  • zxcvbn is an advanced algorithm for gauging password strength. The algorithm identifies the pattern the password belongs to, such as “word, three digits” or “special character, dictionary word, digit sequence”. Next, it calculates the number of iterations required for enumerating each element in the pattern. So, if the password contains a dictionary word, finding it will take a number of iterations equal to the size of the dictionary. If a part of the pattern is random, it will have to be brute-forced. You can calculate the total complexity of cracking the password if you know the time it takes to guess each component of the pattern. This method has a limitation: successful enumeration requires specifying a password or assuming a pattern. However, you can find the popularity of patterns by using stolen samples. Then, as with the brute-force option, allocate to the pattern an amount of computational time proportional to its occurrence. We designate this algorithm as “zxcvbn_corr”.
  • unogram is the simplest language algorithm. Rather than requiring a password pattern, it relies on the frequency of each character, calculated from a sample of passwords. The algorithm prioritizes the most popular characters when enumerating. So, to estimate the crack time, it is enough to calculate the probability of the characters appearing in the password.
  • 3gram_seq, ngram_seq are algorithms that calculate the probability of the next character depending on n-1 previous ones. The proposed algorithm starts enumerating one character, and then sequentially adds the next one, while starting with the longest and most frequently occurring n-grams. In the study, we used n-grams ranging from 1 to 10 characters that appear more than 50 times in the password database. The 3gram_seq algorithm is limited to n-grams up to and including three characters long.
  • 3gram_opt_corr, ngram_opt_corr is an optimized version of n-grams. The previous algorithm generated the password from the beginning by adding one character at a time. However, in some cases, enumeration goes faster if you start from the end, from the middle or from several positions simultaneously. *_opt_* algorithms check the varieties described above for a specific password and select the best one. However, in this case, we need a password pattern that allows us to determine where to start generating from. When adjusted for different patterns, these algorithms are generally slower. Still, they can provide a significant advantage for specific passwords.

Also, for each password, we calculated a best value: the best crack time among all the algorithms used. This is a hypothetical ideal case. To implement it, you will need to “guess” an appropriate algorithm or simultaneously run each of the aforementioned algorithms on a GPU of its own.

Below are the results of gauging password strength by running the algorithms on an RTX 4090 GPU for MD5 with a salt.

Crack time Percentage of brute-forceable passwords ngram_seq 3gram_seq unogram ngram_opt
Best < 60 s 41% 29% 12% 23% 10% 27% 10% 45% 60 s to 60 min 14% 16% 12% 15% 12% 15% 10% 14% 60 min to 24 h 9% 11% 12% 11% 12% 9% 6% 8% 24 h to 30 d 7% 9% 11% 10% 11% 9% 9% 6% 30 d to 365 d 4% 5% 7% 6% 8% 6% 10% 4% > 365 d 25% 30% 47% 35% 47% 35% 54% 23%

The bottom line is, when using the most efficient algorithm, 45% of passwords in the sample under review can be guessed within one minute, 59% within one hour, and 73% within a month. Only 23% of passwords take more than one year to crack.

Importantly, guessing all the passwords in the database will take almost as much time as guessing one of them. During the attack, the hacker checks the database for the hash obtained in the current iteration. If the hash is in the database, the password is marked as cracked, and the algorithm moves on to working on the others.

The use of dictionary words reduces password strength

To find which password patterns are most resistant to hacking, we calculated the best value for an expanded set of criteria. For this purpose, we created a dictionary of frequently used combinations of four or more characters, and added these to the password pattern list.

  • dict: the password contains one or more dictionary words.
  • dict_only: the password contains only dictionary words.
Password pattern Share of passwords, % Share of passwords that can be cracked with a dictionary attack (by pattern, %) Maximum password length in characters by crack time < 60 s 60 s to 60 min 60 min to 24 h 24 h to 30 d 30 d to 365 d > 365 d 24 h to 30 d 30 d to 365 d > 365 d dict_a0 17 63 15 8 5 3 7 10 11 12 aA0! 14 5 6 5 5 3 76 6 7 8 dict_aA0 14 51 17 10 7 4 11 9 10 11 dict_aA0! 14 34 18 12 10 6 20 7 8 8 a0 10 59 22 6 6 1.8 6 10 11 12 aA0 10 19 13 13 6 7 42 9 10 11 0 6 92 5 1.5 1.3 0 0 15 — — dict_a0! 5 44 16 10 8 5 17 9 9 10 dict_a 4 69 12 6 4 2 6 11 12 13 a0! 2 31 19 13 9 5 23 9 9 10 a 1.2 76 7 6 3 3 6 11 12 13 dict_aA 1.2 56 15 8 6 3 11 9 10 10 dict_a! 0.8 38 16 10 8 5 23 8 9 10 aA 0.7 26 10 28 7 2 27 9 10 10 dict_aA! 0.5 31 17 11 10 6 26 8 9 9 0! 0.4 53 15 8 7 5 13 9 10 11 dict_only 0.2 99.99 0.01 0.0002 0.0002 0 0 18 — — dict_0 0.2 89 6 2 2 0 0 15 — — aA! 0.2 11 8 10 16 3 52 8 9 9 a! 0.1 35 16 10 9 5 25 8 9 10 dict_0! 0.06 52 13 7 6 4 17 9 10 11 ! 0.006 50 10 6 8 4 20 8 9 10

The majority (57%) of the passwords reviewed contained a dictionary word, which significantly reduced their strength. Half of these can be cracked in less than a minute, and 67% within one hour. Only 12% of dictionary passwords are strong enough and take more than a year to guess. Even when using all recommended character types (uppercase and lowercase letters, digits and special characters), only 20% of these passwords proved resistant to brute-forcing.

It is possible to distinguish several groups among the most popular dictionary sequences found in passwords.

  • Names: “ahmed”, “nguyen”, “kumar”, “kevin”, “daniel”;
  • Popular words: “forever”, “love”, “google”, “hacker”, “gamer”;
  • Standard passwords: “password”, “qwerty12345”, “admin”, “12345”, “team”.

Non-dictionary passwords comprised 43% of the sample. Some were weak, such as those consisting of same-case letters and digits (10%) or digits only (6%). However, adding all recommended character types (the aA0! pattern) makes 76% of these passwords strong enough.


Modern GPUs are capable of cracking user passwords at a tremendous speed. The simplest brute-force algorithm can crack any password up to eight characters long within less than a day. Smart hacking algorithms can quickly guess even long passwords. These use dictionaries, consider character substitution (“e” to “3”, “1” to “!” or “a” to “@”) and popular combinations (“qwerty”, “12345”, “asdfg”).

This study lets us draw the following conclusions about password strength:

  • Many user passwords are not strong enough: 59% can be guessed within one hour.
  • Using meaningful words, names and standard character combinations significantly reduces the time it takes to guess the password.
  • The least secure password is one that consists entirely of digits or words.

To protect your accounts from hacking:

  • Remember that the best password is a random, computer-generated one. Many password managers are capable of generating passwords.
  • Use mnemonic, rather than meaningful, phrases.
  • Check your password for resistance to hacking. You can do this with the help of Password Checker, Kaspersky Password Manager or the zxcvbn
  • Make sure your passwords are not contained in any leaked databases by going to haveibeenpwned. Use security solutions that alert users about password leaks.
  • Avoid using the same password for multiple websites. If your passwords are unique, cracking one of them would cause less damage.

pfSense, VLANy, proxy, … aneb začínáme krotit divočinu v domácí síti

VIRY.CZ - 29 Květen, 2024 - 09:30

Po čtrnácti dnech je tu závěrečný díl celé série o zabezpečení chytré domácnosti. Pokud tedy nechcete mít doma trojského koně v podobě čínské fotovoltaiky či jiných čínských chytrých zařízení, zde je rozuzlení celé problematiky. A vlastně, ono tohle řešení nabídne i daleko vyšší komfort než řada oficiálních řešení od výrobců!

Předem hlásím, že existuje hromada dalších způsobů, jak si zabezpečit domácí síť a jakým způsobem zajistit dostupnost chytrých zařízení z internetu. Já jsem to zrealizoval následovně.

VLANy – oddělené sítě a přesto provázané

Domácí síť mám rozdělenu do 4 VLAN s využítím IEEE 802.1Q a takhle to mám jak na úrovni bezdrátové (WiFi síť), tak i „drátové“ (ethernetové kabely CAT6). Poněkud úsměvná je ale realita, kdy mám po domě nataženo přes 300m ethernetového kabelu, v každé místnosti minimálně 2 zásuvky, za TV skříní hned 4 a přesto jsem ani tu televizi kabelem nepřipojil. 24-portový switch s podporou VLAN tak byla volba typu „kanónem na vrabce“. Zpět ale k VLAN. Mám nakonec tyto:

  • IOT – zde mám všechna chytrá zařízení, včetně IP kamer, Shelly zařízení, Android TV + Home Assistant nainstalovaný na Raspberry Pi 3.
  • SERVERS – zde mám NAS Synology a UniFi controller (v provozu na Raspberry Pi).
  • PRIVATE – zde jsou zařízení jako stolní PC, notebook, mobilní telefony, tiskárna.
  • GUEST – pro účely Guest WiFi. Vlastně velice podobné IOT, ale včetně izolace zařízení.

Home Assistant pro správu IOT zařízení by měl být z logiky věci spíše ve VLAN SERVERS, nicméně využívám toho, že takhle dokáže automaticky detekovat nová zařízení na stejném segmentu sítě (typicky když dokoupím další Shelly komponentu) a celá topologie sítě je o něco jednodušší.

pfSense – srdce celé infrastruktury

Routování mezi VLANama obstarává pfSense, stejně jako funkci firewallu a dalších služeb. Nejprve jsem provozoval pfSense+ na oficiálním zařízení Netgate 1100. Jakmile si ale začnete s pfSense více hrát, zapínat inspekci provozu a další služby, velice rychle narazíte na limit RAM o velikosti 1 GB. Tudíž později došlo k výměně za výkonější stroj se 4 GB RAM – PC Engines s procesorem AMD GX-412TC-quad core. Bohužel AMD další vývoj těchto chipsetů ukončil, takže pokud to umře, do třetice to bude zase něco zcela jiného, avšak stále s pfSense.

pfSense má dlouhou historii. Je tu s námi od roku 2004, kdy se oddělil od jiné legendy – m0n0wall. V roce 2015 vznikla alternativa v podobě OPNsense. Vše běží na FreeBSD.

VLANu IOT mám zcela odříznutou od internetu a ostatních VLAN. K dispozici je tam DHCP. Podle charakteru mají některá IOT zařízení IP adresu volně přiřazenu a jiné ji mají nastavenu „natvrdo“ (vůči MAC adrese + v nastavení IOT). Toto je typické pro IP kamery či jiná zařízení, kde by změna IP v čase mohla způsobit komplikace (tepelné čerpadlo, fotovoltaika – oboje kvůli TCP Modbus komunikaci). Jedinou povolenou komunikací směrem ven je DNS a NTP (kamery tak budou mít správný datum/čas). Na firewallu pak mám připraveny pravidla, která povolí základní set portů, pokud bych chtěl například aktualizovat firmware IOT zařízení či pustit k tepelnému čerpadlu vzdáleného technika. Standardně jako ale tato pravidla neaktivní.

Nejvíce benevolentní je pochopitelně nastavení VLAN SERVERS a PRIVATE. Z obou se lze dostat do všech ostatních.

Tři WiFi sítě

Drtivou většinu IOT zařízení provozuju bezdrátově přes WiFi síť. WiFi řeším přes několik stropních „talířů“ značky Ubiquiti UniFi s POE napájením. VLANa IOT, PRIVATE a GUEST má své vlastní SSID. V okoli tak vidím 3 WiFi sítě. IOT WiFi jede jen na 2,4 GHz, ostatní pak na 2,4 i 5 GHz. Vím, že některá IOT zařízení mají problém s prvotní instalací, pokud Váš mobil jede na 5 GHz síti a má sloužit k spárování s IOT zařízením, jenž podporuje pouze 2,4 GHz. WiFi síť je pak řízena skrze UniFi Controller, který provozuju též na obstarožním Raspberry Pi 3.

Vedlejším efektem v případě Ubiquiti je například to, že Vám to samo vizualizuje infrastrukturu. Pozor na vyždímané baterie!

Speciálně u bateriových zařízení (ideálně však všude) doporučuji v konfiguraci zakázat používání cloudové infrastruktury výrobce. On sice komunikaci zabrání firewall na pfSense, nicméně pokud necháte cloud povolený třeba v nastavení detektoru otevřených dvěří/oken „Shelly door window 2“, opakované neúspěšné pokusy o navázání komunikace s cloudem vedou k tomu, že baterii, která by měla v zařízení vydržet více než rok, vyždímáte v řádu týdnů! A že jsem těch náhradních baterií nakoupil, než jsem na to přišel Naopak v případě Shelly je doporučeno zapnout ColoT protokol a uvést IP adresu Home Assistant serveru.

To je asi vše k vnitřní části. Jak je ale realizována dostupnost IOT zařízení z internetu? Existuje opět spousta řešení, já se ale rozhodl pro následující.

Dostupnost chytré domácnosti z internetu po vlastní ose

Od internetového poskytovatele mám zajištěnu statickou veřejnou IP adresu (i když stačí i promapování klíčových portů). K ní mám vytvořeny DNS záznamy typu A. Jeden pro přístup k NAS Synology (kde je i správa kamerového systému) a druhý k Home Assistant. Oba záznamy, resp. IP adresa mě dovede až k WAN portu firewallu pfSense.

Na pfSense běží služba pfBlockerNG, která využívá GeoIP pravidla a rovnou zahazuje komunikaci vedenou z jiných zemí, než ČR a SR a blacklistovaných IP adres. Intuitivně není problém přidávat další regiony. Pak je tam v provozu služba Snort, která detekuje různé anomálie v síťové komunikaci a též dokáže rozdávat ať už permanentní nebo dočasne „bany“ na veřejné IP adresy.

Reverzní proxy, HTTP SSL, ACME, Lets encrypt, Fail 2 ban, …

Za tímhle je pak schovaná další služba, reverzní proxy HA Proxy, která legitimní požadavky z internetu na Home Assistant či Synology NAS směruje na správné „backendy“. Ať už se k NAS Synology či Home Assistantu připojujete z internetu skrze webový prohlížeč či mobilní aplikaci výrobce, technicky jde vždy o HTTP komunikaci. Nešifrovanou podobu na portu 80 mám pochopitelně zakázanou. Povolena je pouze šifrovaná varianta SSL, přičemž HA Proxy tuto komunikaci zaterminuje a dále ji podle hostname posílá lokálně již po HTTP na Synology či Home Assistant.

Validitu SSL certifikátů zařizuje další služba, jenž běží na pfSense – ACME. Využita je přitom autorita Lets Encrypt. Žádné výjimky na nedůvěryhodné servery tak není potřeba řešit. „Fail2Ban“, tedy blokování IP adres v případě, že se z ní někdo několikrát pokusí o neúspěšné přihlášení k systému, řeším až na cílových systémech Synology a Home Assistant. Aby to fungovalo korektně, je potřeba v HA Proxy povolit zasílání hlaviček X-Forwarded a brát je v potaz v nastavení Synology / Home Assistantu. V opačném případě zabanujete leda tak sami sebe, resp. vnitřní IP adresu pfSense, nikoliv skutečného viníka / útočníka.


Tohle je tak nějak v kostce řešení, které v domácnosti využívám. Znovu říkám, dalo by se to vyřešit úplně jinak, ale já jsem s tímhle maximálně spokojen. Vše mám v jedné aplikaci, která je rychlejší, lepší a stabilnější, než řada oficiálních řešení od výrobců. Home Assistant zároveň umožňuje realizovat automatizace, které by byly jinak nemyslitelné, drahé, nebo komplikované. Více o tom v předchozím díle. Nicméně zde je rekapitulace všech předchozích dílů:

Máte rádi trojské koně? Pořiďte si čínskou fotovoltaiku!

Rizika nevedou jen přes fotovoltaiku, stačí Vám „Powered by Tuya“ zařízení za pár stovek

Odříznutí internetu, přesun k Home Assistantu

A jak řešíte zabezpečení Vy? A nebo na to „prdíte“? Klidně pište do komentářů.

The post pfSense, VLANy, proxy, … aneb začínáme krotit divočinu v domácí síti appeared first on VIRY.CZ.

Kategorie: Viry a Červi

Odříznutí internetu, přesun k Home Assistantu

VIRY.CZ - 14 Květen, 2024 - 09:30

Třetí díl série o chytrých zařízeních (IOT – Internet of things) v domácnosti je již konkrétnější a ukazuje jednu z alternativních cest jejich použití, která je zcela odlišná od „mainstreamové“ cesty, kterou to zapojí drtivá většina ostatních uživatelů. V konečném důsledku může být právě tohle rozhodující faktor, díky kterému se můžete vyhnout případnému hackerskému útoku či výpadku cloudové infrastruktury výrobců IOT. Příjemným vedlejším efektem je navíc to, že často i stoupne komfort užití IOT zařízení a otevírají se další možnosti jejich spolupráce. Abych ale řekl celou pravdu, tímto přístupem přebíráte i komplet zodpovědnost (za problémy můžete nadávat akorát sobě) a vyžaduje to i větší znalosti IT.

Je plno stejně kvalitních či kvalitnějších alternativ, ale osobně mám drtivou většinu IOT senzorů / detektorů od značky Shelly. Doporučuji se ale podívat i na zařízení na bázi ZigBee. Já jsem ale žádnou centrální bránu řešit nechtěl a spoléhal se čistě na komunikaci po WiFi. Jelikož jde o novostavbu, stropních WiFi „talířů“ je po domě dostatek (Ubiquiti UniFi AC Long Range).

Zařízení „Shelly 1“ (či Shelly 1 Plus) v hodnotě několika stokorun slouží skvěle například na otevírání el. garážových vrat. Paradoxně to vychází finančně levněji, než dokupovat oficiální dálkové ovladače dalším členům rodiny. Navíc můžete vrata otevírat odkudkoliv přímo z mobilního telefonu.

Otevřené okno, děravá pračka

Dále používám Shelly Door Window 2 a Shelly Flood. V obou případech jde o senzory napájené baterií. První detekuje otevřená okna / dveře a druhý únik vody. Detektory na otevřené okna / dveře používáme tam, kde je běžně zapomínáme v rámci větrání zavírat, tedy u oken a dvěří, které nejsou úplně na očích. Shelly Flood je pak umístěn pod pračkou a myčkou. S prorezlou myčkou a tekoucí pračkou máme z minulosti neblahé zkušenosti. Původně byl záměr zaintegrovat detektory vody společně s centrálním uzávěrem vody, ale ten jsem zkritizoval v předchozím díle (powered by Tuya) a už nikdy nedořešil. Pointa, že únik vody z myčky / pračky povede automaticky k uzavření přívodu vody do domu, tak dosud nebyla realizována.

Někdy je umění najít místo, kam senzor otevřených dveří přidělat. Oba díly musí být od sebe maximálně několik mm, pokud mají hlásit stav „zavřeno“. Zde toho bylo dosaženo držáky z 3D tisku.

Měrák elektriky i vody

Další IOT zařízení, která používám, ale jsou spíše pasivního charakteru jsou:

Shelly 3EM – 3-fázový měřák spotřebované el. energie v domácnosti. Původně koupeno spíše jako hračka, nicméně nakonec se ukázalo, že to není úplně marná věc pro detekci anomálií ve spotřebě el. energie. Já tak díky tomuto měřáku včas odhalil, že tepelné čerpadlo nebylo nastaveno úplně ideálně (například, že zbytečně často využívalo neúspornou přímotopnou spirálu).

AI on the edge device – měřák spotřeby vody. Tohle není hotové zařízení, ale pokud za pár stovek koupíte miniaturní integrovanou desku s kamerou a správně ji nasadíte na vodoměr (nutno vytisknout na 3D tiskárně), dokáže spolehlivě převádět stav analogových „budíků“ na litry. A když se pak kouknete na denní spotřebu vody, nestačí se člověk divit. V m3 to nevypadá tak drasticky…

Bez 3D tiskárny se člověk neobejde ani zde. V horní části je umístěn „mini počítač“ na bázi ESP32 CAM se SW AI on the edge, který například co 5 minut vyfotí ciferníky vodoměru miniaturní kamerou (přisvítí si LEDkou) a převede je do digitální podoby.

Trouba a čistička vzduchu taky na internet?

V domácnosti by se našlo více zařízení, která se chlubí možností připojení k internetu, ale nenašel jsem žádný rozumný scénář, proč bych je tam připojoval (trouba, čistička vzduchu, …). Naopak možnost vzdáleně zapnout klimatizaci, poštelovat tepelné čerpadlo či fotovoltaický systém je vítaná. U chytré televize s Androidem je varianta s internetem jasná.

Fotovoltaika značky SOLAX, stejně jako tepelné čerpadlo PZP (model Economic) mají též vlastní cloudovou infrastrukturu a tedy i mobilní aplikaci, nicméně nic z toho se mě netýká. Komunikace je tak vedena lokálně skrze „průmyslový“ protokol Modbus, který obě zařízení skrze síťový protokol TCP nabízejí.

Bez internetu, odříznuto, šmytec

Všechna výše uvedená zařízení jsem laicky řečeno odříznul od internetu. To je alfa a omega odlišného přístupu, který jsem zvolil. Místo oficiální cloudové infrastruktury výrobců tak všechna zařízení směruju na lokální server s open source aplikací Home Assistant. Tahle aplikace umožňuje spravovat téměř vše, co je připojeno ethernetovým kabelem nebo skrze WiFi. A to z jednoho místa (resp. z jedné mobilní aplikace) a často lépe, než přes oficiální aplikace výrobců. Home Assistant provozuji na mini počítači Raspberry 3, protože se mě jich doma prostě několik válelo Variant nasazení ale existuje několik. Kromě toho, že můžete Home Assistant provozovat v režimu „hračička“, můžete v něm mezi připojenými zařízeními vytvářet i automatizace a optimalizovat tak chod domácnosti.

Chytrá IOT zařízení značky Shelly Vám detekuje Home Assistant automaticky během několika minut a jejich připojení je otázkou několika kliknutí. FVE SOLAX lze provozovat skrze protokol Modbus a díky existenci addonu je to i zde na několik kliknutí + nutnost zadat IP adresu střídače. Největší výzvou tak bylo připojení tepelného čerpadla PZP opět skrze Modbus (zvlášť, když tenhle protokol vidíte prvně v životě), ke kterému ale žádný addon neexistuje. Díky vstřícnému přístupu tech. podpory společnosti PZP jsem ale obdržel dokumentaci a několik dalších cenných rad, což vedlo k tomu, že dokážu vyčítat a měnit klíčové parametry tepelného čerpadla.

Home Assistant – z jednoho místa můžete vidět dění v celé domácnosti. Možnosti jsou obrovské. Příjemné je i udržování historie jednotlivých hodnot a hlavně to, že je HA dotaženější než celá řada originálních aplikací od výrobců IOT.

Nebýt otrokem

Ač prostřednictvím Home Assistantu přebírám kontrolu nad tepelným čerpadlem, neohrozím chod TP ani domácnosti v případě, že například server s Home Assistantem „umře“ nebo ho vypnu. V zimě to prostě bude topit tak jako tak a teplá voda taky bude. Obecně to mám takhle nastaveno i vůči dalším IOT zařízením. Garáž můžu pořád otevřít dálkovým ovladačem, světla vypínačem a dveře klíčem. Nechci být otrokem chytré domácnosti. Mimochodem (tohle má teda už hodně daleko od původního tématu ohledně zabezpečení IOT v domácnosti), v případě tepelného čerpadla mě zaujalo to (ač je to patrně normální, ale pro mě novinka, neboť jsem tuto problematiku nikdy neřešil), že se mu musíte v pravidelných intervalech (tuším že každých max. 100 sekund) z Home Assistantu skrze modbus hlásit. Jenom tak ho můžete vzdáleně z Home Assistantu ovládnout. Pokud se hlásit přestanete (například vlivem závady Home Assistant serveru), tepelko převezme řízení zpět. Jednoduché a funkční.

Automatizace na pár kliknutí

Jakmile máte všechna chytrá zařízení na jednom místě v Home Assistantu, můžete prostřednictvím vizuálních průvodců dělat i jinak složité věci jednoduše. Věci, které byste jinak museli řešit přes elektrikáře, nákupem fyzických stykačů, spínačů, …, dokážete vyřešit během pár minut přes klávesnici a myš. Já jsem kupříkladu v Home Assistantu realizoval tyto automatizace:

Akumulace / navýšení cílové teploty vody v bojleru v případě přebytků z fotovoltaiky

Automatizace je nastavena tak, že pokud fotovoltaika vyrábí více než 4 kW po dobu minimálně 20 minut (vyčteno přes modbus Solaxu), navýší významně cílovou teplotu v bojleru i za cenu, že začne tepelné čerpadlo využívat 3 kW přímotopnou spirálu (zařízeno přes modbus PZP). Asi by to šlo vymyslet sofistikovaněji, nicméně mě se předpověď počasí v HA neosvědčila, tudíž pokud moje FVE vyrábí 20 minut v kuse přes 4 kW, beru to, že venku je jasno s minimem mraků a tudíž je malá pravděpodobnost, že si bude tepelko při této operaci zbytečně „docucávat“ z baterie.

Okamžité shození tepelného čerpadla do pohotovostního režimu v případě výpadku el. energie ze sítě

Pokud vypadne el. síť v ulici (vyčteno z modbus Solaxu, který se přepne do režimu „off-grid“), nemá smyslu nahřívat vodu / topit z baterií (zařízeno skrze modbus PZP přehozením TČ do pohotovostního režimu). I v zimě je teplo v baráku naakumulované, tudíž pokud nenastal zrovna konec světa, těch pár minut až hodin, než elektrika naběhne, lze vydržet. Resp. než baterii FVE rychle vyždímat k dohřátí teplé vody a nebo ke zvýšení teploty topení, to ji raději využít k zajištění osvětlení, vaření či dokončení pracího cyklu. Pochopitelně funguje i opačná automatizace, která to po ukončení výpadku „nahodí“.

Zapnutí bazénové filtrace pokud jsou přebytky a venku je teplota, která za tu filtraci bazénu stojí

Elektromobil, spotové ceny, závěr

Pokud pak někdo nakupuje energii za spotové ceny, řeší i její prodej a vlastní elektromobil / wallbox, pak lze vymyslet spousty dalších automatizací. To všechno lze totiž do Home Assistantu integrovat.

No a v příští (a zřejmě poslední) části se teda už opravdu vrátíme k tomu zabezpečení Home Assistant sice v tomto díle spatřil světlo světa, ale těžko si přes něj otevřeme garážová vrata, pokud budeme před domem mimo dosah WiFi signálu. Čekají nás tak pojmy jako VLAN, pfSense, HAproxy, Snort, Acme, GeoIp blocking, fail2ban, …

The post Odříznutí internetu, přesun k Home Assistantu appeared first on VIRY.CZ.

Kategorie: Viry a Červi

Student Loan Breach Exposes 2.5M Records - 31 Srpen, 2022 - 14:57
2.5 million people were affected, in a breach that could spell more trouble down the line.
Kategorie: Viry a Červi

Watering Hole Attacks Push ScanBox Keylogger - 30 Srpen, 2022 - 18:00
Researchers uncover a watering hole attack likely carried out by APT TA423, which attempts to plant the ScanBox JavaScript-based reconnaissance tool.
Kategorie: Viry a Červi

Tentacles of ‘0ktapus’ Threat Group Victimize 130 Firms - 29 Srpen, 2022 - 16:56
Over 130 companies tangled in sprawling phishing campaign that spoofed a multi-factor authentication system.
Kategorie: Viry a Červi

Ransomware Attacks are on the Rise - 26 Srpen, 2022 - 18:44
Lockbit is by far this summer’s most prolific ransomware group, trailed by two offshoots of the Conti group.
Kategorie: Viry a Červi

Cybercriminals Are Selling Access to Chinese Surveillance Cameras - 25 Srpen, 2022 - 20:47
Tens of thousands of cameras have failed to patch a critical, 11-month-old CVE, leaving thousands of organizations exposed.
Kategorie: Viry a Červi
Syndikovat obsah