Příspěvky

2311

Server / Re:Odesílání mailu se zablokovaným portem 25

« kdy: 19. 09. 2019, 09:00:41 »

Btw neumožňuje odeslat poštu pro jakoukoliv doménu třeba smtp Seznamu, když se autentizuju svým seznamáckým účtem? Nezkoušel jsem, já mám třeba vlastní VPS.

Pro jakoukoli doménu (adresáta) to určitě umožňuje. Omezení může být na straně adres odesílatele – vůči autentizovanému uživateli může kontrolovat obálkového odesílatele a odesílatele uvedeného v e-mailu (v hlavičce From). Obálkového odesílatele by kontrolovat měl, hlavičku From by měl ignorovat, ale poštovní servery dnes bývají nastavené různě…

2312

Server / Re:Odesílání mailu se zablokovaným portem 25

« kdy: 19. 09. 2019, 08:57:50 »

A opět rada k ničemu, resp. polovičatá - relay jede po portu 25/TCP a ten má zablokovaný

Že nic nevíte, to by nebyl problém. Že se tím musíte chlubit v diskusích, to už je horší. Tak při tom aspoň neútočte na lidi, kteří na rozdíl od vás něco vědí.

Port 25 už by se pro předání e-mailu z klienta na poštovní server neměl používat, je to zastaralé. Místo toho se nově používá port 587. Dočetl byste se to v tom RFC 6409, kdybyste nebyl líný si ho otevřít.

Postfix samozřejmě nemůže jen tak změnit výchozí port. Na konfigurovat relayhost na jiný port ale je možné. (Ono je možné Postfix nakonfigurovat i tak, aby i při klasickém rozesílání pro nějakou doménu použil konkrétní server a port, jiný od portu 25. Ale to byste musel mít nějaký svůj server, o kterém byste věděl, že naslouchá i na jiném portu.) A hádejte, kde najdete příklad takové konfigurace? V tom článku, který jste odkazoval. Je v něm tohle:

relayhost = [smtp.gmail.com]:587

Zkuste číst alespoň články, na které sám odkazujete…

2313

Server / Re:Odesílání mailu se zablokovaným portem 25

« kdy: 19. 09. 2019, 08:07:18 »

Záleží na tom, čemu říkáte „odeslat e-mail“. Pokud tím myslíte předávat e-maily rovnou cílovým serverům (tj. to, co dělá plnohodnotný e-mailový server), to jinak než na port 25 nejde.

Pokud tím myslíte předávat e-maily k odeslání nějakému (jednomu) serveru (to, co typicky dělá poštovní klient – Outlook, Thunderbird), k tomu se nepoužívá port 25, ale port 587 (viz RFC 6409 Message Submission for Mail). Server pro to odesílání e-mailů na portu 587 by vám měl poskytnout váš ISP. Příklad konfigurace Postfixu je např. zde: Postfix on a dialup machine, důležitá je ta volba relay_host, která určuje, že se e-maily mají odesílat přes jiný server. Ten server (třeba ISP) asi bude vyžadovat autentizaci klienta, vizte dokumentaci Configuring SASL authentication in the Postfix SMTP/LMTP client.

2314

Server / Re:Testovací servery v cloudu

« kdy: 17. 09. 2019, 11:58:10 »

Umí to kterákoli služba, která účtuje provoz po hodinách nebo menších jednotkách, tedy každý cloud. Funguje to přesně, jak popisujete – někde máte uložený obraz disku (za to platíte) a pak si podle potřeby startujete a vypínáte servery běžící z toho obrazu (a platíte jen za dobu, kdy běží). AWS je asi nejznámější, ale umí to spousta dalších poskytovatelů – OVH, DigitalOcean, Homeatcloud…

2315

Software / Re:7z komprese s presmerovanim (bez zapisu kimprimovanych dat na disk)

« kdy: 15. 09. 2019, 18:49:51 »

Nedávno se tu řešilo něco velmi podobného: Konverze archivu ze zip do 7z.

2316

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 10. 09. 2019, 14:25:21 »

Myslel jsem, že chcete ty dokumenty šifrovat tak, aby se k nim pak dostal až uživatel – tj. musel by je dešifrovat uživatel nějakým svým nástrojem, např. PGP. Webové prohlížeče nemají podporu pro bezpečné šifrování, a pokud byste ten dokument chtěl dešifrovat na serveru, je zbytečné šifrovat to pro každého uživatele zvlášť. Pokud byste to chtěl mít zabezpečené tak, aby se k datům nedostal někdo, kdo by třeba ukradl serverový disk, stačí to šifrovat globálně jedním klíčem. Některé databáze mají možnost šifrovat data, případně pokud soubory ukládáte na disk, stačilo by asi použít šifrovaný souborový systém.

