-
31. Data: 2011-01-21 12:17:39
Temat: Re: Polityka bezpieczeństwa PWR PLIX vs niezawodność i wygoda.
Od: Ziolko <z...@i...pl>
W dniu 2011-01-21 12:44, Tomasz Śląski pisze:
> nastach wrote:
>
>> Najgorzej jak ten co robi 10Mbps ma większe wymagania niż ten co co
>> robi 20Gbps ...
>
> Ale to jest pewna prawidłowość zwana Pareto - 20% klientów generuje 80%
> problemów.
> ;-)
>
ale za to 20% klientów generuje 80% zysku
to w sumie sie wyrównuje ;-)
-
32. Data: 2011-01-21 12:40:23
Temat: Re: Polityka bezpieczeństwa PWR PLIX vs niezawodność i wygoda.
Od: Verox <a...@b...veroxsystems.com>
On Fri, 21 Jan 2011 13:17:39 +0100, Ziolko napisał:
> W dniu 2011-01-21 12:44, Tomasz Śląski pisze:
>> nastach wrote:
>>
>>> Najgorzej jak ten co robi 10Mbps ma większe wymagania niż ten co co
>>> robi 20Gbps ...
>>
>> Ale to jest pewna prawidłowość zwana Pareto - 20% klientów generuje 80%
>> problemów.
>> ;-)
>>
> ale za to 20% klientów generuje 80% zysku
>
> to w sumie sie wyrównuje ;-)
Tyle że to nie Ci sami ;-)
Generalnie, cytując klasyka: "klient w krawacie jest mniej awanturującym się"
--
#begin 755 signature.exe
[tomek <at> sikornik <dot> net] vy 73! de SP9UOB
Proud to be 100 percent microsoft free. op. Tomek
-
33. Data: 2011-01-21 13:10:39
Temat: Re: Polityka bezpieczeństwa PWR PLIX vs niezawodność i wygoda.
Od: "Maciej Bebenek (news.onet.pl)" <m...@t...one.pl>
W dniu 2011-01-21 13:17, Ziolko pisze:
>> Ale to jest pewna prawidłowość zwana Pareto - 20% klientów generuje 80%
>> problemów.
>> ;-)
>>
> ale za to 20% klientów generuje 80% zysku
>
> to w sumie sie wyrównuje ;-)
Oba zbiory są rozłączne.
-
34. Data: 2011-01-21 14:20:32
Temat: Re: Polityka bezpieczeństwa PWR PLIX vs niezawodność i wygoda.
Od: "Zboj" <z...@m...dot.pl>
> I poważnie. Zamiast demagogii, że to może wywalić "kawał polskiego
> Internetu", chciałbym przeczytać - w jaki sposób.
I jak to zazwyczaj bywa - postawienie konkretnego pytania zwyczajowo zamyka
dyskusje demagogów.
--
---
Zboj (Piotr Marciniak)
zboj \at/ mnc.pl
-
35. Data: 2011-01-21 14:55:04
Temat: Re: Polityka bezpieczeństwa PWR PLIX vs niezawodność i wygoda.
Od: obeer <s...@g...com>
On Jan 20, 6:56 pm, "Zboj" <z...@m...dot.pl> wrote:
> Mimo wyg oszonej tutaj deklaracji o otwarto ci - PLIX ma swoje maniery i
> priorytety. Czasem nawet nie maskowane regulaminem, a zwyk ym - nie, bo nie.
Bardzo lubię takie wypowiedzi - to tak jak w PiSie - rzucasz tekst,
sam tylko wiedząc o co w nim chodzi.
Pewnie też masz swoją prawdę i ona jest najTwojsza :P
> Ale merytorycznie - niezale nie od oceny rozwi zania z VRRP - wariant 2
> sesji BGP na porcie do 1 odbiorcy, kt ry spe ni by i Twoj propozycj i
> pewnie w jakim sensie oczekiwania Rafa a, wymaga by akceptacji 2 IP i 2 MAC
> na porcie. Trudno mi sobie wyt umaczy , czym 2 pary mac-ip naruszaj
> bezpiecze stwo wzgl dem 1 pary.
Przykro mi to czytać, jeżeli nie wiesz co mogą zrobić 2 mac-addressy w
sieci L2 wpięte na jednym porcie, to zastanawiam się co robisz w swoim
biznesie.
Nigdy nie zdarzyło Ci się, żeby klienci mając na końcu switcha
zapinali sobie dwa kabelki jeden w drugi i robili pętle?
http://www.mnc.pl/aktualnosci/regulamin/
§ 5, pkt. 9
Administrator zablokuje publiczne IP w przypadku wystąpienia
zagrożenia sieci związanego z przyznanym publicznym IP, w
szczególności w przypadku: a. udokumentowanych prób włamań na
komputery w sieci MNC lub w Internecie lub podobnej działalności, np.
skanowania sieci i innych działań mogących stanowić przygotowanie do
włamania;
odnotowania rozpowszechniania z danego IP sprzecznej z prawem treści,
w tym spamu, nielegalnego oprogramowania, itp;
udostępniania w oparciu o przyznane IP zasobów innych komputerów i
urządzeń sieci MNC, które nie posiadają własnych adresów publicznych;
stwierdzenia braku zabezpieczeń komputera, o których mowa w pkt. 4;
odnotowania uporczywych prób włamań z Internetu na przyznany
Abonentowi adres publiczny;
odnotowania faktu blokady klas adresowych sieci MNC na serwerach
wewnętrznych w oparciu o działania danego Abonenta w sieci;
innych działań naruszających bezpieczeństwo Abonentów, sieci lub normy
prawne.
W podanych wyżej sytuacjach, Administrator może odmówić odblokowania
lub powtórnego przyznania publicznego IP danemu Abonentowi.
> Takie 2 pary s wi c bardzo dalekie od dramatycznej
> retoryki Sylwka o wpuszczaniu wszystkiego i braku filtr w na cokolwiek. No
> ale dramatyzm o wiadczenia, zaklinanie si na bezpiecze stwo i eskalacja
> potencjalnych problem w, pozwalaj na uduszenie przeciwnika i jego
> argumentacji.
Piotrze, ty chyba żyjesz w innym świecie niż reszta ludzi. Uważasz, że
wszyscy chcą robić Ci na złość?
Rozumiem, że chcesz na siłę pokazać, że ktoś Ci broni takiego
rozwiązania jakiego byś sobie życzył?
to ja też pozwolę sobie pomarzyć:
W .pl można przekroczyć prędkość o 10km/h, w .se tylko o 1km/h i za to
oberwać mandat.
Co za paskudni Szwedzi, że tak chcą karać. Ja bym chciał, żeby dało
się podróżować autostradami bez limitu.
Kompletnie rpzy tym nie pr buj c wyja ni , co dok adnie np. 2
> pary ip-mac na porcie mog nabroi , e nale y ich tak kategorycznie zakaza .
> Wedle mojej skromnej wiedzy "nie popartej sesjami z 20 IXami" - ryzyko jest
> dok adnie takie samo, jak przy 1 parze ip-mac. Oczywi cie pod warunkiem
> zachowania dok adnie takiej samej konfiguracji bezpiecze twa w zakresie
> innych filtr w.
A wg nas ryzyko jest dużo wyższe, przy 1 macu możemy je praktycznie
wykluczyć.
Jeśli klient wepnie się 2 portami i będzie miał po 1 różnym
macaddressie na każdym, to w przypadku wykrycia pętli switch zablokuje
jego port lub zdropuje ruch z danego portu.
W przypadku gdy mamy 2 macaddressy na jednym porcie, wykrycie pętli i
zablokowanie ruchu z niego jest dużo trudniejsze.
Masz rację co do jednego: robimy to dla naszej wygody i upieramy się,
że nasze rozwiązanie jest bezpieczne.
Mamy do tego prawo, tak samo jak Ty do krytykowania tego podejścia.
I nie raz zmieniamy nasze podejście do różnych spraw, aby być bardziej
użyteczni dla naszych uczestników.
Pewnie i to podejście się kiedyś zmieni (tylko krowa nie zmienia
zdania), ale na razie ze względów technicznych i przyjętej polityki
bezpieczeństwa stosujemy się do tego co krytykujesz.
Zastanów się, proszę, czy gdybyś był na naszym miejscu, to byś tak
łatwo i beztrosko pozwalał wszystkim na robienie czego sobie chcą.
Pewnie może i kiedyś tak było u Ciebie, u nas kiedyś również. Jednakże
życie nauczyło nas tego, że musimy dbać o dobro naszych uczestników, a
większość operatorów chce takiej polityki ze względu na swoje
bezpieczeństwo.
Sylwester
-
36. Data: 2011-01-21 17:12:38
Temat: Re: Polityka bezpieczeństwa PWR PLIX vs niezawodność i wygoda.
Od: "Zboj" <z...@m...dot.pl>
>> Mimo wyg oszonej tutaj deklaracji o otwarto ci - PLIX ma swoje maniery i
>> priorytety. Czasem nawet nie maskowane regulaminem, a zwyk ym - nie, bo
>> nie.
>Bardzo lubię takie wypowiedzi - to tak jak w PiSie - rzucasz tekst,
sam tylko wiedząc o co w nim chodzi.
>Pewnie też masz swoją prawdę i ona jest najTwojsza :P
Nawzajem... Przy czym w tym wypadku dokładnie obaj wiemy, o czym piszę. +
jakichś 150 operatorów. Ale to OT w tym wątku.
> Przykro mi to czytać, jeżeli nie wiesz co mogą zrobić 2 mac-addressy w
sieci L2 wpięte na jednym porcie, to zastanawiam się co robisz w swoim
biznesie.
Zastanów się może lepiej, jak dobrze uzasadnić Twoje zastrzeżenie. Pomijam
edukację mojej ciemnej osoby. Chodzi raczej o techniczne uzasadnienie Twojej
tezy, którego ciągle skąpisz.
>Nigdy nie zdarzyło Ci się, żeby klienci mając na końcu switcha
zapinali sobie dwa kabelki jeden w drugi i robili pętle?
Widziałem sytuacje, w których następiło zwarcie TX z RX w uszkodzonym
switchu, czy kompie 1 usera. Myślisz, że filtry 1 MAC'a cokolwiek pomogły? A
pętle opisane przez Ciebie po prostu downują mi port do usera w switchu
accessowym kompletnie z pominięciem limitów mac/port. Tyle, że w mojej
lokalnej małej sieci mogę wykorzystać np. rstp, stormy i wykrywanie pętli.
Możliwości zależą od sprzętu i softu. Oraz oczywiście od polityki styków z
innymi operatorami. Masz inną perspektywę na pewno. Choć jeśli zapinam np.
odbiorcę biznesowego z jego siecią, routerami itd, to w pewnym sensie mam
podobne do PLIXowych problemy - bo są to dla mnie obce sieci.
> http://www.mnc.pl/aktualnosci/regulamin/
Mój stary regulamin dla userów domowych znam. Co to wnosi do naszej
dyskusji? Że mogę odłączyć abusera? Każdy może. Niezależnie od filtrów.
> Piotrze, ty chyba żyjesz w innym świecie niż reszta ludzi. Uważasz, że
wszyscy chcą robić Ci na złość?
>Rozumiem, że chcesz na siłę pokazać, że ktoś Ci broni takiego
rozwiązania jakiego byś sobie życzył?
Na pewno ja sobie życzę? Przecież zapotrzebowanie zgłosiła do PLIX'a firma
Rafała, nie moja. Ja się tylko włączyłem w wątek.
> A wg nas ryzyko jest dużo wyższe, przy 1 macu możemy je praktycznie
wykluczyć.
Ja właśnie proszę o opisanie tej różnicy. Zamiast mi tu klarować ad
personam, że jestem niedouczonym tłukiem - napisz dokładnie proszę dlaczego
w Twojej opinii wzrasta ryzyko tak dramatycznie.
>Jeśli klient wepnie się 2 portami i będzie miał po 1 różnym
macaddressie na każdym, to w przypadku wykrycia pętli switch zablokuje
jego port lub zdropuje ruch z danego portu.
>W przypadku gdy mamy 2 macaddressy na jednym porcie, wykrycie pętli i
zablokowanie ruchu z niego jest dużo trudniejsze.
Dlaczego? Przecież jest sporo mechanizmów wykrywania pętli. I sporo z nich
nie potrzebuje mac'a. A i w niektórych przypadkach masz pętle, ale żadnego
maca - np. w/w problem zwarcia TX i RX.
>Masz rację co do jednego: robimy to dla naszej wygody i upieramy się,
że nasze rozwiązanie jest bezpieczne.
Ponowię - dlaczego?
>Mamy do tego prawo, tak samo jak Ty do krytykowania tego podejścia.
Tego prawa zdajesz się odmawiać.
Dziękuję za odzew, ale na prawdę ciekaw jestem tej dziury w security
powodowanej przez 2 pary IP-MAC zamiast 1 MAC'a. Zgadzam się zdecydowanie,
że brak mi doświadczenia i rozmachu PLIX'a, więc chętnie spróbuję zrozumieć
to, na co się powołujesz. Zupełnie poważnie.
Pozdrawiam,
Piotr
-
37. Data: 2011-01-21 18:57:25
Temat: Re: Polityka bezpieczeństwa PWR PLIX vs niezawodność i wygoda.
Od: obeer <s...@g...com>
On Jan 21, 6:12 pm, "Zboj" <z...@m...dot.pl> wrote:
> > Przykro mi to czytać, jeżeli nie wiesz co mogą zrobić 2 mac-addressy w
>
> sieci L2 wpięte na jednym porcie, to zastanawiam się co robisz w swoim
> biznesie.
>
> Zastanów się może lepiej, jak dobrze uzasadnić Twoje zastrzeżenie. Pomijam
> edukację mojej ciemnej osoby. Chodzi raczej o techniczne uzasadnienie Twojej
> tezy, którego ciągle skąpisz.
Uważam, że nie przeczytałeś dokładnie tego co napisałem.
przypomina mi się cytat z filmu "Job":
"Drogi chłopcze, rozmowa ze mną nie ma sensu, ponieważ jestem
kompletnie głucha".
I tak samo uważam w tym przypadku. Jesteś głuchy na argumenty innych.
Chcesz sobie robić urynanet w swojej sieci, to sobie rób.
Wypracowałeś best practices na swoim sprzęcie - wyobraź sobie, że inni
również.
Ja nie przekonuję Ciebie do tego, że świadczysz złą usługę, bo nie
spełnia moich oczekiwań.
Nie wiem czy jesteś świadom tego, że mechanizmy wykrywania pętli gdy
po drugiej stronie jest sprzęt innego vendora i skonfigurowany przez
kogoś innego nie zawsze działają?
Jeżeli Twój switch (powiedzmy Cisco) wysyła do innego switcha ramkę
BPDU i czeka aż ona wróci i na tej podstawie stwierdza czy jest pętla
czy nie, to ktoś do kogo jesteś wpięty może filtrować BPDU (Cisco z
włączonym BPDU Filter) i je dropować, a i tak pętle zrobi spinając u
siebie 2 porty. Co w takim przypadku? Twój super switch po prostu
ją przepuści.
Logika switcha PLIXowego jest prosta: ten sam mac pojawia się na 2
portach, znaczy pętla, znaczy coś z tym zrób (co - w zależności od
konfiguracji).
Zapewniam Cię, że mamy dużo filtrów na Layer2 w PLIXie (ACLki na
MACki, loop-detection, rate-limity na broadcasty, multicasty,
dropujemy wszystkie ramki inne niż IP i IPv6, wpuszczamy tylko
konkretne EtherTypy i inne cuda robimy jeszcze) na każdym porcie
klienckim, a mimo tego trzymamy się naszej zasady. Jak na razie zasada
się sprawdza, bo nawet w przypadku gdy switch eFUZJI/KIKE/KIXa, które
to KIKE również reprezentujesz jako Członek Komisji Rewizyjnej, robił
niejednokrotnie pętle w PLIXie, to klienci PLIXowi tego nie odczuwali.
I właśnie wszystkim chodzi o to, aby to było zachowane.
Myślę, że dyskusja odeszła już zupełnie od tego o co pytał Sławek
Lipowski. Ustaliliśmy stanowisko PLIXa, wysłuchaliśmy komentarzy.
Proponuję zamknąć ten temat.
Sylwester
ps. RSTP nie służy do wykrywania pętli.
ps.2. Stormy to z reguły są efektem pętli a nie służą do ich
wykrywania, ale może w tym szaleństwie jest metoda ;-P
-
38. Data: 2011-01-21 20:07:18
Temat: Re: Polityka bezpieczeństwa PWR PLIX vs niezawodność i wygoda.
Od: "Pawel Sikora" <n...@n...pl>
"Zboj" <z...@m...dot.pl> napisał w wiadomości
news:ihceqf$31ku$1@news2.ipartners.pl...
> Dziękuję za odzew, ale na prawdę ciekaw jestem tej dziury w security
> powodowanej przez 2 pary IP-MAC zamiast 1 MAC'a.
pary IP-MAC powiadasz ...
To wy uzywacie tuneli GRE zeby sie tranzytowac? A moze NAT-a :)))
> Piotr
P/
-
39. Data: 2011-01-21 22:52:43
Temat: Re: Polityka bezpieczeństwa PWR PLIX vs niezawodność i wygoda.
Od: Przemysław Gubernat <r...@W...r3pc10.pl.na.newsach>
W dniu 2011-01-20 18:56, Zboj pisze:
>> Czemu nie 2 komplety sesji BGP z kazdym z routerow uniknie sie zbednych
>> announce/withdrawn z BGP i braku dostepnosci na czas renegocjacji sesji ?
>
[..]
>
> I poważnie. Zamiast demagogii, że to może wywalić "kawał polskiego
> Internetu", chciałbym przeczytać - w jaki sposób.
Co by daleko nie sięgać... rozgłoszenie spanning tree i nie do końca dobra
konfiguracja portu.
--
[WRC] Biały Scenic 2000 1,9 dTI
CB: Intek M-490 ML 145
+-=-=-=-=-=-=-=- Przemysław Gubernat -=-=-=-=-=-=-=-=-=-=-=-+
| _API Internet_ A. Stolarczyk i P. Gubernat Spółka Jawna |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-=-=-+
-
40. Data: 2011-01-21 23:40:22
Temat: Re: Polityka bezpieczeństwa PWR PLIX vs niezawodność i wygoda.
Od: Łukasz Bromirski <w...@t...hell>
On 2011-01-21 19:57, obeer wrote:
> Uważam, że nie przeczytałeś dokładnie tego co napisałem.
Tak z boku tej dyskusji - na najbliższym PLNOGu zainteresowane IXy będą
mogły przez 1:15h opowiadać w dowolony sposób o swoich osiągnięciach,
budowie, czemu tak a nie inaczej. Pierwszego i drugiego dnia. Duuużo
czasu na udowadnianie czemu X jest lepsze od Y jeśli na to się
zdecydujecie.
Tak jak pisał Andrzej i o czym wie Sylwek - zapraszamy do zgłaszania
się w ramach procesu CfP żeby opowiedzieć, która wersja podejścia jest
bardziej odporna na atak Turbodymomena lub Nieoczekiwane Podłożenie
Bułeczki.
--
"There's no sense in being precise when | Łukasz Bromirski
you don't know what you're talking | jid:l...@j...org
about." John von Neumann | http://lukasz.bromirski.net