FTP letöltési hiba Digi interneten

Hálózatok általános

Van egy érdekes hibajelenség, ami csak DIGI-s internettel (3 helyen is teszteltük, teljesen más településeken, viszont mindenhol optikais digi van) jelentkezik, mégpedig, hogyha nagyobb (1,5-2 gbájtnál nagyobb) fájlt töltenek le FTP-n, akkor Digis neten hibás lesz a fájl, nagyobb lesz. Nem digis internettel teljesen priman megy minden.

Titkosított átvitel esetén (FTPS, SFTP, SCP, stb, mind Proftpd-be van végződtetve) szintén hibátlan minden digis netnél is. A proftpd logjai alapján az mindig ugyanannyi bájtot küld amekkora a dájl.

Olyan, mintha lenne valami transzparens FTP proxy vagy ilyesmi.

Találkozott ilyennel valaki? Mi a fene lehet ami ezt csinalja?

 

Szerk: Sikerült a hibát reprodukálni egy 250 kbájtos képpel. Ha valaki más is szeretné elemezni itt érhető el az eredeti és a ftp-n feltöltött, hibás fájl: https://mega.nz/file/YLh3waZa#EGJ2nwk2IGmtQTaCH5nC3S-Z6lNtKoI-PNGJon3qtnE

( Mcsiv v | 2020. 06. 10., sze – 15:19 )

Gyorsan teszteltem neked: digi-ről tesztelve pureftpd -vel, 4.5 gigás tömörített file letöltve (passzív módban) SHA512 helyes

// Happy debugging, suckers
#define true (rand() > 10)

( Sulc v | 2020. 06. 10., sze – 15:24 )

Nem lehet az, hogy nincs helyesen beállítva az ascii/bináris mód amikor digiről nézed? Ha nem, akkor érdeklene egymás mellett a helyes és a sérült file is.

Én is ezt az ascii / binary dolgot erőltetném. Azaz van transzparens proxy, de valamit rosszul csinál, ezért lesz nem transzparens, hanem szar. És én is abba az irányba keresném, hogy mi a különbség a hibás és a hibátlanul letöltött fájl között.

Esetleg van valahol egy squid, ami valami rossz konfig miatt a neki (kesseléshez túl) nagy fájlokat már máshogyan proxizza, és ott van elkefélve a dolog. Ha ugyanonnan nézve mobilneten nem romlik el, akkor akár lehet a digis útvonalon is valahol az a szörny.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Egyáltalán miért rak be a digi akármilyen proxy-t az internet kapcsolatai elé?

Minden szolgáltató szokott ilyet, hogy ha valaki letölt valamit külföldről, akkor a következőnek már odaadják helyből, ha a HEAD alapján az jön vissza, hogy nem változott a cucc, ezzel rengeteget lehet spórolni a külföldi sávszélességen (és a belföldin is, ha több proxy is van fa-struktúrában).

https://iotguru.cloud

Hát ha pl. az ascii / binary van elrontva, akkor nem a végén lesz pár felesleges bájt, hanem mindenhol ahol soremelés karakter, oda kocsivissza-sorelemelést rak (ha jól rémlik). Ezért kéne pl. cmp-vel, vagy valami inteligensebb bináris összehasonlítóval megnézni a jó és rossz letöltések eredményét. Mert ha azt látod, hogy egy adott karaktertől egyszerűen el van csúszva, az eléggé árulkodó. Pl: alma és szilva azonos tartalmú szöveges fájlok, csak épp az egyik unixos, a másik dosos sorvégjelekkel van. és itt az összehasonlítás eredménye:

$ cmp -l alma szilva
5 12 15
6 153 12
7 303 153
8 266 303
9 162 266
10 164 162
11 145 164
12  12 145
13 163 15
14 172 12
15 151 163
16 154 172
17 166 151
18 141 154
19 12 166

cmp: EOF ennél: alma

$

Az 5. bájt 12 (unix NL) az almánál, és 15 (ez meg a kocsivissza, CR) a szilvánál. De a következő bájt a szilvánál pont az előző 12-s karakter. És jobban megnézve látszik is, hogy az első 12-s kódú karaktertől van egy csúszás. Aztán a következő 12-s kódú karakternél már kettővel csúszik el a dolog, mert itt is megjelent egy plusz karakter. Ami nehezítés, hogy nagy eséllyel amit letöltesz, az nem egy szöveges valami, hanem - ahogy írod is - CD.ISO, vagy film.mp4 - azaz teljesen véletlenszerűen lesz benne 12-es kódú (sorvégjel) karakter. De a cmp pont azért jó, mert bináris összehasonlításra jó, és ezzel a -l opcióval mutatja az össze eltérést. Mondjuk nagy fájhlnál egy | more azért kéne a végére.

Amúgy tippre pontosan azért rak oda cache-t, mint mindenki: a letöltések gyorsítása és sávszélesség értelmesebb kihasználása érdekében. (A squid pl. a http és https melett ftp-t is tud proxizni, szóval akár ott is lehet gond.) De nem tudom hogy van-e, csak felmerült ez is.)

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

( kbalint v | 2020. 06. 10., sze – 17:31 )

Úgy látom én vagyok az az ember, aki minden ilyen threadben megkérdezi: 2020-ban miért FTP-zik bárki? Mi a gazdasági előnye egy már közmegegyezéssel nem támogatott protokolt használni?

~ubuntu, raspbian, os x~

A cégünknél van publikus FTP az ügyfelek felé, annyi hátránya van, hogy a PDF állományokat nem nyitja meg a böngésző hanem letölti. A célnak megfelel, gazdasági előnye és hátránya nincs. Nagyjából 15 éve használjuk probléma nélkül. 

Bocsánat, de lófaszt, HTTP és SSH a divat már nagyon-nagyon-nagyon régóta, mint elsődleges támadási vektor. Az FTP annyira faék, hogy komolyan vehető biztonsági hiba nem nagyon van már a szoftverekben, ellenben ha nem sikerül kitalálni valami egyszerűen kitalálható jelszót és nincs anonymous írható terület, akkor nem nagyon van rajta fogás sem.

https://iotguru.cloud

A gyenge lába a man-in-middle a plain text jelszó miatt, illetve a jelszólopó vírusok, amik a kliensek gépéin begyűjtik a lemellett ftp-címeket, és a hozzájuk tartozó jelszavakat.

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Hát, nem sokáig fogja a Chromium alapú böngésző letölteni sem.... 

https://docs.google.com/document/d/1JUra5HnsbR_xmtQctkb2iVxRPuhPWhMB5M_zpbuGxTY/edit#

M81 (2020Q1)

  • FTP support is disabled by default. Flags for re-enabling FTP support is still present as with M80.

M82 (2020Q2)

  • Removal of FTP related code and resources.

~ubuntu, raspbian, os x~

Az ügyfeleink egy linket kapnak az oldalunkon. Hogy emögött egy felhő szolgáltatás vagy egy FTP szerver van teljesen mindegy, amíg le tudja tölteni. Ha a böngészők letiltják az FTP protokollt és nem lehet letölteni az állományokat, akkor át kell állnunk felhőre. 

Izé... Ezt nem értem.

Ha a helyi ftp szerver nem tudja ellátni a feladatát, akkor miért nem egy helyi http szervert állítasz be a helyére? Hogy jött ide a felhő?

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Én sem gondolom, hogy egy böngészőnek feltétlenül támogatnia kell az FTP-t, miközben soha egyik sem tudott teljesértékű FTP kliensként viselkedni. Viszont, az FTP nem is arra való, hogy böngészőből kattintgass FTP linkekre, hanem arra, hogy normális FTP klienssel csatlakozz és tölts le/fel.

Tizenöt éve úgy döntöttünk, hogy az ügyfeleinknek FTP-n keresztül adunk támogatást. Egyszerű volt feltölteni és linken keresztül elérhetővé tenni a honlapunkon. Ehhez egy böngésző elegendő az ügyfél részéről. Akkor még a felhős megosztást nem ismertük. 

A honlapunkra csak képet és szöveges tartalmát tudunk feltölteni. Fel sem merült soha, hogy az FTP nem jó megoldás. Egyébként egyszer valamilyen php hibát kihasználva megtörték az oldalunkat, az FTP szerverrel nem volt probléma soha. Nem értek hozzá tehát nem azt állítom, hogy az FTP biztonságosabb csak érdekességképpen írtam. 

Úgy látom, én vagyok az az ember, aki erre a szélsőségesen idealista, vadkapitalista hangvételű hozzászólásra megfelelően reagálni fog.

2020-ban miért FTP-zik bárki? Mi a gazdasági előnye egy már közmegegyezéssel nem támogatott protokolt használni?

1. Azért, mert nem minden internetfelhasználó gazdasági™ előnyöket™ keres azokban a szolgáltatásokban, amiket használ, pláne nem minden felhasználó trend- és évszámbuzi elvek mentén dönt a használt protokollok mellett.

2. Ha mégis, valakinek lehet, hogy nagyobb gazdasági™ előny™, hogy nem kell lecserélnie az FTP kliensét csak azért, mert közmegegyezéssel nem támogatott az Internet kisajátítására törekvő multik és az őket feltétlen véleményhűséggel követő csődület éllovasai épp olyat játszottak, hogy kiszavaztak egy protokollt.

3. Szabványos és ezek a szabványok egyszerűek, egyértelműek és már régóta ismertek, amik nem úgy születtek, hogy leHUPpant valami korral™ haladó™, korszerű™ gondolkodású™ agilis sztárfejlesztő a babzsákjára és kifejlesztette összetákolta az ő saját tutinak gondolt módján.

4. Az FTP továbbra is sokkal egyszerűbb, hatékonyabb és szabványkövetőbb módja a fájlfeltöltésnek, mint amit a HTTP-s megoldások adnak. A legtöbb HTTP-n működő szutykoknál 2020-ban sem sikerült odáig eljutni, hogy egy nagy fájl feltöltését megszakadt letöltés esetén folytatni lehessen.

5. A cloud-idealizmusok, mint a Google Drive, OneDrive és iCloud nagyságrendekkel több erőforrást pocsékolnak el totál feleslegesen mind letöltés, mind feltöltés esetén. Nem beszélve arról, hogy a Google Drive például a mai napig képtelen volt megoldani a megszakadt letöltések folytatását, ami ráadásul jelenleg technikailag is lehetetlen, mivel valamilyen oknál fogva nem küldik le a Content-Length headert. Egyszóval, alapdolgok nincsenek rendben.

6. Kompatíbilitás. Az elmúlt 20-30 évből bármilyen rendszeren találsz egy valamirevaló FTP klienst, amivel tudsz fájlokat feltölteni és letölteni. Böngészőt, amiben tudsz HTTP-n átcsatornázott fájlfeltöltéseket összetapicskolni, már nem biztos.

Nincs saját, publikusan elérhető FTP szerverem, ahogy HTTP, SMB, NFS, egyéb más fájlátvitelre alkalmas protokollon sincs.

Vannak FTP szerverek, amiket én üzemeltetek, ezeknek a címét viszont nem áll módomban megadni.

Ha pedig arra apellálsz, hogy azért nincs létjogosultsága az FTP-nek, mert én nem tartok fenn sajátot, akkor ne fáradj: https://a.te.ervelesi.hibad.hu/te-is

Ezért (is) jó, hogy az ügyfelek nem olvasnak HUP-ot, mert még vannak :)

Speciális igényekre (kamerás példa, de én is tudok egy speciálisat) valóban hasznos lehet az FTP, ugyanakkor, ha az a cél, hogy laikus ügyfelek gyorsan és biztonságosan elérjenek tartalmat/fájlokat, akkor már egy ideje nem érdemes FTP-vel bajlódni. Sajna a gyűlölt felhő vezet, de vannak on-premise megoldások is

Ritkan ertek egyet veled, de most sajnos el kell ismernem, igazad van. Az FTP pont az, amire a kerdezo hasznalni akarja: egy faek egyszeru fajlmegoszto platform. Fajlok feltoltese, letoltese, ennyit tud, es ezt megbizhatoan tudja, ellenben a mostani workaroundotl, ganyolt megoldasokkal (igen, most ratok nezek, Dropbox, Google Drive, OneDrive es tarsai), aminel kb csak azert mukodnek a dolgok, mert a dolgok _altalaban_ mukodnek, ha meg nem, akkor meg IJ, viszlat. 

Es 2020-ban sincs senkinek semmi baja az FTP-vel, csakhat ugye mara egyetlen valodi bongeszogyarto maradt, a Google, es ha o kiszavaz valamit a tamogatasi korbol, akkor nincs mas lehetosege a Microsoft/Mozilla/Opera trionak sem, mint bologatni hozza, mert puhapocsok voltak fenntartani a versenyt. 

Es ezzel sincs amugy semmi gond, de ne allitsuk mar be ezt normalisnak, mert messzemenokig nem az.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Nem értek egyet. Az FTP már egy 49 !!! éves protokoll. Egy olyan korban született, mikor még nem lógott minden és mindenki a neten, ezért a biztonság nem volt követelmény. Bőven van rá modern alternatíva, kritikus, védendő adatokra azt kell használni, pl. SFTP, HTTPS. Upgrade-elni kell, haladni kell a korral, ez nem agilis sztárfejleszőség kérdése.

A Total Commander fájlkezelő, nem FTP kliens, soha nem is lesz az utóbbi. Az FTP funkció csak kényelmi adalék benne. Ha komoly FTP kliens kell, akkor Windowson TC helyett FileZilla.

Kompatibilitást a hajunkra kenhetjük, pont a topik tanulsága, hogy nem mindig működik ez sem megfelelően. Viszont abban egyetértek, hogy FTP kliens még régi OS-ekhez is mindig elérhető, ezért retrózási céllal viszont még használható, csak akkor kritikus adatot nem javallott rábízni. Pl. drivereket, régi játékokat, régi OS-t, egyéb általános (egyéni adatot nem tartalmazó) fájlok megosztására még elegendő, szög egyszerű protokoll.

Magánvéleményként: én sose szerettem az FTP. Kifejezetten összehányt, sebtében foltozgatott protokoll, mindenféle ócska binary meg text alapú hackeléssel, meg ótvar jogosultságkezeléssel. Kifejezetten primitív, átgondolatlan fércmű. Örülök, hogy hal kifelé végre.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Értem én, hogy csak és kizárólag szélsőségesen idealista, évszámbuzi klisékben vagy képes gondolkodni és az elavult vs. nem elavult síkon ítélsz meg mindent, a dolgok gyakorlati hasznát és a szakmaiságot messziről elkerülve és magasról leszarva. Amit már kevésbé értek, hogy ezt miért kell úton-útfélen bizonygatnod.

Egy olyan korban született, mikor még nem lógott minden és mindenki a neten, ezért a biztonság nem volt követelmény.

És egy olyan korban terjedt el, amikor már létezett kábeles internet, de WiFi még nem és nem kellett orrba-szájba túltitkosítani minden hálózati forgalmat ahhoz, hogy az titokban is maradjon. Pláne, hogy akkoriban főleg helyi (magyar szervereken lévő) szolgáltatásokat használtunk, amik 4-5 router hopon belül megvoltak, nem kellett 20-30 csomóponton keresztül megkerülni a fél világot (vagy legalább egy egész kontinenst) a csomagoknak. Később a helyi szolgáltatóktól sikerült multiéknak elszipkázni az Internet népét, és a lényegi kommunikációt már egyre inkább külföldi szervereken bonyolítani. Régi, de aktuális. Aztán később sikerült olyan silány, szabványokat és messziről bűzlő trágyadomb implementációkat kitalálni, mint a 802.11 és ezzel legalább egy évtizedre megágyazni az internetkapcsolatok bárki általi szabad és triviális lehallgatásának, nem beszélve a magánhálózatokba való betörések megkönnyítéséről.

A Total Commander fájlkezelő, nem FTP kliens, soha nem is lesz az utóbbi.

A Total Commander elsősorban fájlkezelő, másodsorban egy jó alapfunkcionalitást biztosító FTP kliens. A FileZilla valóban többet tud nála, így az tekinthető teljesértékű FTP kliensnek, a TC-vel szemben.

ezért retrózási céllal viszont még használható

Nem. A mai napig minden más célra is használható. Nálad valamiért beakadt ez a "retrózási" lemez és a mai napig nem sikerült túllépned rajta. Próbáld meg felfogni, hogy nem mindenki csak a legújabb™, legtrendibb™, legfiatalabb™, legmenőbb™, legnagyobbsztáropensourcefejlesztőáltallegjobbanmegírt™ szoftvereket és protokollokat szereti használni. A kompatíbilitásról meg annyit, hogy adott 20 random platform (OS és hardver bármilyen kombinációja, kortól és architektúrától függetlenül), vajon melyiken mész többre egy akár alapszintű FTP klienssel, mint egy Google Drive linkkel? Szerintem egyértelmű a válasz. Lehet, hogy vannak inkompatíbilis FTP kliens-szerver párok, de nagyságrendekkel kompatíbilisebb egy FTP-s megoldás, mint egy csiligány, JS-bloat webes idealizmus.

Kifejezetten összehányt, sebtében foltozgatott protokoll, mindenféle ócska binary meg text alapú hackeléssel

Pont úgy, mint ahogy a HTTP-t ma használják, meg a GZIP-pel tömörített, minified JS és JSON. Ja nem. Annál kevésbé. Csak a jelenleg csúcsra járatott protokollok ótvarságát elrejti előled a "mindent tökéletesnek látok, ami nem elég régi" szemellenződ.

Az a jo ebben a szalban, hogy eleg nagy biztonsaggal meg tudom tippelni, hogy ki uzemeltet sok eve mindenfele rendszereket, es ki az, aki csak ugy idejon kiduhongeni magat, hogy meg mindig nem NodeJS-ben megirt MongoDB alapu infrakon dolgozunk Angular es/vagy React altal szallitott Twitter Bootstrapban megirt feluleteken.

Annyi sok baj van azzal, amit irtal, hogy nem is tudom, hol kezdjem.

