W dniu 07.01.2022 o 17:37, Robert Tomasik pisze:

> Ja do analizy dostałem akurat obraz w EnCase i
> przyznam się, że nie zastanawiałem się jak to wcześniej zrobili. W
> każdym razie każdy email był pierdylion razy powtórzony

Zapytam z ciekawości.
Co to za serwer pocztowy, który zapisuje jednego maila pierdyliard razy
powtórzonego?

> i pierwsze co
> zrobiłem, to wyszukałem i usunąłem duble po prostu licząc sumę kontrolną
> poszczególnych plików.

Znowu z ciekawości...
Nie było łatwiej np. po message id, transaction id...?

> Ja wywaliłem duble, a następnie LINK-iem zrobiłem graf, na którym było
> widać kto, do kogo, w jakim adresie i ile wiadomości wysłał.

Maile na dysku były, a plików z logami nie było?

Powrotu do zdrowia życzę.
Piotr

do góry

W dniu 07.01.2022 o 18:11, Kviat pisze:

>> i pierwsze co zrobiłem, to wyszukałem i usunąłem duble po prostu
>> licząc sumę kontrolną poszczególnych plików.
> Nie było łatwiej np. po message id, transaction id...?

Jak mam pewność, czy to nie są różne wersje tego emaila? Przykładowo
jakieś kopie bezpieczeństwa tworzone w czasie pisania? A tak pozbywam
się tego, co raczej na pewno tak samo wygląda. Szanse na to, ze dwa
różne emaile mają tę samą sumę są mizerne.
>
>> Ja wywaliłem duble, a następnie LINK-iem zrobiłem graf, na którym było
>> widać kto, do kogo, w jakim adresie i ile wiadomości wysłał.
> Maile na dysku były, a plików z logami nie było?

No popatrz - nie było właśnie. To znaczy logi były, ale log serwera
zawiera inne informacje, niż emaile. Mamy adresy IP, kto, jak i do czego
się łączył. Oczywiście by się pewnie dało posklejać z tego wiele, ale
nie widzę potrzeby.

--
Robert Tomasik

do góry

W dniu 07.01.2022 o 17:49, nadir pisze:
>> Adrese email jest daną osobową. Wiec mamy RODO i uzasadniony interes.
>> Widzisz jakiś interes w przetwarzaniu tych danych?
> Nie da się świadczyć usługi poczty email bez przetwarzania tych danych.

Wydaje mi się, ze nie masz racji, ale być może czegoś nie wiem, więc
wyjaśnij. Email jak go wyślesz na serwer, to następnie serwer email
wysyła go na serwer zgodny z domeną adresu email, a serwer odbierający z
kolei wrzuca go na odpowiedni adres. Sewer poczty wychodzącej nie
potrzebuje w ogóle przetwarzać adresu nadawcy, choć oczywiście go zna.
Serwer odbierający przyporządkowuje email do konta użytkownika. Na co
komu tabelka zawierająca nadawcę i odbiorcę? Przy czym oczywiście żaden
problem te dane mieć, tylko po co to komu?

>> Operatorzy bardzo chętnie by nie gromadzili bilingów, tylko ustawa
>> nakłada na nich taki obowiązek.
>
> I tak, i nie.
> Operatorzy bardzo chętnie gromadzą takie dane jak; bilingi, nagłówki,
> adresy IP i wiele podobnych danych, tylko niechętnie się tymi danymi
> dzielą.

Mam okazję rozmawiać z ludźmi od tych operatorów i twierdza co innego.
Dla operatora to jest zbędny balast.

> Ustawy ich zmuszają, a pieniądze, odpowiednio duże, zmniejszają niechęć
> do dzielenia się.

Ty naprawdę sądzisz, ze operator analizuje, kto do kogo dzwoni? Niby po
co im to?

--
Robert Tomasik

do góry

