Van ám még 216j és 115j is forgalomban, ha esetleg mennél még lejjebb, de én maradnék a 118nál

[ Szerkesztve ]

"A QC alap beállításon miért lenne biztonságosabb ?"

Én ilyet nem írtam. Magaddal szeretnél vitatkozni?

"Már amikor kapcsolódsz a Synologyhoz ott van a címed utána"

What? Nincs ott semmiféle címem. Ahhoz hogy egyáltalán meg tudd a nasom qc címét, végig kell szkennelned az összes létező urlt-t a synology qc oldalán aztán meg végigpróbálkozni az összes felhasználónév+jelszót. Hajrá.

"Biztos jó mert azt használod mondjuk ha a synology vpn guija meg olyan rossz szerinted akkor ebbe nem tudom miért bízol vakon .."
Én egyikben sem bízok vakon. Megint csak magaddal vitatkozol, nálad ez valami szokás?

A synology vpn guija pedig tényleg béna, mert nem lehet rajta beállítani hogy én _csak és kizárólag_ olyan kapcsolatokat fogadok el, amik tanúsítvánnyal jönnek és azok validak, ráadásul nem triviális tőle megszerezni a CA-t és saját aláírt certeket csinálni a kliensekhez.

Konkrétan ha bekattintod a vpn-t, akkor a nason beállított felhasználónév:jelszó kombóval fogd beengedni.
Ha neked van a nason egy micike jelszó: 1234 felhasználód akkor azzal.
Innentől kezdve bárki aki megpróbál bejönni openvpn-en, és rápróbál a micike:1234 felhasználóval, be fogja engedni a vpn-d. És a felhasználók 90%-nak ilyen triviális felhasználónév jelszó párosa lesz, bármilyen szótáras bot úgy fog átmenni a vpn-en mint kés a vajon.

Szóval a vpn-nél biztonságról csak akkor beszélhetünk ha minimum tanúsítvány alapú hitelesítést végez (extraként jöhet még a felhasználó+jelszó).
Nekem igy van beállítva és surprise, nem a guin, hanem magán az openvpn konfigban a nason. De ezt mezei felhasználó nem fogja tudni megcsinálni.

Jelen felállásban a default QC és a default openvpn synology féle megoldásában csak annyi a különbség, hogy egyik esetben a synology szerverét kell végigszkennelned valid url-k után, a másik esetben ip tartományokat kell szkennelned (amiből lényegesen kevesebb van) és ha ráakadtál egy valid címre vagy url-re, akkor rápróbálni egy felhasználónév+jelszóval. Amivel beenged a qc, azzal be fog engedni az openvpn is.

És most tegye fel a kezét aki ezt valaha egyszer végiggondolta. Nem véletlen írtam, hogy az openvpn csak akkor ad extra biztonságot ha értesz hozzá. Ha nem értesz, akkor maximum azt hiszed hogy extra biztonságban vagy.

QC esetén valóban domainneveket kell próbálni, de egyrészt az eleve egy támpont a usernév felé sokaknál (ejnye!) másrészt nem kell port. Másrészt a relay szerver mögött nem csak a doménneved találják meg, ha feltörik, hanem a username+jelszó párost is. Egyébként ipv6nál már gyk. nem biztos, h sokkal jobban jársz ip scannel mint random félértelmes szavak kergetésével. Főleg ha egy megszerzett (bárhonnan, nem kell h synoé legyen, s rengeteg ilyen van) username+jelszó táblából dolgozol, valszeg első körben a userneveken mennék végig, nem ip címeken random
Nomeg nem csak egy, hanem eleve többféle porton kell próbálkozni különböző vpnek miatt, pláne az egyedi portok miatt. Ráadásul preshared key is képbe jöhet, amire van mód összekattintgatni is...

Valamint az még mindig a lényegi különbség, h a qc sokkal könnyebben törhető man in the middle attackkal, míg a vpn úgy gyk. törhetetlen.

[ Szerkesztve ]

Amiket irsz csak részletkérdés, pl. egy kezemen (kis túlzással) megszámolom hol van ipv6 end usereknél.

"Valamint az még mindig a lényegi különbség, h a qc sokkal könnyebben törhető man in the middle attackkal, míg a vpn úgy gyk. törhetetlen."