1) Az FTP 49 eves protokoll, egy olyan korban szuletett, ahol az egyszeruseg volt a fo szempont, es a mai napig ezert nepszeru a hasznalata, mert pl embedded kornyezetbe SSL/TLS alapu titkositast rakni nem is igazan jo otlet (nem annyira alkalmas ra a platform), es eroforraspazarloan felesleges. 
2) Attol, mert valami 49 eves meg nem kell fejbeloni es kiusztatni a tengerre egy jegtablan. Az IP protokoll 41 eves, es koszoni szepen, semmi baja sincs, es van helyette jobb, megsincs tulekedes a levaltasara.
3) Az, hogy amikor az FTP-t fejlesztettek nem volt a biztonsag szempont, semmit nem jelent az utokorra nezve. Jelenleg az FTP tamogatott TLS es SSH felett is, a szerver oldali biztonsag pedig implementacio fuggo. A protokoll egyszerusege miatt siman lehet akar egy FTP szerver emulatort is irni, ami valojaban nem - kozveltenul - fajlokkal dolgozik, csak ugy lattatja a tartalmakat, mintha fajlok lennenek.
4) Arra, hogy egy kompatibilitas nem mukodik megfeleloen, nem az a megoldas, hogy akkor lojuk fejbe, ne szenvedjen. A legtobb esetben az implementacio fixalasa kisebb fajdalom szokott lenni, mint egy teljesen uj protokollra atmigralni ugy, hogy menet kozben kiderul, hogy amugy van 2-3-5-sok device, ami kizarolag az altalunk ancient-nek, nem agilisnek, sot, egyenesen retronak titulatl protokoltt beszeli kizaolagosan, es incredible penz azokat az eszkozoket lecserelni. 

Nagyon szep ez az agilis, fejlodo, minden masodik projektben uj frameworkot es megoldasokat felmutato vilag, kellenek is ilyen projektek - de nem az uzemeltetesbe. Ott bizony sokszor a jo oreg FTP, SMTP, Telnet protokollokkal nagyobb csodakat lehet tenni, mint egy NodeJS -ben megirt csillivili admin felulettel.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Ez nem agilisség, ha van valamire modern alternatíva, ami biztonságosabb, akkor azt érdemesebb használni. Ha már egyszer ki van fejlesztve, és ott van, nem kell hozzá újra feltalálni a kereket. Nem éri meg az elavult dolgokhoz ragaszkodni, mert azzal senkinek nem tesztek jót, magatoknak és másoknak is kárt okoztok vele. Tudni kell elengedni a régi dolgokat. Értem, hogy sokaknak ez megszokás, nosztalgia, a régi megoldások egyszerűbbek, átláthatóbbak, azt még értették, és emiatt megy a ragaszkodás hozzá végtelenségig, meg a hackelés, lélegeztetőgépen tartás.

Ez, amit írsz, hogy régi eszközök, ez nem az FTP mellett érv, hanem a régi eszközök lecserélése mellett. Ma már a gigherces, terabájtos, gigabites hardverek korában nem szempont az egyszerűség sem. Ráadásul az nem egyszerűség, hanem megint mocskos hack, hogy TLS felett futtatod, ez amolyan gányolás gányolása című megoldás, és semmit nem nyersz rajta ahhoz képest, hogy ha eleve SFTP-t használnál.

A világ, technológia, IT ilyen, egyre bonyolultabb. A maga korában az FTP is bonyolultnak számított, meg az Ethernet és a többi. Az újra mindig nyitottnak kell lenni.

Ezt nem érti hajbi sem az XP mániájával. Ja, még lehet futtatni, ha nagyon ultrakeményen hackeled, talán még használható, de egy csomó önszopatás, aminek igazából nincs valódi előnye. Megdolgozol vele, és ott leszel egy elavult öszvérmegoldáson, ami rommá van hackelve, és már csak a csoda tartja össze. Hajbazer sem XP-t használ, hanem egy 64 bites Win2k3-at, amit szénné hackelt már mindenféle alternatív böngészővel meg patch-csel, és már csak a nevében XP, de ez neki csak ilyen pszichológiai dolog, annak a tudata, hogy azt használ, mert az a neve, meg a felülete hasonlít, de igazából csak önáltatás. Kap vele egy kis haladékot még, de a váltás elkerülhetetlen lesz. Még most ő úgy érzi, hogy „nyert”, meg ő megmutatja, hogy „még használható”, közben meg csak önámítás, meg önszopatás az egész. Kicsit olyan, mint mikor a csirkének levágják a fejét, de még reflexből fejetlenül lefutkároz néhány kört, mert nem akarja tudomásul venni, hogy vége.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Hihetetlen, hogy még nem unod a csúcsra járatott papagájkodást. Ami a kisebb probléma lenne, de ráadásul ismét hülyeségeket hordasz össze és hazudsz is.

amit szénné hackelt már mindenféle alternatív böngészővel meg patch-csel

Nincsen szénné hackelve patchekkel. Hivatalos Windows frissítések vannak felrakva rá 2014 áprilisig bezárólag. Semmi más 3rd-party hack, ami rendszerkomponenst érintene, nincs rajta, tehát még egy modded UXTheme.dll sincs.

Képzeld el, vannak alternatív böngészők Windows XP-re, mert volt néhány lelkes fejlesztő-maintainer, akik bevállalták, hogy frissen tartják és hibákat is javítanak, ha már Mozilláéknak büdös volt a munka és nem voltak hajlandóak tudomásul venni, hogy több tízmillió ember használja a böngészőjüket XP-n. Az alternatív böngésző, amit használok a Mypal, a legfrissebb kiadása 11 napos. A motorja a mai napig támogatott, karbantartott és folyamatosan fejlesztett, Gecko-alapú upstreamből jön, a felhasználói felülete pedig a régi Firefoxé. Tehát, a webes szabványokhoz felzárkóztatják, a de a felületét nem basszák szét csiligány, animációbuzi, a használhatóságot és a felhasználói szabadságot minden főverzióval egyre inkább lábbal tipró újításokkal, mint az mostanában Mozzilláéknál szokás. Ezen felül XP-kompatíbilitási patcheket kap, meg néhány optimalizációs patchet, hogy jobban kihasználja az XP-t (pl. GDI rajzolás és videorenderelés terén). És nem, ehhez nem kell 3rd-party WinSSL-t szénné hackelni a rendszerbe, mert a benne lévő, XP-re backportolt NSS minden modern titkosítási szabványt (pl. ECC tanúsítványok) kezel.

és már csak a nevében XP, de ez neki csak ilyen pszichológiai dolog, annak a tudata, hogy azt használ, mert az a neve, meg a felülete hasonlít, de igazából csak önáltatás

Az operációs rendszer neve: Windows XP x64 Edition. A többit beszéld meg a Microsofttal vagy a pszichológusoddal. Emellett, számtalanszor elmondtam már, hogy dual-boot-ban használok 32-bites Windows XP-t és x64 Editiont. Attól, hogy te lehúzod az XP címkét róla, még ugyanúgy ezt a rendszert használom és nem önáltatás, mert hatékonyabban dolgozom vele, mint egy okostelefonbuzi, végletekig lebutított felületű GTK3-as Linuxon, ahol a Red Hat grafikus felületeket érintő ámokfutása után már csak terminálban lehet értelmesen dolgozni, ami akármennyire is szépíted, minimum 30 éves technológiai lemaradás. Nem is értem, hogy te, aki haladó felhasználói gyakorlatként a terminálba pötyögést isteníted, hogy tudsz ezek után fejlődésmániásként tükörbe nézni. Ja bocs te nem nézel tükörbe, mert az múltszázadi™. Te előveszed az okostelefont és bekapcsolod az előlapi kamerát.

Kap vele egy kis haladékot még, de a váltás elkerülhetetlen lesz.

Ezt sohasem tagadtam. Viszont, egyelőre még elkerülhető.

Még most ő úgy érzi, hogy „nyert”, meg ő megmutatja, hogy „még használható”

Nem az a célom, hogy megmutassam, hogy használható. Ezt használom, mert ez az, ami a legjobban használható. Ellentétben veled, aki úton-útfélen akarod rásózni mindenkire a Red Hat által végletekig elsilányított, csiligány, animációbuzi, tapicskoló desktop Linuxot, iPhone- és Android-utánzatú ablakokba erőltetett DOS 6.22-t felülről közelítő használhatósággal.

közben meg csak önámítás, meg önszopatás az egész.

Szerintem meg a desktop Linux napi használata az.

mert nem akarja tudomásul venni, hogy vége.

A szoftverek nem akkor "halnak meg", amikor eltelik X év, ami Raynes Szélsőségesen Évszámbuzi Fejlődésmániás Segédmunkatársnak betriggereli a legacy alarmot, vagy éppen a mögöttük álló profitéhes multi úgy akarja, hogy elegen megvegyék az újrafeltalált kerekét. Akkor "halnak meg", amikor a felhasználók kidobják alóla a gépet vagy abbahagyják a használatát. Nálam még nem halt meg. Nálad meg soha nem is élt igazán.

" Hivatalos Windows frissítések vannak felrakva rá 2014 áprilisig " - Tehát az elmúlt bő hat évben felfedezett sérülékenységek nincsenek, és nem is lesznek javítva.

" Mozilláéknak büdös volt a munka és nem voltak hajlandóak tudomásul venni, hogy több tízmillió ember használja a böngészőjüket XP-n " - TE, mint hardcore XP felhasználó, mivel támogattad őket abban, hogy az XP-s vonalat is tovább tudják vinni?

" Az operációs rendszer neve: Windows XP x64 Edition. " - ami csak a nevében XP, illetve a ráhúzott felületben.

" a Red Hat grafikus felületeket érintő ámokfutása " - tényszerűen mire gondolsz? Mert nekem a twm/ctwm/fvwm95/kde/satöbbi után a RHEL7/CentOS7 GUI-ja teljesen kézreáll, jól használható. Igen, az XP-től távol áll/másképp néz ki/másképp működik... :-P
 

" mert ez az, ami a legjobban használható. " _neked_ a legjobban használható. Mert nulla indíttatásod van arra, hogy újat tanulj. Nekem napi használatban van Windows 7, Windows 10, Raspbian meg CentOS7, illetve néhanapján XP is. Android alaponmeg MIUI, stock Android, meg ADW2 launcher-rel elfedett stock Android felüelt. És mindegyiken meg tudom csinálni azt a feladatot, amit ott épp kell. Varietas delectat, és nem tudnám megmondani, hogy melyik az, amelyik a legjobb, mert mindegyiket lehet hatékonyan kezelni.

" A szoftverek nem akkor "halnak meg", amikor eltelik X év, ami Raynes Szélsőségesen Évszámbuzi Fejlődésmániás Segédmunkatársnak betriggereli a legacy alarmot " Hanem mikor? Amikor hájblézer ludditta maradásmániás XP-buzi kitalálja? (Bocs, de a negatív jelzők aggatását te kezdted...) Egy sw életciklusa normálisan akkor ér véget, amikor a funkcionális- és biztonsági hibáinak a javítását már nem csinálják meg, azaz megszűnik a támogatása. Akkor bizony célszerű új verzióra váltani. Lehet maradásmániásan ragaszkodni a DOS-hoz meg a Windows 3.1-hez, Trumpet winsock-kal, meg mosaic böngészővel - csak erősen szuboptimális lesz... :-P

 

Tehát az elmúlt bő hat évben felfedezett sérülékenységek nincsenek, és nem is lesznek javítva.

Ami biztonságtudatos felhasználás mellett az ég világon semmi hátrányt nem jelent. Más kérdés, hogy te hátradőlsz és az operációs rendszeredtől várod a biztonságot a frissítések általi biztonság illúzióját.

TE, mint hardcore XP felhasználó, mivel támogattad őket abban, hogy az XP-s vonalat is tovább tudják vinni?

Amennyivel te, hogy a keresősávot a friss verziókban a pofádba animálják és a régire való visszaállítás lehetőségét is kivegyék.

ami csak a nevében XP, illetve a ráhúzott felületben.

Akkor máskor majd NT verziót írok, hogy neked se és Raynes-nek se ránduljon görcsbe a gyomra, amikor azt látja leírva tőlem, hogy Windows XP x64 Edition, és érezzen kényszert, hogy undorítóan szőrszálhasogató módon mindig odabiggyessze, hogy "az csak nevében XP". Egyáltalán mit akarsz ezzel mondani? Windows XP SP3-at (32-bit) és Windows XP x64 Edition-t használok. Pont. A többit beszéld meg multiékkal, hogy miért így nevezték el.

tényszerűen mire gondolsz?

Számtalanszor leírtam nagyon sok threadben. Ha ezt, a Raynesnek címzett válaszomat megtaláltad és sikeresen belekötöttél, keresgélj még egy kicsit és fogsz találni elég indokot.

RHEL7/CentOS7 GUI-ja teljesen kézreáll, jól használható.

Egy okostelefon használhatósági szintjét lehet, hogy hozza, de egy normális desktop operációs rendszerét nem. Vagy mondom inkább másképp, hátha így megérted: Nekem nem áll kézre.

Mert nulla indíttatásod van arra, hogy újat tanulj.

Van, hogy naponta próbálok ki új rendszereket és deklarálom, hogy továbbra sem érett meg a Linux a desktop használatra.

És mindegyiken meg tudom csinálni azt a feladatot, amit ott épp kell.

Én is meg tudom, csak én nem akarom, ha XP-n is meg lehet.

" Amennyivel te, hogy a keresősávot a friss verziókban a pofádba animálják és a régire való visszaállítás lehetőségét is kivegyék. " - Én picivel többel, de sebaj - tőled tehát nem számíthatnak sem közreműködésre, sem másmilyen segítségre.

" Akkor máskor majd NT verziót írok, hogy neked se és Raynes-nek se ránduljon görcsbe a gyomra " senkinek nem rándul görcsbe a gyomra, csak jeleztük már többször, hogy attól, hogy XP-nek hívják, a rendszer lényegét tekintve nem az - ahogy egy jól felpimpelt fvwm95-tel sem lesz Windows 95 a Linuxból.

" Számtalanszor leírtam nagyon sok threadben. " - ha volt erőd számtalanszor leírni, akkor ide is idebiggyeszthetted volna, hogy tudjam, mi az annyira fosch a napi használatban kényelmesnek tűnő RHEL/CentOS grafikus felületében... Mert nem bírok rájönni... (Ha csak az nem, hogy nemikszpé... bár ez kettőnk közül maximum neked gond...)

" mondom inkább másképp, hátha így megérted: Nekem nem áll kézre " - Ez egészen mást jelent,mint amikor azt írtad, hogy: "
" a Red Hat által végletekig elsilányított, csiligány, animációbuzi, tapicskoló desktop Linuxot, iPhone- és Android-utánzatú ablakokba erőltetett DOS 6.22-t felülről közelítő használhatósággal "

Remélem érzed a kettő kijelentés közötti, árnyalatnyinál nagyobb különbséget.

" Van, hogy naponta próbálok ki új rendszereket és deklarálom, hogy továbbra sem érett meg a Linux a desktop használatra. " - tedd hozzá, hogy szerinted. És azt is, hogy futólag megnézve. Képzeld: A Windows 10-et megszokni, és hatékonyan használni nekem sem egy nap volt. Viszont most már teljesen jól elvagyok vele - ha az ember hajlandó a felhasználói felületet felfedezni, hajlandó időt szánni arra, hogy átlássa, mit és miért úgy oldott meg a felület zervezője/fejlesztője, mindjárt kézreállóbb lesz az, ami épp előtte van.

" Én is meg tudom, csak én nem akarom, ha XP-n is meg lehet. " - Van olyan, amikor nincs választás, támogatás nélküli rendszert nem lehet használni, azaz az XP "nem opció". Egyébként mióta csak alkalomszerűen kerül elém XP, egyre jobban látszik/érezhető, hogy mennyivel hatékonyabb a Windows7/10, vagy épp a CentOS7 GUI-s felülete. Megszokás és "akarás" kérdése az egész.

attól, hogy XP-nek hívják, a rendszer lényegét tekintve nem az - ahogy egy jól felpimpelt fvwm95-tel sem lesz Windows 95 a Linuxból.

Oké. Elsőre is tudomásul vettem, sőt előtte is tisztában voltam vele, hogy mivel későbbi kiadás, így a már korábban is 64-bites kiadással rendelkező, 2003-ból forkolták, nem a klasszikus 32-bites XP-ből. Miért kell úton-útfélen, szőrszálhasogató módon ebbe belekötnöd? Tekintettel arra, hogy az sem igaz, hogy nem használok 32-bit-es XP-t, mivel használok. Vagy minden egyes alkalommal írjam le, hogy "Windows XP x64 Edition, tudod, amit 2003-ból forkoltak"? Tényleg nem esik le a tantusz, mennyire undorítóan szarrágó dolog ezt számonkérni?

nemikszpé... bár ez kettőnk közül maximum neked gond

Tekintettel arra, hogy egyértelműen az "én igényem != te igényed" szintű kötekedés a célod, most nem látom értelmét újra leírni. Ha tényleg ennyire érdekel, majd szépen visszakeresed. De nem fogod, mert csak kötekedni akarsz.

Remélem érzed a kettő kijelentés közötti, árnyalatnyinál nagyobb különbséget.

Arra írtam, hogy "nekem nem áll kézre", hogy ha te képtelen vagy tudomásul venni, hogy vannak haladó felhasználók, akiket igenis zavar a grafikus felületek Red Hat általi egyre inkább végletekig butítása, akkor vedd úgy, hogy nekem nem áll kézre és egyezzünk ki ennyiben, hiszen ígyis-úgyis engem próbálsz majd beállítani feketebáránynak, hogy valójában a RHEL7 a hiperszuper™ és bennem van a hiba, hogy képtelen vagyok megszokni a csiligány UI-t, meg a jobbnál jobb anti-feature-öket, mint például a kikapcsolhatatlan rekurzív fájlkeresést, ami persze szintén csak "nekem gond". Ja nem.