On 2022-01-07, Tomasz Kaczanowski <kaczus@_wiadomo_.onet.pl> wrote:
> W dniu 07.01.2022 o 12:32, Marcin Debowski pisze:
>> On 2022-01-07, Tomasz Kaczanowski <kaczus@_wiadomo_.onet.pl> wrote:
>>> W dniu 06.01.2022 o 17:07, Robert Tomasik napisał:
>>>> W dniu 06.01.2022 o 16:58, nadir pisze:
>>>>> Jak coś jest usunięte, to tego po prostu nie ma i backup tego nie
>>>>> wyczaruje. Ale sam folder Kosz/Trash to nie do końca usunięty mail,
>>>>> dlatego te foldery też się backup-uje. Natomiast użytkownik lub
>>>>> ustawienia serwera decydują czy i kiedy usuwać maile z tego folderu.
>>>>
>>>> O usuwaniu emaili z foldera usunięte oczywiście masz rację. Ale to nie
>>>> jest ich bezpowrotne usunięcie w praktyce.
>>>
>>> Jeśli partycja jest szyfrowana to jest bezpowrotne, chyba, że jest to
>>> standardowa partycja, to można znaleźć informacje
>>
>> Przecież operator nie będzie tego mejla szukał na jakiejś zewnętrznej
>> maszynie, a w normalnych warunkach z odszyfrowanym woluminem widocznym
>> dla systemu plikow i dowolnego innego programu z odpowiednimi prawami
>> dostępu, jako zwykłe urządzenie blokowe. Więc jak najbardziej odzyska.
>>
> Partycja szyfrowana ma to do siebie, że zmiana na niej powoduje
> nadpisanie danych. Więc o ile Rober miał zapewne na myśli, że wiele
> filesystemów przy usuwaniu pliku unieważnia tylko nagłówek,
> identyfikujący i przejrzenie dysku w trybie raw może pozwolić dużo
> rzeczy odzyskać (wręcz były kiedyś do takich rzeczy odpowiednie
> narzędzia), to przy partycji szyfrowanej zapisywane są (w zależności od
> sposobu szyfrowania oraz kilku innych rzeczy) za każdym razem duże
> partie dysku różnymi danymi, więc przejrzenie tego w trybie raw nie
> pozwoli znaleźć tych danych. Najprostszy sposób szyfrowania (najmniej
> wydajny oraz szkodliwy dla dysków, ale najbezpieczniejszy jeśli chodzi o
> bezpieczeństwo dostępu do danych), przy każdej zmianie nadpisuje całą
> partycję - oczywiście z takich metod nie korzysta się przy większych
> dyskach, ale chodzi o to by zrozumieć sposób działania - to nie jest
> jedynie szyfrowanie pliku, zapisywanie dużych fragmentów fizycznych dysku.

Dobrze, to może inaczej. Robię sobie cryptsetup luksFormat, dalej
luksOpen z utworzeniem urządzenia blokowego pod /dev/mapper, formatuję
to urządzenie do ext4, montuję, kopiuję tam parę zdjęc jpg, kasuję je,
odmontowuje, robię sync, luksClose, robię ponownie open, zapuszczam, bez
montowania, na tym photorec, odzyskuje wszystkie pliki zdjęć. Co robię
nie tak? :)

--
Marcin

do góry

W dniu 08.01.2022 o 00:08, Marcin Debowski pisze:
> Dobrze, to może inaczej. Robię sobie cryptsetup luksFormat, dalej
> luksOpen z utworzeniem urządzenia blokowego pod /dev/mapper, formatuję
> to urządzenie do ext4, montuję, kopiuję tam parę zdjęc jpg, kasuję je,
> odmontowuje, robię sync, luksClose, robię ponownie open, zapuszczam, bez
> montowania, na tym photorec, odzyskuje wszystkie pliki zdjęć. Co robię
> nie tak?:)

