Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Ogłoszenie
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
#1 2014-04-08 20:34:46
morfik - 
Cenzor wirtualnego świata
Dziura w openssl
http://niebezpiecznik.pl/post/krytyczna-dziura-w-openssl-ponad-65-serwerow-w-internecie-podatnych-na-podsluch-i-to-od-2-lat/
brak tzw. bound checka w obsłudze heartbeatu TLS może powodować ujawnienie 64k pamięci serwera. Na błąd podatne są wersje od 1.0.1 do 1.0.1f oraz 1.0.2-beta wraz z 1.0.2-beta1. —Błąd odkrył Neel Mehta z Google Security.[/quote]
Lepiej łatajcie. Póki co poprawiona wersja jest w sidzie:Kod:
# apt-cache policy openssl openssl: Installed: 1.0.1g-1 Candidate: 1.0.1g-1 Version table: 1.0.2~beta1-1 0 130 http://ftp.pl.debian.org/debian/ experimental/main amd64 Packages *** 1.0.1g-1 0 500 http://ftp.pl.debian.org/debian/ sid/main amd64 Packages 100 /var/lib/dpkg/status 1.0.1f-1 0 900 http://ftp.pl.debian.org/debian/ testing/main amd64 PackagesNie ma to jak społeczność weryfikująca kod. xD
Offline
#2 2014-04-08 20:36:47
Jacekalex - Podobno człowiek...;)
- Jacekalex
- Podobno człowiek...;)
- Skąd: /dev/urandom
- Zarejestrowany: 2008-01-07
Re: Dziura w openssl
Było w CB dzisiaj rano.
A na społeczność możesz nie miauczeć, ciekawe, jak często szacowni producenci routerów z VPN zapewniają łatki dla swoich systemów, na których chodzą miliony ich urządzeń.
Po ataku na serwery BGP, kiedy cały FB leciał przez Chiny, jakoś nie zauważyłem, żeby był dużo większy ruch w aktualizacjach softu na routery.
PS
Czy W BGP dalej używa się haseł hashowanych md5?
Pytam, bo sam podsłuch szyfrowania SSL na wiele się nie zda, jeśli ten szyfrowany sygnał nie leci przez infrastrukturę do podsłuchu, więc trzeba do tego zrobić jeden z dwóch ataków, albo włamanie na DNS, co łatwo wykryć i przeciwdziałać, albo włamanie na BGP, gdzie można zdecydować o przekierowaniu milionów pakietów przez inną część sieci, czego wielu ludzi nie zauważy w ogóle.
Bo niby kto pamięta, że pingi do banku, to 21,3 ms, i zacznie alarm, kiedy będą wynosić 134,7ms.
Ostatnio edytowany przez Jacekalex (2014-04-08 20:49:42)
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)
Offline
#3 2014-04-08 20:42:01
morfik - Cenzor wirtualnego świata
#4 2014-04-08 20:49:21
enether - wiecznie niewyspany
- enether
- wiecznie niewyspany
- Zarejestrowany: 2012-05-01
Re: Dziura w openssl
Żadnego łatania paczkami z sida...
Od tego są poprawki na paczki w gałęzi security by z nich korzystać ;) I jak rano serwery łatałem już była poprawiona wersja dla Wheezy'ego.
https://www.debian.org/security/2014/dsa-2896
Offline
#5 2014-04-08 20:54:32
yossarian - Szczawiożerca
- yossarian
- Szczawiożerca
- Skąd: Shangri-La
- Zarejestrowany: 2011-04-25
Re: Dziura w openssl
The oldstable distribution (squeeze) is not affected by this vulnerability.
For the stable distribution (wheezy), this problem has been fixed in version 1.0.1e-2+deb7u5.
For the testing distribution (jessie), this problem has been fixed in version 1.0.1g-1.
For the unstable distribution (sid), this problem has been fixed in version 1.0.1g-1.
We recommend that you upgrade your openssl packages.[/quote]
[quote=morfik]Nie ma to jak społeczność weryfikująca kod. xD[/quote]
Ile kodu sam zweryfikowałas?
Offline
#6 2014-04-08 21:00:15
Jacekalex - Podobno człowiek...;)
- Jacekalex
- Podobno człowiek...;)
- Skąd: /dev/urandom
- Zarejestrowany: 2008-01-07
Re: Dziura w openssl
Tak przy okazji, znacie jakieś automatyczne skrypty, które bez specjalnego angażowania administratora, automatycznie wygenerują nowy
RootCA i certy dla poszczególnych usług?
Zamierzam sobie coś podobnego skołować albo wyrzeźbić, i zastanawiam się, czy użyć expecta, czy kombinować z perlem.
W standardowych openssl, ca.pl trzeba co chwila tłuc hasła, potwierdzać informacje, potem na jednej maszynie jest pół godziny pieprzenia.
[UWAGA]
Nie wiem, czy ktoś zauważył, ze poza aktualizacją, trzeba by na nowo wygenerować wszystkie certy do serwerów używających biblioteki OpenSSL, żeby być pewnym bezpieczeństwa usług.
Skąd pewność, że cert prywatny nie wyciekł na starej wersji biblioteki? i nie fruwa gdzieś na necie?
[/UWAGA]
Pozdro
;-)
Ostatnio edytowany przez Jacekalex (2014-04-08 21:00:46)
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)
Offline
#7 2014-04-08 21:07:48
enether - wiecznie niewyspany
- enether
- wiecznie niewyspany
- Zarejestrowany: 2012-05-01
Re: Dziura w openssl
Zauważyli zauważyli ;) I po ręcznej zabawie na dwóch maszynach stwierdzono że tą metodą to się można bawić dłuższy czas.
Offline
#8 2014-04-08 21:20:35
morfik - Cenzor wirtualnego świata
Re: Dziura w openssl
E tam, ja nie miauczę. xD No ale 2 lata? xD
Ile kodu sam zweryfikowałas?[/quote]
Ja nie umiem kodzić, więc to pytanie nie do mnie, tylko do tych co się w tym orientują, a ci jak jeden mąż mówią, że ktoś to weryfikuje. xD To jest największy problem open source i zarazem fałszywe poczucie bezpieczeństwa, że ktoś się doszuka, że ktoś znajdzie, problem w tym, że niewielu w ogóle sobie głowę tym zawraca, oczywiście z tych niezrzeszonych z danym projektem. I to jest fakt.Nie wiem, czy ktoś zauważył, ze poza aktualizacją, trzeba by na nowo wygenerować wszystkie certy do serwerów używających biblioteki OpenSSL,[/quote]
No skoro przez 2 lata można było sobie pozyskać taki cert z servera, to raczej trzeba wymienić. Póki co, to google i riseup zmienili do poczteksa i jabbera, przynajmniej tyle mi wyrzuciło jak n arazie.Offline
#9 2014-04-08 21:27:27
enether - wiecznie niewyspany
- enether
- wiecznie niewyspany
- Zarejestrowany: 2012-05-01
Re: Dziura w openssl
Swoją drogą ciekawostka, rano aktualizowałem paczki na Debianach, nie chciało restartu usług, teraz pojawiły się kolejne łatki na te same paczki i pyta czy je zrestartować ;)
Więc Ci którzy jak ja łatali rano mają powtórkę z rozrywki...
Offline
#10 2014-04-10 11:52:57
remi - amputować akrobatów
- remi
- amputować akrobatów
- Zarejestrowany: 2011-05-27
Re: Dziura w openssl
Cześć. W sieci dostępny jest ciekawy plik, dokument z dn. 24.go lutego ilustrujący: "[i](..,) a vulnerability introduced to elliptic curve cryptographic protocols when implemented using a function of the OpenSSL cryptographic library[/i]". Artykuł - wraz ze szczegółowymi informacjami - stworzony przez Yuval Yarom oraz Naomi Benger, znajduje się pod adresem; [url=http://eprint.iacr.org/2014/140][color=blue]http://eprint.iacr.org/2014/140[/color][/url] ([u]"Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack[/u]").
[color=#5B5B5B][tt][b]Ł[/b][i]a[/i]m[/tt] [tt][b][i]Z[/b][/i]As[i]a[/i]d[b][/tt][tt]y[/tt][/b][b]![/b] w[i]Y[/i][b]j[/b][b]ą[/b]Tk[i][b]Ó[/b][/i][b]w[/b] [tt][i]j[/i][b]e[i]s[/i][/b]t[/tt] w[tt][b][/b]I[b][i]ę[/i][/b][/tt]c[b]e[i]j[/i][/b][/color].
Offline
#11 2014-04-10 16:22:04
menel - Użytkownik
- menel
- Użytkownik
- Zarejestrowany: 2013-11-02
Re: Dziura w openssl
2 lata ja pierdziele...ciekawe czy tor się podniesie...(wszystko tam spalone może być...
a propo tora:
http://www.reddit.com/r/DarkNetMarkets/comments/22k76z/do_not_use_tor_right_now_heartbleed_is_affecting/
Ostatnio edytowany przez menel (2014-04-10 16:33:36)
Offline
#12 2014-04-10 19:38:33
uzytkownikubunt - Zbanowany
- uzytkownikubunt
- Zbanowany
- Zarejestrowany: 2012-04-25
Re: Dziura w openssl
[url]http://article.gmane.org/gmane.os.openbsd.misc/211963[/url]
Theo de Raadt - założyciel i przewodniczący projektów OpenBSD i OpenSSH o luce w OpenSSL.
BTW OpenSSH, pomimo tego że korzystało z dziurawej wersji OpenSSL, jest odporne na atak Heartbleed. Niestety nie oznacza to, że wszystko programy korzystające z OpenSSL w OpenBSD są na niego odporne...
Offline
#13 2014-04-10 20:24:56
menel - Użytkownik
- menel
- Użytkownik
- Zarejestrowany: 2013-11-02
Re: Dziura w openssl
a mi to śmierdzi z daleka skoro starsze wersje nie miały hearbeat'a i były bezpieczne to jak ja się pytam można zamiast łatać jeszcze bardziej coś dziurawić. Założę się, że sporo szemranych agencji w tym NSA wiedziały o furtce od początku, bo same ją tam wrzuciły hehe
Tor jest wykończony tym, wszystko spalone tam już jest..
firmy handlujące certami już ręce pewnie zacierają..interes życia..
Ostatnio edytowany przez menel (2014-04-10 20:38:34)
Offline
#14 2014-04-10 20:39:24
fervi - Użytkownik
- fervi
- Użytkownik
- Zarejestrowany: 2010-03-14
Re: Dziura w openssl
@menel
Jest hipoteza informatyczna, według której poprawiając kod - tworzysz kolejnego buga
Niemniej osobiście nie widzę problemu - HTTPS [b][i][u]NIGDY[/b][/i][/u] nie był bezpieczny
Fervi
Ostatnio edytowany przez fervi (2014-04-10 20:39:52)
Offline
#15 2014-04-10 20:45:13
menel - Użytkownik
- menel
- Użytkownik
- Zarejestrowany: 2013-11-02
Re: Dziura w openssl
jaka tam hipoteza to tylko pokazuje, że w nadchodzących czasach [b]nic[/b] nie będzie bezpieczne i takie agendy jak NSA wszędzie włożą swoje łapska bez względu czy to będzie open source czy zamknięte oprogramowanie. Prawda jest taka, że w sieci nic nie jest już bezpieczne a szyfrowania i inne gówna to tylko ułuda poufności mogąca dać bezpieczeństwo jakiemuś maniakowi co sobie szyfruje partycje i łączy się z fejsbukiem ale nie firmom czy infrastrukturom państwowym gdzie jest przepływ strategicznych i wrażliwych danych...
Ostatnio edytowany przez menel (2014-04-10 20:52:59)
Offline
#16 2014-04-10 21:09:32
enether - wiecznie niewyspany
- enether
- wiecznie niewyspany
- Zarejestrowany: 2012-05-01
Re: Dziura w openssl
Abstrahując od tego czy jest to backdoor złych trzyliterowych agencji, błąd programistyczny czy działania jaszczurzych żydomasonów chciałem poinformować tych którzy jeszcze ni e zauważyli że nie tylko serwery są podatne ale i klienci którzy mieli pecha trafić na złośliwy serwer ;)
Swoją drogą, o ile się nie mylę i pamiętam dobrze to i owo o architekturze pamięci procesów w Linuxie to pamięć jądra jak i każdego z procesów z osobna jest separowana, nawet na jądrze które ominęło błogosławieństwo grseca. Tak?
Offline
#17 2014-04-10 21:14:01
menel - Użytkownik
- menel
- Użytkownik
- Zarejestrowany: 2013-11-02
Re: Dziura w openssl
ja profilaktycznie wymieniłem wszystkie wrażliwsze hasła między innymi do banku..wolę dmuchać na zimne..;)
Ostatnio edytowany przez menel (2014-04-10 21:14:30)
Offline
#18 2014-04-10 21:16:25
enether - wiecznie niewyspany
- enether
- wiecznie niewyspany
- Zarejestrowany: 2012-05-01
Re: Dziura w openssl
Technicznie w przypadku korzystania z 2 factor auth to posiadanie hasła to tylko połowa sukcesu.
Anyway... ktoś coś lepiej kojarzy w temacie architektury pamięci? Bo wybitnie nie mam dziś sił się przebijać przez tony opracowań naukowych.
Offline
#19 2014-04-10 23:53:22
Jacekalex - Podobno człowiek...;)
- Jacekalex
- Podobno człowiek...;)
- Skąd: /dev/urandom
- Zarejestrowany: 2008-01-07
Re: Dziura w openssl
Ja raczej podejrzewam, że ta dziura w OpenSSl 1.0.x, to wybitny sukces chińskiej myśli technicznej.
Nauczyli się już manipulować od czasu do czasu protokołem routingu dynamicznego BGP, ta dziura w OpenSSL dopełnia kompletu zabawek szpiegowskich.
Szkoda tylko, że tak rzadko inni Ludzie badają zachowanie OpenSSL, bo błąd jest dosyć śmieszny.
Najdłuższy klucz OpenSSL może mieć 64000 bit, a nieszyfrowanym kanałem musi ujawnić klucz publiczny serwera, jeśli ten klucz jest krótszy niż 65535 bitów (zazwyczaj ma 1024 - 4096 bit), to wypluwa znacznie więcej niż klucz?
Ktoś zamiast zmiennej opisującej długość klucza publicznego wsadził 65535 tworząc stałą wartość?
Toż to praktycznie drobiazg brzemienny w skutki, który w kodzie dosyć ciężko zauważyć.
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)
Offline
#20 2014-04-11 01:13:42
uzytkownikubunt - Zbanowany
- uzytkownikubunt
- Zbanowany
- Zarejestrowany: 2012-04-25
Re: Dziura w openssl
@Jacekalex tutaj jest wszystko opisane:
http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html/ <- serwer pokazuje błąd, ale cache Google'a ciągle trzyma stronę
http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf
Zabezpieczenia grsecurity czy w OpenBSD powinny bez problemu wyłapać błąd w normalnym kodzie C, tylko autorzy OpenSSL zdecydowali się na stworzenie własnych niestandardowych funkcji do zarządzania pamięcią...
http://article.gmane.org/gmane.os.openbsd.misc/211963
Offline
#21 2014-04-11 01:19:46
menel - Użytkownik
- menel
- Użytkownik
- Zarejestrowany: 2013-11-02
Re: Dziura w openssl
tylko autorzy OpenSSL zdecydowali się na stworzenie własnych niestandardowych funkcji do zarządzania pamięcią...[/quote]
Ty w to wierzysz? serio?
Zdecydowali się na stworzenie furtki to tak...
W życiu nie uwierzę, że to był przypadek i zwykły błąd, przeoczenie czy jak to zwał...Takie samo gówno jak swojego czasu backdoor w obsd..Dostali hajsy i zrobili swoje...każdego można kupić...trzeba tylko znać cenę i rodzaj waluty..
dla przypomnienia
http://niebezpiecznik.pl/post/fbi-odpowiedzialne-za-backdoor-w-stosie-ipsec-openbsd/Ostatnio edytowany przez menel (2014-04-11 01:35:40)
Offline
#22 2014-04-11 01:42:03
Jacekalex - Podobno człowiek...;)
- Jacekalex
- Podobno człowiek...;)
- Skąd: /dev/urandom
- Zarejestrowany: 2008-01-07
Re: Dziura w openssl
[quote=uzytkownikubunt]@Jacekalex tutaj jest wszystko opisane:
http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html/ <- serwer pokazuje błąd, ale cache Google'a ciągle trzyma stronę
http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf
Zabezpieczenia grsecurity czy w OpenBSD powinny bez problemu wyłapać błąd w normalnym kodzie C, tylko autorzy OpenSSL zdecydowali się na stworzenie własnych niestandardowych funkcji do zarządzania pamięcią...
http://article.gmane.org/gmane.os.openbsd.misc/211963[/quote]
Bzdury piszesz.
Grsecurity, a zwłaszcza zawarty w nim PAX dodaje solidnych mechanizmów obronnych, jak Mprotect czy Randustack, ale nie ingeruje w samo działanie aplikacji, jeśli aplikacja pod kontrolą wykonuje swoją robotę, to Grsec/Pax nie widzi nic groźnego.
Wszystkie zabezpieczenia typu Grsec/pax dotyczą działania exploitów atakujących aplikacje w przestrzeni pamięci RAM, ale nie ubezpiecza na wypadek celowego czy przypadkowego błędu w działaniu aplikacji, jak w przypadku biblioteki OpenSSL.
Takie rzeczy w przypadku OpenSSH i tuneli VPN potrafi wykrywać Snort przy pomocy specjalnych dekoderów, sprawdzających, jaka ilość danych nieszyfrowanych poprzedza nawiązanie szyfrowanego połączenia.
Natomiast twierdzenie, że większość "dużych" serwerów chroni Grsec, czy jest tam OpenBSD, to ciężka naiwność, raczej mega pro systemy korporacyjne jak RHEL czy SUSE, gdzie takie ekstremalne zabezpieczenia "nie są potrzebne".
Tutaj nawet nie było senso-stricte backdoora, pozornie OpenSSL działał prawidłowo, tylko zamiast klucza publicznego wysyłał nieszyfrowanym strumieniem 65535 bitów danych, zawierających również klucz prywatny serwera.
Z punktu widzenia modułu Grsec czy systemu ACL to nie był błąd, tylko FEATURE aplikacji.
Fajnie byłoby wiedzieć, skąd w OpenSSL się taki FEATURE znalazł,
ale jak wiadomo, różne Mukhbaraty mają długie ręce.
To mogło być FBI czy NSA (amerykańskie), rosyjskie FSB, Chińczycy, albo ktokolwiek inny.
Ostatnio edytowany przez Jacekalex (2014-04-11 02:14:49)
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)
Offline
#23 2014-04-11 09:30:55
uzytkownikubunt - Zbanowany
- uzytkownikubunt
- Zbanowany
- Zarejestrowany: 2012-04-25
Re: Dziura w openssl
[quote=Jacekalex][quote=uzytkownikubunt]@Jacekalex tutaj jest wszystko opisane:
http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html/ <- serwer pokazuje błąd, ale cache Google'a ciągle trzyma stronę
http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf
Zabezpieczenia grsecurity czy w OpenBSD powinny bez problemu wyłapać błąd w normalnym kodzie C, tylko autorzy OpenSSL zdecydowali się na stworzenie własnych niestandardowych funkcji do zarządzania pamięcią...
http://article.gmane.org/gmane.os.openbsd.misc/211963[/quote]
Bzdury piszesz.
Grsecurity, a zwłaszcza zawarty w nim PAX dodaje solidnych mechanizmów obronnych, jak Mprotect czy Randustack, ale nie ingeruje w samo działanie aplikacji, jeśli aplikacja pod kontrolą wykonuje swoją robotę, to Grsec/Pax nie widzi nic groźnego.
Wszystkie zabezpieczenia typu Grsec/pax dotyczą działania exploitów atakujących aplikacje w przestrzeni pamięci RAM, ale nie ubezpiecza na wypadek celowego czy przypadkowego błędu w działaniu aplikacji, jak w przypadku biblioteki OpenSSL.
Takie rzeczy w przypadku OpenSSH i tuneli VPN potrafi wykrywać Snort przy pomocy specjalnych dekoderów, sprawdzających, jaka ilość danych nieszyfrowanych poprzedza nawiązanie szyfrowanego połączenia.
Natomiast twierdzenie, że większość "dużych" serwerów chroni Grsec, czy jest tam OpenBSD, to ciężka naiwność, raczej mega pro systemy korporacyjne jak RHEL czy SUSE, gdzie takie ekstremalne zabezpieczenia "nie są potrzebne".
Tutaj nawet nie było senso-stricte backdoora, pozornie OpenSSL działał prawidłowo, tylko zamiast klucza publicznego wysyłał nieszyfrowanym strumieniem 65535 bitów danych, zawierających również klucz prywatny serwera.
Z punktu widzenia modułu Grsec czy systemu ACL to nie był błąd, tylko FEATURE aplikacji.
Fajnie byłoby wiedzieć, skąd w OpenSSL się taki FEATURE znalazł,
ale jak wiadomo, różne Mukhbaraty mają długie ręce.
To mogło być FBI czy NSA (amerykańskie), rosyjskie FSB, Chińczycy, albo ktokolwiek inny.[/quote]
A mógłbyś przeczytać to, co zalinkowałem?
[quote=Theo de Raadt ]So years ago we added exploit mitigations counter measures to libc
malloc and mmap, so that a variety of bugs can be exposed. [u]Such
memory accesses will cause an immediate crash, or even a core dump,
then the bug can be analyed, and fixed forever.[/u]
Some other debugging toolkits get them too. To a large extent these
come with almost no performance cost.
But around that time OpenSSL adds a wrapper around malloc & free so
that the library will cache memory on it's own, and not free it to the
protective malloc.[/quote]
Offline
#24 2014-04-11 09:44:37
Jacekalex - Podobno człowiek...;)
- Jacekalex
- Podobno człowiek...;)
- Skąd: /dev/urandom
- Zarejestrowany: 2008-01-07
Re: Dziura w openssl
Przeczytałem, inna sprawa, czy w to wierzę.
Identyczny błąd może się powtórzyć np w SSH czy jakimś VPNie, może też w samej bibliotece OpenSSL wyleźć w innym miejscu, inaczej "zaimplementowaną" metodą.
Jak zajrzysz do reguł Snorta przeznaczonych do kontrolowania protokołu SSH, to tam zauważysz inspekcję liczby nieszyfrowanych danych wysyłanych przez serwer SSH przed rozpoczęciem szyfrowania transmisji.
To praktycznie jedyna metoda, aby w przyszłości tak pilnować, czy SSL nie wysyła więcej nieszyfrowanych danych, niż powinno.
Nawiasem pisząc, GnuTLS też ciągle łapie mniejsze lub większe wtopy z bezpieczeństwem, jak ostatnio z tą [url=http://dug.net.pl/news/574/]walidacją certyfikatu[/url].
Ostatnio edytowany przez Jacekalex (2014-04-11 09:45:24)
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)
Offline
#25 2014-04-11 10:14:36
bobycob - Członek z Ramienia
- bobycob
- Członek z Ramienia
- Skąd: Wrocław
- Zarejestrowany: 2007-08-15
Re: Dziura w openssl
Jacek, BGP wspiera używanie haseł do autoryzacji, ale w praktyce nie jest często używane nawet w dużych (polskich) punktach wymiany ruchu. Są to najczęściej połączenia p2p między routerami do których dostęp mają tylko administratorzy danych routerów. Przy czym standardem jest odpowiednie filtrowanie tras rozgłaszanych na konkretnych połączeń. Czyli nie rozgłosisz nic ponad to co zadeklarowałeś i do tego pokrywa się z danymi w RIPE.
Więc autoryzacja jako taka nie ma tu większego znaczenia.
[edit]
The Great Firewall jak podejrzewam interesujące służby adresy rozgłasza jako własne. W sytuacji gdy operatorzy z którymi łączą się chinole nie zadbali odpowiednie filtry, może z powodu ich rozmiaru, a skośnooki admin pomylił się w konfiguracji. W konsekwencji te routery dla których to połączenie było najbliższe przełączyły ruch na TGF. Więc nie demonizuj incydentu z Chińskim BGP boś nie onet :). Czesi przypadkiem parę lat temu podobny numer zrobili.
[url]http://www.szkoleniabgp.pl/ciekawostki/zle-skonfigurowany-router-wplynal-na-dzialanie-czesci-internetu/[/url]
Ostatnio edytowany przez bobycob (2014-04-11 10:39:02)
Offline
Informacje debugowania
| Time (s) | Query |
|---|---|
| 0.00018 | SET CHARSET latin2 |
| 0.00006 | SET NAMES latin2 |
| 0.00103 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='18.118.0.48' WHERE u.id=1 |
| 0.00207 | REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '18.118.0.48', 1732507833) |
| 0.00055 | SELECT * FROM punbb_online WHERE logged<1732507533 |
| 0.00060 | DELETE FROM punbb_online WHERE ident='18.188.119.67' |
| 0.00065 | DELETE FROM punbb_online WHERE ident='3.145.8.2' |
| 0.00048 | SELECT topic_id FROM punbb_posts WHERE id=262951 |
| 0.00006 | SELECT id FROM punbb_posts WHERE topic_id=25583 ORDER BY posted |
| 0.00032 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=25583 AND t.moved_to IS NULL |
| 0.00027 | SELECT search_for, replace_with FROM punbb_censoring |
| 0.00266 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=25583 ORDER BY p.id LIMIT 0,25 |
| 0.00088 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=25583 |
| Total query time: 0.00981 s | |