tedd hozzá, hogy szerinted. És azt is, hogy futólag megnézve.

Azt hittem, hogy abból, hogy egyes szám első személyben fogalmazok, magától értetődő, hogy a véleményemről van szó. Ezt a szintű szövegértést általános iskolában tanítják. Azt pedig ne te mondd meg, hogy futólag vagy sem, hadd tudjam jobban, hogy én mit csinálok, még akkor is, ha az eközben kialakult véleményemmel nem értesz egyet. Órákat-napokat eltöltöttem már desktop Linux-rendszereken és bőven van tapasztalatom ahhoz, hogy kijelentsem, hogy számomra még nem érett meg desktop rendszernek, sőt egyre távolabb van attól, amit én egy desktop rendszertől elvárnék. Ha pisztolyt tartanának a fejemhez, akkor egyik napról a másikra át tudnék szokni és egyáltalán nem érezném úgy, hogy a hiányzó szaktudásom áll ennek az útjában. Azt kéne elfogadnod neked is és Raynesnek is, hogy én, mindkét rendszer haladó szintű ismeretét tekintve úgy döntöttem, hogy továbbra is XP-t használok, mert még mindig sokkal egységesebb, gyorsabb, hatékonyabban használható, kevésbé idegesítő professzionális alternatíva a csiligány modernnek™ hazudott, animációbuzi tabletutánzatok és bloatware-ek helyett.

hajlandó időt szánni arra, hogy átlássa, mit és miért úgy oldott meg a felület zervezője/fejlesztője, mindjárt kézreállóbb lesz az, ami épp előtte van

Vagyis, ha hajlandó úgy gondolkodni, mint egy IQ=80 tapicskoló ösztönlény és tudomásul venni, hogy mától csak úgy használhatja a rendszert, mint ők, mert ők vannak többen és sok lúd disznót győz alapon neki kell önként és dalolva belefojtani a haladó felhasználói szokásait a használhatatlanság bugyraiba. Lásd pl. kikapcsolhatatlan rekurzív keresés. Semmilyen desktop Linuxot nem vagyok hajlandó főrendszerként használni, amiben ez, a felhasználói szabadságot és a használhatóságot lábbal tipró anti-feature benne van. Pontosan tudom, hogy kell kipatchelni a GTK3-ból, és azt is, hogyan kell DEB/RPM csomagot csinálni belőle, hogy rendszerszintű legyen a módosítás. Elvből nem fogom megtenni. Ha megtenném, akkor lenne, a Raynes által említett, "szénné hackelt" rendszerem. Pláne nem fogok olyan rendszert használni (RHEL7), ami után az egyre inkább katasztrófális szintre butított felhasználói felületeket elsilányító Red Hat licencdíjat kap.

Van olyan, amikor nincs választás, támogatás nélküli rendszert nem lehet használni, azaz az XP "nem opció".

Nekem lehet használni. Sajnálom, hogy neked ilyen szélsőségesen idealista, fejlődésmániás főnök/munkahely/értékrend jutott, hogy nem opció.

mennyivel hatékonyabb a Windows7/10, vagy épp a CentOS7 GUI-s felülete

Én ugyanezt érzem, csak fordítva, amikor valami miatt több óráig, vagy akár több napig egy modern desktop Linuxon kell dolgoznom. Talán CentOS 6 az egyetlen kivétel, de azt már nagyon régen kellett használnom. Amikor visszaülök az XP elé, érzem azt, hogy minden azonnal úgy történik, ahogy én szeretném, abban a szent pillanatban, hogy a billentyűparancsot lenyomtam és számíthatok arra, hogy ami ma működik X módon, az holnap is X módon fog működni és nem azon kell elmélkednem, hogy most éppen Matthias Clasen, Peter Hutterer vagy Lenart Poettering szélsőségesen idealista Red Hat fejlesztő miért döntött úgy, hogy holnaptól, egy rendszerfrissítés után, csak egy fokkal elbaszottabb módon, kevésbé hatékonyan használhatom a rendszeremet. Apropó, a hatékonyabb™ Windows 7-en nem félsz, hogy meghekkelnek? Vagy az még opció™, mert nem olyan régen járt le a támogatása?

Az lenne a kánaán :)

Amúgy mostanság épp normális PDF nézegetőt keresek. A Foxitreader jó és gyors volt vagy 5 évig. Aztán azt is megvette vmi moslék arcnélküli capitalinvestmentes befektetőcsoport. Na azóta basztak bele cloudbafeltöltő plugintól kezdve minden lószart. Így már olyan tetves lassú lett mint anno az Acrobat szarja, aminek sok évvel ezelőtt a leváltására kinéztem a foxit-et.

Ezzel az a baj, hogy csak Windows-ra van, pedig engem is erdekelne alternativa. Van barkinek otlete olyan pdf-olvasora, ami kicsi, konnyu, gyors es megy Mac OS-en es Windows-on is? Elony lenne, ha a fillable pdf-et is tudna kezelni (ki tudnam tolteni, ez valamiert jellemzoen leginkabb az Adobe-nak megy, nem ertem miert ennyire bonyolult).

( answ | 2020. 06. 11., cs – 09:18 )

Nincs víruskereső/"okos" tűzfal a gépen, amin próbálod? Az szokott ilyet okozni. Lehet másik netnél nem aktív ez a funkció, mert valami biztonságos zónának hiszi.

Nekem is digis netem van (FTTH) bridge módban. Ki fogom próbálni. De lehet router módban kever be valami FTP ALG az eszközön.

Nem kapcsolható ez a routerben?

user: user

pass: digi

Legtöbb ilyen otthoni eszközben be szokott lenni pipálva és lehet signed hossz probléma szoftverében.

Kipróbáltam bridge módban Digi FTTH-n Mikrotik routeren Firefox alatt letölteni:
http://ftp.fsn.hu/mirrors/ubuntu-cd/20.04/ubuntu-20.04-desktop-amd64.iso

~1 perc alatt lejött és tökéletes lett sha256sum.

Milyen ONT-n próbáltad?

Próbáld meg kikapcsolni FTP ALG-ot egy ilyen helyen (és persze használj passzív módot különben nem fog menni):
http://screenshots.portforward.com/routers/ZTE/F668/ALG.htm

Ha ekkor megy (egyébként pedig nem), akkor szoftver hiba van az ONT-ben az FTP ALG-ban.

( hajbazer v | 2020. 06. 11., cs – 09:46 )

Javaslom, hasonlítsd össze a két fájlt, hogy hol (milyen offseten) kezd el nem stimmelni az adat és ott mi az, amiben különbözik, milyen extra dolgok kerülnek be. Total Commander File -> Compare by Content funkcióval szépen lehet ilyeneket nyomozni.

( procika v | 2020. 06. 11., cs – 10:40 )

Én FTP, SFTP, SSH is töltök több terrát is le. Videó állományokat, munka miatt. Semmi gond nincs. Viszont befele nem jön az FTP mióta optika van. Se aktív, se passzív, de mivel másként megoldva a probléma így nem zavar.

A 25-ös port blokkolása a spambotok miatt érthető, de arra a szolgáltatók adnak alternatívát és az ő SMTP szerverükhöz lehet ezen a porton kapcsolódni. Emellett persze, még ugyanúgy pofátlanság azokkal szemben, akik szeretnének alternatív SMTP szervert használni.

Tehát azt állítod, hogy a legtöbb botnet FTP szervereket fertőz meg, remote exploitot kihasználva a 21-es porton.

A kérdés az, hogy a botmesterek mely operációs rendszer felhasználóit célozták meg ezekkel, ugyanis sem egy Windows-on (XP, Vista, 7, 8, 10) sem egy desktop Linuxon nincs alapból nyitva ez a port, ami annak köszönhető, hogy nem kerül fel opt-in FTP szerver. Szóval több, mint egymilliárd potenciális Windows zombigép helyett maradt 10-15 millió potenciális zombigép FTP szerver. Furcsa logikája van ezeknek a botmestereknek.

Maga a feltelepült botnet szoftver implementálta az FTP protokollt, mert az FTP nem egy komplex protokoll viszont eléggé hatékony a fájlok átvitelére és általában nem gyanús, hogy az FTP porton FTP protokollon fájlok közlekednek.

Furcsa logikája van ezeknek a botmestereknek.

Nincs furcsa logikájuk, egyszerűen neked kevés a tudásod és abból próbálsz extrapolálni, amennyit megértesz, ezért gyakran nagyon rosszul extrapolálsz.

https://iotguru.cloud

Tehát, ha a zombigépek kifelé kapcsolódnak a 443-as porton a botnetre, akkor arra az a megoldás, hogy a 443-as porton a kifelé irányuló kapcsolatokat letiltjuk, hogy azt is megszivassuk vele, aki értelmes célra akarná használni.

Vagy esetleg arra gondoltál, hogy a zombigépek kifele ne tudjanak kapcsolódni a 21-es porton, ezért tiltjuk le befelé a 21-es portot? Aminek szintén semmi értelme.

egyszerűen neked kevés a tudásod és abból próbálsz extrapolálni, amennyit megértesz, ezért gyakran nagyon rosszul extrapolálsz

Szerintem több zombigépet láttam, néztem át, elemeztem hálózati forgalom szempontjából és tisztítottam le, mint amennyiről te életedben félreeső, féligazságokkal teli cikkeket olvasgattál a tech-lakájmédia hasábjain. Egyébként, nem extrapoláltam, hanem kérdéseket tettem fel neked, amire közhelyes skatulyaválaszokkal és elitista szúrkálódással reagáltál, konkrétumok említése helyett. Pedig lehet, hogy tanulhattam volna valami újat.

Ha láttál már volna életedben botnetet, vagy legalább utána olvastál volna, akkor tudnád, hogy a legtöbb IRC-t használ és a fájlátvitel nem elsődleges célja és feladata egy botnetnek.

Ettől függetlenül, továbbra is szívesen tanulok újat és várom a normális választ a kérdéseimre. Például megemlíthetnél egy (már felszámolt) botnetet, aminek az elsődleges célja nagyobb fájlok ellopkodása volt és/vagy a botokat is a zombigépekre befelé irányuló FTP kapcsolaton keresztül irányították. Mert egyedül ez indokolná a szolgáltatói oldalon a befelé irányuló FTP kapcsolatok tiltását.

Tehát, ha a zombigépek kifelé kapcsolódnak a 443-as porton a botnetre, akkor arra az a megoldás, hogy a 443-as porton a kifelé irányuló kapcsolatokat letiltjuk, hogy azt is megszivassuk vele, aki értelmes célra akarná használni.

Így van, ezért van például a 80-as és 443-as port is tiltva egy csomó szolgáltatónál az ügyfelek irányába, mert az ügyfelek elsöprő többsége nem üzemeltet otthon webszervert, ha igen, akkor tud róla, tud kérni portnyitást.

Szerintem több zombigépet láttam, néztem át, elemeztem hálózati forgalom szempontjából és tisztítottam le, mint amennyiről te életedben félreeső, féligazságokkal teli cikkeket olvasgattál a tech-lakájmédia hasábjain.

Azt, persze, igen.

Például megemlíthetnél egy (már felszámolt) botnetet, aminek az elsődleges célja nagyobb fájlok ellopkodása volt és/vagy a botokat is a zombigépekre befelé irányuló FTP kapcsolaton keresztül irányították.

Hol írtam olyat, hogy elsődleges célja a nagy fájlok lopkodása volt vagy hogy azon keresztül irányították? Te érted amúgy a magyar nyelvet? Ha már annyit linkelgeted az érvelési hibákkal kapcsolatos weboldalt, akkor olvasd el kérlek a szalmabáb érvelést, köszönöm.

Mert egyedül ez indokolná a szolgáltatói oldalon a befelé irányuló FTP kapcsolatok tiltását.

Igazad van, mi más is lenne a szolgáltatók célja, mint hajbazer idegesítése.

https://iotguru.cloud

Így van, ezért van például a 80-as és 443-as port is tiltva egy csomó szolgáltatónál az ügyfelek irányába, mert az ügyfelek elsöprő többsége nem üzemeltet otthon webszervert

Aminek továbbra sincs semmi értelme, ha a botnetet megvalósító malware kifelé kapcsolódik. Márpedig miért ne kifelé kapcsolódna, egy dinamikus IP tartományból. Szóval, igazából sikerült kibaszni az otthoni cloudot üzemeltetni akaró tudatos felhasználóval, de a kifelé irányuló kapcsolatokat nem szűrtük, amin a botnetek csatlakoznak a botmester IRC szerveréhez.

Hol írtam olyat, hogy elsődleges célja a nagy fájlok lopkodása volt vagy hogy azon keresztül irányították?

Arról pampogtál, hogy a botnetek FTP szervert nyitnak a zombigépen és az mennyire hatékony a fájlok átvitelére. Miközben a fájlátvitel utolsók között van egy botnet céljai és értelme között. Továbbá, azt is állítottad, hogy a botnetek FTP-n keresztül szaporodnak.

Szóval, igazából sikerült kibaszni az otthoni cloudot üzemeltetni akaró tudatos felhasználóval, de a kifelé irányuló kapcsolatokat nem szűrtük, amin a botnetek csatlakoznak a botmester IRC szerveréhez.

Szerintem fordítva ülsz a lovon, ha cloudot akarsz üzemeltetni tudatos felhasználóként akkor egyeztess a szolgáltatóval, mint üzleti felhasználónak a segged is kinyalják jó pénzért. Ha a botnetek a 80-as vagy 443-as porton kapcsolódnak kifelé és ezt jól megszűrik akkor most a HUP-ot sem olvassuk és nem válaszolgatunk egymásnak.

Az, hogy a saját fájljaimhoz szeretnék távolról hozzáférni, nem üzleti igény, mivel ezzel nem termelek magamnak pénzt. Ez ugyanolyan magáncélú igény, minthogy otthonról szeretnék internetezni. Szóval, nem én ülök fordítva a lovon, hanem azok, akik etikusnak tartják a szolgáltató részéről az üzleti előfizetés erőltetését azok részére, akiknek problémájuk van a portletiltással. Ami egyébként a netsemlegesség alapelvét is sérti.

Az meg az önrendelkezés elvét sérti, hogy le akarod korlátozni, hogy ki milyen adatát adja át harmadik félnek a Facebook interfészein át, de azzal meg nincs bajod. Mi ez a kettős mérce?

Amúgy meg ha valamelyen oknál fogva a szokásuktól eltérően nem nyitják ki, ha kéred, akkor kiteszed másik portra és tudod, hogy hol van az FTP szervered, használod örömmel.

https://iotguru.cloud

Kettős mérce továbbra is nálad van, amikor egyetértesz a portok tiltogatásával, miközben a Facebook-ról harmadik fél számára történő adatszolgáltatás szigorításával nem és inkább az áldozatokat hibáztatod és balfaszozod.

Egyébként ezt még nem is mondanám kettős mércének, egyszerűen csak profitbuzi, korporatokrata hozzáállásod van. Minden olyan esetben, amikor egy multicég üzleti modellje, realizálható profitja vagy extraprofitja kerülne veszélybe, akkor a multik érdekében érvelsz. Most például a Digi és a Facebook profitérdekei mellett.

kiteszed másik portra és tudod, hogy hol van az FTP szervered

Ezzel a lehetőséggel eddig is tisztában voltam.

Egyébként ezt még nem is mondanám kettős mércének, egyszerűen csak profitbuzi, korporatokrata hozzáállásod van.

Szarok én a profitjára.

Tudod, az a furcsa, hogy egyik témában vered az asztalt, hogy hogy meri a szolgáltató korlátozni a hozzáférést, majd a felhasználó eldönti, hogy mekkora kockázatot vállal; a másik témában meg vered az asztalt, hogy miért nem korlátozza a szolgáltató a hozzáférést, mert a felhasználó nem tudja eldönteni, hogy mekkora kockázatot vállal. És ez nem egyedi eset, egyik témában vered az asztalt, hogy csökkenteni kell a fogyasztást, a másik témában meg vered az asztalt, hogy neked jogod van 200 wattos izzószállal világítani és mindenki hagyjon békén azzal, hogy pazarolsz, neked annak tetszik a fénye.

Te egyszerűen csak a saját életviteledet és világlátásodat akarod mindenki másra ráerőltetni, aztán meg agresszív leszel, ha erre nem vevők.

https://iotguru.cloud

Más szemében a szálkát, saját szemedben a gerendát tipikus esete, amit művelsz. Itt véded multiékat, hogy jogosan szűrik az FTP portot, miközben az apropóját nem sikerült szakmailag alátámasztanod. Másik oldalon meg véded multiékat, hogy nehogymá szigorítsák az őket érintő adatvédelmi törvényeket, miközben az adatvédelmi fiaskó áldozatait hibáztatod és balfaszozod.

aztán meg agresszív leszel, ha erre nem vevők.

Most sem én kezdtem a verbális agressziót. Te kezdted, az elitista leminősítéseddel.

" Ami egyébként a netsemlegesség alapelvét is sérti " Az általad igényelt "kifelé" irányú szűrés nem sértené?! És mit szólsz azokhoz a szolgáltatókhoz, akik CGNAt mögé rakják az ügyfeleket? És nem csak mobilneten, aminél még a forgalmi limites csomagok okán érthető is lehet, hogy "befelé", nem az üf. kezdeményezésére (de az ő kontójára) ne mehessen adatforgalom, hanem drótos neten is.
Érdekes, hogy a fehasználók döntő többségének nincs ezzel gond, és nem, nsm csak az általad konzumidiótának, meg tapicskolójánosnak meg hasonlóknak aposztrofált felhasználóknak, hanem azoknak sem, akik otthonról dolgoznak ilyen netszolgáltatáson. A "netsemlegesség" fogalmának meg illene utánanézni, ugyanis pont nem arról szól, amihez te idekeverted...

