Příspěvky

1531

Odkladiště / Re:Nabízí ještě nějaká banka normální internetbanking?

« kdy: 21. 06. 2018, 20:43:02 »

Zbyl tu ještě někdo normální?

Zkuste FIO. IB bez Ajaxu, funguje vpřed, zpět i reload. Mají jednoduché API. Transakce jsou vidět v reálném čase (po reloadu). Z mého pohledu okouzlující jednoduchost.

1532

Server / Re:Šifrování existující databáze

« kdy: 20. 06. 2018, 19:48:19 »

Proxy či přesun databáze na jinou virtuálku vás ani omylem nezachrání. Musíte si uvědomit, kudy se lze k datům dostat a cíleně tomu zamezit. A tam, kde to lze, omezit i okruh potenciálních útočníků.

Takže zakažte na virtuálce všechny nepotřebné služby a porty, otevřete jen port pro ty webové aplikace. Pokud to lze, tak jen pro vybrané IP adresy nebo pouze prostřednictvím VPN.

...

Pokud na tom záleží, nechte si to zkontrolovat od někoho, kdo se tím rutinně zabývá. Jako laik v té oblasti nemáte šanci domyslet všechny úskalí.

Zde, ZAJDANE, souhlasím. Oddělení může snížit jen určitý typ rizik, mimo to byste měl mezi oddělenými stroji vytvořit VLAN a i v rámci ní mít firewall a dokonce i na odchozí spojení. Ani to sice, jak píše pan Němeček, nezabrání 100 % útoků, ale minimálně to dost zkomplikuje život těm, kteří budou útočit jen skrz nějakou slabinu, ale nezíská přímo přístup do celé instalace. Pokud ho získá, otevře si aplikaci, vyčte heslo k databázi a má data tak jako tak.

Pak by měla být zabezpečena i nová odchozí spojení ze serveru, protože tím ztížíte stažení dalších nástrojů, kteřé útočníci využívají. Management (SSH) by měl být dostupný jen z privátní VLAN, do ní přístup např. přes VPN.

Aplikace je samozřejmě základ. Pokud necháte díru v samotné aplikaci, nezachrání Vás nic. Proxy může pomoci např. tím, že ještě dodatečně omezí jak velikost POST requestu, tak i návratu. Tím opět zpomalíte únik dat a zabráníte části automatizovaných scriptů, které hackůjí, aby provedly, co potřebují.

Nedá se do diskuse popsat, co máte udělat, to jsou jen takové tipy, které ve Vás mají nastartovat zamyšlení se nad tématem. Je opravdu nejlepší to svěřit do rukou odborníka, ten to dá nejlépe dohromady s architektem aplikace / řešení.

(Mám ale trochu pocit, že se snažíte dohnat jakousi bezpečnost "šifrováním", ale ve skutečnosti máte běžnou webovou appku nejlépe běžící na apachi, s .htaccessem a mysql, vše v jednom virtual rootu, ... - tam bezpečnost nenaženete a opravdu začněte od appky a její architektury).

1533

Server / Re:Šifrování existující databáze

« kdy: 20. 06. 2018, 13:29:22 »

jsou tam data jako maily, IBAN,BIC, přibudou tam kódy k zámkům(boxy, kontajnery)
...
Ale tak i tak se může útočníkovi podařit proniknout dovnitř a mě zajímá jak nejlépe utajit data v DB.

Pokud se dostane do běžícího serveru, tak žádné šifrování, ani na úrovni filesystému Vám nepomůže. Data budou přimountovaná a viditelná. Šifrování filesystému ochrání po odcizení serveru, kdy se vypne a bez rozšifrování data neuvidí. Je potřeba ale také pohlídat swap a veškeré tempy - v nich mohou zůstat jak nesmazané soubory s daty, tak na samotném disku bloky dat s informacemi.

Pokud se jedná o kódy, tak tam si musíte položit otázku, jestli potřebujete mít samotný kód šifrovaný reverzibilně (tedy se správným klíčem se dostanete k původnímu kódu), nebo jestli uložíte jen osolený otisk. Otisk má výhodu v tom, že můžete ověřit, že "kdosi" má v ruce správný kód, ale nedokážete zpětně rozšifrovat, jaký je (leda hrubou silou). To už je ale věc návrhu architektury, ne šifrování dat.

No a samozřejmě, platí pravidlo oddělování. Databáze na jiném stroji než web, web za reverzní proxy, virtualhosty oddělené a podle  účelu mít na virtualhostech co nejnižší limity (timeouty, paměť, ...). Pokud to namrskáte na jednu virtuálku u nějakého hostéra, DB bude přímo na webseveru, atd., atd., pak nepřemýšlejte ani o šifrování. Je to zbytečný výdaj energie, který nemůže napravit špatně postavené základy.

1534