Ez továbbra is csak és kizárólag akkor igaz, ha te állítod be a certeket.
Ha nem, akkor a kliensed nem tudja a nasod certjét, ergó simán átverhető MITM támadással, a szerveren meg a guin ez egyáltalán nem beállítható, tehát a szerver meg konkrétan lesz@rja hogy milyen certet kap.
Tehát a guis openvpn beállítással bárki olyan MITM támadást csinál a nasod ellen amilyet akar.

Csak és kizárólag az én módszerem (kulcsos auth) véd ez ellen, de ahhoz bizony be kell ssh-zni a nasra és fejbekólintani a generált default openvpn konfigot, meg nem árt ha az ember tud certet generálni.

De ez megint csak mellékvágány, mert elég pici a valószinüsége hogy micike nas-a ellen célzott támadás menne. Sokkal valószinübb a botok általi automatikus támadás, ami konkrétan ip+port scan, majd a detektált szolgátatások ellen gyakori felhasználónév+jelszó próbálgatása.

Egyébként lehet irok egy kis szösszenetet hogy hogyan állítsuk be a synology nasunkat _tényleg_ biztonságosra (ha még nincs ilyen tutorial), mert az látszik hogy itt is nagyon sok a tévhit ez ügyben és közkedvelt informatikai mondás hogy nincs rosszabb a hamis biztonságnál.

"Konkrétan ha bekattintod a vpn-t, akkor a nason beállított felhasználónév:jelszó kombóval fogd beengedni.
Ha neked van a nason egy micike jelszó: 1234 felhasználód akkor azzal.
Innentől kezdve bárki aki megpróbál bejönni openvpn-en, és rápróbál a micike:1234 felhasználóval, be fogja engedni a vpn-d. És a felhasználók 90%-nak ilyen triviális felhasználónév jelszó párosa lesz, bármilyen szótáras bot úgy fog átmenni a vpn-en mint kés a vajon."

A beállítások résznél van egy olyan hogy melyik felhasználó jogosult a vpn használatára. Az openvpn szerver a nason generál .crt és.ovpn fájlokat amit a kliensnek meg kell adni hogy a kapcsolat működjön.

Accuphase E-306 integrált erősítő eladó.

Sajnos nem. Nézz bele a serveren az openvpn konfigban (/usr/syno/etc/packages/VPNCenter/openvpn/openvpn.conf), lesz benne egy ilyen sor:
client-cert-not-required

Akár élesben is letesztelheted, töröld ki a certedet a kliensből, és voalá, úgy is menni a fog a vpn.
A felhasználó amúgy is állítható elég jól ha http-n akarsz belépni, nincs diffi, és megint csak lényegtelen mert 99% valószinüséggel akit vpn-ezni engedsz azt http-n is beengeded plusz a legtöbb felhasználónál 1 user van.

Sziasztok ezeket hol lehet megnézni kiváncsiságból megnézném én is a 415+ nas-on

Felhő

Ja a 2 cert törölhető de ha a generált configból kitörlöd a <ca> </ca> közül a certek tartalmát akkor mindjárt nem enged be . Vagy csak nekem van speciális VPN szerverem...