Én nem igényeltem kifelé szűrést, csak mondtam egy példát egy fiktív, elbaszott intézkedésre, amit ugyanolyan szélsőségesen idealista elvek mentén lehetne ennyi erővel eszközölni, mint ami alapján a 21-es port kitiltását eszközölték. Ezzel arra akartam rávilágítani, hogy szakmailag megalapozatlan a 21-es port tiltása és valószínűleg több benne a profitéhség (az azt igénylők üzleti előfizetés felé terelése), mint az internetbiztonság iránti elkötelezettség.

" Én nem igényeltem kifelé szűrést, csak mondtam egy példát egy fiktív, elbaszott intézkedésre " - pedig ezt az igényt lehet kivenni a hőbörgésedből.

A CGNAT-ról nem látom, hogy írtál volna, pedig arra nagyon-nagyon kíváncsi lennék, hogy mi erről a véleményed.

Ja, és a "netsemlegesség" fogalmának ugye utánanéztél?

CGNAT esetén nincs saját külső IP címed. Ebben az esetben technikailag nincs miről beszélni a portszűrést illetően, mivel a géped NAT mögött van és nem elérhető kívülről. Ugyanakkor a Digi hatályos ÁSZF-ben vállalja, hogy külső IP címet biztosít bizonyos lakossági csomagokhoz.

A munkaállomáshoz 1 db (dinamikusan változó) publikus IP címet biztosítunk.

Innentől kezdve szimplán etikátlan, hogy a befelé irányuló forgalmat a saját idealizmusaiknak megfelelően korlátozzák, csak azért, hogy a reklamáló lakossági ügyfeleket a túlárazott üzleti csomagok felé tereljék.

Nomostan CGNAT nem csak a DIGI-nél van, hanem -meg fogsz lepődni - az összes mobilneten lógó eszközt, valamennyi szolgáltató beqrta CGNAT mögé - mert tényleg nincs elég IPv4 cím az összes egyidejűleg neten lógó eszköznek. És igen, a Digi-nél sincs annyi, amennyi midnenkinek elég lenne. Ez a dolgok egyik része.
A másik, hogy a felhasználók 99.sok%-a lesz@rja, hogy a világ túlfeléről péhápépistike tudja-e pingetni az ő egyszem routerét vagy épp asztali pécéjét, netán notebook-ját (azaz van-e publikus ipv4-es címe, vagy sem) - viszont elvárja, hogy 7x24-ben tudjon ipv4-en kommunikálni. Nomostan ez utóbbinak feltétele az, hogy CGNAT mögött legyen a felhasználók többsége, mert mindenkineknem jutna ipv4-es publikusan route-olt cím.
Ha valakinek kell, publikus ipv4 cím, akkor felhívja az ügyfélszolgálatot, kéri, és jó esetben mire leteszi a telefont, és odamenyg a gépéhez, már újrarúhták a túloldalon a PPPoE-t, és hopp, ott az eszköze szolgáltató oldali lábán a publikus ipv4-es cím.  Ezt mondjuk egy T-nél, monilneten próbáld meg elérni...

" csak azért, hogy a reklamáló lakossági ügyfeleket a túlárazott üzleti csomagok felé tereljék " - False. Nem terelnek semerre - ha kéred, megkapod. Ingyen és bérmentve a publikus, dinamikusan kiosztott IPv4-es címet.
Statikus IPv4-es címre, illetve kifelé 25-ös tcp-portra valóbannem fogsz lakossági üf.-ként pozitív választ kapni - de megit csak azt tudom mondani, hogy a felhasználók 9x.sok%-ának nincs rá szüksége - akkor meg minek tornázzanak PPPoE-s userhez rendelt fix IP-címekkel? A a 25/tcp kifele tiltása meg megint a saját, és az ügyfelek védelmében van - nagyon nem jó, ha komplett szolgáltatói tartományok mennek spamdb-be...
Ja, a dinamikus címkiosztással egyébként pont, hogy több macera van naplózás tekintetében (hiszen egy hatósági megkeresésénél tudni kell, hogy adott időpontban melyik üf.-nek az eszközére volt kiosztva az x.y.z.w IP-cím)...

Nomostan CGNAT nem csak a DIGI-nél van, hanem -meg fogsz lepődni - az összes mobilneten lógó eszközt, valamennyi szolgáltató beqrta CGNAT mögé

Nem lepődtem meg és azt sem állítottam, hogy csak a Diginél van CGNAT.

A másik, hogy a felhasználók 99.sok%-a lesz@rja, hogy a világ túlfeléről péhápépistike tudja-e pingetni az ő egyszem routerét vagy épp asztali pécéjét

Tudom, hogy jól esik úton-útfélen megalázni a 0,1%-ot, aki tudatosan szeretné használni az Internetelőfizetését, vagy éppen jobban ki szeretné használni azt. Nem igazán értem, hogy mire föl, ugyanis a felhasználói igényeket illetően se volt vita köztünk.

Statikus IPv4-es címre, illetve kifelé 25-ös tcp-portra valóbannem fogsz lakossági üf.-ként pozitív választ kapni - de megit csak azt tudom mondani, hogy a felhasználók 9x.sok%-ának nincs rá szüksége

De igen, szüksége van rá, ha nem bloated cloudos webmailt használ levélküldésre. Csakhogy, a szolgáltató biztosít a saját IP tartományában SMTP-t, amire viszont ki lehet menni a 25-ös porton. Bár lehet, azt is azért biztosítja, mert nincs™ rá szükség™.

False. Nem terelnek semerre - ha kéred, megkapod. Ingyen és bérmentve a publikus, dinamikusan kiosztott IPv4-es címet.

Kivéve, amikor nem. Kivéve, amikor véletlenül™ lekerül a kivétel és akkor derül ki, amikor fontos lenne elérni az otthoni gépet.

A a 25/tcp kifele tiltása meg megint a saját, és az ügyfelek védelmében van - nagyon nem jó, ha komplett szolgáltatói tartományok mennek spamdb-be...

Minden szolgáltatói tartomány, amiben dinamikusan kiosztott IP-k vannak, alapból a spamdb-ben van.

Ja, a dinamikus címkiosztással egyébként pont, hogy több macera van naplózás tekintetében

Mintha a CGNAT-on belül nem lenne dinamikus a címkiosztás...

Nem igazán értem, egyáltalán mi volt a célja ennek a kommentednek, amiben olyan nyilvánvaló dolgokat írtál le, amit amúgy nem vitattam korábban.

" Tudom, hogy jól esik úton-útfélen megalázni a 0,1%-ot, aki tudatosan szeretné használni az Internetelőfizetését, vagy éppen jobban ki szeretné használni azt. " Ennél jóval kisebb az, akinek gondja van vele - ne feledd, hogy az összes mobileszköz CGNAT mögött csücsül, és bizony abból többvan(!) mint otthoni előfizetésből.

" De igen, szüksége van rá, ha nem bloated cloudos webmailt használ levélküldésre. Csakhogy, a szolgáltató biztosít a saját IP tartományában SMTP-t, amire viszont ki lehet menni a 25-ös porton. "

Az a bloated webmail tud egy rakat olyan dolgot, amit a nembloated desktop vackok, ha megfeszülnek, sem fognak tudni. (Pl. az összes levelet elérni bárhonnan, szinkronban tartott címtár a desktop és a mobileszközökközött, satöbbi...). Ja, és nem kell hozzá plusz egy alkalmazást fellapátolni a gépemre... AMi csak a bloat faktort növelné... :-P
Pont azt írtam, hogy a szolgáltató hálózatából kifelé nincs szükség 25/tcp forgalmat engedni minden ügyfélnek, elég, ha a szolgáltatói szervert eléri (pedig ez is plusz meló/feladat/erőforrás a szolgáltatónak, mert le kell rakni megfelelő teljesítményű vasat, üzemeltetni kell, menteni kell, frissíteni kell, foltozni kell az esetleges lukakat, estébé...

Az volt a kérdés lényege, hogy mennyire tartod "etikusnak/jónak" a CGNAT-ot, ha már a "befelé 21/tcp drop"-on így kiakadtál...?

Ja, és nem kell hozzá plusz egy alkalmazást fellapátolni a gépemre... AMi csak a bloat faktort növelné... :-P

Igen, biztos növelné a bloat faktort, hogy tizedannyi memória és CPU használattal futtatsz egy natív szoftvert a JS-bloat szutyok helyett. Ja nem.

Pont azt írtam, hogy a szolgáltató hálózatából kifelé nincs szükség 25/tcp forgalmat engedni minden ügyfélnek, elég, ha a szolgáltatói szervert eléri

Rendben. Akkor ebben egyetértünk.

Az volt a kérdés lényege, hogy mennyire tartod "etikusnak/jónak" a CGNAT-ot, ha már a "befelé 21/tcp drop"-on így kiakadtál...?

Ha szerződésbe foglalják, hogy nem kapok publikus IP címet, akkor elfogadhatónak tartom. Ha viszont a szerződésbe azt foglalják, hogy kapok publikus IP címet (ahogy a Digi tette), akkor szeretnék publikus IP címet kapni és szeretném a publikus IP címemet teljeskörűen kihasználni, nem agyonra korlátozva. A Digi mindkét esetben sunyul, spúrkodik, trükközik. Egyrészt, simán bevág CGNAT mögé a beleegyezésed nélkül, és ha nem veszed észre, és nem szólsz nekik, ott is maradsz. Nem tudom, hogy ennél egy fokkal jobb vagy rosszabb, amikor IPv6-only kapcsolatra erőltetnek át, ezt mindenki döntse el maga. Másrészt, publikus IP-vel is korlátozgat, ráadásul olyan protokollt, aminek az előfizetők többségére gyakorolt veszélyességét sem a Digi, sem Frankó Mérnök Úr nem tudják szakmailag alátámasztani (ellentétben mondjuk egy 139-es port befele szűrésével, ami a Windows-ok többségén default nyitva van és ezért potenciálisan sebezhető). Mindezekután nem nehéz azt feltételezni, hogy a korlátozás valódi oka a SCOPE kolléga által megfogalmazottak szerinti árukapcsolás, vagyis megpróbálják a tudatosabb, minden személyes adatuk multiknak való kiszolgáltatása helyett otthoni cloudban gondolkodó felhasználói réteget szélsőségesen túlárazott, üzleti előfizetésekre áterőltetni.

" Igen, biztos növelné a bloat faktort, hogy tizedannyi memória és CPU használattal futtatsz egy natív szoftvert a JS-bloat szutyok helyett. Ja nem. " És mondd, ki a lottyadt lótöcsöt érdekel, hogy a CPU 95%-ban, vagy 35%-ban van "IDLE" álalpotban, illetve hogy memóriában dettó ennyi különbséggel lötyögnek az alkalmazások? Jó, az XT-fanoknak, meg a hatszáznegyvenká elég lesz midnenre hippiknek igen, de az elmúlt úgy 10 éveben értelmes vas nem jött ki 1-2GB RAM meg olyan CPU nélkül, amin egy webmail-t használó böngésző ne futna el vidáman.
Van egy Acer Aspire One netbook-om - valami 533MHz-es egy magos Atom CPU, meg tán 1GiB RAM. És basszus teljesen használható a G-mail - természetesen böngészőből. Nomostan aki 2020-ban ennél fostalicskább hardvert használ, az azért kellően perverz és zakkant, no meg ritka jószág, úgyhogy inkább ne az ilyenek igénye legyen a zsinórmérték.
Ja, volt olyan munkám, amikor SSL-es IMAP-on kellett a levelezésemet kvázi bárhonnan elérni erről a gépről. A nembloat natív MUA-k (próbáltam párat) _akkor_ sokkal sz@rabban muzsikáltak, mint most a szerinted bloat szutyok js-es webmail megoldások.

" A Digi mindkét esetben sunyul, spúrkodik, trükközik. " - Basszus, fogd már fel a félbites agyaddal, hogy _nincs_ annyi kiosztható IPv4 cím a birtokában gyakorlatilag egyetlen valamire való internet-szolgáltatónak sem, amennyi ügyfelük egyidejűleg akar a neten lógni! Ez nem spúrkodás, hanem állapot. Lassan írom: nincs elég IPv4 cím - és nem is lesz. Elfogyott.

" bevág CGNAT mögé a beleegyezésed nélkül, és ha nem veszed észre, és nem szólsz nekik, ott is maradsz " És ez miért is baj _neked_? Ha "nem veszed észre", az azt is jelenti, hogy nincs problémád belőle. Ha viszont problémát jelent, akkor közel NULLA ráfordítással (igen, fel kell hívni az ügyfélszolgálatot...) belekerülsz a nem CGNAT-os pool-ba. Ez az ára annak, hogy egyáltalán tudnak IPv4 címet adni.

" IPv6-only kapcsolatra erőltetnek át " - a Digi-nél ilyen nincs, ellenberger van dual stack,azaz IPv4+IPv6 már baromi régóta. A vége egyébként az lesz, hogy IPv6 a preferált, és v4 lesz az opcionális.

" ellentétben mondjuk egy 139-es port befele szűrésével " - Próbáltad...? :-P A tcp/21 tiltása befelé témában többször, érthetően le lett írva, hogy mivel támasztható alá szakmailag - csakl ugyebár az a szelektív olvasás, az ne lenne...

" otthoni cloudban gondolkodó felhasználói réteg " - mert ők azok,akik ftp-szervert akarnak üzemeltetni... #facepalm

" szélsőségesen túlárazott, üzleti előfizetések " - Egyrészt nem szélsőségesen drága az üzleti előfizetés náluk (volt szerencsém több szolgáltatót megversenyeztető potenciális ügyfélnél beérkező ajánaltokat látni), másrészt meg senkit sem terelnek ebbe az irányba: Egyszerűen a lakossági előfizetéseknél ezek olyan marginális igények (miközben biztonság szempontjából fontos korlátozásokról van szó), amikre nem érdemes "lőni".

Engem például érdekel az erőforráshasználat, mert nem szeretem, amikor a Google babzsákfejlesztőinek kényelmeskedésére megy el feleslegesen sokszor annyi CPU és memória, mint amennyit egy normálisan megírt, natív szoftver igényelne. Mindezt úgy, hogy a Google egyáltalán nem szorul rá, hogy a szoftverfejlesztés költségeit elspúrkodja, hiszen a világ egyik vezető tech-óriása. Egy startup cégnél még meg lehetne érteni, hogy az 1.0-ás webmailjük bloated frameworkben összetákolt JS-szutyok. Ez nem XT-fan hozzáállás és nem is azt mondtam, hogy 640KB-on kéne futnia a Gmail webes felületének. A jelenlegi 2 magos Turion 64-em 4 GB RAM-mal megfelel a 2020™ évszámbuzi kritériumaidnak. Mégis használhatatlanul lassú rajta a Gmail, főleg mióta megújították. Nem csak egy Outlook Express 6, illetve egy Microsoft Outlook 2003, hanem egy friss, 2020-as™ The Bat! 9.1.18 is szarráveri sebességben, még úgy is, hogy utóbbiba is kerülnek be azért lassulgatós elemek.

fogd már fel a félbites agyaddal, hogy _nincs_ annyi kiosztható IPv4 cím

Felfogtam, nem most, hanem már korábban is, hogy nincs elég IPv4 cím. A Digi gyakorlatát vitattam és nem azért tettem szemrehányást, hogy nincs elég IPv4 címük. Az, hogy ez sokadszorra se jött át, nem az én agyam félbitességéről tesz tanúbizonyságot.

Ha viszont problémát jelent, akkor közel NULLA ráfordítással (igen, fel kell hívni az ügyfélszolgálatot...) belekerülsz a nem CGNAT-os pool-ba.

Mégis beleírják a szerződésbe, hogy biztosítanak publikus címet, tehát alapból szerződésszegésből indulunk és nekem kell szarakodni, meg órákat várni az ügyfélszolgálaton a kapcsolásra, ha azt a szolgáltatást szeretném igénybe venni, amire szerződést kötöttem és nem annak egy kiherélt változatát.

A tcp/21 tiltása befelé témában többször, érthetően le lett írva, hogy mivel támasztható alá szakmailag

Le lett írva egy elmélet, konkrét példák, konkrét kártevők megnevezése és bármiféle bizonyítás nélkül, ami így szakmailag nem állja meg a helyét. Vagy ha igen, akkor ennyi erővel a 443-at is korlátozni kell kifele, mert létezik legalább egy olyan kártevő a világon, ami ezt használja. A tiltás akkor lenne szakmailag megalapozott, ha látnánk azt, hogy a Digi hálózatán a gépek többségén nyitva van a 21-es port és lehetőséget ad arra, hogy azt valami befertőzze, tehát sebezhető. Hasonlóképpen, mint a 139-es portnál.

" Engem például érdekel az erőforráshasználat, " -engem is, de mint írtam, egy 533MHz-es ketyegő, egy magos Atom procin és 1GB RAM-on _jobban_ működik az általad erősen lenézett wedmail, mint a kényszerből kipróbált 3-4 natív kliens. És ez a legvacakabb PC-kategóriájú eszköz, amihez az elmúlt mondjuk 10-15 évben szerencsém volt, a többin nagyjából annyi a különbség, hogy a CPU mennyit tölt IDLE-ban, illetve a RAM-ból mennyi a szabad. (Jellemzően mindkettő sok, illetve több).

" Mindezt úgy, hogy a Google egyáltalán nem szorul rá, hogy a szoftverfejlesztés költségeit elspúrkodja, hiszen a világ egyik vezető tech-óriása. " Arra nem gondoltál, hogy talán azért van azon a helyen, ahol, mert jobban tudja, mit lehet "elspúrkodni", és mit nem? Hogy például egy egyszámjegyű %-nyi CPU-spórolásra nem szabad sok fejlesztői erőforrást szánni, mert van egy szint, amikortól az optimalizálás _jóval_ költségesebb, mint amennyi valós bevételt hoz? Te vennélolyan szoftevrverziót, ami a "base" kivitelnek a duplájába kerül, de cserébe a CPU-ból mondjuk 2-5%, RAM-ból meg 10%-kal kevesebbel is beéri? És nem, nem légből kaptt a dupla ár ekkora erőforrásigény különbségnél - nem egy optuimalizálásra kihegyezett refaktoringhoz volt szerencsém - nagyon izzadós tud lenni ilyen mértékű erőforrásigény-javulás elérése is.

" A jelenlegi 2 magos Turion 64-em 4 GB RAM-mal " - Az atomerőmű az általam írt Atom procis netbookhoz képest, és bizony ez utóbbin veri szarrá a böngészőben futó G-Mail a thunderbird/bat/franctudja mi még imap-os vackokat. Igen, ez utóbbiakat sok éve nem frissítettem, mert nem használtam, és igen, vannak benne lokálisan lerakott levelek is szép számmal.

" beleírják a szerződésbe, hogy biztosítanak publikus címet " - Ezt hol látod? Mert én csak a régi ajkai (ÁSZF "c" melléklet 8.10) látok ilyet.

" nekem kell szarakodni, meg órákat várni az ügyfélszolgálaton a kapcsolásra, " - Szerintem a te hívószámod valami blacklist-en lehet, mert nekem amikor kellett, nem tartott tovább 5-10 percnél az egész üfsz.-os telefonálósdi. :-)

