Olyan automatizálható (API) szolgáltatásra lenne szükségem, ami ellenőriz egy URL-t, hogy káros, veszélyes, csaló, átverő, stb. oldalra visz-e. Nézegettem, de csak olyanokat találtam, amik kézi használatra készültek, captcha, egyebek, az nem jó.
Tudtok ilyet?
A minap frissítettem a firefox-ot, akkor, rögtön nem jelentkezett, viszont most félóránként(?) random üzeneteket dobál fel amolyan "kicsi ablakocskában" a képernyő jobb felső sarkában. Még valamit aktiválnom is kellene, van rajta egy bekeretezett "Activate" felirat. Számos női névvel és pici fürdőruhás(?) képekkel.
Felcsaptam az "AdBlocker Ultimate"- et de nem tűnt el a jelenség. Lehet semmi köze a firefox-hoz?
A Debian 11 -en nyoma sincs ennek a jelenségnek, pedig ott is frissítettem a Firefox-ot, ill. a héten vagy 100 más csomagot.
Mi az ördög lehet ez?
Hogy lehet ettől megszabadulni?
Megjegyzés: ezen a gépen, szinte folyamatosan fut a win10 egy Oracle virtual boxban, ott nem látom ezt a jelenséget
Arra gondoltam, hogy létrehozok egy üres Thunderbird profilt és pop3 vagy imap kapcsolaton lementeném az összes levelemet. Kimenőt és bejövőt. Régi emlékek miatt főleg.
Kérdésem: Tudja valaki mi a pop3/imap elérhetősége, port száma most a szolgáltatásnak? Csinált valaki hasonlót?
Köszönöm.
Szasztok!
Lehet van róla már másik topik, (gyors kereséssel nem találtam), de ugye (nagyon)fizetős lesz az indamail (is).
A kérdés innentől adott: van-e megbízható(bb), minimális költségű, (netalán ingyenes) mailszolgáltató, ahova érdemes átreggelni.
Saját mélszervert ugyan technikailag tudnék építenék, de kissé körülményesnek tartom a hivatalos részét, plusz csak mobilnet van itthon. Meg talán ágyúval verébre eset.
Kösz. Üdv. Sz.
1. kérdés (A probléma innen indul https://hup.hu/node/179458)
Adva van két ASUS router. Az egyik (a szolgáltató által kezelt) NAT mögött a másik publikus IP címen (freeDNS) jól látható.
A jól látható működik mint OpenVPN szerver, a másik (szolgáltatói NAT mögött) kliens. A kliens oldali hálózatból látszik a szerver oldali hálózat (mini szerver SMB,), a szerver oldali hálózatból nem látszik a kliens oldali hálózat (jelenleg csak egy Raspberry Pi kamera és meteorológiai "állomás").
Van erre egyáltalán megoldás?
(A kliens oldalon nem érdemes szervert indítani - NAT mögött van, nincs publikus IP cím.)
2. kérdés
Adva van egy OpenVPN szerver (mondjuk egy szerver gépre telepítve ami router/tűzfal mögött van) és néhány kliens kapcsolódhat rá.
Belehet állítani úgy az OpenVPN szervert hogy a kliensek lássák egymást?
(Ez tulajdonképpen ugyanaz a kérdés, csak az OpenVPN oldaláról megközelítve. Lehet szellemet üldözök?)
Sziasztok!
Egy ismerősöm tegnap óta nem tud belépni a gmail fiókjába a jelszavával.
Erős a gyanú, hogy feltörték a fiókját, és emiatt.
Telefonszáma hozzá van kötve a fiókjához, korábban gyakran volt, hogy telefonra küldött 6 számjegyű azonosítót a google, és azzal tudott belépni, de most nem ez van.
Telefonjára tegnap délután kapott is valami hasonló tartalmú üzenetet, hogy a jelszava megváltoztatása folyamatban van, most tudja leállítani, ha nem Ő volt, de mire eljutott odáig, már nem tudott belépni.
Tegnap délutántól, amikor próbál belépni, azt írja ki neki, hogy x órája megváltozott a jelszava. Ha próbál új jelszót kérni, először valami olyasmit kér, hogy az USB portra csatlakoztassa a biztonsági hardverkulcsot, majd miután megadja, hogy olyan nincs, kér valami 8 jegyű biztonsági kódot, ami szintén nincsen (vagy nem tudja).
A telefonja hozzá van kötve az email fiókhoz, valami módjának kellene lennie, hogy visszaállítsa - feltételezem.
2 email címe volt, mindkettőnél ugyanez történt, valószínűleg ugyanaz volt a jelszava mindkét email címéhez. A jelszó, amit használt, a google szerint erős jelszónak minősült.
2 faktoros authentikáció valószínűleg nem volt bekapcsolva, de úgy tudom, hogy kb. 1 éve a google automatikusan bekapcsolta mindenkinél.
Mi az, amit jelen esetben tud tenni? Mit érdemes még megpróbálni?
Valahol olvastam olyat, hogy élő emberrel is lehet beszélni a google-nél vagy szóban, vagy chaten. Tud erről valaki valamit?
Köszi a tippeket.
Sziasztok!
Adott egy Ubuntu 20.04-re telepített Zentyal7. Ez domén kontrollerként működik, a realm-je IRODAHAZ.LOCAL, workgroup irodahaz és a netbios name az iroda.
A probléma az lenne, hogy a login-logout folyamatok nagyon lassúak egyes klienseken. A hálózatuk rendben van. A barangoló profilok aktívak. Ha belépve készítek új mappát az asztalon, kilépés után 10--15 percig is áll le a gép és csak utána jelenik meg a /home/samba/profiles/<fh.nev>/desktop helyen a fájl.
A kliensek Win 10 Pro gépek.
A nyomozgatásom során néhány érdekességbe botlottam, de nem tudom, van-e köze a problémámhoz.
A syslog-ban elég gyakoriak az ilyen jellegű hibák
smbd_audit: chdir_current_service: vfs_ChDir(/home/samba/profiles) failed: Permission denied. Current token:...
A profiles mappán belül minden mappa megfelelően a felhasználók tulajdonában van, meg ahogy írtam, rendben megjelennek a fájlok, módosítások a profilokon.
A másik, hogy a samba-tool parancsnál pl. egy DNS query esetében ha az első paramétert, vagy is a server-t úgy adom meg, hogy IRODAHAZ.LOCAL akkor dob egy kerberos hibát:
Server host/IRODAHAZ.LOCAL@LOCAL is not registered with our KDC: Miscellaneous failure (see text): Server (krbtgt/LOCAL@IRODAHAZ.LOCAL) unknown
Ha viszont IRODA.IRODAHAZ.LOCAL formában teszem, akkor már nem dob hibát. Mindkét esetben lefut a dns query, vagy ha rekordot módosítok.
Nem tudom, merre tudnám tovább keresni a hibát. A gépet, Samba-t már számtalanszor indítottam újra, így most a közösség erejében bízom:D. Google sajnos nem segített és a Chat GPT sem.
A megoldás (május 5.):
Át kellett írni a stubs-ban a Samba konfigurációs fájlját, hogy csak az eth1 (belső) és lo interfészen hallgasson, az eth0-n ne. Ezt követően a host parancs már csak a belső címet adta az irodahaz.local-ra és iroda.irodahaz.local-ra is.
A tűzfalon nem engedte be az RPC porttartományát (49k valamennyitől 65000-ig). Megoldás a tűzfalon minden bejövő kapcsolat engedélyezése a belső hálóról, majd, mivel így megy, finomhangolás, hogy amire nincs szüksége mindenkinek, ne érje el.
Végül biztos ami biztos alapon azt a beállítást is engedélyeztük, ami azt teszi lehetővé, hogy a Zentyal a más DNS szerverekre irányuló kéréseit is a saját forwarderével kezelje le. Mivel csak AD-s gépeket szolgál ki, amiken a mi DNS-ünknek kell működnie, ez inkább fő a biztonság jellegű beállítás. Jelenleg úgy néz ki, működnek a barangoló profilok is.
Köszönöm mindenkinek a hozzászólásokat, ötleteket és segítséget!
Sziasztok!
Édesanyámnak van egy freemail-es (tévedésből) és egy gmail-es email címe. Az egyszerűség kedvéért beállítottunk átirányítást, hogy minden levelet toljon át a freemail a gmail-es fiókba. Azonban az a cudar helyzet állt elő, hogy a reklám levelek egytől egyig megérkeznek, a számlák viszont nem.
Ami számlánál lehetett, ott átírtuk a kapcsolattartói e-mail címet, azonban az egyik szolgáltatónál ezt nem tudjuk meglépni:
a jelenlegi email címhez tartozó aktiváló linkre nem lett kattintva és az csak 24 óráig él. Viszont megváltoztatni nem lehet az email címet, amíg a jelenlegi nincs aktiválva. Aktiváló link újra küldésére nincs lehetőség afaik.
Sakk-matt.
Ötlete valakinek?
Tudjuk, sz*r a freemail :)
Sziasztok!
Nem tudom, hogy ki használja közületek ezt a "csodát", de időről időre meggyűlik vele a bajom. A kártyán lejár a tanúsítvány, és megint cserélni kell.
Az aktuális oprendszer Windows 10 22H2, 64 bit, JRE fent van. A kártyaolvasó rendben van, AWP 5.3.2 telepítve, érzékeli a kártyát, be tudom rá jelentkezni. A GiroLock + Girolock2 CA és Root_ca tanúsítványokat telepítem a tanúsítványtárba a megfelelő helyre (Webhandler kézikönyv v5 alapján).
Felépül a VPN kapcsolat, kapok belső IP-t (Chrome, illetve Edge alatt is).
Indítom a Portable Firefox-ot (ebbe beimportálom a tanúsítványokat ugyanúgy, hozzákapcsolom az AWP-t), amit a GIRO-tól töltök le (68.3.0 ESR), frissítést kikapcsolom teljesen (updater.exe-t is törlöm), még véletlenül sem talál frissebbet. Erre a GIRO Zrt oldala csont nélkül betöltődik minden megnyitott böngészőben, tehát elvileg felépül a kapcsolat, de úgy néz ki, hogy mégsem.
A Webhandler oldala sem jön be, tehát nem tudok tanúsítványcserét indítani.
A giro-gateway szoftver fut a háttérben, hibát nem ír. Olyan, mintha nem azon keresztül menne a forgalom ...
Most este megpróbáltam itthoni gépen is, ugyanaz a szitu.
Aki használja közületek, nincs valami ötlete? A HelpDesk-kel ma több mint egy órát telefonáltam ... Előre is köszi!
Sziasztok!
Egy nagyon érdekes problémát vettem ma észre: Néhány külső mail szolgáltató (pl. google.com, t-online.hu) SMTP szervere TCP resetettel szakítja félbe a felőlük mifelénk beküldött leveleik TCP adatfolyamát, amint a beküldött adat mennyisége túllépi a 12MB-ot. Néhány napig újra próbálkozik az SMTP szerverük a levél beküldésével, de aztán feladja, amikor is a küldő valami ilyesmi hibaüzenetet kap (gmail esetén):
"Diagnostic-Code: smtp; write error: FAILED_PRECONDITION: write error (0): error"
A leveleket fogadó mail gateway-ünk az internet felől nézve DNAT mögött van és postfix fut rajta. Megpróbáltam egy másik postfixről ennél nagyobb (kb. 25MB-os) levelet átküldeni a szóban forgó mail SMTP gatewayre hasonló DNAT-on keresztül, de arról simán, minden hibaüzenet beérkeztek ezek a nagyméretű levelek.
Sokat próbálkoztam a postfixben a CHUNKING és PIPELINING képességes meghirdetésének kikapcsolásával, illetve a reject_unauth_pipelining korlátozás feloldásával, sőt átmenetileg még a spamszűrő miltert (rspamd) is letiltottam, de a hiba maradt. Ilyesmi üzeneteket látok a postfix logjában:
postfix/smtpd[7822]: lost connection after DATA (12779680 bytes) from mail-pl1-f169.google.com[209.85.214.169]
Amikor viszont kikapcsoltam a STARTTLS képességet a bejövő levelek fogadása esetén (azaz titkosítatlanná tettem a bejövő levélforgalmunkat a smtpd_tls_security_level = none paraméterrel), akkor már probléma nélkül bejönnek a nagyméretű levelek a fent említett szolgáltatóktól.
Összegezve úgy tűnik tehát, hogy bizonyos nagy email-szolgáltatók szerverei valami miatt nem hajlandóak kb. 12MB-nál hoszabb TLS titkosítású adatfolyamot fenntartani a felénk irányuló SMTP kommunikáció során, hanem látszólag minden különösebb ok nélkül TCP resettel zárják a kapcsolatot a bűvös határ átlépésekor. Néhány TLS kapcsolat kicsit tovább is eljut (láttam ~17MB-osat is), de általábon nem sokkal a 12MB-os korlát átlépésekor megjön a TCP RST.
Tapasztaltatok már ilyesmit? Mi lehet az oka?
Szerk: Ahogy andrej_ rávilágított, egy IDS/IPS rendszer okozta a hibát, amit azonban nem a szolgáltató üzemeltet, hanem on premise. Mea culpa.