Příspěvky

5131

Server / Re:Malý server na platformě ARM

« kdy: 03. 09. 2014, 07:05:08 »

Já se hlásím, že malých serverů na platformě ARM už pár mám, a spousta lidí okolo také. Prodává je každý e-shop s počítačovou technikou - NAS třeba od Synology nebo Q-NAPu.
Jinak je fajn, že jste si pro sebe něco objevil, že si hrajete a že vás to nadchlo, ale pořád nevím, co my s tím máme dělat.

5132

Server / Re:Seznam k nám nedoručí poštu

« kdy: 30. 08. 2014, 20:21:28 »

Tady to ale z dumpů vypadá, že úvodní handshake proběhl správně.

5133

Server / Re:Seznam k nám nedoručí poštu

« kdy: 30. 08. 2014, 11:56:34 »

Nějak mi není jasné, jak by nastavení síťové masky mohlo způsobit to posílání RST paketu.
Jinak ifconfig je na Linuxu už od roku 1999 zastaralý a nefunguje. Takže být vámi, nepodivoval bych se tolik nad tím, že opravdu nefunguje, a raději bych začal používat iproute2.
Gentoo má pro konfiguraci síťových rozhraní konfigurační soubor /etc/conf.d/net a startovací skripty /etc/init.d/net.*, konfigurací ve vlastním skriptu si také jen zaděláváte na problémy.

5134

Desktop / Re:Přesměrování na podvodné stránky FF a Xubuntu

« kdy: 29. 08. 2014, 09:45:30 »

Predejit tomu jde snad leda tak, ze na podivne stranky polezete s vypnutym javascriptem. To by nejspis zabralo, nicmene nejspis ani ty podivne stranky se mozna nebudou zobrazovat.

Pokud není v prohlížeči bezpečnostní díra, tak se ten škodlivý kód jen tak sám od sebe JavaScriptem nenainstaluje. A pokud v prohlížeči bezpečnostní díra je, nemusí být zrovna v JavaScriptu. Ostatně doplňky do prohlížeče se neinstalují přes JavaScript.
Předejít se tomu dá tak, že člověk neinstaluje kdejaký nesmysl, na který narazí. Také je rozumné nevypínat v prohlížeči Safe Browsing, protože je pravděpodobné, že na tu podivnou stránku už narazil někdo před vámi, a prohlížeč vás tak bude varovat. Samozřejmě je pak potřeba se tím varováním také řídit a na tu nebezpečnou stránku nelézt.

5135

Server / Re:Seznam k nám nedoručí poštu

« kdy: 29. 08. 2014, 06:50:14 »

Pokud by to byl blacklist na základě IP adresy, ani by spojení nenavazoval. Mohla by to být nějaká kontrola (nebo blacklist) na základě doménového jména, které vrací SMTP server v uvítací zprávě. Ale pokud by Seznam resetoval spojení, proč by si dál myslel, že má spojení otevřené, a pokoušel se ho za minutu regulérně ukončit pomocí FIN?

5136

Server / Re:Seznam k nám nedoručí poštu

« kdy: 28. 08. 2014, 08:13:22 »

Pořád je to ale FIN po RST, což nedává smysl – stále to vypadá, jakoby Seznam o tom resetu vůbec nevěděl, tj. jako by byl do toho spojení vložen navíc někým jiným. Není to nějaká antispamová featura vašeho ISP?
Tenhle výpis má logiku, až na ten první reset – Seznam se pokouší spojení po minutě neaktivity regulérně ukončit, a když se mu to nepodaří, po dalších pěti minutách spojení natvrdo resetuje.
Pokud by ten první reset posílal Seznam, je to jejich chyba. Pokud se tam dostává později, je potřeba vypátrat, kde – zda to dělá váš ISP nebo až vaše síťová infrastruktura. Chtělo by to dump z hranice vaší sítě – a pokud to bude i tam, měl byste to řešit s vaším ISP. Že by správně trefil sekvenční číslo útočník úplně odjinud a poslal ten správný paket ve správné desetině sekundy, to se mi nezdá pravděpodobné.

5137

Server / Re:Seznam k nám nedoručí poštu

« kdy: 27. 08. 2014, 19:49:57 »

V tom výpisu máte jedno spojení, které je ukončené ihned tímto paketem:

Kód: [Vybrat]

15:10:00.693152 IP 77.75.76.125.50900 > 77.93.220.62.25: Flags [R.], seq 1, ack 37, win 0, length 0

Pak po pěti sekundách divný konec jiného spojení (je navázané z jiného portu). Což je samo o sobě divné, poštovní server normálně nenavazuje víc spojení k jednomu serveru zároveň, nedává to žádný smysl.