Nie chcę się upierać, ale moim zdaniem, jeśli tylko da się dany nośnik
odczytać, to można z niego dane odzyskać. Są programy (przykładowo
przywołany tu przez Ciebie PhotoRec, ale jest ich więcej, które po
prostu rozpoznają strukturę charakterystycznych plików. PhotoRec akurat
jest optymalizowany na obrazki, ale AutoPsy ma moduły potrafiące
odtworzyć choćby kawałek obrazka.

By mieć pewność, że się nie uda nic z tzw. "wolnej przestrzeni"
odczytać, trzeba ją kilkukrotnie nadpisać. Najpopularniejszym programem
do tego jest chyba CClaner, ale widziałem kilka innych. One po prostu
nadpisują wolną przestrzeń losowymi danymi i to kilkukrotnie. Czytałem,
że 3 razy w zasadzie gwarantuje, ze nic się wycisnąć ze śmieci nie da.

--
Robert Tomasik

do góry

On 2022-01-08, Robert Tomasik <r...@g...pl> wrote:
> W dniu 08.01.2022 o 00:08, Marcin Debowski pisze:
>> Dobrze, to może inaczej. Robię sobie cryptsetup luksFormat, dalej
>> luksOpen z utworzeniem urządzenia blokowego pod /dev/mapper, formatuję
>> to urządzenie do ext4, montuję, kopiuję tam parę zdjęc jpg, kasuję je,
>> odmontowuje, robię sync, luksClose, robię ponownie open, zapuszczam, bez
>> montowania, na tym photorec, odzyskuje wszystkie pliki zdjęć. Co robię
>> nie tak?:)
>
> Nie chcę się upierać, ale moim zdaniem, jeśli tylko da się dany nośnik
> odczytać, to można z niego dane odzyskać. Są programy (przykładowo
> przywołany tu przez Ciebie PhotoRec, ale jest ich więcej, które po
> prostu rozpoznają strukturę charakterystycznych plików. PhotoRec akurat
> jest optymalizowany na obrazki, ale AutoPsy ma moduły potrafiące
> odtworzyć choćby kawałek obrazka.
>
> By mieć pewność, że się nie uda nic z tzw. "wolnej przestrzeni"
> odczytać, trzeba ją kilkukrotnie nadpisać. Najpopularniejszym programem
> do tego jest chyba CClaner, ale widziałem kilka innych. One po prostu
> nadpisują wolną przestrzeń losowymi danymi i to kilkukrotnie. Czytałem,
> że 3 razy w zasadzie gwarantuje, ze nic się wycisnąć ze śmieci nie da.

Nie jestem pewien czy gdzieś się po prostu z Tomaszem nie rozumiemy bo
szyfrowanie jest na zupełnie innym poziomie abstrakcji niż system
plików, więc zwyczajnie nie rozumiem co tam ma gdzieś bruździć i
zmieniać. Z p. widzenia systemu plików i tego co pozostaje po jego
działaniu, tam nie ma żadnego szyfrowania. System plików nie wie, że jest
gdzieś warstwa szyfrująca, i odwrotnie, warstwa szyfrująca nie ingeruje
w żaden sposób w system plików. To nie jest sytuacja gdzie ktoś wyciąga
fizyczny, zaszyfrowany dysk i próbuje czytać go jak leci bez
odszyfrowania. To jest szyfrowany wolumin, który jest otwarty (podano
poprawny klucz) i online, więc dla dowolnego programu, który czyta z
tego woluminu tam nie ma żadnego szyfrowania.

--
Marcin

do góry

W dniu 07.01.2022 o 18:39, Robert Tomasik pisze:
> W dniu 07.01.2022 o 18:11, Kviat pisze:
>
>>> i pierwsze co zrobiłem, to wyszukałem i usunąłem duble po prostu
>>> licząc sumę kontrolną poszczególnych plików.
>> Nie było łatwiej np. po message id, transaction id...?
>
> Jak mam pewność, czy to nie są różne wersje tego emaila?

Taką, że skoro już liczysz sumę kontrolną, to różne wersje tego samego
emaila będą miały różną sumę kontrolną. A pisałeś u usuwaniu dubli.

Zapytam z ciekawości...
Jak po sumie kontrolnej stwierdzałeś, że dany mail jest roboczą wersją
tego, a nie innego maila?
(No i skąd te duble?)

> Przykładowo
> jakieś kopie bezpieczeństwa tworzone w czasie pisania?

Czyli każda zmiana tworzyła różny plik, z różną sumą kontrolną...
A potem serwer pocztowy tworzył pierdyliard kopii tych wersji roboczych
w pierdyliardzie kopii bezpieczeństwa?
Który serwer pocztowy tak robi?

> A tak pozbywam
> się tego, co raczej na pewno tak samo wygląda. Szanse na to, ze dwa
> różne emaile mają tę samą sumę są mizerne.

A jakie są szanse, że jakiś serwer pocztowy zapisuje różne wersje
robocze tego samego e-mailia w pierdyliardzie identycznych egzemplarzy
rozsianych gdzieś po dysku?
Jaki serwer pocztowy tak robi?

>>> Ja wywaliłem duble, a następnie LINK-iem zrobiłem graf, na którym
>>> było widać kto, do kogo, w jakim adresie i ile wiadomości wysłał.
>> Maile na dysku były, a plików z logami nie było?
>
> No popatrz - nie było właśnie. To znaczy logi były, ale log serwera
> zawiera inne informacje, niż emaile. Mamy adresy IP, kto, jak i do czego
> się łączył. Oczywiście by się pewnie dało posklejać z tego wiele, ale
> nie widzę potrzeby.

Chcesz mnie przekonać, że ludzie sobie wysyłają kopie robocze i na tym
twoim grafie było widać "kto, do kogo, w jakim adresie i ile wiadomości
wysłał"?
Zawsze myślałem, że ludzie sobie wysyłają ostatnią wersję, a nie kopie
robocze... i za chuja pańskiego z kopii roboczej maila nie wyciągniesz
do kogo i kiedy został wysłany, skoro... nigdy nie został wysłany, bo to
tylko kopia robocza (dla porządku dodajmy, że zapisana przez serwer w
pierdylionie identycznych egzemplarzy, w dublach pierdyliona kopii
zapasowych).

To właśnie w logach widać adresy IP kto do kogo wysyłał i co wysłał, jak
i z czym się łączył, a nie w treści kopii (pierdyliarda dodajmy dla
porządku) roboczych maila. Bajki o robieniu takiego grafu z treści kopii
roboczych (sic!) to możesz dzieciom opowiadać.
Z logów możesz się dowiedzieć kto, do kogo i ile razy wysyłał maile, gdy
ten mail dawno został skasowany, a miejsce po nim na dysku został
wielokrotnie zapisany gołymi babami.
Ale skoro nie widzisz potrzeby...

Weź już skończ.

Powrotu do zdrowia życzę.
Piotr

do góry

W dniu 07.01.2022 o 18:44, Robert Tomasik pisze:

> Na co komu tabelka zawierająca nadawcę i odbiorcę?

Jak na przykład przyjdziesz po pół roku do dostawcy poczty z kolegami i
zapytasz czy z takiego a takiego serwera został nadany, lub nie, jakiś
mail, nie jego treść ale sam fakt wysłania/odebrania, to jak dostawca
nie mając logów ma to stwierdzić, gdy użytkownik poczty skasował
wiadomość zaraz po wysyłce?

> Mam okazję rozmawiać z ludźmi od tych operatorów i twierdza co innego.
> Dla operatora to jest zbędny balast.

Balast, bo trzeba się dzielić informacjami ze służbami, bo trzeba
rozpatrywać reklamacje. Teraz może mniej, ale wiele lat temu bilingi
były jedną z podstaw rozpatrywania reklamacji.
Przy obecnych taryfach za połączenia, to straciło na ważności, ale i
operatorzy zaczęli świadczyć dodatkowe usługi. Dziś w cenie są dane
geolokalizacyjne, preferencje wyszukiwania, grupy kontaktów. Obecnie
strony www pytają a o akceptację cookies, ale jeszcze parę lat temu to
była wolna amerykanka. To też są dane, które niewiele różnią się od
bilingu czy nagłówka maila.

> Ty naprawdę sądzisz, ze operator analizuje, kto do kogo dzwoni?

Ja to wiem. Teraz to może nie bilingi, ale inne dane, tak jak napisałem
wyżej. No i operatora specjalnie nie interesowało/interesuje czy
Maliniak rozmawia z Kowalskim, chodzi o coś innego. Nie wiem czy dziś u
operatorów telekomunikacyjnych istnieje jeszcze coś takiego, ale kiedyś
istniała inżynieria ruchu. Analizowała obciążenie central i łączy,
analizowano skuteczność i jakość połączeń. Co prawda nie w oparciu o
stricte bilingi, ale inne dane, które też były logowane na centralach a
formalnie do zestawienia połączeń nie były niezbędne.

> Niby po co im to?

A chociażby po to, żeby rozbudować centralę, zwiększyć liczbę łączy,
przekierować prefiksy na mniej wykorzystane łącze.
W czasach gdy były jeszcze rozróżniane połączenia międzymiastowe,
międzynarodowe, czy komórkowe operatorzy oferowali dodatkowe
minuty/pakiety/bonusy na jakieś konkretne rodzaje połączeń, bo abonent
miał na przykład jakiś ulubiony kierunek albo porę dnia w której
rozmawiał. Jak myślisz, skąd oni mieli te dane?

do góry

W dniu 08.01.2022 o 15:21, Kviat pisze:

>>>> i pierwsze co zrobiłem, to wyszukałem i usunąłem duble po prostu
>>>> licząc sumę kontrolną poszczególnych plików.
>>> Nie było łatwiej np. po message id, transaction id...?
>> Jak mam pewność, czy to nie są różne wersje tego emaila?
> Taką, że skoro już liczysz sumę kontrolną, to różne wersje tego samego
> emaila będą miały różną sumę kontrolną. A pisałeś u usuwaniu dubli.

To teraz wiesz, czemu p osumie kontrolnej usuwałe, a nie ID.
>
> Zapytam z ciekawości...
> Jak po sumie kontrolnej stwierdzałeś, że dany mail jest roboczą wersją
> tego, a nie innego maila?

No więc nie było wersji roboczych, ale nie znając dokładnie algorytmu
wykluczyć nie mogłem.

> (No i skąd te duble?)

Nie wiem. Nie było to przedmiotem mojej troski i nie chciało mi się tego
dochodzić.
>
>> Przykładowo jakieś kopie bezpieczeństwa tworzone w czasie pisania?
>
> Czyli każda zmiana tworzyła różny plik, z różną sumą kontrolną...

Nie tworzyła, ale nie mogłem tego wykluczyć na początkowym etapie. W
przeciwieństwie do niektórych na tej grupie nie wiem wszystkiego i
staram się działać tak, by zapobiec skutkom swojej niewiedzy. >
>> A tak pozbywam się tego, co raczej na pewno tak samo wygląda. Szanse
>> na to, ze dwa różne emaile mają tę samą sumę są mizerne.
> A jakie są szanse, że jakiś serwer pocztowy zapisuje różne wersje
> robocze tego samego e-mailia w pierdyliardzie identycznych egzemplarzy
> rozsianych gdzieś po dysku?

Odzyskiwali dane z tzw. "wolnej przestrzeni" i tam te dane były
wielokrotnie replikowane. Po za tym nie sądzę, by jakikolwiek tego typu
serwer nie działał bez automatycznego replikowania. Serwer NAS, to chyba
minimum bezpieczeństwa.
>> No popatrz - nie było właśnie. To znaczy logi były, ale log serwera
>> zawiera inne informacje, niż emaile. Mamy adresy IP, kto, jak i do
>> czego się łączył. Oczywiście by się pewnie dało posklejać z tego
>> wiele, ale nie widzę potrzeby.
> Chcesz mnie przekonać, że ludzie sobie wysyłają kopie robocze i na tym
> twoim grafie było widać "kto, do kogo, w jakim adresie i ile wiadomości
> wysłał"?

Jak na to wpadłeś?

> Zawsze myślałem, że ludzie sobie wysyłają ostatnią wersję, a nie kopie
> robocze... i za chuja pańskiego z kopii roboczej maila nie wyciągniesz
> do kogo i kiedy został wysłany, skoro... nigdy nie został wysłany, bo to
> tylko kopia robocza (dla porządku dodajmy, że zapisana przez serwer w
> pierdylionie identycznych egzemplarzy, w dublach pierdyliona kopii
> zapasowych).

W sumie dobrze myślałeś. Ale część ludzi korzysta do pisania email
przykładowo a oprogramowania WEB-owego, a nie programu pocztowego, a to
działa na serwerze. >
> To właśnie w logach widać adresy IP kto do kogo wysyłał i co wysłał, jak
> i z czym się łączył, a nie w treści kopii (pierdyliarda dodajmy dla
> porządku) roboczych maila. Bajki o robieniu takiego grafu z treści kopii
> roboczych (sic!) to możesz dzieciom opowiadać.

Tyle, że jeśli serwer stoi w Europie, to szybciej te dane wyciągniesz z
tych emaili :-)