Záleží na tom, k čemu přesně to šifrování má sloužit, proti jakým vektorům útoku má bránit.

2317

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 10. 09. 2019, 13:17:28 »

Hesla bych k tomu vůbec nepoužíval – aby to bylo bezpečné, musela by být dostatečně složitá, a pak je problém, jak si je bude uživatel ukládat… Lepší je použít asymetrickou kryptografii, veřejné a soukromé klíče. Uživatel má svůj privátní klíč, dokumenty pro něj zašifrujete veřejným klíčem. Tím pádem nemusíte řešit distribuci hesel, pouze máte na serveru pro každého uživatele jeho veřejný klíč.

Ale udělat to opravdu bezpečně je složitější, než celý zbytek aplikace. Je otázka, zda má smysl se do toho pouštět a komplikovat si tím aplikaci, když to stejně nejspíš nebudete mít udělané dostatečně bezpečně. Třeba e-maily se dnes v drtivé většině případů posílají nešifrované, a skoro nikoho to netrápí…

2318

Server / Re:Server se neptá na heslo neexistujícího uživatele

« kdy: 09. 09. 2019, 23:13:11 »

sshd podporuje různé způsoby přihlášení. Jen tak tipovat nemá smysl – pomohlo by, kdybyste sem dal konfigurační soubor, aby bylo vidět, jak máte přihlašování nakonfigurované. Pak se můžeme podívat na jednotlivé způsoby přihlášení, zda nemůže být problém v nich.

Například pokud byste měl povolené pouze přihlášení klíčem z domovského adresáře uživatele, po zadání neplatného uživatelského jména server zjistí, že nemůže načíst veřejný klíč – a bylo by zvláštní, pokud by se v takovém okamžiku rozhodl jen tak požadovat třeba heslo, když autentizace heslem vůbec není povolena. Navíc uživatel znalý nastavení systému by i podle toho požadavku na heslo poznal, že daný uživatel neexistuje.

2319

Server / Re:Antispam na poštovní server.

« kdy: 09. 09. 2019, 15:59:57 »

A následně na přijímacím mail serveru nastavit SPF kontrolu. Vyhodí to nejen příchozí spamy s adresou “z vaší domény” ...

Kontrola SPF se aplikuje na obálkového odesílatele (MAIL FROM), bohužel už tím nelze kontrolovat odesílatele hlavičkového (FROM), takže i se striktní SPF kontrolou může uživateli přistát do mailu spam z jeho vlastní domény, sám jsem to řešil ve firmě.

To je ale v pořádku. Díky SPF nebo DKIM víte, který server ten email poslal, a řešit to s nimi – a pokud budou spam posílat dál, můžete je dát na blacklist.

2320

Vývoj / Re:DB desgin+funkcionalita proti brute-force

« kdy: 07. 09. 2019, 14:36:40 »

Pokud aplikace není za reverzním proxy serverem, použijte jenom request.getRemoteAddr() a tu hlavičku ignorujte.

Podle mne není standardizováno, v jakém formátu má request.getRemoteAddr() IPv6 adresu vracet. Takže asi nezbyde, než ji parsovat a ořezávat na adresu sítě ručně. Nenašel jsem pro to ani žádnou utilitu ve Springu. Existuje knihovna pouze pro práci s IP adresami IPAddress – pomocí new IPAddressString("…"), pak ji buď můžete správně oříznout na adresu sítě a převézt zpět na String, nebo ji můžete přes    toFullString() rovnou převést na úplnou reprezentaci IPv6 adresy a pak prostě humpolácky použít 19 znaků zleva.

2321

Vývoj / Re:DB desgin+funkcionalita proti brute-force

« kdy: 07. 09. 2019, 13:08:42 »

Takže když použiji tento tutorial, který používá cache místo DB, tak je to lepší řešení? + bych přidal k tomu ještě tu captchu
https://www.baeldung.com/spring-security-block-brute-force-authentication-attempts

