Portál AbcLinuxu, 30. dubna 2025 09:10
find /var/log/jetty -name '200*.log' -exec awk '{ print $1 }' {} \; | sort -u > tmp/ip.txt wc -l tmp/ip.txtAle i pro větší množství adres je to myslím dobrý nápad, a možná by ani nebylo nutné vymýšlet speciální strukturu – tabulku třeba se sto tisíci záznamy by MySQL pořád měla zvládnout, bylo by tam jen pořadové číslo a 32bitový integer (IP adresa) s vhodným indexem (třeba právě BTree).
náhodné orakulum
. Je ešte možné ku každej IP priraďovať náhodné číslo, ak by bol záujem o.i. utajiť skutočný počet IP navštevujúcich server. 32-bitová hashovací funkce je třeba CRC-32, případně se dá vzít MD5 a z výsledku použít jen 32 bitů. Tak jako tak ale v tomto případě stejně nebude zajištěna jednoznačnost.
Symetrická šifra vypadá o poznání lépe, ale má tu nevýhodu, že ten, kdo má přístup k serveru, bude schopen provádět inverzní převod. Z toho bych si ale nedělal těžkou hlavu, kdo má přístup k serveru, bude schopen si dohledat skutečné adresy jinak (navíc bych osobně neviděl naprosto nic špatného ani na zveřejňování skutečných IP adres komentujících). Nevidím ovšem smysl ve znovuvynalézání kola, spíš bych se poohlédl po nějaké známé a prověřené 32-bitové šifře, než bych trávil týden vymýšlením něčeho, co průměrně schopný kryptolog prolomí za půl hodiny. Zkusím se podívat, zda něco takového existuje. Případně by šlo použít 64-bitový hash, je sice delší, ale pokud použijeme kódování jako u unixových hesel, není problém ho zapsat pomocí 11 znaků.
Úplně nekvalitnější řešení by asi bylo použít něco na způsob {R,D,EC}SA, tj. vygenerovat tajný a veřejný klíč, tajný zahodit a veřejným to šifrovat. Otázkou ale je, jak těžké by bylo přizpůsobit tyto známé asymetrické algoritmy pro potřeby šifrování 32-bitových bloků.
Otázkou ale je, jak těžké by bylo přizpůsobit tyto známé asymetrické algoritmy pro potřeby šifrování 32-bitových bloků.
To samozrejme nieje ziadny problem... Staci nieco taketo:
kluc
= obrovske prvocislo
hash = IP^kluc & 0xFFFFFFFF
Totok je RSA algoritmus okresany o moznost desifrovania...
Vie niekto ako spravit mocninu takym velkym cislom? Ja si to uz nepamatam
& 0xFFFFFFFF
? To je naprosto zbytecne a neudela to nic, pak nam zbyde pouhy XOR, coz bych v tomto pripade ani nenaval jako nejakou hashovaci funkci^
zde asi není myšleno jako XOR, ale jako mocnina. Jenže by to musela být mocnina modulo něco, nejlépe 2^32, a pak už je tam ten AND zbytečný.
To samozrejme nieje ziadny problem... Staci nieco taketo:
kluc
= obrovske prvocislo
hash = IP^kluc & 0xFFFFFFFF
Totok je RSA algoritmus okresany o moznost desifrovania...
Tak takhle jednoduché to opravdu není.
Vie niekto ako spravit mocninu takym velkym cislom? Ja si to uz nepamatam :-(
To je skoro jednodušší vymyslet než najít, ne? Hint1: x^(2^n) se dá spočítat na n násobení, hint2: každé číslo n se dá napsat jako součet nejvýše 1+log_2 n mocnin dvojky.
Ale je... nieje to az tak davno co som mal za A z kryptografie (asi pol rokaTo samozrejme nieje ziadny problem... Staci nieco taketo:
kluc
= obrovske prvocislo
hash = IP^kluc & 0xFFFFFFFF
Totok je RSA algoritmus okresany o moznost desifrovania...
Tak takhle jednoduché to opravdu není.
Prave som sa vratil z kopania zemiakov a matematika je to posledne na co sa mi chce myslietVie niekto ako spravit mocninu takym velkym cislom? Ja si to uz nepamatam :-(To je skoro jednodušší vymyslet než najít, ne? Hint1: x^(2^n) se dá spočítat na n násobení, hint2: každé číslo n se dá napsat jako součet nejvýše 1+log_2 n mocnin dvojky.
Ale je... nieje to az tak davno co som mal za A z kryptografie (asi pol roka)
Promiňte, ale na to mohu reagovat jen slovy klasika: "To dodává slovu hrůza nový rozměr."
Safra... aj by som sa na to vykaslal... ale neznasam, ked zo mna robia debila... Clovek chce iba pomoct, a nakoniec sa musi sam branit...
RSA algoritmus je zalozeny na jednoduchom principe. Ked pracujem vo zvyskovych triedach, tak vzdy existuju cisla e,d pre ktore plati:
b = (b**e)**d
(** je umocnovanie (python) aby sa to neplietlo)
Na tomto je zalozeny cely RSA algoritmus. e je sifrovaci kluc, d je desifrovaci kluc. Jedine co je na RSA zlozite je najst tie prvocisla e a d, preto je generovanie klucov pomale, ale samotne sifrovanie uz prebieha rychlo.
Ja som od tial len vykopol hladanie paru klucov a nahradil ho nahodnym sifrovacim klucom...
Tymto koncim... Hadat sa nemienim... Netvrdim, ze som nejaky genius v oblasti kryptografie, ale aspon nake zaklady (kolko si len clovek zapamata, ked z niecim nerobi pol roka) mam.
Z toho samozrejme vypliva, ze na dany problem sa RSA neda vyuzit, nakolko nedokazem dostat 1:1 (p a q su prvocisla).
Symetrická šifra vypadá o poznání lépe, ale má tu nevýhodu, že ten, kdo má přístup k serveru, bude schopen provádět inverzní převod. Z toho bych si ale nedělal těžkou hlavu, kdo má přístup k serveru, bude schopen si dohledat skutečné adresy jinak (navíc bych osobně neviděl naprosto nic špatného ani na zveřejňování skutečných IP adres komentujících).IP adresa je už nyní uložena v databázi u každého komentáře, takže před administrátory je zbytečné hash chránit.
Nevidím ovšem smysl ve znovuvynalézání kola, spíš bych se poohlédl po nějaké známé a prověřené 32-bitové šifře, než bych trávil týden vymýšlením něčeho, co průměrně schopný kryptolog prolomí za půl hodiny. Zkusím se podívat, zda něco takového existuje.Znovuvynalézat kolo jsem nechtěl, jenom jsem měl utkvělou představu, že hledám hashovací funkci, a vůbec mne nenapadlo, že vlastně hledám šifru. Přesně tohle jsem potřeboval – někoho, komu když popíšu příznaky, řekne mi, co vlastně řeším za problém
On je taky jiný problém, já třeba se vyskytuji z hlediska internetu asi na deseti různých IP adresách, ze kterých přispívám. U sebe doma jsem jednoznačný, ale třeba u kamaráda bude dva naprosto různí lidé mít stejnou IP adresu, aniž bychom si nějak koordinovali příspěvky.S tím se počítá, ten systém samozřejmě není dokonalý. Ale dokud se nebude vyžadovat otisk prstu, sken oční sítnice nebo DNA, vždy bude existovat buď riziko, že se dvě různé identity omylem ztotožní za jednu, nebo naopak jeden člověk se bude moci vydávat za více různých identit. Navíc pokud vy ani váš kamarád nebudete trollovat, nebude shodný hash asi nikdo řešit. Tady jde spíš o takové případy, kdy se někdo v diskuzi chová podivně jako registrovaný, a pod druhou anonymní identitou se v tom podporuje, nebo si nahrává.
Já osobně bych neviděl nic špatného na zveřejňování IP, případně čístí IP, nebo doménových názvů, ze kterých člověk přistupuje. Na mnoha místech si s tím hlavu nelámou.Zveřejňování IP by bylo riskantní. Představte si, že se nějaký začátečník zeptá, že má podezření na nějakou bezpečnostní díru, má staré jádro a potřebuje ho zaktualizovat, nebo něco podobného. A vedle bude jeho IP adresa. AbcLinuxu už dnes není relativně uzavřená komunita, která si může navzájem plně důvěřovat – je potřeba už počítat i s náhodnými kolemjdoucími nebo občasnými čtenáři, kteří by takovou věc klidně zneužili. Doménové názvy už vůbec ne, spousta IP adres nemá reverzní záznam, navíc by se pro každý komentář musel dělat dotaz do DNS cache.
První otázka zní, nakolik je IP adresa tajný údaj, aby s ní bylo nutné dělat jakékoliv obstrukce - mně osobně je třeba úplně jedno, jestli by se v diskusi moje IP adresa objevovala nebo ne. Budeme ale předpokládat, že adresu potřebujeme utajit, jinak samozřejmě nemá další diskuse smysl.
Další zjevný fakt je, že pokud by se hashovalo nějakým "výpočtním alogirtmem", něco v použitém algoritmu bude muset být tajné - buď algoritmus sám, nebo alespoň nějaký jeho klíč. Prostor IP adres je dostatečně malý na to, aby člověk se zcela normálními prostředky dokázal vypočítat celý prostor hashů a tak z hashe dokázal identifikovat jakoukoliv IP adresu.
Z možných algoritmů mě napadá:
Řekl bych, že utajení klíče při použití známého (ať už jakéhokoliv) algoritmu stačit nebude. Útočník má totiž vždy k dispozici "plaintext" (IP adresu), "ciphertext" (hash), bez větší práce navíc vícekrát (pro více IP adres) a konečně 32 bitů je natolik malý prostor, že není problém provést nějaký cílený brute-force útok. V takové situaci asi nenaleznete žádný algoritmus, který by odolal.
Z toho důvodu vidím jako jediný vhodný způsob ten "nevýpočetní", který navrhl kolega Kubeček. Administrátoři serveru jistě dokáží z logu zjisit, řádově kolik unikátních IP adres tento server navštěvuje. A i když jich nebude 3000, ale 300000 nebo 3000000, pořád to není mnoho. A není samozřejmě nutné vymýšlet žádnou složitou paměťovou strukturu, ty stovky tisíc nebo miliony řádků si bez potíží zapamatuje databáze v jedné tupé a nevelké tabulce. Místo IP adresy pak vypisujte primární klíč záznamu a hotovo.
Z toho důvodu vidím jako jediný vhodný způsob ten "nevýpočetní", který navrhl kolega Kubeček. Administrátoři serveru jistě dokáží z logu zjisit, řádově kolik unikátních IP adres tento server navštěvuje. A i když jich nebude 3000, ale 300000 nebo 3000000, pořád to není mnoho. A není samozřejmě nutné vymýšlet žádnou složitou paměťovou strukturu, ty stovky tisíc nebo miliony řádků si bez potíží zapamatuje databáze v jedné tupé a nevelké tabulce. Místo IP adresy pak vypisujte primární klíč záznamu a hotovo.Souhlasím, navíc se tím „zadarmo“ vyřeší i možnost získat všechny komentáře z jedné IP adresy (alespoň pro správce z SQL konzole).
…ale predpokladám, že 95% prispievateľov je z .cz. Koľko IP blokov je asi tak alokovaných pre .cz?
Říkejme raději "z ČR" (a SR). A priori není žádná rozumná vazba mezi doménovým jménem a tím, jestli se počítač nachází v ČR nebo ne. U IP rozsahů to samozřejmě také není stoprocentní, ale pořád se to tomu blíží podstatně více.
priznávam sa k XXX (dobrý námet na anketu)
registrovaný_1
, registrovaný_2
, anonym
jako něco různého jde proti základnímu smyslu celého snažení, totiž ztížit vystupování jedné osoby pod více identitama.
echo "stodevadesátdva.stošedesátosm.jedna.jedna" |md5sum
Tak si tak říkám, jestli někteří komentující (a to se netýká jen vás) ten blogpost vůbec četli celý…
PS: Proč jednoduše nepoužiju nějakou známou ověřenou hashovací funkci, jako MD5 nebo SHA-256? … Jednak všechny hashovací funkce, se kterými se znám, mají hash minimálně 128 bitů, což je 32 hexačíslic – to je trochu moc na to, aby to někdo u komentářů ručně porovnával. Navíc z 32 bitů stejně nedostanu ví jak 2^32 kombinací, takže delší hash je zbytečný – pouze přidává balast do výstupu.
Spoustě z nás se určitě nelíbí různé snahy státu zjišťovat nebo sledovat čím dál víc údajů, někomu se nelíbí, že takové údaje může sledovat Google, Microsoft… A připadá mi zvláštní rozdělovat svět na ty zlé (stát, Microsoft), u kterých nám to vadí, a na ty hodné (abclinuxu.cz), kterým to dovolíme. Vzhledem k tomu, že Abíčko zveřejňovat plné IP k ničemu nepotřebuje, nevidím důvod, proč by to mělo dělat.Tak potom je ale nezobrazování IP adres jen kamufláž, protože se ve skutečnosti ty IP adresy ukládají a tak je ABCLinuxu (respektive jeho provozovatel) ve skutečnosti může sledovat. Lidé, kteří se něčeho takového obávají už dávno používají tor, nebo anonymní proxy servery.
Na builder.cz to funguje jen v rámci jednoho tématu - tedy v tomto případě by to bylo třeba teď v rámci jedné diskuse v blogu. Takže případný překlep se projeví na jednom místě v jedné diskusi. Možná právě to rozdílné chápání tohoto detailu působí, že si nerozumíme - a myslíme každý trochu jinak.Ano, v tom je nedorozumění. Já bych ale rád, pokud už by se něco takového implementovalo, aby ta identifikace fungovala napříč diskuzemi, abych např. mohl zjistit, zda anonym pod jedním článkem nepřistupuje náhodou z té samé IP adresy, jako „jiný“ anonym pod týden starým jiným článkem.
Jinak nevím přesně, jaká je databázová struktura abclinuxu.cz a ani po tom nechci pátrat. Ale představuji si tam nějak, že každý komentář je jeden řádek v nějaké tabulce, kde kromě jiného je i přezdívka (případně cizí klíč na nějakou tabulku registrovaných uživatelů) a ve stejném řádku je i sloupec s IP adresou. Alespoň tak by to mohlo logicky vypadat. Tudíž všechny údaje ke zkonstruování seznamu identických přezdívek v jednom blogu jsou v jedné tabulce.Každý komentář je záznam v tabulce, je tam cizí klíč do tabulky uživatelů v případě, že je autor registrovaný. Pokud není registrovaný, je jméno uživatele přímo v XML (1 sloupeček v DB). V XML je pak i vlastní text komentáře a IP adresa (plus případně administrátorské zásahy, jako cenzura komentáře). V případě použití hashů se schéma rozšíří o jeden sloupeček s hashem. Pokud nebudu mít všechny „kolegy ze stejné IP adresy“ v jednom sloupci tabulky (který by musel mít nějaký vnitřní formát, který by se zase musel parsovat), musí se buď provést extra dotaz pro každý komentář (protože pro jeden komentář mám N kolegů), nebo by se musel udělat OUTER JOIN, čímž by se zbytečně posílala opakovaně ta samá data, navíc by si to pak ještě aplikace uměla přebrat. PostgreSQL by to asi dokázala nacpat do nějakého pole a vrátit všechny kolegy v jedné položce v záznamu s komentářem, ale tohle podle mne MySQL neumí.
Pokud jsem to správně pochopil, u každého příspěvku máte dneska v tabulce zaznamenánu IP adresu. Stejně dobře tam můžete mít zaznamenaný "hash" této adresy.
Jednorázově můžete (někdy v noci) vytvořit tabulku hash+ip_adresa a naplnit ji (něčím jako "select unique ip from prispevky"). Následně u všech příspěvků udělat "update prispevky join hashe using (ip) set prispevky.hash=hashe.hash" a tak ke všem příspěvkům přidat příslušný "hash" (de facto primary key) IP adresy. A následně zahodit položku ip_adresa v tabulce příspěvků.
S tabulkou mapování IP adresa na klíče by se pracovalo jen při přidávání příspěvku, nikoliv při jeho zobrazování. Čili při zobrazování diskuse vám nepřibývá navíc vůbec nic, režie narůstá jen při přidávání příspěvku, a to rozhodně není "až tak kritická operace".
emerge net-misc/tor
Dobrý večer. Chtěl bych Vás poprosit, aby se tento systém vztahoval pouze na komentáře, které byly vloženy až po jeho zavedení. Vynechejte starší komentáře.O aplikaci na starší komentáře myslím nikdo neuvažoval (rozhodně by retroaktivní zveřejnění nebylo fér).
1) Neřeší problém. Provokatérkých příspěvků se nezbavíte, systém bude např. obcházen přes anonymní proxy. Zmizí jen symptomy. 2) Dochází ke ztrátě anonymity. Není již možné být anonymní vůči ostatním uživatelům. Pokud uživatel A o sobě něco prozradí ("jsem teď v práci, pracuju v microsoftu čr") a jiný uživatel B je s ním ve stejné síti se stejnou veřejnou ip, odhaluje se informace i o uživateli B (toto odhalení funguje i do minulosti, proto můj požadavek). Pokud by navíc chtěl někdo sledovat jiné osoby (ale nezná jejich login), postačí když z jejich počítače odešle komentář.Zeslabení pocitu anonymity je myslím právě účelem toho zveřejňování. Dneska je hrozně snadné získat pocit, že jsem anonymní – stačí se odhlásit (pokud používám profil) a do políčka vyplnit jiné jméno. Účelem opatření by mělo být, že takový člověk bude muset pro svou anonymitu udělat něco víc – najít vhodný proxy server, nastavit si jej v prohlížeči – a třeba mu během toho dojde, že mu to nestojí za to, a že radši komentář napíše slušně, nebo vůbec. Ale to že můžu nechtěně vyzradit informaci o někom jiném, je dobrá připomínka. Asi by to chtělo udělat anketu, a raději na titulní straně, v blogu by si jí všiml málokdo.
if (showIPhash(comment)) then hash := lookupHash(ip) else hash := invalidHash;vedla k nějakému pozorovatelnému zpomalení. V šabloně se nic měnit nemusí.
Nikdo tu zverejnovat IP adresu nechce.
"Chce" je asi trochu silný výraz, ale kdyby takový návrh padl, byl bych pro.
implementácia: tabuľka (id, ip), index na ip, id autoincrement, hash = select podľa ip alebo insert. IPv4 = int4, hash by teoreticky bolo možné rozdeliť na 4x8bit a zobrazovať formou IP.
toto je práca na 5 minút aj s prestávkou
hash by teoreticky bolo možné rozdeliť na 4x8bit a zobrazovať formou IP.
To by nebylo dobré. Lidé většinou ze zásady nečtou dokumentaci, takže by si mysleli, že je to skutečná IP adresa.
Dochází ke ztrátě anonymity. Není již možné být anonymní vůči ostatním uživatelům.
To bych označil za přínos, ne za chybu.
deb http://ftp.cz.debian.org/debian jessie main contrib non-free
K cemu to tedy cele je?Psychologický efekt pro komentující – nejste až tak anonymní, jak si myslíte. A psychologický efekt pro čtenáře – pokud se přezdívka X a přezdívka Y chovají v diskuzi podivně, mají nápadně podobný jazyk, pořád ještě s říkám, že může jít o náhodu a nechci jim křivdit. Když budou mít i nápadně stejný hash IP adresy, bude to na můj vkus už náhod moc. Člověk pro své rozhodování nepotřebuje jen tvrdá fakta, dokáže se rozhodovat i podle informací typu „mají stejnou IP adresu, možná je to jeden a tentýž člověk“.
int vrat_kod(){
struct timeval a;
int vrat;
gettimeofday(&a,NULL);
srand(a.tv_usec);
vrat = rand()*... // Teraz nejaké blbosti s danými časovými údajmi na prípadné zozložitenie a je to.
return vrat;
Nikto sa nemusí báť, že by sa dala zistiť spätne IP adresa, keďže sa s ňou nepracuje. Ak by sa náhodou podarilo získať rovnaký kód ako už v databázi je, celé by sa to proste zopakovalo.
A výpočet hashu ponechať na trigger ...To půjde v MySQL 4 těžko.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.