> Z logów możesz się dowiedzieć kto, do kogo i ile razy wysyłał maile, gdy
> ten mail dawno został skasowany, a miejsce po nim na dysku został
> wielokrotnie zapisany gołymi babami.
> Ale skoro nie widzisz potrzeby...

O ile tylko nie musisz tego sam zrobić od początku do końca. Mało który
admin przechowuje dłużej, niż kilka dni logi, a emaile ja mam sprzed
kilkunastu lat.
>
> Weź już skończ.

Następnym razem im podpowiem, by poszli i Ciebie powołali, bo wiesz
lepiej :-)


--
Robert Tomasik

do góry

W dniu 08.01.2022 o 23:10, nadir pisze:
>> Na co komu tabelka zawierająca nadawcę i odbiorcę?
> Jak na przykład przyjdziesz po pół roku do dostawcy poczty z kolegami i
> zapytasz czy z takiego a takiego serwera został nadany, lub nie, jakiś
> mail, nie jego treść ale sam fakt wysłania/odebrania, to jak dostawca
> nie mając logów ma to stwierdzić, gdy użytkownik poczty skasował
> wiadomość zaraz po wysyłce?

Operatorzy twierdzą, ze nie mają takich danych. Zauważ, ze obowiązek
wiedzieć mają operatorzy telekomunikacyjni.

>> Ty naprawdę sądzisz, ze operator analizuje, kto do kogo dzwoni?
> Ja to wiem.

Niepokoi mnie ta Twoja pewność, ale cóż mogę poradzić?
>
>> Niby po co im to?
> A chociażby po to, żeby rozbudować centralę, zwiększyć liczbę łączy,
> przekierować prefiksy na mniej wykorzystane łącze.

Naprawdę podejrzewasz, że w zależności do tego, czy email wysyłam do
serwera onet.pl, czy neostrada.pl, to one idą innym kabelkiem i trzega
dbać o ich grubość?


--
Robert Tomasik

do góry