" Le lett írva egy elmélet, konkrét példák, konkrét kártevők megnevezése és bármiféle bizonyítás nélkül " - ha _neked_ tossza a csőrödet, akkor hajr, írj egy dörgedelmes levelet a szolgáltatónak, a jó ég tudja, hogy hívják most az érintett felügyeleti szerveknek, meg az atyaistennek, hogy ez így rossz, átverés, satöbbi. Ja, és a CGNAT okán gyakorlatilag okafogyott a "befelé portszűrés" is - már ami az IPv4-et illeti.

engem is, de mint írtam, egy 533MHz-es ketyegő, egy magos Atom procin és 1GB RAM-on _jobban_ működik az általad erősen lenézett wedmail

Akkor neked bizony az a nagy szerencséd van, hogy ugyanabban az alternatív univerzumban élsz, mint Saxus Mérnök Úr, akinek Pentium 4-en gond nélkül, a megfelelő drivereket mind automatikusan feltelepítve, gyorsabban fut a legfrissebb Windows 10, mint a hozzávaló Windows XP.

Hogy például egy egyszámjegyű %-nyi CPU-spórolásra nem szabad sok fejlesztői erőforrást szánni, mert van egy szint, amikortól az optimalizálás _jóval_ költségesebb, mint amennyi valós bevételt hoz?

Egyfelől, nem egyszámjegyű CPU spórolásról beszéltünk, hanem arról, hogy a JS-szutykok szeretnek több, mint 100 MB memóriát és minimum egy magot 100%-on felzabálni, a legegyszerűbb feladatokra is. Másfelől, a Google fejlesztési irányelvei ott csapnak át racionális üzleti megfontolásból etikátlan szervezeti arroganciába, amikor a megspórolt fejlesztői erőforrást a felhasználók fizetik meg. A Gmail-nek másfélmilliárd felhasználója van. A nagy átlag napi 10 percet tölt e-mail olvasgatással. Az irodában dolgozóknál a munkaügyben olvasott és írt e-mailek miatt ez az időtartam sokkal több, de induljunk ki az átlagemberekből, mert ők vannak többen. Ha a JS-bloat (tehát a babzsákfejlesztők kényelmeskedése a nem™ éri™ meg™ optimalizálni™ égisze alatt) miatt másfélmilliárd asztali gép, notebook, okostelefon fogyaszt akár 1W-tal többet 10 percen keresztül, az 1×10÷60×1500000000 ≅ 250 MWh többletenergia naponta. Ez az áram átlagos világpiaci árával (14 cent) számolva kb. 35000 dollár. A havi energiatöbblet 7,45 GWh, vagyis 1 050 000 dollár. Tehát, a Google spúrkodása és babzsákfejlesztőinek kényelmeskedése több, mint egymillió dollár költséget okoz a világgazdaságnak, miközben ennek az összegnek a töredékéből rá tudnának állítani egy tucat fejlesztőt arra, hogy optimalizáljanak megfelelően, ami a Google dollármilliárdjaihoz képest is csak kerekítési hiba lenne. Az által, hogy a Google termékeit százmilliók használják, közvetett felelőssége is van, bárhogy is próbálod eltagadni. Ha a JS-bloat több CPU-t zabál, akkor jóval több energia lesz világszinten elpöfögtetve és ez által a környezetszennyezés is nagyobb lesz. Sajnos ezen az se segít, hogy a Google telerakja napelemmel az adatközpontjait. Lehet, hogy egyes cégeknek csak a marketingasztalon létezik a társadalmi feleősségvállalás koncepciója, de attól még számít és ha valaki a gyakorlatban szarik rá, az etikátlan üzleti magatartást folytat, akkor is, ha Zeller Mérnök Úr szeme kiszúrható egy velejéig arrogáns, korporatokrata nem™ éri™ meg™ üzleti idealizmussal.

Szerintem a te hívószámod valami blacklist-en lehet, mert nekem amikor kellett, nem tartott tovább 5-10 percnél az egész üfsz.-os telefonálósdi. :-)

Nincsen blacklisten a számom, de érdekes, hogy most nem sajnálod a 10 percet a telefonos ügyfélszolgálattól, máskor meg foggal-körömmel ragaszkodsz az okostelefonok nyújtotta tapicskoló kényelemhez, kőkorszakinak kiáltva azokat, akik butatelefont használnak és nem sajnálnak egy buszmenetrendet megérdeklődni telefonos ügyfélszolgálaton, ha épp elfelejtették előre megnézni.

" optimalizáljanak megfelelően " - definiáld, hogy mire optimalizáljanak? Memóriaméretre, CPU-időre, tárhelyre, felhasználói válaszidőre, I/O mennyiségre...? Vagy mire?

" Nincsen blacklisten a számom, de érdekes, hogy most nem sajnálod a 10 percet a telefonos ügyfélszolgálattól, máskor meg foggal-körömmel ragaszkodsz az okostelefonok nyújtotta tapicskoló kényelemhez " - célhoz az eszközt. Amikor hibabejelentés/ügyféligény céljára a telefon a megfelelő, akkor azt használom, ha meg információt szeretnék kapni, akkor számítógépen, online információforrásokat. Igen, az okostelefon is ez.

> definiáld, hogy mire optimalizáljanak?

Sorrendben a felsoroltakra. Ne is haragudj, de az tenyleg katasztrofa, hogy a Google Chrome onmagaban megeszik 1-2 GB memoriat ugy, hogy kb semmi nincs benne megnyitva. Egy GitHub, egy GMail es egy JIRA megnyitasaval ez felugrik 3-5 GB-ra is, es 100%-on tekeri a procit ugy, hogy nincs erdemi user interakcio a weboldalon. Ha ez szerinted normalis, akkor valahogy nagyon mas fogalmaink vannak a normalisrol.

Es ez a szutyok Chrome van most mar mindenhol, az Opera, a Firefox, az IE Edge mind-mind Chromium engine-t hasznal. Eddig legalabb voltak alternativak...

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Most megnyitottam egy HUP-ot, egy redmine-t, meg egy iNotes levelezőt Chrome-ban. Ez úgy 250-260MB  nálam. Fura, fölöttébb fura. De ha dupla vagy tripla lenne, az sem lenne a világvége. A 100%-on tekeri a procit meg felzabálja a világ memóriáját is nekem olyankor jött egyébként elő, amikor csillomezer csingiléingi meg add-on volt bepakolva. Most van egy AdblockPlus, aztán gyakorlatilag ennyi.

Memóriaméretre, CPU-időre, tárhelyre, felhasználói válaszidőre

Tudom, most jön az, hogy ha processzorra optimalizálunk, akkor az több memória, ha memóriára, az több processzor. Ez az egyetemi előadásokon jól hangzik, meg a powerpointokon is jól néz ki, de a Chrome és a Gmail vonatkozásában már rég nem erről van szó. Hanem arról, hogy minden egyes funkciót 2x-3x-10x annyi erőforrást felzabálva valósít meg egy JS-szutyok Gmail, vagy akármilyen trendbuzi frameworkben szarul-húgyul összetákolt webököri idealizmus. Szóval, régesrég invalid az az érvelés, hogy azért enne több memóriát, hogy kevesebb CPU-t egyen. Mert mind memóriából, mind CPU-ból a többszörösét zabálja, mint egy natív szoftverben megvalósított azonos funkcionalitás.

Amikor hibabejelentés/ügyféligény céljára a telefon a megfelelő, akkor azt használom, ha meg információt szeretnék kapni, akkor számítógépen, online információforrásokat.

Értem, tehát a te saját kényelmes seggednek fenntartod a jogot a kényelmeskedésre, de ha én mondjuk nem szeretnék egy alapszolgáltatásért telefonos ügyfélszolgálaton sorbanállni, akkor az már le van söpörve az asztalról annyival, hogy "nyugi, csak 5-10 perc telefonálósdi".

" Hanem arról, hogy minden egyes funkciót 2x-3x-10x annyi erőforrást felzabálva valósít meg egy JS-szutyok Gmail, vagy akármilyen trendbuzi frameworkben szarul-húgyul összetákolt webököri idealizmus. " - ha ennyire tudod, írd meg jobban, küldj javítást - örülni fognak neki, hogy tizedannyi erőforrást használva megoldod a világ problémáit.

Definiáld légyszives a "natív szoftver" fogalmát... Ja, hogy pure C, vagy netán asm? Jó. tessék pure C-ben gui-s funkcionalitást megírni úgy, hogy lehet alatta n+1 különböző tudású/funkciót tartalmazó megjelenítési réteg. Natívan, C-ben tessék megoldani, hogy fusson WindowsXP 64 bit mellett Windows7, Windows 10 környezetben, mindenféle grafikus adapteren, felbontáson, miegyében... Ja, és persze működjön tetszőleges további platformokon, webről letöltve, hiszen a webmail-es részről indultunk ki, aminek ugye nem csak Windows* klienseket, hanem csillió+1 GUI-s böngészőt, meg mobilos klienst kell tudni _jól_ kiszolgálni.

 

Nem hiszem, hogy attól, hogy észreveszem a bloatot, az én dolgom lenne újraírni a világ összes szoftverét optimálisan.

Egyszerűen csak azt mondom, hogy jól látszik, milyen konzumerista mélyrepülésen megy át a szakma, ha még a Google-dollármilliárdokból sem futja hatékony szoftverre. Értsd: ha az egyetlen cég, aki megengedhetné magának, hogy a végtelenségig kioptimalizáljon bármit, se teszi. Persze, SHA1-törésre, CPU-belassítást okozó Spectre-Meltdown-kutatgatásra arra mindig futja nagyságrendekkel több emberi és hardveres erőforrásból.

csillió+1 GUI-s böngészőt, meg mobilos klienst kell tudni _jól_ kiszolgálni.

Ez a fajta "írjuk meg egyszer, működjön mindenen" idealizmus soha a büdös életben nem működött. Valakivel mindig ki volt baszva és nem kicsit. Legújabban a desktop felhasználókkal van, a felhasználói felületek tapicskoló okostelefonbuzi lebutítása miatt. A Gmail webes felülete pedig a legrosszabb példa, ugyanis azt még multiék se vállalják be, hogy a csiligány, JS-bloat szutykukat mobilon futtatgassák, inkább áterőltetik birkáékat Gmail App-ra.

Aminek továbbra sincs semmi értelme, ha a botnetet megvalósító malware kifelé kapcsolódik. Márpedig miért ne kifelé kapcsolódna, egy dinamikus IP tartományból.

Mert ugye ezek elosztott P2P hálózaton beszélnek egymással, amelyiknek van központja, az a botnet sebezhető.

Szóval, igazából sikerült kibaszni az otthoni cloudot üzemeltetni akaró tudatos felhasználóval, de a kifelé irányuló kapcsolatokat nem szűrtük, amin a botnetek csatlakoznak a botmester IRC szerveréhez.

Aki otthon akar szervert üzemeltetni, megteheti, vagy másik porton vagy vegyen üzleti internet előfizetést.

Arról pampogtál, hogy a botnetek FTP szervert nyitnak a zombigépen és az mennyire hatékony a fájlok átvitelére. Miközben a fájlátvitel utolsók között van egy botnet céljai és értelme között. Továbbá, azt is állítottad, hogy a botnetek FTP-n keresztül szaporodnak.

A botnetek fájlokból állnak. Ezeket a fájlokat rendszeresen el kell juttatni a fertőzött gépekhez. A fertőzött gépek továbbadják egymás között, hogy ne egy központ legyen terhelve, különben DDoS indítanának saját maguk ellen, annyira meg nem hülyék. Ennek a protokollja gyakran FTP volt, mert a tűzfal szoftverek erre nem riasztottak, mert az FTP pont arra szolgált, hogy fájlok legyenek átküldve rajta, ebben az esetben épp az egyik fertőzött gépről a másikra.

Ez amúgy már a múlté, manapság a Pastebin és a GitHub az, amin keresztül kommunikálnak, mert azt nem ellenőrzik, hogy ki és mit tölt fel, illetve nem annyira egyszerű túlterhelni és földrajzilag is elosztott rendszer.

https://iotguru.cloud

Mert ugye ezek elosztott P2P hálózaton beszélnek egymással, amelyiknek van központja, az a botnet sebezhető.

P2P hálózatot feltételezve teljesen értelmetlen az FTP port letiltása. Ha ott nem tudnak kapcsolódni, kapcsolódnak majd másik porton. P2P kommunikáció általában DHT-alapon, random portokon zajlik. Ez önmagában biztos, hogy nem indokolja a tudatos felhasználók szivatását, akik FTP-n szeretnének hozzáférni az otthoni szerverükhöz.

Ennek a protokollja gyakran FTP volt, mert a tűzfal szoftverek erre nem riasztottak

Meglepő. Alapértelmezésben egy Windows XP beépített tűzfala is riaszt egy FTP szerverre a 21-es porton, sőt még egy FTP kliensre is, ha nem passzív módot használ.

mert az FTP pont arra szolgált, hogy fájlok legyenek átküldve rajta, ebben az esetben épp az egyik fertőzött gépről a másikra.

Tudom mire lett kitalálva az FTP, viszont ebben a kontextusban maximum arra szolgálhatna, hogy a protokollszűrést végző szolgáltatóktól próbálja meg elrejteni a forgalmat. Itt viszont nem erről volt szó, hanem a 21-es port blokkolásáról.

Ez amúgy már a múlté, manapság a Pastebin és a GitHub az, amin keresztül kommunikálnak, mert azt nem ellenőrzik, hogy ki és mit tölt fel

Tehát továbbra is értelmetlen lezárni a 21-es portot befelé, biztonsági okokra hivatkozva.

Az egyetlen érthető és szakmailag is megalapozott oka az FTP port letiltásának az lenne, ami oka volt a 139-es port letiltásának. Hogy a gépek 90%-án fut egy sebezhető (már meglévő) szolgáltatás, ami tömeges fertőződésekhez és zombihálózat egyszerű kiépüléséhez vezethet. Ez a veszély viszont nem áll fenn a 21-es port esetén, és soha nem is állt fenn. Sem a Windows, sem a Mac, sem a desktop Linux nem tartja nyitva ezt a portot és nem üzemeltet FTP szervert.

Az egyetlen érthető és szakmailag is megalapozott oka az FTP port letiltásának az lenne, ami oka volt a 139-es port letiltásának. Hogy a gépek 90%-án fut egy sebezhető (már meglévő) szolgáltatás, ami tömeges fertőződésekhez és zombihálózat egyszerű kiépüléséhez vezethet. Ez a veszély viszont nem áll fenn a 21-es port esetén, és soha nem is állt fenn. Sem a Windows, sem a Mac, sem a desktop Linux nem tartja nyitva ezt a portot és nem üzemeltet FTP szervert.

Ebből azért le tudnád vezetni, hogy nincs igazad, ha ennek ellenére tiltják és kérésre nagy általánosságban kinyitják a portot.

https://iotguru.cloud

Maximum akkor, ha minden esetben és nem csak "nagy általánosságban" nyitnák ki a portot. Esetleg, ha bridge módban semmiféle portszűrés nem lenne amellett, hogy a NAT-olt kapcsolat az alapértelmezett. Ettől függetelnül továbbra is szakmailag megalapozatlan az 21-es port tiltása. A 139 tiltását nem tartom annak, de ott is lehetővé kell tenni, hogy kérésre kinyissák.

Tudod, az a baj ezzel a "nagy általánossgában kinyitják" dologgal, hogy nem számonkérhető. Tehát, senki nem garantálja, hogy egyszercsak nem veszik el "véletlenül" a kivétel, amit felvettek és nem kell mondjuk havonta újrakérni. Ez pedig már egy ütőkártya multiék kezében, amivel noszogathatják az ügyfeleket a magáncélú igényekhez képest túlárazott üzleti előfizetés felé úgy, hogy előbb-utóbb az őrületbe hajszolják az FTP-szervert üzemeltető felhasználót, akitől minden hónapban elnézést kérnek, hogy lekerült a kivétel, és hozzáteszik, hogy üzleti előfizetés esetén nem fordult volna elő.

Kicsit sokat latsz bele par artalmatlan szoba . A "nagy altalanossagban kinyitjak" itt arra utal, hogy az altalam ismert esetek (es ezzel gondolom _Franko_ is igy van) mindegyikeben kinyitottak, azonban kis szamu esetbol nem lehet nagy mintara altalanossagokat megfogalmazni. En konkretan meg nem talalkoztam olyannal, hogy ha egy szolgaltatot felhivok, hogy a XY portot kerem kinyitni mert csak, azt megtagadtak volna, de elkepzelhetonek tartom, hogy pl a notorius keson fizetoket, problemas ugyfeleket maskeppen kezelik. En is igy fogalmaztam volna, hogy "nagy altalanossagban kinyitjak". 

