Jump to content

Renoirdaniel

Administrators
  • Posts

    1,484
  • Joined

  • Days Won

    3

Posts posted by Renoirdaniel

  1. Mam bardzo wielki problem związany z komputerem a dokładniej z aplikacjami i grami szczególnie. Więc tak niemogę zainstalować nowszych gier i programów gdyż wyświetla mi się okienko:

     

    Nieobsłogiwany wyjątek

    Błąd numer: 0x80040706

    Opis: Referencja do obiektu nie została ustawiona

     

    Rady w stylu:

    Możesz usunąć katalog C:\Program Files\Common Files\InstallShield i wtedy próbować

     

    albo

     

    http://consumer.installshield.com/kb.asp?id=Q110641

     

    nie pomogły ;)

     

    kto pomoże adminowi ;) :D

  2. Użycie zatruwania DNS do walki z piractwem. Organizacja antypiracka GEMA zażądała od 42 niemieckich dostawców usług internetowych 'zatrucia' serwerów DNS, tak, by ich klienci nie mogli korzystać ze stron udostępniających odnośniki do nielegalnych plików, dostępnych w sieci eDonkey. Od firm, które nie wywiążą się z tego obowiązku, GEMA będzie domagała się nawet 100 tys. euro odszkodowania.
  3. DNS cache poisoning (zatruwanie bufora cache DNS) stało się w ostatnim czasie bardzo popularne. Co umożliwia ta technika? Rozważmy pewna hipotetyczna sytuacje:

    Pan X chce wejść na stronę swojego banku aby dokonać przelewu. W tym celu musi wejść na stronę np.: www.bank.pl. 2 min przed nim pewien pan Y wykonał pewna sztuczkę. Wysłał do serwera DNS, z którego także korzysta pan X zapytanie o adres IP domeny bank.pl -> serwer DNS wysłał zapytanie do jednego z głównych serwerów i oczekuje na odpowiedz. Zanim jednak ja otrzyma pan Y wysyła do tego serwera DNS spreparowana odpowiedz o adres bank.pl -> podając przy tym adres IP swojego własnego komputera. Wcześniej pan Y przygotował stronę wyglądającą zupełnie tak jak strona bank.pl i umieścił ja na swoim komputerze. Serwer DNS akceptuje ta odpowiedz i wysyła panu Y odpowiedz, ze adresem bank.pl jest adres jego własnego komputera. Pana Y bardzo to ucieszyło, ponieważ było to tym co chciał. Serwer DNS w celu przyspieszenia wyszukiwania dodał taki wpis do swojej pamięci bufora. W tej chwili według serwera DNS adresem bank.pl jest adres komputera pana Y. Kiedy nadeszła poprawna odpowiedz na zapytanie które wysłał serwer DNS, została ona zignorowana ponieważ informacja o tym znajdowała się juz w pamięci. Pan X otwiera przeglądarkę i wpisuje adres www.bank.pl. Jego komputer wysyła zapytanie do serwera DNS o adres bank.pl. Niestety serwer utrzymuje w pamięci cache odpowiedz, której udzielił przed chwila panu Y (ta sfałszowana). Pan X nieświadomy niczego wchodzi na stronę banku, którą wygląda identycznie jak prawdziwa. Niczego nie podejrzewając wpisuje swój login oraz hasło, które przechwytuje pan Y. Błyskawicznie łączy się z prawdziwym bankiem, wpisuje login i hasło pana X a zleca przelew na swoje konto.

    W przytoczonym powyżej przykładzie pan X padł ofiara ataku zwanego DNS cache poisoning i w zasadzie nie miał nawet najmniejszej szansy aby się przed nim obronić. Wprawdzie pan Y nie miał możliwości spreparowania certyfikatu, którym legitymuje się bank, jednak mógł wstawić inny, fałszywy, o którym poinformowała by przeglądarka u pana X. Jednak większość ludzi widząc ostrzeżenia o tym, ze certyfikat może być sfałszowany nie widzi w tym najmniejszego problemu i klika po prostu "Zaakceptuj" po czym nie widzi żadnego problemu. Sęk w tym, ze problem jest i to jest bardzo poważny. Wymieniony wyżej przykład jest jednym z bardziej czarnych scenariuszy ale ofiara takiego ataku może paść w zasadzie każda domena. Do zadań administratora należy dbałość o to, ażeby takie ataki nie miały miejsca.

     

    Co możemy zrobić jako administratorzy usług DNS ? Po pierwsze używać DJBDNS, który jest zdecydowanie mniej podatny na ataki DNS cache poisoning. Dobrym rozwiązaniem jest wyłączenie zapytań rekurencyjnych i używanie zapytań iteracyjnych. Czym się one różnią ? Otóż model zapytań rekurencyjnych opiera się na tym, iż serwer DNS jeżeli nie zna odpowiedzi na nasze zapytanie sam pyta dalej oraz szuka tej odpowiedzi, po czym ja umieszcza w cache, a wynik zwraca do pytającego. W modelu iteracyjnym jeżeli serwer DNS nie zna odpowiedzi sam nie wysyła innych zapytań, zwraca natomiast pytającemu adres innego serwera DNS, który jego zdaniem będzie w stanie obsłużyć zapytanie. Niezbyt zalecanym choć najbezpieczniejszym rozwiązaniem jest wyłączenie pamięci cache serwera nazw, jednak na pewno spowoduje to opóźnienie w działaniu usług korzystających z DNS. Ponownie najlepszym rozwiązaniem o którym juz wcześniej wspominałem jest użycie DNSSEC.

     

    Zabezpieczenie się przed atakami DNS cache poisoning jest najskuteczniejsze wtedy gdy współdziałają ze sobą administratorzy DNS, twórcy WWW oraz sami użytkownicy. O ile metody zabezpieczenia się adminów DNS opisałem powyżej o tyle twórcy WWW i użytkownicy dysponują mniejszym orężem w walce z tym procederem. Twórcy WWW mogą zastosować SSL do uwierzytelniania ich stron, aczkolwiek jest to możliwe do obejścia poprzez technikę zwana IDN. Najlepszym wyjściem byłoby gdyby użytkownicy nie używali nazw domenowych, a adresów IP jednak z racji tego iż jest to ekstremalnie niewygodne raczej nie ma na to co liczyć :).

     

    Użycie zatruwania DNS do walki z piractwem. Organizacja antypiracka GEMA zażądała od 42 niemieckich dostawców usług internetowych 'zatrucia' serwerów DNS, tak, by ich klienci nie mogli korzystać ze stron udostępniających odnośniki do nielegalnych plików, dostępnych w sieci eDonkey. Od firm, które nie wywiążą się z tego obowiązku, GEMA będzie domagała się nawet 100 tys. euro odszkodowania.

  4. DNS cache poisoning (zatruwanie bufora cache DNS) stało się w ostatnim czasie bardzo popularne. Co umożliwia ta technika? Rozważmy pewna hipotetyczna sytuacje:

    Pan X chce wejść na stronę swojego banku aby dokonać przelewu. W tym celu musi wejść na stronę np.: http://www.bank.pl. 2 min przed nim pewien pan Y wykonał pewna sztuczkę. Wysłał do serwera DNS, z którego także korzysta pan X zapytanie o adres IP domeny bank.pl -> serwer DNS wysłał zapytanie do jednego z głównych serwerów i oczekuje na odpowiedz. Zanim jednak ja otrzyma pan Y wysyła do tego serwera DNS spreparowana odpowiedz o adres bank.pl -> podając przy tym adres IP swojego własnego komputera. Wcześniej pan Y przygotował stronę wyglądającą zupełnie tak jak strona bank.pl i umieścił ja na swoim komputerze. Serwer DNS akceptuje ta odpowiedz i wysyła panu Y odpowiedz, ze adresem bank.pl jest adres jego własnego komputera. Pana Y bardzo to ucieszyło, ponieważ było to tym co chciał. Serwer DNS w celu przyspieszenia wyszukiwania dodał taki wpis do swojej pamięci bufora. W tej chwili według serwera DNS adresem bank.pl jest adres komputera pana Y. Kiedy nadeszła poprawna odpowiedz na zapytanie które wysłał serwer DNS, została ona zignorowana ponieważ informacja o tym znajdowała się juz w pamięci. Pan X otwiera przeglądarkę i wpisuje adres http://www.bank.pl. Jego komputer wysyła zapytanie do serwera DNS o adres bank.pl. Niestety serwer utrzymuje w pamięci cache odpowiedz, której udzielił przed chwila panu Y (ta sfałszowana). Pan X nieświadomy niczego wchodzi na stronę banku, którą wygląda identycznie jak prawdziwa. Niczego nie podejrzewając wpisuje swój login oraz hasło, które przechwytuje pan Y. Błyskawicznie łączy się z prawdziwym bankiem, wpisuje login i hasło pana X a zleca przelew na swoje konto.

    W przytoczonym powyżej przykładzie pan X padł ofiara ataku zwanego DNS cache poisoning i w zasadzie nie miał nawet najmniejszej szansy aby się przed nim obronić. Wprawdzie pan Y nie miał możliwości spreparowania certyfikatu, którym legitymuje się bank, jednak mógł wstawić inny, fałszywy, o którym poinformowała by przeglądarka u pana X. Jednak większość ludzi widząc ostrzeżenia o tym, ze certyfikat może być sfałszowany nie widzi w tym najmniejszego problemu i klika po prostu "Zaakceptuj" po czym nie widzi żadnego problemu. Sęk w tym, ze problem jest i to jest bardzo poważny. Wymieniony wyżej przykład jest jednym z bardziej czarnych scenariuszy ale ofiara takiego ataku może paść w zasadzie każda domena. Do zadań administratora należy dbałość o to, ażeby takie ataki nie miały miejsca.

     

    Co możemy zrobić jako administratorzy usług DNS ? Po pierwsze używać DJBDNS, który jest zdecydowanie mniej podatny na ataki DNS cache poisoning. Dobrym rozwiązaniem jest wyłączenie zapytań rekurencyjnych i używanie zapytań iteracyjnych. Czym się one różnią ? Otóż model zapytań rekurencyjnych opiera się na tym, iż serwer DNS jeżeli nie zna odpowiedzi na nasze zapytanie sam pyta dalej oraz szuka tej odpowiedzi, po czym ja umieszcza w cache, a wynik zwraca do pytającego. W modelu iteracyjnym jeżeli serwer DNS nie zna odpowiedzi sam nie wysyła innych zapytań, zwraca natomiast pytającemu adres innego serwera DNS, który jego zdaniem będzie w stanie obsłużyć zapytanie. Niezbyt zalecanym choć najbezpieczniejszym rozwiązaniem jest wyłączenie pamięci cache serwera nazw, jednak na pewno spowoduje to opóźnienie w działaniu usług korzystających z DNS. Ponownie najlepszym rozwiązaniem o którym juz wcześniej wspominałem jest użycie DNSSEC.

     

    Zabezpieczenie się przed atakami DNS cache poisoning jest najskuteczniejsze wtedy gdy współdziałają ze sobą administratorzy DNS, twórcy WWW oraz sami użytkownicy. O ile metody zabezpieczenia się adminów DNS opisałem powyżej o tyle twórcy WWW i użytkownicy dysponują mniejszym orężem w walce z tym procederem. Twórcy WWW mogą zastosować SSL do uwierzytelniania ich stron, aczkolwiek jest to możliwe do obejścia poprzez technikę zwana IDN. Najlepszym wyjściem byłoby gdyby użytkownicy nie używali nazw domenowych, a adresów IP jednak z racji tego iż jest to ekstremalnie niewygodne raczej nie ma na to co liczyć :).

     

    Użycie zatruwania DNS do walki z piractwem. Organizacja antypiracka GEMA zażądała od 42 niemieckich dostawców usług internetowych 'zatrucia' serwerów DNS, tak, by ich klienci nie mogli korzystać ze stron udostępniających odnośniki do nielegalnych plików, dostępnych w sieci eDonkey. Od firm, które nie wywiążą się z tego obowiązku, GEMA będzie domagała się nawet 100 tys. euro odszkodowania.

  5. hehe z tego co widze to dzieki temu sign profit mamy zalew obcokrajowcow na forum :D

     

    i to dosyć spore, jak sie zdenerwuję to zacznę banować :o

     

     

    btw:

    Account verification link has been sent to Your e-mail address (XXXX@XXXX). Please check the box and click it.

     

    z tego co widzę zaczęto także robić weryfikacje kont, szkoda tylko ze narazie mi na interie nie dochodzi ten mail :confused:

  6. oprocz wlasciciela zmieniaja sie takze zasady, jak np:

     

    Widze zmianę w poziomach poleconych.

     

    Poprzednio:

     

    * 1 poziom - 10%

    * 2 poziom - 5%

    * 3 poziom - 3%

    * 4 poziom - 2%

     

    Obecnie:

     

    * 1 poziom - 15%

    * 2 poziom - 10%

    * 3 poziom - 5%

    * 4 poziom - 2%

     

     

    Czy aby to dobra decyzja? Dosyc spore % za polecoych jak na system z niskim (5zl) minimu. Cos mi sie zdaje ze poprostu nowy WM szaleje - nie biorąc pod uwagę daleko idących temu konsekwencji... a może ma poprostu swój sposób na dokładanie do biznesu ;)

×
×
  • Create New...

Important Information

Terms of Use