(#37752) Porthoszx
Te abban bízva gondold így, hogy amikor Gizike meghívja böngészőből azt, hogy http://QuickConnect.to/QCcime akkor ez rögtön egy titkosított csatornába varázsolódik és azt a hálózaton mindenki előtt titokba oda varázsolódik a Synology szervereire ????

[ Szerkesztve ]

A Chrome böngészőhöz készült egy beépülő modul ( plugin ) amivel " 1 kattintásos " letöltés indítható a nason futó Download Stationban.

Ez a plugin hibás mert csak 100-ig mutatja a feladatokat.

Magában a Download Stationban is meg lehet nézni , hogy hány feladat fut.

Download Station bejegyzésében írtam a plugin-ről is.

Synology NAS DSM6 - Összefoglaló : https://logout.hu/bejegyzes/borisz76/synology_nas_osszefoglalo.html

Dehogynem beenged szerver. Csakhogy mivel a kliensed konfigjában nincs benne a no-client-cert-requried sor, ezért ő ellenörzi a szerver certjét és mivel ez ca hiányában nem lehetséges, eldobja a kapcsolatot. A szerver úgy beenged mint a huzat.

és most tedd fel a kérdést, egy támadót aki próbálgatja a nasodon futó openvpn-t gyakori felhasználónevekkel, mennyire érdekli, hogy te a kliensed biztonsággá konfiguráltad, miközben ő a szervered támadja amelyik vigan beengedi certek nélkül?

Ez alapján tényleg kell az a cikk, mert nekem nagyon úgy tünik hogy IT security kapcsán az idevágó részekben nagyon sok kavar van itt a fejekben és ahogy mondtam a legrosszabb ha hamis biztonságérzetbe ringatod magad.

szerk: a második kérdésed még csak nem is értem.
De ez most meddő vita, mert látszik hogy nem vagy tisztában mélységében azzal hogy hogyan müködik akár az openvpn akár a qc, sem gyakorlatban, sem elméletben. Sőt alapvetően a PKI alapelveivel sem.

[ Szerkesztve ]

Értem akkor ez nem DS-ben van hanem a pluginba így ha én ezt nem használom akkor semmi jelentősége számomra, jól értem ugye?

Felhő

Örömmel vennénk egy amatőrök számára is érthető , képekkel megtűzdelt , alapos, részletes leírást.
Én tuti nem fogok ilyet írni mert nem vágom a témát!

felho001

Jól gondolod.

[ Szerkesztve ]

Synology NAS DSM6 - Összefoglaló : https://logout.hu/bejegyzes/borisz76/synology_nas_osszefoglalo.html

Ha beleírom ezt a sort a configba :
no-client-cert-requried
akkor nem is próbál kapcsolódni
Próbáltam még verify-client-cert-none verify-client-cert none de azok se működnek.

[ Szerkesztve ]

Ott a pont.
client-cert-not-required

A másik állításomhoz ragaszkodok.

Itt ha csinálsz egy felhasználói fiókot és csak azzal a fiókkal megy a vpn kapcsolat. A normál eléréshez kell egy másik megfelelő jogosultságokkal rendelkező fiók.

Kösz a hibafeltárást.

Accuphase E-306 integrált erősítő eladó.

Akartam már írni, hogy Opera-ra is van plugin és működik is. (ha valaki más is harcban áll a chrome-al )

https://www.youtube.com/user/kigyi23/

Ha átjavítom erre akkor el sem indul a openvpn szerver

client-cert-required

[ Szerkesztve ]

Accuphase E-306 integrált erősítő eladó.

Azt csak kommenteld ki
#client-cert-not-required

Nálad működik a kliens cert nélkül ?

[ Szerkesztve ]

Azt még nem próbáltam, mert az élő rendszereket nem piszkálom. Felteszek egy image-t aztán ott megnézem.
A kommentet próbálom.
Számomra az zavaró miért lenne benne egy ennyire nyilvánvaló hiba?

Accuphase E-306 integrált erősítő eladó.

Mert valószínűleg :
That client-cert-not-required will not obviate the need for a server certificate, so a client connecting to a server which uses client-cert-not-required may remove the cert and key directives from the client configuration file, but not the ca directive, because it is necessary for the client to verify the server certificate.

Attól, hogy ezt kiveszed kezelni is kellene a kliensekhez tartozó kulcsokat
Szóval a kivétel max arra jó, hogy utána nem fog engedni kapcsolódni ...

[ Szerkesztve ]

Kikommentelve a kliens nem tud csatlakozni!
(#37769) gyugyo79: Ezt írtad.

[ Szerkesztve ]

Accuphase E-306 integrált erősítő eladó.

Ha tudod kliensbe nézd már meg, hogy kiveszed a configból a <ca> </ca> közti részt (addig egy txt fájlba vagy valahova elmented, hogy vissza tudd rakni) és beírod a no-client-cert-requried -t, hogy nálad elfogadja e.

Én nem tudom kötelező e valamelyik irányból a tanúsítvány megléte. Ezért érdekel. Mert akkor a 2 irányból meglévő az csak + vagy a fn/pass a + a két tanúsítvány mellé akkor tök8 nem akkora gáz ha el van hagyva az egyik irányból a tanúsítvány megkövetelése.
Én is láttam, azt hogy volt ilyen kliensbe írható sor amúgy csak nálam ha nincs kliens konfigba tanúsítvány nem is működik ami önmagában megint nem jelent semmit de magát azt a sort se fogadja el ami lehet pont olyan klienst használok aminél ez nem ment de ha van olyan ami meg működik anélkül és a szerver is elfogadja akkor nem jó ....

[ Szerkesztve ]

Törlöm a kliensből .crt fájlokat és csatlakozott a szerverhez.
A logban: WARNING: No server certificate verification method has been enabled
Egyértelműen a szervernek kellene megkövetelni a tanúsítványt.

[ Szerkesztve ]

Accuphase E-306 integrált erősítő eladó.

A cert fájlok tartalma ott van a konfigban ezért tényleg törölhetőek, a konfigurációs fájlból szedd ki ha van kedved. csak előtte mentsd vagy valami ...

[ Szerkesztve ]

Valóban. A logban akkor miért van ez a figyelmeztetés?

Ha tudod kliensbe nézd már meg, hogy kiveszed a configból a <ca> </ca> közti részt (addig egy txt fájlba vagy valahova elmented, hogy vissza tudd rakni) és beírod a no-client-cert-requried -t, hogy nálad elfogadja e.

Nem fogadja el.

[ Szerkesztve ]

Accuphase E-306 integrált erősítő eladó.

Csak tippelek sajnos nem tudom!

Szóval mint írtam akár egy kulccsal is lehet mind a 2 irányba kicsit biztonságot elérni.
Az egyik, hogy a kliens tudja, hogy a megfelelő szerverhez kapcsolódik. Na amikor azt 2 fájlt törölted ezt nem tudta ellenőrizni.
Míg a beírt kulcs az kötelező eleme lehet szerver oldalról az autentikációnak ...Ami mellé jöhet még egy kulcs vagy Fn/pass vagy mind a 2 és akkor 100% biztonság van.
Kb mint a L2TP/IPSEC előre megosztott kulcsa annyi különbséggel, hogy azt te írod be .

De nem tudom így van e ....

[ Szerkesztve ]

Mert a szerver nem ellenorzi a certet es erre figyelmeztet.
A synology altal bekapcsolt opcio kevesbe biztonsagossa teszi a vpnt amde nem kell foglalkozni a certekkel.

Cserebe barki probalkozhat felhasznalonevekkel a szerveren. Innentol lasd elozo kommentjeim

Ez szerver oldali opcio.

Ha hazaertem majd elmondom hogy tortenik az egesz ssles hitelesites telefonrol maceras

Szerintem mi erről már itt diskuráltunk, akkor annyiba maradtunk, h miután én sehol nem a syno vpnjét használom, ezért nem tudom, de hittem neked s akkor is nemtetszésem fejeztem ki
s bevallom nem csináltam meg a házifeladatom s állítottam be tesztelgetni azóta se
Ettől függetlenül a certes vpn biztonságos, s azt vmiért tényként kezelem, h cert márpedig kell Ha tényleg nem követeli meg, vmi leírást nem ártana feldobni, meg felhívni erre az emberek figyelmét akik vpneznek synval, az biztos!

Legalábbis mintha azt anno itt veled folytattam volna le...

[ Szerkesztve ]

Ne haragudj sejtem, hogy értesz hozzá de ezek azért nekem ez elég furcsa ha tényleg így van.

"Mert a szerver nem ellenorzi a certet es erre figyelmeztet."
De hát miért nem figyelmeztet addig amíg ez ott van a könyvtárban ? A szerver attól ugyan úgy van beállítva akár szólhatna addig is amíg a kliens könyvtárba ott vannak ezek, nem ?

Mert a szerver nem ellenorzi a certet es erre figyelmeztet.

Erre hogy ellenőrizze van valami beállítás?

Accuphase E-306 integrált erősítő eladó.

Szóval kipróbáltam, hogy átírtam a configban lévő certifikate -be egy betűt.
Így eljut az authentikációig DE a helyes adatok megadása után NEM lehet belépni!

Kb szerintem nem is jól kódolva küldi ilyenkor az adatot ...

Nekem ezek után elégé világos, hogy nem véletlenül van ez ott és eléggé fontos az ismerete.

[ Szerkesztve ]

Ezen nincs mit bizonyítani, minek után a "client-cert-not-required" opció benne van a default openvpn konfigban amit a synology generál, az pedig azt csinálja amit mondtam.
De ha kell doksi tessék:
https://openvpn.net/index.php/open-source/documentation/howto.html
Using username/password authentication as the only form of client authentication

By default, using auth-user-pass-verify or a username/password-checking plugin on the server will enable dual authentication, requiring that both client-certificate and username/password authentication succeed in order for the client to be authenticated.

While it is discouraged from a security perspective, it is also possible to disable the use of client certificates, and force username/password authentication only. On the server:

client-cert-not-required

És aztán még folytatják hogy ez egy olyan erős opció hogy a szerver kiütheti a kliens konfigjából a cert és key beállításokat stb stb.

De ahogy mondtam ezt bárki tesztelheti, semmit sem kell csinálni a szerveren, csak a kliens openvpn konfigból törölje ki a cert és key opciókat és próbáljon csatlakozni. És voalá, pont ugyanúgy be fog csatlakozni a kliens pedig nincs certje.

Tehát a synology default openvpn megoldásában, a szerver nem ellenörzi a klienst, pusztán csak a felhasználónév jelszó páros. Bárkit beenged, aki eltalálta ezt.
Ahogy mondtam (és ahogy a doksiban is említve van), ez biztonsági szempontból aggályos, ámde lényegesen könnyebb beállítani vpn kapcsolatot.
A helyzet az hogy szerintem 10-ből 1 ember tudja beizzitani a vpn-jét a nason, a korrekt cert ellenörzést pedig ennek az egy tizednek a tizede tudná beállítani, ezért vélhetően a synology könnyitett a dolgon.

Ami azt is jelenti hogy ebben a formában, a synology openvpn nem lényegesen biztonságosabb mintha synology qc-t használnál. Ha kell a tuti biztonság, akkor töröld ki a fenti opciót a nason az openvpn konfigból és inditsd újra a szolgáltatást vagy a nast.

Innentől kezdve az openvpn csak azt engedi be aki rendelkezi a megfelelő tanúsítvánnyal és tudja a felhasználónév jelszó párost. Nincs többé felhasználónév próbálgatás, mert a szerver el fogja hajtani a próbálkozót mint macskát sz@rni a tanúsítvány hiányában.

Gyugyo az isten áldjon meg töröld már ki a cert és key sort
A certbe hiába piszkálsz bele, a not required nem azt jelenti hogy nem ellenörzi, hanem hogyha nem küldesz az is jó. Te most küldtél egy hibásat, amit nem tudott ellenörizni mert hibás és ezért elhajtott. Ha nem küldesz akkor nem is próbál meg ellenörizni hanem mehetsz tovább

Én azért bizonyos dolgokat az otthoni használat során én alapból nem vagyok hajlandó feladni és beáldozni a biztonság oltárán ....
Amúgy Synology router pld de a két utóbbi frissítés is necces volt amit a NAS kapott szóval bármi lehet.
Pont ezért írtam pld, hogy a QC megoldásuk miért lenne jobb? Max ott a boldog tudatlanság van, mert egy OpenVPN -nél legalább beszélni tudunk róla meg tudjuk nézni míg ott ?

NEM mehetek tovább!!! Ha ezt törlöm nem működik ezt értsd meg!
Linkelj egy klienst amibe nem kell

Ami nem kell az a 2 db key fájl DE a VPNConfig.ovpn -ből nem lehet a 2 *.crt tartalmát törölni.
Azt ami a <ca> </ca> közt van!

[ Szerkesztve ]

A CA marad.
ca nem egyenlő cert, szerintem kevered a fogalmat.

Na, nálam igy néz ki a konfig ide vágo része:
ca c:\\Users\\foo\\OpenVPN\\config\\keys\\syno-ca-cert.pem
cert c:\\Users\\foo\\OpenVPN\\config\\keys\\client.crt
key c:\\Users\\foo\\OpenVPN\\config\\keys\\client.key

ebből ennyi maradjon:
ca c:\\Users\\foo\\OpenVPN\\config\\keys\\syno-ca-cert.pem

A te esetedben <ca>cert</ca>maradjon, de a
<cert>blabla</cert>
<key>blabla</key>
ne.

És ezek után próbálj meg csatlakozni.

Kb én ezt most úgy látom, hogy ha törlöm a 2 db fájlt akkor el lehet a klienst téríteni és egy nem ellenőrizhető szerverre fog rá próbálni a loginnal, de a VPNConfig.ovpn -be lévő adatok (kulcsok) miatt amúgy se lehet ezzel mit kezdeni mert az alapján kódolva küldi az adatokat. Ezért csak figyelmeztet. Pont ezért nem is hagyja ezt törölni mert ezek nélkül nem tud a jó szerverrel se beszélni!

Amit te mondasz kliens.cert az meg csak egy + biztonság erre.

Na de ne hülyéskedj már ha a CA marad akkor miről beszélünk . Azt 3. fél honnan fogja kitalálni ?
+ 2 crt van amit a Syno generál meg a félig előre megírt *.ovpn

ca.crt + ca_bundle.crt.
Ezek tartalma van szintén a VPNConfig.ovpn -ba .

Szóval ezeket mint törölni kell és lehet próbálkozni, ha bármire azt mondod maradjon az nem jó teszt.

[ Szerkesztve ]

Szia!

"gyugyo79" "Madve"......

Nos ebből a diskurzusból, nyilván nem árulok el titkot, egy szót sem értek szinte......De egyvalami lejön azért belőle. Nevezetesen, hogy cseszhetjük mi ezek szerint az általunk biztonságosnak hitt beállításainkat, mindenféle QC+jelszavakat+fiókokat+jogosultságokat...vpn ide, vagy oda. Arról már nem is beszélve, hogy a nemrégen bejelentett Meltdown+Spectre, ami az összes létező processzorból bármilyen adatot jelszavakat kinyerhetővé tesz.(nyilván valaki/valakik direkt készítették így a procikat, csak lebuktatták őket) Nos ezek után, én azt hiszem, minden védelem "szinte"(ez persze így nem igaz) feleslegessé is válik, mert csak azt hisszük, hogy biztonságban vagyunk.

Soha ne félj valami újat csinálni! A bárkát is egy lelkes amatőr készítette, a Titanicot meg egy halom szakértő!

Hát kezdek kifogyni az ötletekből hogyan magyarázzam el neked.

a lényeg: a nason az openvpn szervered, a gyári beállításokkal bármilyen vpn klienst beenged, ha az tudja a felhasználónév jelszó párost. Nem végez tanúsítványt ellenörzést ha a kliens nem küld.

Ad abszurdum, ha most megmondanád nekem a felhasználónév jelszót meg a nasod címét, én innen a saját gépemről be tudnék vpn-ezni hozzád anélkül hogy bármiféle certet ismernék.

És pont ez csinálják a botok, szkennelik az internetet, megtalálják a nasod, szkennelik a portokat, megtalálják a vpn szervered, beazonosítják hogy vpn szerver, és rápróbálnak a gyakori felhasználónevekkel. Ha talált akkor süllyedt.

szerk: a CA-t nem kell kitalálni. Arra semmi szüksége annak aki be akar hatolni a nasodra. a CA neked kell, hogy tudd a saját nasodra akarsz belépni és nem épp valaki MITM támadást játszik.

szerk2: gyu tehetünk egy próbát, privátban elküldöd az ip címet a nasnak, meg a felhasználó jelszó kombót (csinálsz valami limitált usert) és én 5 perc múlva elhelyezek egy fájlt a nasodon ahová ennek a usernek van írási joga. Anélkül hogy bármiféle certet ismernék

[ Szerkesztve ]

Már ne is haragudj De ha úgy működik ahogy én írtam akkor amit írsz az nem úgy van és én ahogy linkelsz egy klienst amivel be tudok lépni én rögtön beírom ide. De jelenleg ha logikusan végig gondolod meg kell értened miért nem hiszem, hogy úgy működik ahogy te írod.

Hisz a te általad eddig felvetett lehetőségeknél végig bent hagytad a lényegi részt ami pont 2 kulcs tartalma ami azért nem elbagatellizálható.

Mert érted, ha működik azokkal -> akkor azok nélkül miért működne - ha meg mindegy a szervernek, hogy egy algoritmus alapján kódolt valamit fogad el vagy egy kódolatlant akkor meg bármit írhatnék el kéne fogadnia, nem?

Ergó ha az OpenVPN x.y.zx kiadásától kitalálták, hogy a kliensbe ez innentől kötelező és ráadásul ez az ide beírt szám+betű halmaz fel van használva az authentikációhoz, máris megvédték azokat akik úgy kapják a Synologytól az eszközüket mint mi ....

[ Szerkesztve ]

Egyébként ha már biztonság, csak most a való világban

Tudtok olyan biztonsági kamerát ajánlani, ami wifis, de hálózati konnektoros nem akkus s a synora menti a videot, s streamelhető is realtime? esetleg dual audio is érdekelne odavissza, vagy noti mozgás vagy hangra telefonra, nem tudom azok mennyire dobják meg az árát, eddig itthon is kaphatóak közül kb a logitech circle 2-t találtam ami mindent tud, de nem nasra ment s csak 24h ingyenes... nomeg ha feleannyi lenne az se lenne baj köszi!

Szia!

Örülök, hogy válaszoltál, már csak azért is , mert meg tudom végre kérdezni. Nevezetesen ezekről a fránya portokról lenne szó. Igen át írtam a portokat, de tulajdonképpen mit ér el vele az ember, ha ezek a portok végesek! Valami 65ezer akárhány....ezt egy robotnak olyan nehéz végigkajtatni? Érteném, ha végtelen lenne, de így!

"Bonyolult és hosszú jelszót használsz? nehezebb dolguk lesz.----úgy gondolom azt használok
Egyedi portokat használsz? nehezebb dolguk lesz----igen
Tiltasz ip címeket sikertelen próbálkozások után? nehezebb dolguk lesz-----igen
Nem admin jogú felhasználóval matatsz általában távolról? helyes!"------no erre eddig nem is gondoltam, bevallom férfiasan, hogy DE admin jogú felhasználóval matatok. Akkor ez így hüleség gondolom!

Csinálni kellene egy nem admin jogút, vagy a jelenlegitől elég ha elveszem eme jogot? A távolról matató felhasználó, csak olvasási jogot kapjon? Vagy akkor mit is kéne csináljak?

[ Szerkesztve ]

Soha ne félj valami újat csinálni! A bárkát is egy lelkes amatőr készítette, a Titanicot meg egy halom szakértő!

Szia!

Kicsit félve , de rákattintottam, nos az egyik valóban az otp oldalára visz (https), a másik meg(http://xn--tpbank-vqf.hu/) ide.... mittudomén?

Egyébként teljesen jó az autós példa, amit felhoztál.

Soha ne félj valami újat csinálni! A bárkát is egy lelkes amatőr készítette, a Titanicot meg egy halom szakértő!

Azért jó portot eltenni, mert a gyári portok ismertek, s első körben ott fog próbálkozni az illető az adott eléréssel. S ha be van állítva ip banolás, akkor azt a portkeresgéléssel már bukta az illető (hacsak nem syno a téves portot nem érzékeli annak, nem lennék meglepve ezek után, mert végülis belépni nem próbált, csak elérni )
S a legtöbb bot eleve csak pár dologgal próbálkozik, 21, 80 stb, az ritkább h az összes porton végigmenjen. Van olyan is, de így már a behatolók 90% kb aki eleve scannel kizártad.

Admin jogú helyett sima user használata csak egy erős ajánlás. Lehet neki akár egyébként az összes mappára olvasási és akár írási joga is, ha szükséges, a lényeg az, h a dsmben ne tudjon semmit se állítgatni, így ha valahogy megszereznék az adatait, akkor max ahoz férnek hozzá, amihez az a usered, és a dsmben semmit nem tudnak mókolni.

[ Szerkesztve ]

Az egyik linkben az o betü az nem o betü, hanem az orosz betükészletből az o betüre hasonlító karakter

Ez az átverés úgy müködik, hogy pl. lemásolják teljesen az otp oldalát, elküldik a linket, te ránézel és látod hogy az az otp oldala, rákattintasz, bejön az (ál) otp oldala, belépsz, ők eltárolják a felhasználó jelszó párost, majd továbbdobnak az otp oldalára egy üzenettel hogy pl. váratlan hiba történt, próbálja újra. Ekkor megpróbálod újra, immáron a valódi otp oldalán ahol minden megy mint a karikacsapás.

Csakhogy eközben már hackerek is tudják a banki belépődet és te ebből semmit nem vettél észre...

na ezért vezették be a bankok az sms meg mobil tokenes belépést, mert eszméletlen pénzeket nyúltak le a hackerek ilyen egyszerü módszerekkel.

Na de ez már off topic itt, csak arra akartam rámutatni hogy nem a spectre meg a meltdown az amitől egy átlag felhasználónak félnie kell, ez sokkal inkább a másik oldal réme.