Es nem igaz az, hogy nem szamonkerheto. Ma mar minden ugyfelszolgalat bemondja, hogy a hivast rogztiik, a rogzitett hanganyagot igy es igy ered el. Ez alapjan igenis szamonkerheto, hiszen - reszben - ezert is rogzitik, de ezen felul minden ilyen igenyt fel kell vezessenek az adott elofizetes szolgaltato odlali profiljaba is, mert ez nem ugy mukodik, mint KisPistike Bt-nel, hogy a telefonos ugyintezo rogton szol Ver Istvan halozati mernoknek, hogy legyszi-legyszi, hanem hibajegyeken, stb-ken keresztul, amik ismet szamonkerhetoek. Tehat, ha ez a kivetel valaha elveszne (?? mitol veszne el? Bottal utnem azt a halozati mernokot, aki olyan rendszert tervez, ahol ilyesmi csak ugy elveszhet), akkor ezek alapjan visszakovetheto, es szamonkerheto a szolgaltato, es a port kinyitas ujra megigenyelheto. De a sajat praxisomban nem is talalkoztam meg olyannal, hogy egy elozoleg kinyitott port "elveszett" volna.

Ami az uzleti elofizetesek fele terelheti az embereket az kizarolagosan a fix IPv4 cim intezmenye. Ez annak fenyeben ertheto, hogy mennyire keves IPv4 cim van a szolgaltatoknal, es hogy meg mindig nem jott el az IPv6 eve (szerintem a Linux Desktop evevel fog egyutt jonni). 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

" Aminek továbbra sincs semmi értelme, ha a botnetet megvalósító malware kifelé kapcsolódik. " - és keresi a "párját", akivel szerver nélkül is tudna csacsogni, mondjuk a zombigépre befelé csattanva 80 vagy épp 443-as porton.

" kifelé irányuló kapcsolatokat nem szűrtük " - No ezt mégegyszer... Tehát azzal bajod van, hogy _befelé_ irányban, ahol 9x% fölött _nincs_ websterver szűrik/tiltják a 80 meg a 443 portok elérését, de azt viszont hiányolod, hogy a szolgáltató kifelé nem bontja ki az ssl-t, és néz bele a forgalomba, hogy az mehet vagy sem... Merthogy egy rosszinduulatú "vezér szerver" mellett n+1 fake, de "tiszta" tartalom is ott szokott figyelni a tapasztalatok szerint - ha már http(s)-en dolgozik a "vezér".

" a fájlátvitel utolsók között van egy botnet céljai és értelme között " - Kivéve, ha a zombi önmagában csak zombi, és a payload, a tényleges támadó tartalom utólag kerül rá...

Kivéve, ha a zombi önmagában csak zombi, és a payload, a tényleges támadó tartalom utólag kerül rá...

Így van, a botnetek nagy részét bérbe lehet venni, különféle célokra használni, akár csak bányászatra, akár spam küldésre, akár célzott támadásokra. Ezeket elosztott hálózaton szórják szét, P2P segítve a terjedést, amikor csak lehet. Kreatívak.

https://iotguru.cloud

Igen, az oka általában nem frissített szoftver, viszont a csatorna, amin keresztül letöltik azt, amit majd művelnek a fertőzött gépeken, az régebben FTP protokollon ment, mert az szabad volt, könnyű volt implementálni és nem vinnyogott miatta a tűzfal sem.

https://iotguru.cloud

Digi jogsértései:
(az én jogi értelmezésem szerint)

#vol1:
Nincs benne az ASZF-ben tételesen.
(Hiteles tájékoztatás joga sérül +megágyaz az árukapcsolásnak)

