Security-all

Magánélet - adatvédelem, titkosítás

Fórumok

2016. novemberében indult el az azóta több százezer látogatószámot elérő maganelet.hu weboldal, melynek célja egy olyan magyar nyelvű tudásbázis létrehozása volt, ahol laikusok és szakemberek számára egyaránt értékes információk találhatóak olyan megoldásokról, mely fókuszában a magánélet és az adatvédelem áll.

Ma már kétségtelen és szinte vitathatatlan, hogy az internetes kommunikáció terjedésével a felhasználók egyik legnagyobb gondja az adatbiztonság, az adatvédelem lett. Nagyon sokan nem ismerték ezt fel, de történjen bármilyen incidens – adatlopásból származó kár, személyes adatokkal való visszaélés stb. – az adott személy azonnal rájön, milyen „rizikós” is az internetet használni egy olyan világban, ahol az egyik legértékesebb pénzügyi és hatalmi tényező az információ.

A mai nappal a weboldal korábbi tartalma teljesen megújult. 4 év alatt rengeteget változtak és fejlődtek a különféle szoftveres megoldások, számtalan információ szivárgott ki a gyengeségekről. Ezeket az információkat aktualizálva, új külsővel megújult a weboldal. A jelenlegi formájában további bővülés is várható, cél egy fórum létrehozása is, ahol az érdeklődők részletesebben is megvitathatják az egyes megoldásokkal kapcsolatos véleményeiket.

OpenVPN kapcsolat saját PC és Android között

Fórumok

Hogyan lehet a leggyorsabban és legegyszerűbben openvpn kapcsolatot létrehozni saját PC-n működő Openvpn server és egy Android mobil között, hogy minden adatforgalom a mobilról a PC-n keresztül menjen át? 

https://openvpn.net/community-resources/static-key-mini-howto/

Ez volt a kiindulópont, de Android openvpn kliens mindenképpen CA-t akar, ami ebben az esetben nincs is.

Wordpress "felügyelet" - üzemeltető oldalról

Fórumok

Sziasztok,

Sajnos (?) lassan minden harmadik oldal WP alapú. Ez pedig folyamatosan generálja a problémákat.
Eljutottunk odáig hogy több 100 WP oldalt „üzemeltetünk”, úgy hogy a többségéről nem is tudunk.

Ezek közül rendszeresen vannak problémás oldalak.

Arra gondoltam hogy ezeket valahogyan keresni kellene.

Két dologra keresek megoldást:

  • adott hoston megkereseni egy scripttel a WP-s oldalakat, ez valószínűleg pár grep-el megvan.

  • A megtalált oldalakon valamilyen check-ek lefuttatni pl. wpvulndb.com alapján

  • a sérült oldalakról értesítést kapni

Ami főleg kérdés lenne, github és társai tele vannak WP scanner scriptekkel amit wpvulndb-t (is) használják, van ezekkel valakinek tapasztalata?
Megbízható, más kedvességet nem tartalmazó scriptet keresek.

[Megoldva] Let's encrypt online generálás

Fórumok

Üdv!

Eddig a https://zerossl.com/free-ssl oldalon tudtam online generálni 90 napos certet.

Csak megadtam a key és csr fájt, erre adott egy txt fájlt amit fel kellett töltenem a szerverre, majd ellenőrzés után adta a certet.