Určitě je to lepší, než zapisovat každý neúspěšný pokus o přihlášení do relační databáze. Vázat to na IP adresu odradí primitivní pokusy, pro odhodlaného útočníka nebude problém zkoušet to z různých IP adres. Taky ten tutorial moc nepočítá s IPv6 – tam koncový uživatel dostane celou síť, takže nemá smysl rozlišovat jednotlivé IPv6 adresy, ale je potřeba brát celou /64 síť jako jednoho uživatele. A určitě bych neblokoval toho uživatele natvrdo, jak je to v tom tutoriálu, ale použil bych nějakou CAPTCHA, jak jsem psal.

Také je potřeba zacházet pečlivěji s hlavičkou X-Forwarded-For – pokud aplikace nebude schovaná za reverzním proxy serverem, musí tuhle hlavičku ignorovat, protože by ji mohl klidně nastavit útočník. Naopak pokud bude za reverzním proxy serverem, musí ten server zajistit vymazání případné hlavičky od útočníka a vložení nové hlavičky se správnou hodnotou. A aplikace pak musí používat hodnotu z téhle hlavičky.

2322

Vývoj / Re:DB desgin+funkcionalita proti brute-force

« kdy: 07. 09. 2019, 11:47:22 »

Pokud budete při útoku hrubou silou na hesla zapisovat každý pokus do databáze, je to ideální příležitost pro DoS – tedy aby útočník vytížil vaši databázi neúspěšnými pokusy o přihlášení natolik, že už nezvládne nic jiného.

Blokovat uživatele při opakovaném zadání chybného hesla (bez dalších podmínek) je zase pro útočníka ideální způsob, jak zablokovat přístup konkrétnímu uživateli (tedy DoS ne na celý server, ale na vybrané uživatele). Stačí každé dvě minuty minut učinit neúspěšný pokus o přihlášení daným uživatelským jménem, a ten uživatel už se nikdy nepřihlásí.

Omezovat to na konkrétní IP adresu není řešení – v době všudypřítomných NATů může mít útočník docela snadno stejnou IP adresu, jako oběť. A naopak pokud by se někdo pokoušel hádat hesla, může dělat každý pokus z jiné IP adresy.

Z toho plyne, že neúspěšné pokusy o přihlášení bych držel jenom v paměti a s minimem informací, ať je to pro server co nejméně náročné. V případě překročení počtu neúspěšných pokusů by nemělo dojít k blokaci účtu, ale jenom ke zpomalení hádání, ale umožnit uživateli dál projít – tj. použít tam nějakou CAPTCHA. Spíš složitější, aby se nedala hádat automaticky, oprávněnému uživateli to holt v případě útoku na jeho účet dá víc práce přihlásit se, ale pořád bude mít tu možnost. Do třetice by tam měla být kontrola, aby uživatel nemohl zadat vyloženě slabé heslo.

Pokud uživateli chcete dát možnost zabezpečit svůj účet víc, dejte mu možnost spárovat účet s jinými službami, přes které se může přihlásit – Google, Facebook, Twitter, MojeID, obecné OpenID. Když to uživatel použije, zbavíte se v jeho případě zodpovědnosti za bezpečné přihlašování :-) Dále umožněte uživateli zapnout si dvoufaktorovou autentizaci, tj. přihlašování pomocí jednorázových hesel.

2323

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 06. 09. 2019, 19:13:12 »

Synchronizaci na úrovni Javy bych nedělal – kdybyste synchronizoval celou metodu, budou na sebe volání čekat, i když budete upravovat různé dokumenty. Ale hlavně by konkurenční přístup neměl být závislý na tom, že do databáze zapisuje jediná aplikace. Když bude aplikace víc využívaná, nebude aplikační server stíhat a budete ho chtít spustit ve více instancích na různých serverech – a rázem by vám veškerá řešení konkurenčního přístupu v aplikaci přestala fungovat. (Je mi jasné, že to asi nebude případ vaší aplikace, ale nedává smysl učit se to dělat špatně.)

Tohle se řeší pomocí zamykání na úrovni databáze. Buď pomocí pesimistický zámků, kdy ty záznamy opravdu zamknete (pomocí SELECT … FOR UPDATE) a ostatní transakce budou čekat na jejich uvolnění. U takovýchhle aplikací je ale daleko lepší použít optimistické zamykání – předpokládá se, že většinou ke konfliktu nedojde, takže se nezamyká, ale při zápisu se kontroluje, zda mezi tím nedošlo ke změně. A řeší se to teprve ve výjimečném případě, kdy ke změně došlo.