#vol2:
Amikor fel akarod oldatni, először terelnek az üzleti előfizetés felé, illetve nem is oldanak fel mindent.
(Árukapcsolás #1 + Netsemlegesség: mindet fel kellene oldania)

#vol3:
Amikor az üzleti neten vagy, akkor meg kiderül, hogy mindez fix IP alatt értendő.
(Árukapcsolás #2)
 

Na ezt hívják DIGI módra "netsemlegesség"-nek...
Ettől függetlenül a hálózat stabilitását dicséret illeti.

Én értem, hogy ~3000Ft-ból kb lehetetlen üzemeltetni az infrastruktúrát, részemről nem is okozna gondot, ha kicsivel többet (pl: 4500Ft) kellene fizetni ugyanezért, de ettől, a romániában egyébként elterjedt "pofámba hazudás" stílustól én viszketést kapok.

Diginél legalább díjmentesen és gyorsan igényelhetsz publikus IP címet. Engem nem tereltek sehova mikor mondtam, hogy kamerák + VPN miatt van rá szükség, Telekomról ez nem igazán mondható el. Az is csoda, amíg végre eljutok valakihez, aki érti miről beszélek. Ugyanúgy kérdezték itt sokan, hogy Telekom mobilnet esetén.. gyakorlatilag bármi.. és csodálkoznak, hogy első válasz, hogy menekülj!

Egyébként Diginél is vannak problémák, de a többi szolgáltatónál sokkal több van.

Jobb helyen ezt nem az admin/root/Rendszergazda droid találja ki. Egyébként meg lehet T-re, Flip-re (uganaz, csak más színben...) vagy másegyéb szolgáltatóra váltani - sokkal többért, gyakorlatilag ugyanazt fogod kapni. Vagy sz@rabbat, lásd például a Tré/Flip IPTV-only (és max. két szolgáltatói doboz per előfizetés, ha jól tévedek...).

Már nem emlékszem melyik, de a T-s, vagy Vodás usb stickes kapcsolódásnál például az IPSEC protokol van blokkolva.

( •̀ᴗ•́)╭∩╮

"speciel a blockchain igenis hogy jó megoldás, ezért nagy erőkkel keressük hozzá a problémát"

"A picsat, az internet a porno es a macskas kepek tarolorandszere! : HJ"

( E-Medve v | 2020. 06. 11., cs – 13:22 )

Szerkesztve: 2020. 06. 11., cs – 13:23

Kipróbáltam én is, Digi optikával letöltöttem az ftp.fsn.hu-ról két Debian DVD iso-t. Az egyiket wget-tel, a másikat 83-as chrome-mal (figyelve az ftp://-ra). A wget-nél szépen látszik, ahogy lefut a PWD, CWD, RETR trió, az is látszik, hogy passzív módban töltötte. Az sha256-ok egyeznek mindkét esetben.

Nálam a Digi doboz bridge módban van. Akinél nem (vagy hibásan) működik, ott bridge vagy router módban van a Digi eszköz?

3 véletlenszerű helyről próbálkoztam wget használatával, továbbra is Debian iso-k a tesztalanyok és továbbra sem sikerült reprodukálni a problémát.

Ezeket próbáltam: ftp.sunet.se, ftp.uni-stuttgart.de, ftp.crifo.org (francia)

Valamelyikről próbálj meg letölteni egy Debian DVD iso-t, nálad egyezik az sha256?

( mbael | 2020. 06. 11., cs – 13:42 )

Total Commander, FTP

Ez a topik visszarepitett 2006-ba

A Total Commander a mai napig az egyik leghatékonyabb fájlkezelő. 2006 óta gyakorlatilag megduplázódott a funkcionalitása, mégis ugyanolyan jól használható, extra bloat nélkül.

Az FTP egy protokoll.

A proftpd és a pureftpd a világ legnépszerűbb FTP szerverei közé tartoznak. A mai napig fejlesztik és karbantartják őket.

" megduplázódott a funkcionalitás " - és nem bloat? Fájlkezelőnek az mkdir/rmdir/cp/mv parancsokat kell tudnia -minden ezen túlmutató dolog fölösleges csicsa, túlgondolás, funkcionális extra bloat :-P

Attól, hogy ftp kiszolgáló szoftvereket mind a mai napig javítgatnak, az csak annyit jelent, hogy mind a mai napig van velük mókolni való, nem azt, hogy az idők végezetéig kéne használni azokat. Attól, hogy van friss, ropogós (akár Windows 10-re is elkészített) Gopher kliens, még nem biztos, hogy a Gopher-t mint egykoron népszerű szolgáltatást annyira nagyon kéne használni manapság :-D

és nem bloat?

És nem bloat, mert Christian Ghisler meg tudta írni normálisan, bloated framework és fejlesztői kényelmskedés nélkül. Egy alkalmazás az általa elhasznált/elpocsékolt erőforrás alapján bloat vagy nem bloat, nem a funkciógazdagsága alapján.

Attól, hogy ftp kiszolgáló szoftvereket mind a mai napig javítgatnak, az csak annyit jelent, hogy mind a mai napig van velük mókolni való, nem azt, hogy az idők végezetéig kéne használni azokat.

Valójában egyiket se jelenti.

https://a.te.ervelesi.hibad.hu/hamis-okozat

Én pont arra szerettem volna felhívni a figyelmet, hogy nem évszámbuzi idealizmusok mentén dől el, hogy az FTP-nek van-e létjogosultsága vagy sem.

Arra pedig, hogy megpróbálod az említett FTP szervereket alávalónak beállítani, mivel mókolni kell velük, csak annyit tudok válaszolni, hogy a HTTP szervereket is legalább ennyit (de inkább többet) kell mókolni. Egy stabil nginx verzióra jóval több biztonsági frissítés jön adott időintervallumon belül, mint egy FTP szerverre. Ennek viszont semmi köze nincs ahhoz, hogy van-e létjogosultságuk, illetve kéne-e használnunk vagy sem. Szóval ebben akár egyet is érthetünk.

" Egy alkalmazás az általa elhasznált/elpocsékolt erőforrás alapján bloat vagy nem bloat, nem a funkciógazdagsága alapján " A fölösleges funkciók bizony pazarolják a tárhelyet, meg néhanapján a CPU-t és a RAM-ot is. És nem, marhára nem lényeges, hogy az adott feladat végrehajtása közben a CPU/RAM 28%-a van kihasználva, vagy 82%-a - ugyanis az erőforrás ott van, elérhető, nem akkor kell pluszban előállítani, amikor a szeritned bloat alkalmazást akarja valaki futtatni. De ilyen alapon mindenre lehet mondani,hogy bloat,aminél van kisebb erőforrásigényű környezet - és az általad istenített Windows-verzió is baromira bloat, merthogy komplett gui meg IP-stack és böngésző, fájlkezelő miegyéb összerakható egy darab 1.44MB-os (3.5"-os) flopira is, és bizony elfutkorászik a 32 ites x86-os procik legócskábbikán is - ha kab 4MB RAM-ot, akkor egyenesen száguld.

Szóval mi a bloat...? És mit jelent az, hogy mind a mai napik reszelik az ftp-kiszolgálószoftvereket, ha nem az, hogy van velük mókolnivaló? Egy qmail-t nem reszel senki,vagy épp egy tis fwtk-t dettó nem, miközben arra, amire készültek anno, tökéletesen megfelelnek mind a mai napig.
Semi bajom azzal, hogy fingot reszelnek az 1024 éve jól ismert, kipróbált és stabil protokollt beszélő szerverszoftverekkel, de megismétlem: attól, hogy valami 1024+ éves, és van, aki matat még a kódban,  attól még nem szentírás, hogy örökkévalóságig kell és szabad a sw-rel/protokollal tervezni. Ha ezen a vonalon picit extrapolálunk, akkor mi a búbánatnak az IP? Jó volt az X25. csomagkapcsolt világ, kermit, s02342235satöbbi...

 

Zeller, azert, mert neked a fajlkezeles kimerul a cp/rm/ls/mkdir/touch -ban, ez meg nem biztos, hogy mindenkire igaz, Ennyi erovel a MC-nek sincs semmi letjogosultsaga,hiszen az SFTP/SMB link elerest tudja az smbclient meg az sftp parancs. Ja, hogy way kenyelmetlenebbul? Hat, igy jart.

Ertem, hogy fontos a resource footprint, es egyet is ertek a minimalizmusra torekvo irannyal, de azert az onszopatas talan nem kellene, hogy cel legyen, vagy legalabbis nem kellene mindenkit rakenyszeriteni. Meglepo modon, adminok millioi hasznaljak a TC/MC funkcionalitasanak jo reszet, es mindenki mast. Raadasul ez az alkalmazas 2020-ban sem eszik meg partiz MB-nal memoriat, ellentetben nehany minimalista, nem bloated cuccal, lasd meg: Messenger, Slack, stb. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Hasznaltam egy jo ideig en is, hasznos tool volt.

Azota megvaltoztak a szokasaim, mert tobbnyire nem matatok ilyen mennyisegu fileok kozott, hogy szuksegem legyen ra. Mondjuk nem is hianyolom oszinten. Ha meg igen, arra ott a forklift macen, ami kvazi a total commander mai megfeleloje.

Mielőtt elindítanád itt a TC és FTP ellenes FUD köröket, azt elárulod, miben más TC-ből mentett FTP jelszavakat lopni, mint Chrome-ból HTTP-s szolgáltatások (Facebook, Gmail stb.) jelszavait és/vagy bejelentkezett sessionjeit (cookie-kat)? Mármint azonkívül, hogy az egyiknél egy INI-t olvasol ki, a másiknál meg egy SQLite-ot.

Elég sokban más, de neked, mint exra nagy tudású programozónak (is) illene tudni. Lécci mutass arra példát, amikor nagy tételben, jelentős számú usernek lopták el a böngészőben tárolt jelszavait. A session hijacking-ra tudok példát én is - el...ott (azóta javított) böngésző és/vagy webes alkalmazás kell(ett) hozzá.

Elég sokban más a Total Commander saját wcx_ftp.ini scrambler algoritmusának implementálása helyett a Chrome profilkönyvtárában lévő Login Data SQLite adatbázisból egy SELECT * FROM logins eredményének titkosított mezőire ráhívni egy CryptUnprotectData()-t, a Chrome-ot futtató user nevében. Tényleg, hatalmas programozói tudás és tapasztalat kell egy SQLite selecthez, meg egy DPAPI függvényhíváshoz, míg a nembiztonságos™ Total Commander jelszavakat még Tapicskoló Tamás is játszva feltöri. Ja nem.

11 éve védhetőek a Total Commander tárolt FTP bejelentkezési adatai mesterjelszóval és AES256 titkosítással. Míg a Google Chrome 2020-ban sem képes mesterjelszó szerint titkosítani az érzékeny adatokat, inkább idealista módon használ DPAPI-t, nehogy ne lophassa el egy limitált userként futó malware az összes érzékeny adatot, nehogy lehessen értelmes módon áthordozni egy profilkönyvtárat egyik Windows installációról a másikra (egyiken CryptProtectData()-zott Login Data másikon már nem unprotectelhető). Szarnak egy pofon, aztán még egy. Erre futotta a Google-dollármilliárdokból. Tehát, egy Total Commander továbbra is biztonságosabban használható, mint egy Google Chrome.

Az adott user nevében futó folyamat valóban képes a DPAPI-n keresztül az AES256 titkosított jelszavakhoz hozzáférni, és azokat kibontani. Azaz a TC-hez hasonlóan a _tárolás_ AES256-tal titkosítva történik. Nem egyedi mesterjelszóval, hanem a Windows-os DPAPI-n keresztül.

Az adott user nevében futó folyamat valóban ki tudja bontani, de ez volt a megcélzott működés: így a kecske és a káposzta is le van rendezve: a tárolás titkosítással történik felhasználói beavatkozás nélkül, és nem lehet elfelejteni a titkosításhoz szükséges credential-t (ha be tud jelentkezni az OS-be,az elég ugye...) Pont ebből adódik, hogy fájlmásolással nem működik a jelszavak átvitele userek/gépek között - viszont van export/import, ami megetszi neked ezt a szívességet.

A titkosított tárolás Chrome-ban default, TC-ben opcionális, ha jól tudom, és anno pont azért volt ordenáré szívás a TC-s tárolt jelszavakból, mert egy jól irányzott malware, ami admin joggalé futott, minden user tc-s jelszótárjához hozzáfért.

Az ftp-jelszavakat meg totál fölösleges egyébként titkosítva tárolni - elég a malware-nek a tcp-streamhez hozzáférni, abból simán ki tudja szedni, gyakorlatilag nulla erőfeszítéssel... :-P

A titkosított tárolás Chrome-ban default, TC-ben opcionális, ha jól tudom, és anno pont azért volt ordenáré szívás a TC-s tárolt jelszavakból, mert egy jól irányzott malware, ami admin joggalé futott, minden user tc-s jelszótárjához hozzáfért.

Szívás azért volt belőle, mert amikor még erre specializálódtak a malware-ek (több, mint egy évtizede), akkor a Total Commander még nem tudta titkosítottan tárolni a jelszavakat és az akkori svájci exporttörvények miatt Ghisler nem is implementálhatott titkosítást a TC-be. Chrome ekkor még nem is létezett.

Még mielőtt megpróbálnál összemosni különböző támadási vektorokat, emlékeztetnélek, hogy malware-ek (trójaik, egyéb kémszoftverek) által lenyúlt jelszavakról volt szó. Onnantól kezdve, hogy futó malware-ről beszélünk, teljesen mindegy, hogy egy Copy() vagy helyben lefuttatott CryptUnprotectData() lopja ki a jelszavakat. Mindkettő ugyanúgy lefuttatható egy lépésben limitált userként és sikeres lesz.

Az ftp-jelszavakat meg totál fölösleges egyébként titkosítva tárolni - elég a malware-nek a tcp-streamhez hozzáférni, abból simán ki tudja szedni, gyakorlatilag nulla erőfeszítéssel... :-P

Kivéve, ha AUTH TLS be van kapcsolva. Ha pedig a TCP streamhez való (admin jog nélküli) hozzáférés nulla erőfeszítéssel implementálható, akkor a CryptUnprotectData() meghívása -1 erőfeszítéssel. Mire a le nem tárolt (vagy mesterjelszóval védett) TC jelszót ellopja a malware, addigra már rég ellopta a Chrome-ban tárolt jelszavakat, amit amúgy esélyed nincs normálisan levédeni, még akkor sem, ha kitalálhatatlan jelszóval véded a Windows-profilod. Te pedig ezt próbálod biztonságosabbnak™ beállítani a TC által felkínált FTP-jelszavak védelmét illető lehetőségeknél. Lehet, hogy lassan ideje lenne elismerned, hogy Christian Ghisler egyszemélyben képes volt tanulni korábbi hibájából és jobban védhetővé tenni az FTP jelszavakat, mint egy dollármilliárdos multi?

" Ha pedig a TCP streamhez való (admin jog nélküli) hozzáférés nulla erőfeszítéssel implementálható " - ahhoz nem is kell az adott ezsközön futnia a kódnak, elég valahol út közben... Ha már az ftp-ről beszélünk...

A TC-ben opció a tárolt jelszavak titkosítása, azaz ha pistike nem kattintja be, akkor az adminjózsika (vagy más, megfelelő jogosultsággal rendelkező processz elolvashatja.

A "ha az user akarja, titkosítva kerül a fájlba" szerintem gyengébb védelem, mint az, hogy csak akkor olvasható, ha az adott user vagy, egyébként meg titkosított a fájl.

ahhoz nem is kell az adott ezsközön futnia a kódnak, elég valahol út közben... Ha már az ftp-ről beszélünk...

Igen, tehát hálózati infrastruktúrát megfelelően védeni ismét luxus, meg hát ezek a csúnya gonosz hekkerek is úgy működnek, hogy könnyebben törnek fel szolgáltatói gerinchálózatokat, mint Tapicskoló Tamás Windows-zát. Továbbra is azt tudom mondani, hogy AUTH TLS, ha paranoid vagy, illetve tessék szépen levédeni a WiFi hálózatot, vagy vezetékes internetet használni.

A TC-ben opció a tárolt jelszavak titkosítása, azaz ha pistike nem kattintja be, akkor az adminjózsika (vagy más, megfelelő jogosultsággal rendelkező processz elolvashatja.

Ami egy desktop gépen egyenértékű azzal, hogy maximum adminjózsika olvashatja el a felhasználón kívül, és általában nem adminjózsika van, hanem adminpistike, mert ugyanaz a felhasználó az adminja a gépnek, aki limitált felhasználóként is használja. Mellesleg, adminjózsika simán berak benyom regedittel vagy GP-be egy Run vagy RunOnce scriptet a usernek, ami kiolvashatja a jelszavait. Sőt ugyanezt megteszi egy malware is. Bár amúgy minek kellene neki, ha tud pistikeként is futni és akkor egy lépésben megvannak a tárolt Chrome jelszavak úgy, hogy se adminjózsika, se pistike nem tud ez ellen semmit tenni, mivel a Google-dollármilliárdokból nem futotta mesterjelszavas védelemre.

A "ha az user akarja, titkosítva kerül a fájlba" szerintem gyengébb védelem, mint az, hogy csak akkor olvasható, ha az adott user vagy, egyébként meg titkosított a fájl.

Szerinted. Szerintem pedig a gyakorlatban, malware szempontból egyenértékű. Összességében pedig silányabb biztonság az, hogy nem lehet mesterjelszóval védeni az érzékeny adatokat Chrome-ban, így bármilyen process hozzáférhet, ami az adott felhasználó jogosultságaival fut.

" Igen, tehát hálózati infrastruktúrát megfelelően védeni ismét luxus, " plain text protokoll esetén, amiben a jelszó is így utazik, mi a búbánatot tudsz védeni "megfelelően"? Az auth tls egy ronda gányolás az ftp-hez, amit _lehet_ de nem _kötelező_ használni, ergo az ftp protokoll támadhatósága megmaradt.

" malware szempontból egyenértékű " -tehát egyik sem rosszabb, _ha_ fut az OS a gépen. Oké. Ha viszont nem fut, akkor melyik a jobb? Az, ami csak lehetővé teszi a titkosított tárolást, vagy az, ami alapból titkosítva tárol?

plain text protokoll esetén, amiben a jelszó is így utazik, mi a búbánatot tudsz védeni "megfelelően"?

Mondjuk a kommunikációs csatornát, amin utazik.

Az auth tls egy ronda gányolás az ftp-hez, amit _lehet_ de nem _kötelező_ használni, ergo az ftp protokoll támadhatósága megmaradt.

Az AUTH TLS nem egy ronda gányolás, hanem a protokoll egy kiterjesztése, amivel az érzékeny adatok megvédhetők könnyen lehallgatható adatcsatornán. Szükség csak akkor van rá, amikor a kommunikációs csatorna védelme nem megfelelően biztosított. Tehát pl. megfelelően switchelt belső hálózat esetén semmi szükség nincsen rá. Támadhatósága nem egy protokollnak van, hanem egy gyakorlati alkalmazásnak. Például egy FTP szervernek. Ha nem biztosított a kommunikációs csatorna, illetve a hálózati infrastruktúra védelme, akkor tessék úgy configolni az FTP szervert, hogy elvárja az AUTH TLS-t, vagy akár a teljes SSL-titkosítást. Az, hogy nem a körülményeknek vagy a biztonsági előírásoknak megfelelően configolják be az FTP szervert, nem a protokoll hibája.

Oké. Ha viszont nem fut, akkor melyik a jobb?

Attól függ, milyen más támadási vektorokat szeretnénk kivédeni, ha feltesszük, hogy nincs malware, aminek esélye lenne futni adott gépen. Innentől viszont már elég marginális esetek vannak csak, a véletlen vagy szándékos idiótaságok (teljes home könyvtár megosztása SMB-n) és a fizikai hozzáférés (wcx_ftp.ini pendrive-ra másolása). Amik jóval ritkábban fordulnak elő, mint a malware támadások és kockázatra nem összemérhetőek velük.

A munkaállomásokról történő tömeges adatlopások nem fájlmásolgatáson keresztül történnek, hanem malware-ek által. Erre való tekintettel az esetek túlnyomó részében a Total Commander védelme nem kevésbé biztonságos, mint a Chrome védelme. Ugyanakkor, a Total Commander lehetőséget nyújt olyan védelemre, ami a Chrome védelménél is erősebb. Valóban vannak olyan támadási vektorok, ahol a Google Chrome CryptProtectData() megoldása alapértelmezésben biztonságosabb, de ezek marginális esetek és ritka szituációk. Az esetek túlnyomó részében a Total Commander védelme összességében biztonságosabb, az elérhető lehetőségek alapján.

" Mondjuk a kommunikációs csatornát, amin utazik. " - magyarul kihajítod az ftp-t, és ssl-es valamire váltva kommunikálsz. naccerű, problem solved.
 

" A munkaállomásokról történő tömeges adatlopások nem fájlmásolgatáson keresztül történnek, hanem malware-ek által. Erre való tekintettel az esetek túlnyomó részében a Total Commander védelme nem kevésbé biztonságos, mint a Chrome védelme. " - Egy _opcionálisan bekapcsolható_ titkosítás tehát szerinted ugyanolyan biztonságos _tárolást_ nyújt, mint az, aminél nem lehet a titkosítást kikapcsolni. Ezt azért gondold át még egy picit...

 

magyarul kihajítod az ftp-t, és ssl-es valamire váltva kommunikálsz. naccerű, problem solved

Nem hajítom ki: https://en.wikipedia.org/wiki/FTPS

Egy _opcionálisan bekapcsolható_ titkosítás tehát szerinted ugyanolyan biztonságos _tárolást_ nyújt, mint az, aminél nem lehet a titkosítást kikapcsolni. Ezt azért gondold át még egy picit...

Átgondoltam. Egy kötelezően bekapcsolt, bármilyen azonos userspace-ben futó process által triviálisan visszafejthető titkosítás nem biztonságosabb, mint egy INI fájlba tárolt scrambled jelszó, ha malware általi támadási vektort nézzük, és azt nézzük, mivel messze gyakoribb, mint a szimpla fájlmásolgatásra épülő támadási vektorok.

Nincs mit javítani, mert nem volt hiba. Hiányzó feature volt.

Alapból nincsenek titkosítva a jelszavak most sem, csak egy scrambler algoritmussal emberi szemlélőnek olvashatatlanná teszik. A scrambler nyilvánvalóan reverzibilis. Zeller Mérnök Úr a 2000-es évek közepére gondolt, amikor még nem lehetett levédeni mesterjelszóval az FTP jelszavakat és megpróbálta elhitetni hupuékkal, hogy a probléma még mindig fennáll és így Total Commander nem™ biztonságos™. Total Commander 7.5 (2009) óta van lehetőség mesterjelszavas védelemre és ilyenkor AES256 titkosítás kerül rá.

Szóval tessék rá mesterjelszót rakni és akkor tekintheted úgy, hogy már javították.

" Alapból nincsenek titkosítva a jelszavak most sem " - tehát a felhasználó döntésétől függ, hogy van-e titkosítás, hogy lophatóak e tetszőleges olyan processzel a jelszavak,amik képesek olvasni a user tc-s jelszavait tároló állományt. (Kontra: Chrome esetén default AES256, és csak az adott user processzei tudják kibontani...)

Én támogatom a döntési lehetőséget. Utálom mikor helyettem próbál gondolkodni a szoftver és korlátoz. Például egy rendszer csak interaktívan akarta jelszót bekérni és mindenféle hülye trükkökkel korlátozott, hogy ne tudjam automatizálni, miközben csak egy bemutató teszt rendszerről volt szó. Ugyanígy idióta böngészők nem engedik felülbírálni ma már HSTS-t, miközben tudtam, hogy hibás az adott oldal és csak egy információra volt szükségem róla.

Ha ma már pedig ennyi hülye van, akit meg kell védeni önmagától, akkor legyen valamilyen iddqd / idspispopd hogy engem ne korlátozz semmiben..

Ja és ugyanígy Android is csessze meg VPN jelszó megjegyzési policy-jét, hogy kötelező hozzá képernyőzár. Volt olyan ember, aki nem volt hajlandó ezt beállítani, ezért portot kellett nyitni a rendszernek. VPN-en csak az a rendszer volt elérhető. Valóban ha ellopják a telefonját, akkor más is eléri, de így most mindenki eléri. Gratulálok Google!

Te támogatod a döntési lehetőséget, az átlagos felhasználó meg next-next-finish megoldást akar, úgy, hogy biztonság is legyen, de ne legyen szükség csillió+1 jelszóra meg "mindenféle marhaságra". A mentett jelszavak biztonságos, védett tárolását hogyan oldanád meg másképp, mint userhez kötött credential hazsnálatával? Nem, a "tessék bekapcsolni itt, meg jelszót megadni ott kétszer, meg mentő kérdést hármat legalább..." - Nos, a felhasználók vagy az 1. lépsét sem hajtanák végre, vagy ha az a kikapcsolás és ezzel megmenekülés a következő lépésektől,akko kikapcsolnák azonnal... És utána szdnák a guglit, hogy nemvédtemegajelszavaikatbrühühühühü... 

" egy rendszer csak interaktívan akarta jelszót bekérni " - Ez is egy feature a rendszerben: nem enged automatizált/mentett logint - vélhetőleg nem a te robotizált mókolásod a célközönség.

" legyen valamilyen iddqd / idspispopd " - sajnos ezt a lehetőséget pont azok a hülyék használnák leginkább, akiket a saját hülyeségük ellen is védeni kell.

" csessze meg VPN jelszó megjegyzési policy-jét, hogy kötelező hozzá képernyőzár. " - Tehát szerinted rossz, hogy az Android-ban a vpn-es jelszót megjegyezni csak úgy lehet, hogy a telefonhoz való hozzáférés mellett kell egy tudás (pin/minta) is? Szerintem meg teljesen korrekt - ne legyen már nyitott a vpn-hozzáférés a telefon birtokában... (

Ha így haladunk, akkor lassan el fogunk jutni oda, hogy idióták ülnek mindenütt, semmit sem lehet dönteni, aztán majd a Teslánk belerohan egy nyergesvontatóba, mert már fékezni sem enged vagy már pedál sincsen hozzá, amivel lehetne. Ugyanígy majd a biztonsági övet nem engedi a gép kikapcsolni és bent égsz az autóban. Vagy előz valaki, nem tud visszasorolni, jönnek szembe, erre sebességkorlátozó miatt frontális karambol. Remélem ezt a világot már nem élem meg..

Vagy TV kötelezően felhasználói nevet és jelszót kér, nehogy véletlenül kiskorú nézzen nem neki való filmet rajta. Fogadok ha így haladunk, akkor ez is eljön néhány éven belül.

És emiatt van, hogy hívhatsz autómentőt. Tudod hogy szegény a keverék, de az ECU-t nem tudod felülbírálni. Ugyanígy DPF "tisztításról" az autó dönt, mert ő jobban tudja mikor fogok autópályán hosszabban haladni. Persze ez nem gond hiszen emiatt ki van iktatva DPF a magyar használt prémiumok nagy részében. (Mielőtt írná valaki, nekem elvből csak benzines autóim vannak. Már apámnak is csak 1 autója diesel. Azonban ismerősök járják kelik a várost DPF nélkül. Ha megtérül és használható távolságok lesznek elektromos autók esetén, akkor pedig azt veszek.)

Most mondom neked, hogy valószínűleg mindenkinek (így neked is) van olyan ismerőse, akinek DPF ki van iktatva ugyanis autószerelő ismerőseim is azt mondják, hogy használt prémiumok jókora (ha nem nagyobb) része így jár. Keress rá neten, ha jól emlékszem cikk is volt belőle, sőt erre szakosodott műhelyek vannak!

(Persze most nem a márkaszervizbe hordott autókról beszélek, hanem a Németországból behozott leharcolt, független szervizbe vittekről.)

Ja és ezek csak egyre többen lesznek. Azonos diesel autó kb fele áron megy benzineshez képest használtan, így még kevesebbet fognak költeni rá, "mert hát az autó nem ér annyit!!". És ugye csak egyre megy le az áruk.. A DPF pedig egyszer biztosan meghal. Kb 150e km élettartamot mondtak rá régen, mennyi is van ezekben a dieselekben? Majd biztos megjavítja az autójával összemérhető értékben igaz és nem kiiktatja "olcsóért"? Én a hatóság helyében Budapesten megállítanék találomra 100 autót, fogadok, hogy abból a fele nem menne át a károsanyag-kibocsátás vizsgálaton.

A lehet, hogy van, az egy dolog. Te úgy írtál róla, hogy tudod, hogy van olyan ismerősöd. Én az ilyen szabályokra fittyet hányó lóf...jóskákkal nem dicsekednék - akinek majomra van pénze, banánra is legyen: amikor megvette az autót, tudta, hogy a részecskeszűrő van, és hogy annak az üzemeltetési kültségben jelenős része lesz vagy lehet.
Remélem, hogy a szabályozás abba az irányba fog mozdulni, hogy nagyon ne érje meg se a szerelőknek, se a tulajdonosoknak ilyet csinálni. (EGyszerű lenne egyébként: a szerelő, ha ideiglenesen (a működöképesség visszaállítása érdekében, a tulajdonos felelősségére, ahogy papíron most is) kiiktatja a részecskeszűrőt, köteles lenne az NKH felé ezt a tényt motorszám/alvázszám/rendszám adatokkal jelezni, _és_ az ilyen átalakítás automatikusan mondjuk 30 vagy 60 napra korlátozná a forgalmi érvényességét.
Az NKH azért kell a képbe, mert az így jelentett járműveket -a megadott határidő után- hatóságilag ki tudják vonni a forgalomból, annak minden következményével együtt.
Az érvénytelen forgalmival autózást meg simán lehet(ne) akár az önkormányzatok által kirakott, akár az EKÁER-es kamerákkal is figyelni - rendszámfelismerőre tolni az adatokat, aztán ha "olyat dob" a nyilvántartó, akkor az adott képet lehetne idő/hely adatokkal beküldeni zárt rendszerben, és máris izzenhetne a nyomtatóból a szab.sért. bírságról szóló határozat.

Chrome esetén is tetszőleges processzel lophatóak a jelszavak, amik a felhasználó nevében futnak és képesek hozzáférni a Login Data fájlhoz. A Chrome DPAPI-s titkosítása elbaszott látszatmegoldás.

Emellett, a Chrome felhasználóknak multiék meg sem adták a döntés jogát. Ők csak és kizárólag egy kevésbé biztonságos megoldást használhatnak, ami felhasználói folyamatként futó kártevő esetén egyenlő a Total Commander default jelszóbiztonsági szintjével és így a biztonság hamis illúzióját adja.

Chrome esetén is tetszőleges processzel lophatóak a jelszavak, amik a felhasználó nevében futnak és képesek hozzáférni a Login Data fájlhoz. A Chrome DPAPI-s titkosítása elbaszott látszatmegoldás.

Ennyire nem egyszerű, mert rákérdez a jelszavadra a Windows ilyenkor és megmondja, hogy milyen process, milyen okból és mihez akar hozzáférni, engedélyezed-e.

https://iotguru.cloud

Hát nem egészen.

Alapértelmezésben semmiféle prompt nincs, csak akkor, ha egy másik usert szeretnél megszemélyesíteni, vagy admin jogot kérsz.

Az, hogy a CryptProtectData() és a CryptUnprotectData() lehetőséget ad prompt feldobására promptstruct beállításával, nem azt jelenti, hogy ne tudná egy limitált felhasználóként futó folyamat (egy malware) mindenféle prompt feldobálása nélkül kiolvasni a Chrome jelszavakat. Azt jelenti, hogy te a saját alkalmazásodból kérhetsz promptot, a biztonság még nagyobb illúziójának megteremtésére.

Hogy hol biztonságosabb a Chrome vagy a TC, az már inkább use case kérdése.

A TC magasabb fokú biztonságra ad lehetőséget, mint a Google Chrome és ha van a gépen egy futó malware, az alapértelmezésben ugyanolyan könnyen megszerzi a scrambled TC jelszavakat, mint a CryptProtectData()-zott Chrome jelszavakat.

A TC haladó felhasználóknak való és nem egységsugarú tapicskolóknak, akikkel elhiteti a Google, hogy biztonságban™ vannak, miközben amúgy nincsenek, és ha egyszer lamerből tapasztalt felhasználóvá érnek, se lesz magasabb fokú biztonságra lehetőségük, mivel a Google túl milliárdos ahhoz, hogy mesterjelszavas védelem implementálására pazarolja a pénzét.

Továbbá, ismét megkérnélek, hogy ne mosd össze szélsőségesen idealista módon a támadási vektorokat. Malware által kibányászható érzékeny adatokról volt szó és nem fájlmásolgatásról. Vagy szerinted a rosszfiúk™ majd elkéregetik egyenként mindenkitől Facebook Messengeren a wcx_ftp.ini-t, vagy pendrive-on lemásolgatják?

" Malware által kibányászható érzékeny adatokról volt szó és nem fájlmásolgatásról. " - bizony. A plain text fájlt elég felküldeni a botnet megfelelő node-jára, onnantól lehet támadni az összes szolgáltatást az user feltételezhető felhazsnálói neveivel meg a kapott jelszavakkal.

" Google túl milliárdos ahhoz, hogy mesterjelszavas védelem implementálására pazarolja a pénzét. " - Felhasználói oldalról igazuk van: kikapcsolhatatlan a titkosított _tárolás_, az usernek nem kell plusz jelszóval foglalkoznia. Igen, ha az user nevében fut egy malware, akkor az ki tudja szedni a jelszavakat a fájlból, ez igaz. Mint ahogy keyloggerként is tud működni, ergo az, amit a bejelentkezés _után_ begépelsz, az ebből a szempontból dettó sérülékeny/ellopható, ergo a tc-s hűdeszuper masterkey is. És a tapasztalatok bizony arra mutatnak, hogy keylogger-jellegű támadások a gyakoribbak, minthogy a chrome titkosított jelszóadatait célzottan támadják.
Ha valami csak opcionálisan kínál titkosított jelszótárolást, az manapság nem elfogadható szint. (Igen a FF is ilyen, és igen, az R=1 userek miatt, akik azt az egy master jeszót is képesek elfelejteni...)
 

A plain text fájlt elég felküldeni a botnet megfelelő node-jára, onnantól lehet támadni az összes szolgáltatást az user feltételezhető felhazsnálói neveivel meg a kapott jelszavakkal.

Senki nem fogja önként és dalolva külön elküldözgetni a wcx_ftp.ini fájlját egy botnet megfelelő node-jára. Vagy úgy egyáltalán bárkinek. Előbb fog bekerülni ő maga a botnetbe és onnantól meg már nem számít, hogy triviálisan unprotectelhető Chrome jelszavak vagy wcx_ftp.ini-ben tárolt scrambled jelszavak. Fogalmazok másképp, hátha így megérted: Amíg 1000-ből 1 botnetbe nem került birka elküldi a wcx_ftp.ini-jét egy másik botnetbe került birkának, addig a másik 990 birkát már befertőzte a botnet, ami egyenértékű a Chrome jelszavak ellopásával.

kikapcsolhatatlan a titkosított _tárolás_, az usernek nem kell plusz jelszóval foglalkoznia.

Látom, hajlandó vagy a szavakat is kiforgatni multiék spúrkodásának igazolása érdekében. Nem, nem erről volt szó. Arról volt szó, hogy a Google-milliárdokból nem futja egy erősebb védelmi szintre, amit pl. egy mesterjelszó jelenthetne. Azzal, hogy a usert nem kérdezik meg a CryptProtectData() általi titkosításról, biztonsági szempontból semmi gond nincs. Azzal már van, hogy a CryptProtectData() helyhez (installációhoz) kötöttsége miatt nem lehet értelmesen migrálni a Chrome profilokat egyik gépről a másikra, 3rd-party cucc nélkül. Tehát vagy áthekkeled valamilyen programmal, vagy felküldöd a Google-nak a cloud-ba minden személyes adatoddal és jelszavaddal együtt. Ez konkrétan a felhasználói szabadság sárba tiprása és kifejezetten etikátlan a Google részéről.

Nem fogod fel, vagy nem akarod felfogni, hogy a tárolás kötelezően titkosított volta az az egyik target, a másik meg az, hogy ehhez az usertől lehetőleg minimális interakciót kelljen elvárni, _és_ az adatvesztés (elfelejtett master jelszó) kockázata minimalizálható legyen. Ezt a Chrome tudja. A TC, meg az opcionálisan titkosítható jelszótárolással, meg masterjelszóval működő motyók meg nem.

_Nem_ volt cél az, hogy opcionális titkosítás legyen, nem volt cél, hogy opcionálisan más master jelszóval lehessen a tárolt adatokat védeni (adatvesztés lehetősége ugye...). Az, hogy sima másolással nem költöztethető a Google Chrome  profilkönyvtára gépek között, az irreleváns: van működő export/import, tessék azt használni (tudom, most költöztettem két gép között a Chrome profilomat, adatostól, jelszavastól.) A jelszavas rész itt van: https://www.webnots.com/how-to-import-and-export-passwords-in-chrome/

 

Érdekes, hogy a máskor csúcsra járatott, szélsőségesen idealista, vadkapitalista, mindent pénzben mérő, kockázatelemző befektetőlogikádat ilyenkor jó messzire félreteszed, pedig most pont azt kéne látnod, hogy egy malware fertőzésre sokkal nagyobb esély van, mint arra, hogy Pistike lemásolja a wcx_ftp.ini-t Józsika gépéről és mindeközben Pistike gépe pont egy zombihálózat tagja.

Ha azt akarod hallani, hogy a Chrome alapértelmezett jelszókezelése összességében biztonságosabb, mint a Total Commanderé, akkor azt nem fogod, mert nem igaz.

Ha azt akarod hallani, hogy a Chrome jelszókezelésének legmagasabb elérhető biztonsági szintje magasabb, mint a Total Commanderé, azt sem fogod, mert nem igaz. A Total Commander nagyobb biztonságot nyújt, mesterjelszóval.

Ha azt akarod hallani, hogy létezik olyan támadási vektor, ami ellen a Chrome jelszókezelése jobban véd, mint a Total Commanderé alapértelmezésben, akkor azt fogod, mert az igaz, de csak szélsőséges, ritka esetekben. Malware támadás és zombihálózat esetén nem.

Ha ezeket képtelen vagy sokadjára is megérteni, akkor vagy a felfogásoddal van súlyos probélma, vagy annyira elsüllyedtél a "csak a multiknak lehet igazuk, csak ők lehetnek biztonságosak™, mert náluk van a pénz" mocsárban, hogy nekem esélyem nincs kirángatni téged.

Alapvetés, amit minden biztonsági témánál első körben elmondanak: jelszót titkosítatlanul NEM tárolunk. Pont. Innen következik, hogy az opcionális titkosítás nem elégséges megoldás. Sziontén alepvető fontosságú, hogy az adatvesztés lehetőségét is minimalzálni kell. Ha a mesterjelszó eléfelejtése a tárolt adatok elvesztését okozza, akkor az baj, az adott megoldás (mesterjelszó) elkerülendő.

 

az opcionális titkosítás nem elégséges megoldás

Idealizmus. Nem rossz, de nem állja meg a helyét, ha a titkosítás támadók által is triviálisan feloldható.

alepvető fontosságú, hogy az adatvesztés lehetőségét is minimalzálni kell

Igen, ezért tapossuk még inkább a porba a felhasználói szabadságot és az esélyét se adjuk meg annak, hogy valaki biztonságosabban használhassa a Chrome-ot az alapszintnél. Inkább kiegyezünk egy középszarban, amire rá lehet ragasztani a biztonságos™ címkét, mert nem plaintext, de malware-támadás esetén egyenértékű a plaintextben tárolással.

Nagyjából ez az a szélsőségesen idealista, korporatokrata narratíva, ami az IT-szakmát az elmúlt 10 évben tönkretette és elsilányította.

Apropó, az adatvesztés Windows-jelszó elfelejtése esetén is ugyanúgy érvényes, mert egy admin általi jelszóváltoztatással odalesznek a DPAPI kulcsok is. Tehát nem csak nevetséges, még érvénytelen is az érvelésed a felhasználói szabadság lábbal tiprása mellett.

" Igen, ezért tapossuk még inkább a porba a felhasználói szabadságot és az esélyét se adjuk meg annak, hogy valaki biztonságosabban használhassa a Chrome-ot az alapszintnél. " - Számoltak, és nem érte meg plusz kockázati tényezőt (user elfelejti a master jelszót, keylogger begyűjti a master jelszót és úgy visz el adatot) bevinni, plusz fejlesztési erőforrásokat rászánni.

" malware-támadás esetén egyenértékű a plaintextben tárolással " - megfelelően felkészített malware esetén. A sima plaintext tárolásnál meg a malware-nek elég direktben elolvasni a fájlt, ami azért jóval kisebb ráfordítással működik, ergo a plaintext-ben lerakott jelszót jóval egyszerűbb ellopni, akármennyire is úgy akarod beállítani, hogy egyforma a kettő.

A Windows-os jelszó felhasználó általi visszaállíthatósága megoldott (jelszóemlékeztető, azonosítási kérdések,stb.), a harmadik fél általi jelszóresetnek meg szerintem illendően dobnia kell az user mentett credential-jeit, hiszen ha nem így lenne, egy ilyen jelszóresettel egy harmadik fél hozzáférhetne az user jelszavaihoz. Egy hiszékeny r=1 user esetén simán megjátszható lenne, hogy "de igen, biztosan elfelejtetted a jelszavad, azért nem enged be, adunk másikat, és azzal menni fog..." Egyébként az is jó kérdés, hogy AD-s user esetén mi van a Chrome-os jelszavakkal - azt még nem néztem meg.

Számoltak, és nem érte meg plusz kockázati tényezőt

Nem olyan nehéz ám kimondani: Nem tartják fontosnak. Magasról leszarják. Mert papíron megvan a biztonság™, akkor meg miért törekedjenek nagyobb gyakorlati biztonságra, hiszen egy dollármilliárdos multi menedzsmentje akkor a legboldogabb, ha a költségvetés 0,000001%-át megpspórolják valamin, ami egyébként hasznos lenne a felhasználóknak, még ha nem is mindegyikük, vagy nem is több, mint 50% használná.

megfelelően felkészített malware esetén

Arra is megfelelően fel kell készíteni a malwaret, hogy pont a wcx_ftp.ini-t másolja le. Sőt még arra is, hogy a Total Commander reverzibilis scrambler logikáját implementálja és dekódolja, majd kigyűjtse a jelszavakat a malware-gazdának. Kódsor-mennyiségre és komplexitásra ráadásul a Chrome jelszólopás kevesebből megvan. Nem egy proprietary scramblert kell újraimplementálni, csak egy publikusan dokumentált API függvényt meghívni.

akármennyire is úgy akarod beállítani, hogy egyforma a kettő.

Ha jelszavak ellopkodására specializált malware-ekről beszélünk (márpedig arról beszéltünk mindezidáig), akkor alapértelmezésben egyforma a kettő. Bármennyire is úgy akarod beállítani, hogy a Total Commander, mint FTP kliens használata nem™ biztonságos™, vagy hogy a Google-dollármilliárdokból nem kellett volna egy picivel erősebb védelmet nyújtani, a Total Commander összességében továbbra is magasabb szintű jelszóbiztonságot tesz lehetővé, mint a Google Chrome.

A Windows-os jelszó felhasználó általi visszaállíthatósága megoldott (jelszóemlékeztető, azonosítási kérdések,stb.), a harmadik fél általi jelszóresetnek meg szerintem illendően dobnia kell az user mentett credential-jeit

Ez nem zárja ki azt a lehetőséget, hogy a Chrome-ban is legyen emlékeztető a mesterjelszóra. Tehát, még mindig arról beszélünk, hogy a Google spúrkodik a dollármilliárdjaival és nem hajlandó implementálni. Ez persze nem meglepő, hiszen régóta arra sem futja a Google-dollármilliárdokból, hogy egy szaros alap feature bookmark separatort beiktassanak. Az elitista hozzáállás, a felhasználók sértegetése, a "mi jobban tudjuk, mi kell a felhasználóknak" és a légből kapott "senkinek nincs erre szüksége" közhelyek hangoztatása természetesen mind nagyon jól megy a Google-dollármilliárdokon elkényelmesedett babzsákfejlesztőknek.

" Arra is megfelelően fel kell készíteni a malwaret, hogy pont a wcx_ftp.ini-t másolja le. Sőt még arra is, hogy a Total Commander reverzibilis scrambler logikáját implementálja és dekódolja, majd kigyűjtse a jelszavakat a malware-gazdának. " - Nem kell a malware-nek dekódolnia, mivel a fájlt elég elvinni, és bárhol vissza lehet fejteni. Nagyon nem mindegy.
 

" Google spúrkodik a dollármilliárdjaival és nem hajlandó implementálni " Nem spúrkodik, hanem költség/haszon alapon nem költ olyanra, ami nem éri meg. Meg a másik, hogy nem lehet, hogy azért van annyi pénze, mert olyasmire nem költ, ami nem térül meg...?

Nem kell a malware-nek dekódolnia, mivel a fájlt elég elvinni, és bárhol vissza lehet fejteni. Nagyon nem mindegy.

Igen, hekkerék majd nekiállnak több tízezer wcx_ftp.ini-t manuálisan, vagy külön scripteket írogatva dekódolni a saját gépeiken, csakhogy bebizonyítsák, hogy mennyire nem™ biztonságos™ a Total Commander és hupuék is lássák, hogy Zeller Mérnök Úrnak van igaza. Furcsa, hogy fejlődésmániásként ennyire le vagy maradva a modern malware-ek ismeretét illetően. Mert ha nem lennél, legalább olyan alapkoncepciókkal tisztában lennél, hogy a mai malware-eket lehetőség szerint a végletekig automatizálják, a rejtjelezett vagy titkosított adatokat még a célgépen visszafejtik és ezeket később adatbázisokba gyűjtik, hogy a botmestereknek elég legyen egy SELECT-et lefuttatni.

Ja és a Google Chrome biztonságos™: https://spyware-techie.com/google-chrome-users-should-watch-out-for-cstealer

Nem spúrkodik

De igen, spúrkodik. Válasz.

" Igen, hekkerék majd nekiállnak több tízezer wcx_ftp.ini-t manuálisan, vagy külön scripteket írogatva dekódolni " - ha arról van szó, akkor igen. Vagy épp a botnet más gépein fognak vele foglalkozni - látott már ilyet a világ... A lényege az, hogy egy "ha van ilyen fájl, akkor küldd el" kód jóval egyszerűbb, kevésbé feltűnő(!),mint az, ha egy random program dekódolásra használatos kódrészletet tartalmaz.

( kubi | 2020. 06. 11., cs – 19:11 )

Az FTP nem kepes hibak eszlelesere es korrigalasara alap esetben. Az alatta levo protokollretegekre hagyatkozik, a TCP meg eleg veges. Nagyobb fileok atvitele eseten siman becsuszhat par byte hiba. Szepen ki lehet szamolni...

Persze, ha nagyon szetcsuszik az atvitel, akkor mashol kell keresgelni.

Kis fileok eseten mit latsz?

Binary / ASCII?

Nem valoszinu, de nem 0 a valoszinusege. Nem veletlenul van az FTP-hez is kiegeszites, illetve epitettek bele egyeb atviteli protokollokba is.

Es nincs minden retegben vedelem. Az IPv4 peldaul egyaltalan nem vedi az adatot, csak a fejlecet, az IPv6 meg azt se.

Az Ethernet-ben van 32 bit CRC, TCP-ben 16 bit CRC.

Ha nagyon ratyi a fizikai reteg, akkor siman erzekelhetove valik nagyobb mennyisegu anyag atvitele eseten.

A CRC raadasul egyaltalan nem ved egy hulladek, memoriahibas routerrel vagy switchel szemben.

( E-Medve v | 2020. 06. 11., cs – 22:01 )

Egy vad ötlet: nézd meg, hogy Digi és mobilnet esetén az adott ftp szerver címét ugyanarra az IP-re oldja-e fel. Lehet, hogy az egyik IPv4, a másik meg IPv6? Elvileg nem kellene, hogy ez bekavarjon, de ki tudja.

( uid_395 v | 2020. 06. 19., p – 16:08 )

Szerkesztve: 2020. 06. 19., p – 16:09

btw, offtopic, FTP használattal két féle helyen találkoztam.

Egyik a földmérő cégek, másik a TV* média cégek. (bár utóbbi talán már kezdi elhagyni)

De földmérőknél pl azért kellett / kell FTP, mert maga az eszköz amivel kinn van a csóka és méricskél, stb, az bizony nem beszél más nyelven, csak úgy hogy FTP és azon akarja felküldeni az adatokat az irodába. (Vagy beszél még úgy, hogy rádugod a gépre kábellel és lekéred az adatokat) Nyilván régi eszköz, de ettől még kifogástalanul mér és ellátja feladatát, kidobni nem fogják csak azért mert nem *cloud* ready.. amúgy sem túl olcsó cuccok ezek.

+ még amire használnak ilyen cégeknél FTP-t tapasztalatom szerint, az a nagyobb térkép / egyéb munkaállományok küldözgetése / feltöltése / letöltése. Ezek általában térképrészletek, mérési eredmények. Kb 0 információval ha esetleg meg is szerzi valaki "menet" közben, semmire nem fogja tudni önmagában használni ezt az adott cuccot. Ha esetleg menet közben megszerzi a credential adatokat uploadfm1 user / UpdlFM1pass -t na paff. azzal se megy semmire. Tud feltölteni adatokat hurrá :D (letölteni nem, jobb helyeken)

Mondjuk nem az eredeti hozzászólásra válasz, csak itt a nagy össznépi "utáljuk az FTP-t irtsuk ki" -ra inkább. szóval offtopic :)