Server / Re:Šifrování existující databáze

« kdy: 20. 06. 2018, 13:08:05 »

mam již existující MySQL databázi a rozhoduju se jakou metodou ji začít šifrovat.
---
šifrujete jen citlivé sloupce nebo celou DB?

Popište spíš, co řešíte za problém. Tedy jaká data, v jakém režimu a před kým chcete chránit. Jaká identifikujete rizika, která chcete eleminovat.

Váš dotaz je ve stádiu výběru řešení, ale popsaná situace spíš ukazuje, že jste ve stádiu identifikace rizik.

1535

Studium a uplatnění / Re:Benefity

« kdy: 16. 06. 2018, 09:24:40 »

Ono je to dost omezené zákonem, protože benefity - odměny zaměstnance se hledají takové, které si zaměstnavatel může odečíst z daní a zaměstnanec nemusí danit a odvádět pojištění.

Kdyby Vám dal zaměstnavatel např. kupon na nákup potravin domů, nebo palivo do osobního auta, pak by to nemohl mít ani v nákladech, ale ještě by z té částky musely jít odvody, stejně jako kdyby Vám dal peněžní odměnu.

Ideální je projít si v zákonech, co je možné pro zaměstnavatele (zákoník práce, zákon o dani z příjmů) nabídnout.

1536

Odkladiště / Re:Fakturace do zahranici v ramci EU - DPH atd.

« kdy: 13. 06. 2018, 21:52:11 »

Ještě zdroj:

https://www.zakonyprolidi.cz/cs/2004-235

§6h:
Osoba povinná k dani se sídlem nebo provozovnou v tuzemsku, která není plátcem, je identifikovanou osobou ode dne přijetí zdanitelného plnění s místem plnění v tuzemsku od osoby neusazené v tuzemsku, pokud se jedná o

a) poskytnutí služby,

b) dodání zboží s instalací nebo montáží, nebo

c) dodání zboží soustavami nebo sítěmi.

1537

Odkladiště / Re:Fakturace do zahranici v ramci EU - DPH atd.

« kdy: 13. 06. 2018, 21:47:15 »

Nu... jeste jinak.

S prvni fakturou s 0 DPH, reverse charge se nahlasis na financak. Stane se z tebe identifikovana osoba. Budes kazdy mesic delat priznani k dph a podavat 'souhrne hlaseni'. Az prelezes 1M, stane se z tebe platce dph s v podstate stejnymi povinostmi jako identifikovana osoba, ale budes si moci dph z nakupu v CZ narokovat, ale jeste pribude kontrolni hlaseni.

Prosím neraďte blbosti. Identifikovaná osoba se týká toho, když nakupujete služby ze zahraničí, NIKOLIV KDYŽ DO ZAHRANIČÍ PRODÁVÁTE.

1538

Odkladiště / Re:Fakturace do zahranici v ramci EU - DPH atd.

« kdy: 13. 06. 2018, 21:11:54 »

1 Stane se ze mne stane "Identifikovana osoba" a budu muset davat kontrolni hlaseni?
2. Na fakture budu muset udavat "Reverse Charge" klausuli -> DPH platit nebudu, bude ji ale muset odvest firma v zahranici?

Nepíšete zásadní informaci. Jestli jste aktuálně plátce DPH.

Pokud ano:
ad 1) nestane, jste už plátce a tak jako tak podáváte kontrolní hlášení
ad 2) pokud Vám druhá strana dá své DIČ, ověříte, jestli je plátcem v jiné zemi (v registru VIES) a fakturujete bez DPH

Pokud plátce nejste:
ad 1) nestane, identifikovaná osoba byste byl, pokud byste PŘIJÍMAL služby od rezidenta jiného státu,
ad 2) ne, nejste plátce DPH, takte stále vystavujete bez DPH (ale z příjemce se stane identifikovaná osoba a on zdaní v režimu reverse charge, nebo pokud je plátce DPH ve své zemi, tak uplatní DPH na vstupu i výstupu, takže mu nula od nuly pojde)

1539

Sítě / Re:HTTPS na privátní adrese

« kdy: 13. 06. 2018, 17:24:25 »

Akorát že vůbec nejde o počet spojení, ale o datový tok. Pokud má ta síť připojení do internetu 100 Mbit/s, musí ten router umět uNATovat 100 Mbit/s. Pokud bude mít server s 1 Gbit/s síťovkou, měl by ten router umět uNATovat 2 Gbit/s. To je sakra rozdíl.

U routeru bude zásadnější packet rate, než propustnost pásma. Pokud by se jednalo o gigabity, je jak otázka, tak zvažovaná řešení mimo mísu. V takovém případě by si to opravdu žádalo zajistit si veřejné ip adresy a servery mít na takovém segmentu.