Ez így már nem él (illetve más lett, nem Let's encryt-tet ad), ezért keresek olyan oldalt, ahol ilyen egyszerűen elintézhetném. De nem igazán találtam ilyet.

Létezik még ilyen oldal?

 

====

Jelenleg egy ZeroSSL RSA Domain Secure Site CA a kibocsájtója a most generált certnek, nem a Let's...

Erre a certre meg azt mondja a Gmail, hogy a tanusítvány nem megbízható (win 2008R2-re van a cert telepítve). Ez hogy lehet?

Köszönöm a segítséget!

 

Megoldás itt

Nem találtam olyan online felületet, ahol az eddigi módon hozzájuthattam volna Let's X3-as tanúsítványhoz. Programra váltottam.

Köszönöm az hozzászólásokat!

TakarékBank SMS phishing?

Fórumok

Jött egy ilyen SMS a +36 30 344 4332 számról (ma reggel), azért elég gyanúsan phishing gyanús nem?

Tisztelt Ügyfelünk! Amennyiben folytatnà hitele törlesztését, ezt nyilatkozat formàjàban is jelezheti! Kattintson a linkre: https://bit.ly/2AsZA16 Takarékbank

Linkrövidítő, ismeretlen telefonszám, az itt lévő értékelések is érdekesek: https://www.kihivott.hu/telefonszam/06303444332

a bit.ly-s rövidítés az úgy látom https://takarekbank.hu/hitel-torlesztesi-moratoriummal-kapcsolatos-info… címre old fel, akkor mégis valid SMS lenne? De bakker, ebben minden benne van ami az anti phishing tréningeken van, hogy mik a gyanús jelek.

  • Nem várt SMS (két hónapja van hitel moratórium...)
  • Linkrövidítő
  • Hibás ékezetek
  • Nincs személyes megszólítás

Szólna valaki valami illetékesnek, hogy ez azért nem kóser így?

DoH privacy/security/performancia egyensúly egészséges megtartása?

Fórumok

Sziasztok!

Arra lennék kíváncsi, hogy van-e valakinek valamilyen gyakorlati, jó megoldása a DoH kontrollálására.

Kifejezések tisztázása:

  • DoH == DNS over HTTPS, a DNS kérések HTTPS-en utaznak 443/tcp-n
  • DoT == DNS over TLS, a DNS kérések TCP payloadként TLS-be tekerve utaznak 53/tcp-n

Háttér:

A környezet home environment, szóval semmi üzleti kritikus cumóról nincs szó. Fogalmazzunk úgy, hogy az otthoni infra permanens test lab mindenféle use-case-ek életszerű, mindennapi használattal járó kitesztelésére.

A cél:

DNS kérések utazzanak externet szakaszon secured transporton, de a belső DNS szerver ne legyen megkerülhető.

Per pillanat az intra DNS logika a következőképpen néz ki. Adott két ANS melyek a belső zónákat szolgálják ki. Adott két CNS, melyeken a conditional forwarderek az ANS-ek felé küldik a belső zónákra irányuló kéréseket. Minden egyéb kérést a CNS hostokon, localban figyelő dnscrypt-proxy továbbítja az upstream NS-ek felé DoT-on. A border GW-en minden 53-ra érkező kérés a belső CNS felé van forwardordolva tűzfal szabályokkal.

A jelen logika célja többrétű:

  • A CNS-ek DNS alapú szűrést végeznek, így minden hálózatra kötött kliens bizonyos szintig védettséget élvez: ad, kártékony oldalak, session replay scriptek, stb. Pl. mobil folyton OpenVPN-en lóg és a CNS-eket kérdezi, szóval nem kell a szűréssel kliens oldalon bohóckodni.
  • Egy esetleges belső host kompromittálódás esetén DNS alapú védelmi réteget biztosít. Pl. feltételezve hogy a kártékony kód logika hardkódolt DNS szervereket tartalmaz, az abba az irányba küldött kérést is az intra CNS terminálja, így szűri. Nyilván a védettség nem 100%-os, ez csupán az egyik védelmi réteg.
  • A külső hálózaton a DNS kérések TLS-be tekerve utazzanak.

Viszont az utóbbi időben nagyon úgy néz ki hogy a DoH irányába mozdulnak el a browser vendorok [1]. A gondom ezzel az, hogy kb. pofán csapja a fenti logikát és teljesen kicsúszik a fent vázolt kontroll a kezemből. Értem én a privacy törekvéseket és bizonyos fokig még egyet is értek velük, de keresek valami egészséges egyensúlyt.

Látom pl. hogy nginx-ben implementálható a DoH/DoT GW [2]. Ha pl. a róka nagyon szeretne csak DoH-on beszélgetni, ez erre a részére megoldást jelenthetne. Viszont továbbra is kérdés a kimenő, DoH felett utazó, nem kívánatos kérések kontrollja. Nyilván a HTTPS tartalom vizsgálatára és annak függvényében valamilyen döntési mechanizmusra van szükség. Amire gondolni tudok az egy HTTPS proxy, ami érzésem szerint felhasználói oldalról nézve performancia overhead-et jelentene az egyébként normál HTTPS forgalom esetén is. Emellett, tekintve hogy ez feltételezi a teljes HTTPS forgalom vizsgálatát, meglátásom szerint éppen a HTTPS-sel járó privacyt csapja pofán. Permanens eavesdropping ha úgy tetszik.

Szóval a poszt célja kettős:

  • Mit gondoltok erről az egész DoH témáról a poszt címe és a fentiek kontextusában?
  • Van-e valamilyen gyakorlati, kiegyensúlyozott megoldási ötletetek arra, hogy az eddigi működési logika DoH mellett megmaradjon, feltételezve hogy várhatóan az hamarosan ki lesz kényszerítve.

--
[1] https://blog.mozilla.org/blog/2020/02/25/firefox-continues-push-to-bring-dns-over-https-by-default-for-us-users/
[2] https://www.nginx.com/blog/using-nginx-as-dot-doh-gateway/
 

google blokkolás de jquery legyen

Fórumok

Hali!

Nem szeretném hogy a google tudjon arról, hogy milyen oldalakat nézegetek, ezért szeretném letiltani teljesen. Sajnos ekkor néhány oldal elromlik, például a stackoverflow is, ami aktívan használja a https://ajax.googleapis.com/ajax/libs/jquery/1.12.4/jquery.min.js könyvtárat. Szeretném valahogy megoldani, hogy a google le legyen tiltva, de mégis működjön az oldal, például hogy ezt a könyvtárat a böngészőm inkább a saját gépemről töltse le, vagy akárhogy máshogy.

Hogyan/mivel érdemes blockolni és átirányítani a kérést? Vannak erre tapasztalatok?