Hej,
Pod rozwagę, zwłaszcza dla adminów.
---------- Treść przekazywanej wiadomości ----------
Temat: Re: [cryptography] To Protect and Infect Slides Data: poniedziałek, 6 stycznia 2014, 22:48:48 Od: Cathal Garvey Do: cypherpunks@cpunks.org
How would you monitor, maintain & troubleshoot administration & security issues on your servers if you do not have logs? Or are you talking about retention of said logs?
I read from this that excessive logging outside of a debugging scenario, coupled with either bad security or wilful sharing of log files, is the culprit.
So you're running a server, you want logs. Fine; what do you need to know? Statistical information about access, but not necessarily *who* is accessing. Perhaps you need to see if one person is accessing more than their share, but unless they exceed a certain threshold you don't want to record who they are; hash the IPs with a salt. Sure, yes, I expect you can reverse IP hashes, but at least you're trying.
Point being that logs are for debug and performance monitoring, but in this era of A) spying without consent and B) wilful assistance of spies by sysadmins globally, to be a good guy you have to wear blinders and collect only what you need. To resist the urge to hoard that comes with being raised in a marketing-heavy capitalism and with seeing storage volumes growing exponentially and remembering your days of scrimping on poorly encoded mp3s. Store what you need. Ditch the rest before it's even paged.
On 06/01/14 16:42, Laurens Vets wrote:
On 2014-01-05 01:01, John Young wrote:
If your server or ISP generates log files, as all do, you cannot be secure. If upstream servers generate log files, as all do, you cannot be secure. If local, regional, national and international servers generate log files, as all do, you cannot be secure.
So long as log files are ubiquitous on the Internet, no one can be secure.
Log files are the fundamental weakness of the Internet because system administrators claim the Internet cannot be managed and maintained without them.
This is not true, it is merely an urban legend to conceal the interests of system administrators and their customers to exploit Internet user data.
There is no fundamental need for log files, except to perpetuate the other urban legend, privacy policy, which conceals the abuse of log files by web site operators and their cooperation with "lawful" orders to reveal user data, most often by being paid to reveal that data to authorities, to sponsors, to funders, to advertisers, to scholars, to private investigators, to inside and outside lawyers, to serial cohorts, cartels and combines, to providers and purchasers of web sites, to educators of cyber employees, to courts, to cybersecurity firms, to journalists, to anybody who has the slightest justification to exploit Internet freedom of information by way of phony security, privacy and anonymizing schemes.
In this way, the Internet corrupts its advocates by inducing the gathering and exploiting user data, . It is likely your organizaion is doing this ubiquitous shit by pretending to ask for advice on security. As if there is any. NSA is us.
How would you monitor, maintain & troubleshoot administration & security issues on your servers if you do not have logs? Or are you talking about retention of said logs?
At 05:44 PM 1/4/2014, you wrote:
On 31/12/13 21:13, Jacob Appelbaum wrote:
I'm also happy to answer questions in discussion form about the content of the talk and so on. I believe we've now released quite a lot of useful information that is deeply in the public interest.
All the best, Jacob
Hi people:
As most of the people around the world, I find really troubling all these revelations. Of course we suspected this kind of shit, we just didn't know the gory and surprising details.
I work in a libre-software e-voting project [0] which has been deployed in some interesting initiatives already [1] and we strive to make it as secure as possible [2], though our resources are currently limited. Of course, anyone is welcome to join and help us.
Do you have any specific recommendation for securing the servers of the authorities who do the tallying, in light of latest revelations? it seems really difficult to get away from the NSA if they want to get inside the servers.
Kind regards,
cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
-----------------------------------------
"tak, ale": masz serwer pocztowy, jak bez informacji kto, komu, kiedy odpowiesz na pytanie "ale ja mu tego maila wysłałem a on nie dostał"?
Dnia wtorek, 7 stycznia 2014 00:44:35 viq pisze:
"tak, ale": masz serwer pocztowy, jak bez informacji kto, komu, kiedy odpowiesz na pytanie "ale ja mu tego maila wysłałem a on nie dostał"?
+1 Dokładnie ten sam przykład chciałem przytoczyć. Wielokrotnie na różnych serwerach którymi adminowałem (w BRAMIE przecież też nam się to zdarzało) nagle się okazywało, że trzeba sprawdzić czy mail od X do Y faktycznie przeszedł. A niewiele więcej gorszych rzeczy (poza samą treścią) można w poczcie logować niż to kto do kogo pisze.
Dodatkowo twierdzenie "logujcie tylko tyle ile potrzeba i możliwie najmniej" jest teoretycznie słuszne, ale jak dobrze wiesz z praktyki kiedy coś się sypie czasem nie wiesz nawet jakich danych potrzebujesz. Wtedy najbardziej pomocne są możliwie kompletne logi w dodatku nie tylko z momentu crashu, ale też z normalnej operacji serwera dla porównania co się w zasadzie zmieniło.
Wydaje mi się, że ważniejszą kwestią raczej jest ewentualna anonimizacja tych danych tam gdzie tylko się da oraz sposób (osobny serwer zdolny tylko do przyjmowania logów bez jakiejkolwiek możliwości zdalnego logowania) i czas ich przetrzymywania.
Trochę bullszit, gdyż zawsze możesz się kogoś spytać, czemu nie dochodzi. A zresztą w przypadku faila serwer docelowy odpowie, że wystąpił błąd, a autora wiadomości możesz się po prostu spytać.
Nie słyszałem jeszcze o takim problemie, żeby trzeba było robić rzeczywistego diffa na logach i nie było widać w tych logach błędu gołym okiem, a trochę serwerami mailowymi adminowałem. Jeśli występował jakiś błąd, to rzeczywiście był to błąd - albo SMTP, albo MDA, albo było doręczone i ugrzęzło w kolejce, gdzie przy flushu od razu pojawiał się błąd.
R.
On Tuesday 07 of January 2014 07:13:54 Radoslaw Szkodzinski wrote:
Trochę bullszit, gdyż zawsze możesz się kogoś spytać, czemu nie dochodzi.
Możesz się spytać użytkownika czemu jego wiadomość zniknęła w czeluściach internetu? Na pewno pani Krysia Ci na to odpowie jak ona tylko wie, że nacisnęła wyślij... A może zapytasz serwer czemu 10 minut temu nie dostarczył wiadomości? A skąd wogóle będziesz wiedział, że nie dostarczył? Może np. z logów się dowiesz, że wiadomość została zamrożona i dlaczego?
A zresztą w przypadku faila serwer docelowy odpowie, że wystąpił błąd, a autora wiadomości możesz się po prostu spytać.
Ty mówisz o twardych failach np. w przypadku braku konta. A jeśli ktoś oczekuje, że jego wiadomość dojdzie natychmiast bo akurat gada z odbiorcą przez komórkę, a okazuje się, że wiadomość trafiła na greylistę i żadna ze stron nie wie co się dzieje? A może opuściła twój serwer i teraz krąży gdzieś w odmętach internetu? W logach masz takie info.
Nie słyszałem jeszcze o takim problemie, żeby trzeba było robić rzeczywistego diffa na logach i nie było widać w tych logach błędu gołym okiem, a trochę serwerami mailowymi adminowałem.
Po pierwsze tutaj już nie miałem na myśli tylko serwera mailowego. Też nie mówię o diffie na logach, tylko właśnie manualnym porównaniu. W ten sposób często łatwiej jest szybko zobaczyć, że user przestawił sobie sposób logowania do serwera, albo inne jakieś drobne parametry które się zmieniły względem zeszłego tygodnia, a na pierwszy rzut oka wyglądają OK. A w sytuacjach skrajnych kiedy masz poważny fail też masz porównanie jak serwer działał poprawnie.
Dnia wtorek, 7 stycznia 2014 12:49:12 piorek pisze:
(words)
No wszystko fajnie, ale z drugiej strony trzeba minimalizować ilość trzymanych logów, i ilość informacji w tych logach, ze wszystkich powodów podanych w mailu, którym zacząłem ten wątek.
Zamiast trzymać logi Do Końca Świata I Jeden Dzień Dłużej, może wystarczy np. tydzień? Jeśli jest problem z pocztą, zwykle zauważy się błyskawicznie.
Jeśli jest problem z mailem juzera, czemu nie poprosić go o wysłanie maila ponownie (jednocześnie włączając dokładniejsze logowanie *na czas debagowania problemu*)?
Ja wiem, że wygoda adminów n'shit, ale czas zacząć zdawać sobie sprawę, jak ważną kwestią jest ograniczanie tego, co się trzyma w logach.
On Tuesday 07 of January 2014 13:08:33 rysiek wrote:
No wszystko fajnie, ale z drugiej strony trzeba minimalizować ilość trzymanych logów, i ilość informacji w tych logach, ze wszystkich powodów podanych w mailu, którym zacząłem ten wątek.
Zamiast trzymać logi Do Końca Świata I Jeden Dzień Dłużej, może wystarczy np. tydzień? Jeśli jest problem z pocztą, zwykle zauważy się błyskawicznie.
Czyli jednak Diabełko ma rację, że maile masz write-only. ;) Z mojego pierwszego maila: On Tuesday 07 of January 2014 02:54:56 piorek wrote:
ważniejszą kwestią raczej jest ewentualna anonimizacja tych danych tam gdzie tylko się da
sposób (osobny serwer zdolny tylko do przyjmowania logów bez jakiejkolwiek możliwości zdalnego logowania) ich przetrzymywania
czas ich przetrzymywania
Dnia wtorek, 7 stycznia 2014 13:16:04 piorek pisze:
On Tuesday 07 of January 2014 13:08:33 rysiek wrote:
No wszystko fajnie, ale z drugiej strony trzeba minimalizować ilość trzymanych logów, i ilość informacji w tych logach, ze wszystkich powodów podanych w mailu, którym zacząłem ten wątek.
Zamiast trzymać logi Do Końca Świata I Jeden Dzień Dłużej, może wystarczy np. tydzień? Jeśli jest problem z pocztą, zwykle zauważy się błyskawicznie.
Czyli jednak Diabełko ma rację, że maile masz write-only. ;) Z mojego pierwszego maila:
On Tuesday 07 of January 2014 02:54:56 piorek wrote:
ważniejszą kwestią raczej jest ewentualna anonimizacja tych danych tam gdzie tylko się da
sposób (osobny serwer zdolny tylko do przyjmowania logów bez jakiejkolwiek możliwości zdalnego logowania) ich przetrzymywania
czas ich przetrzymywania
<trololo> Gdzieś mi ten e-mail uciekł, możesz zajrzeć w logi, co się stało? :P </trololo>
Ale tak, racja.
Po pierwsze, maile nie uciekają. Lądują albo w kolejce (czyli są u ciebie na serwerze), albo są bounce z errorem, które powinny być na tyle rzadkie, że można je spokojnie logować. Incl. triple bounce. (oczywiście nie trzymać na 100 lat chyba, że zmuszają ciebie regulacje PL i UE)
Opisz mi sytuację inną niż włamanie czy inne naruszenie bezpieczeństwa, gdzie diff logów *normalnej pracy* coś by dał. (Log level niższy niż WARN, Warning czy takie.) Na serwerze produkcyjnym - choćby minimalnie przetestowanym. A jeśli już ktoś się włamał porządnie, to mógł spreparować dowolne logi oczywiście.
R.
-
piorek -
Radoslaw Szkodzinski -
rysiek -
viq