Navíc na tom serveru nepoznáte, odkud ta spojení jdou, všechna budou z routeru – nemůžete dělat QoS, nic nepoznáte z logu.

Uznávám.

Že je to řešení pro síťaře čitelné a chová se vypočitatelně je snad vtip. Porovnáváte přímé spojení přes switch se spojením dvakrát NATovaným na routeru. Nechcete snad tvrdit, že ten dvojitý NAT to zpřehlední a vylepší…

Jak co. Pro ladění opravdu hlubokých problémů je dvojitý NAT peklo (ostatně, jakýkoliv NAT). Zase na ladění vyšších služeb, aplikací atd., aby člověk přemýšlel, kde je zadrátovaná IP adresa na pevno, jakou cestou se z jakého programu reslovuje atd. atd. Podle mě si nevyberete. Uznávám, že jsem tvrzení vzal moc zhurta, ono to bude asi prašť jako uhoď.

1540

Sítě / Re:HTTPS na privátní adrese

« kdy: 13. 06. 2018, 17:00:46 »

Navíc úplně stejný problém nastává i tam, kde žádná veřejná IPv4 adresa není – kde je server v lokální síti, který z venku nemá být dostupný a žádnou nadbytečnou veřejnou IPv4 adresu, kterou byste na něj dal, nemáte. Představte si třeba školní síť se serverem, a od ISP dostane ta škola v lepším případě jednu dynamickou veřejnou IPv4 adresu pro vnější rozhraní routeru, v horším případě se bude dělat NAT až u ISP.

Ano, ale "uzváldat" SNAT+DNAT na routeru, např. ve školní síti, není zas až tak nepřekonatelný problém. Podle mě bude existovat jen málo skutečných situací, kdy nemáte možnost mít veřejnou IP adresu a zároveň nemáte ani možnost "ustíhat" NAT. Když si představím hraniční router takové sítě, podle mě na conntracku NATU má takové množství spojení, že ještě nějaká navíc zpět do vlastní sítě už nemohou hrát tak velkou roli. To řešení má velkou výhodu v tom, že je pro síťaře dobře čitelné a chová se vypočitatelně. Ale jak píšete, za cenu ztraceného výkonu na routeru.

1541

Sítě / Re:HTTPS na privátní adrese

« kdy: 13. 06. 2018, 16:20:06 »

To, že se musí vedle DNATu udělat ještě SNAT, je na tom celém to nejmenší. Podstatné je to, že tu komunikaci nuceně ženete přes router, přestože by mohla jít přímo. Když budete chtít mezi klientem a serverem přenášet větší objem dat, je dost podstatný rozdíl, zda budete ze serveru na klienta přímo přes switch stahovat třeba 800 Mbit/s, nebo jestli to poženete přes router, který tím pádem bude potřebovat odbavit 1,6 Gbit/s a ještě to bude prohánět NATem.

Vzhledem k tomu, že Stillet píše o omezení zátěže NATu, je ta vaše rada přesně to, čemu se chce vyhnout.

Souhlasím, ale považuji to za menší zlo než jiná řešení.

1542

Sítě / Re:HTTPS na privátní adrese

« kdy: 13. 06. 2018, 16:10:17 »

co samozrejme nebude fungovat, pretoze klientovi v tomto pripade pride odpoved z 10.0.0.1 a nie z 184.47.23.3...

Cestou zpět se uplatní zase, takže jsem to měl napsat spíš jako:

10.0.0.10 => 10.0.0.1/184.47.23.3 => 10.0.0.45

1543

Sítě / Re:HTTPS na privátní adrese

« kdy: 13. 06. 2018, 16:04:40 »

To reknete tem poskytovatelum, u kterych je ten "privatni" server umisten?

Ano, asi by jim to mělo být řečeno , protože server, který je z vnitřní sítě nedostupný, ač má být dostupný veřejně, je zjevná chyba.

S touto situací jsem se setkal jen v rámci jedné firmy, jedné přípojky, kdy zákazník má server ve vnitřní síti, a zvenčí je NAT a zevnitř je problém se na něj dostat (právě kvůli resolvování DNS na veřejnou IP adresu). U ISP, doufám, toto nenastává. Na hostingu je pořád standard veřejná IP adresa, pro tyto účely je jich pořád dostatek.

1544

Odkladiště / Re:search engines - vyhledávání obrázků

« kdy: 13. 06. 2018, 15:51:33 »

děkuji za odpověď..co myslíte tím kontextem?

Např. texty na stránce (stránkách) ve kterých je daný obrázek úmístěn.

1545

Odkladiště / Re:search engines - vyhledávání obrázků

« kdy: 13. 06. 2018, 15:47:27 »

Nejen to, ale i kontext umístění obrázku a kdovíco ještě.
Na principu jméno+alt fungovala možná tak Altavista před drahnými léty.