Máte zachycený i počátek toho druhého spojení? Mně to totiž připadá, jakoby ten resetovací paket poslal někdo jiný a komunikaci se Seznamem vám tím odstřelil. Vy tím pádem nijak neodpovíte a Seznam po pěti sekundách to spojení ukončí. Divná je ale ta změna zdrojového portu, to by tam muselo být víc manipulace s tím spojením, než jenom vložení toho resetu.

Je to divné, ale je to jediný výklad, který mne napadá, a který by byl zároveň v souladu s ostatními tvrzeními u dotazu. Nemůžete ten provoz odchytávat ještě někde dřív, než na serveru, třeba na routeru?

5138

Server / Re:Seznam k nám nedoručí poštu

« kdy: 27. 08. 2014, 17:45:23 »

To jméno, které vrací váš server, se přes A/AAAA záznam překládá na IP adresu, na které byl server kontaktován? Není v tom výstupu tcpdumpu vidět nějaká neobvyklá prodleva? Bez toho výstupu tcpdumpu vám asi těžko někdo poradí, bylo by dobré ho sem vložit.

5139

Vývoj / Re:r23

« kdy: 23. 08. 2014, 12:51:48 »

Aha, já měl zato, že se musejí dát zdrojáky ke všemu, co je spolu distribuované.

Nikoli, GPL vyžaduje, aby pod GPL bylo šířeno odvozené dílo. Pokud vaše dílo není od linuxového jádra nebo jiného GPL odvozené, můžete jej licencovat jak chcete. Někdy samozřejmě není jasné, zda něco je nebo není odvozené dílo - ale pokud vaše aplikace pouze běží pod Linuxem, určitě to odvozené dílo není.

5140

Windows a jiné systémy / Re:Certifikát uložený v registrech Win

« kdy: 22. 08. 2014, 08:32:31 »

DER mě napadl hned, ale openssl to nedalo.

Možná k tomu mají Windows v registru přilepená nějaká další data.
Každopádně je nesmysl hackovat data s neznámou strukturou z registrů, když jsou přímo ve Windows nástroje na zobrazení toho certifikátu i export do souboru v DER formátu.

5141

Windows a jiné systémy / Re:Certifikát uložený v registrech Win

« kdy: 22. 08. 2014, 00:20:53 »

Ale co za formát to je netuším.

Od oka bych to odhadoval na binární ASN.1, takže pravděpodobně binární DER. Vzhledem k těm nulovým bajtům na začátku to určitě nebude BASE64.

5142

Windows a jiné systémy / Re:Informace z certifikatu ulozeneho v registrech win

« kdy: 21. 08. 2014, 18:51:26 »

Otevřete si Možnosti internetu v ovládacích panelech, tam si najdete správu certifikátů, najdete příslušný certifikát a ten si zobrazíte. Případně si do MMC přidáte modul Certifikáty a certifikát si najdete tam.

5143

Vývoj / Re:Tak to zkusím i tu - socket.io/sock.js

« kdy: 21. 08. 2014, 13:10:21 »

http://es5.github.io/x2.html#x2

podle toho to musí být utf-16 nebo ucs2

Nemusí. Tohle popisuje, jak interpretovat znaky na vstupu, ale neříká, jaká má být vnitřní reprezentace v interpretu. Ono také nedává smysl, aby standard předepisoval vnitřní reprezentaci, která kód v JavaScriptu žádným způsobem nemůže ovlivnit.

5144

Vývoj / Re:Tak to zkusím i tu - socket.io/sock.js

« kdy: 21. 08. 2014, 12:15:32 »

JS pouziva ucs2 nebo utf-16.

To je ale jen interní implementace některých interpretů JavaScriptu. Jiný interpret by klidně mohl String interně reprezentovat v UTF-32 nebo libovolném jiném kódování, které dokáže ukládat 16bitové znaky (protože podle standardu není String text v Unicode, ale posloupnost 16bitových čísel). Podstatné je to, že z JavaScriptu se nemáte jak dostat k té interní reprezentaci, takže na ní nezáleží. Podobné je to třeba v Javě. Naopak v C si můžete textový řetězec kdykoli přetypovat na pole bajtů, takže tam záleží na tom, jak je řetězec interně uložen.

5145

Studium a uplatnění / Re:Založení s.r.o. při zaměstnání

« kdy: 21. 08. 2014, 11:23:04 »

Zákony v tom nijak nebrání ani nevyžadují, abyste to se zaměstnavatelem řešil. Ale můžete mít nějaké ujednání v zaměstnanecké smlouvě, které se toho týká. Pokud se tedy jedná o klasický zaměstnanecký poměr k soukromé firmě.