Optimistické zamykání se dělá tak, že u databázového záznamu máte uložené i označení jeho verze. Může to být čítač, který se s každým zápisem zvýší o jedničku, může to být třeba časové razítko poslední změny záznamu. Když načítáte data, načtete i to číslo verze, a když pak záznam aktualizujete, přidáte do WHERE podmínky tu verzi. Pokud by jiná transakce záznam mezi tím změnila, porovnání čísla verze nebude sedět a UPDATE proběhne „na prázdno“ – nezaktualizuje se žádný záznam. Podle toho poznáte, že v databázi jsou novější data a musíte požadovanou operaci provést znovu nad těmi novějšími daty. Má to tu výhodu, že to číslo verze můžete protáhnout až k uživateli do webové aplikace. Uživatel tak může mít záznam rozeditovaný klidně několik hodin, ten záznam není na serveru zamčený, takže neblokuje ostatní – a až se po několika hodinách rozhodne, že data uloží, jenom se podle čísla verze zkontroluje, že se mezi tím v databázi nic nezměnilo. Pokud se něco změnilo, nebudou čísla verzí souhlasit a musí se to vyřešit – buď uživateli načtete aktuální data z databáze a necháte ho jím provedené změny udělat znovu, nebo mu můžete zobrazit aktuální verzi a jeho změny, a nechat ho ty jeho změny zapracovat do té aktuální verze na serveru.

2324

Server / Re:HTTP 421 Misdirected request - vysvětlení, příčina

« kdy: 06. 09. 2019, 14:05:53 »

Je to chyba klienta – pošle v hlavičce Host jiné jméno, než to platné pro aktuální spojení podle SNI. Je to tedy specifické pro HTTPS, protože tam se posílá hostname v SNI rozšíření TLS a pak ještě jednou v hlavičce Host. Zajímalo by mne, který klient to dělá – tipoval bych si, jestli to nebude nějaký „chytrý“ proxy server, nejspíš nějaký, který se bude pyšnit tím, jak zabezpečuje komunikaci…

Nemusí to být ani „stejné“ spojení – pokud budete testovat něco třeba pomocí curl, můžete v parametru pro SNI použít nějaké hostname, a pak do požadavku napíšete hlavičku Host, kde uvedete jiné hostname. Pokud budete zkoušet kontaktovat víc serverů, může se vám stát, že prostě zapomenete to jméno přepsat na obou místech. Nemusí tedy jít o následující požadavek, ale hned o ten první (je možné, že pak server pošle trochu jinou chybovou hlášku, ale princip – konflikt mezi SNI a hlavičkou Host – je stejný).

napadá mě, že to jde v hanshake TLS

Je to volitelná položka v úvodu TLS spojení, ještě v té nešifrované části.

A co znamená HTTP hlavička authority (v curl zapsané -H "authority: subdomena.serppklc.cz) ? a Jak se liší /souvisí s Host: ?

Hlavička :authority je nová v HTTP/2 a víceméně by měla nahradit hlavičku Host z HTTP/1.1. V požadavku by měla být buď jedna nebo druhá.

2325

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 06. 09. 2019, 13:44:15 »

Anotace @Transactional na třídě má identický význam, jako kdybyste oanotoval @Transactional každou metodu v dané třídě.

Ta anotace znamená, že se metoda účastní „databázové“ transakce. Předpokládám, že používáte jenom jednu databázi – pak se to chová, jako kdybyste na začátku metody zavolal BEGIN TRANSACTION a na konci COMMIT nebo ROLLBACK (podle toho, zda byla vyhozena výjimka nebo ne).

Jak se budou chovat souběžné transakce určuje parametr isolation. Výchozí hodnota záleží na databázi, ale nebývá to SERIALIZABLE. Ten váš popis – spouštění po sobě – odpovídá právě izolaci SERIALIZABLE, která znamená, že se transakce musí chovat, jako by byly spuštěny jedna po druhé. Např. v PostgreSQL je výchozí  izolace transakcí Read Committed .

Ještě jednou upozorňuju, že se to týká databázových transakcí, není to synchronizace kódu v Javě – třeba pokud by databáze musela kvůli jiné transakci čekat s commitem, proběhne celá vaše metoda až do konce a čekat se bude až ve volání commitu, které Spring „přilepí“ (buď pomocí proxy bean nebo úpravou bajtkódu) až za kód vaší metody.