Article View: pl.internet.polip
Article #93751Re: Polityka bezpieczeństwa PWR PLIX vs niezawodność i wygoda.
From: obeer
Date: Fri, 21 Jan 2011 14:55
Date: Fri, 21 Jan 2011 14:55
98 lines
6392 bytes
6392 bytes
On Jan 20, 6:56 pm, "Zboj" <zboj_...@mnc.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
Technical Details
Message-ID:
<2343167c-98d1-45d1-80df-b8d9b5b7940e@t23g2000vby.googlegroups.com>Path:
mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.gazeta.pl!newsfeed.pionier.net.pl!news.glorb.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!t23g2000vby.googlegroups.com!not-for-mailReferences:
<ih4abu$25q$1@inews.gazeta.pl> <9f3ad206-ad8e-463d-b704-b11b26962c7d@l24g2000vby.googlegroups.com> <ih6qkc$6rf$1@news2.ipartners.pl> <ih6ulr$p1e$1@news.onet.pl> <760ff2e9-6410-4cfe-9876-740eeb74a418@i18g2000yqn.googlegroups.com> <eacea4c9-eb17-42fc-81f8-395b931fd7ef@o14g2000yqe.googlegroups.com> <91ba10c2-38cd-4705-8717-b9e2a3946c6c@m13g2000yqb.googlegroups.com> <ih7qsa$77h$1@news.tiberium.net.pl> <ih9svo$1oi9$1@news2.ipartners.pl>Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.gazeta.pl!newsfeed.pionier.net.pl!news.glorb.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!t23g2000vby.googlegroups.com!not-for-mail From: obeer <sylwester.biernacki@gmail.com> Newsgroups: pl.internet.polip Subject: Re: Polityka bezpieczeństwa PWR PLIX vs niezawodność i wygoda. Date: Fri, 21 Jan 2011 06:55:04 -0800 (PST) Organization: http://groups.google.com Lines: 115 Message-ID: <2343167c-98d1-45d1-80df-b8d9b5b7940e@t23g2000vby.googlegroups.com> References: <ih4abu$25q$1@inews.gazeta.pl> <9f3ad206-ad8e-463d-b704-b11b26962c7d@l24g2000vby.googlegroups.com> <ih6qkc$6rf$1@news2.ipartners.pl> <ih6ulr$p1e$1@news.onet.pl> <760ff2e9-6410-4cfe-9876-740eeb74a418@i18g2000yqn.googlegroups.com> <eacea4c9-eb17-42fc-81f8-395b931fd7ef@o14g2000yqe.googlegroups.com> <91ba10c2-38cd-4705-8717-b9e2a3946c6c@m13g2000yqb.googlegroups.com> <ih7qsa$77h$1@news.tiberium.net.pl> <ih9svo$1oi9$1@news2.ipartners.pl> NNTP-Posting-Host: 193.22.169.237 Mime-Version: 1.0 X-Trace: posting.google.com 1295621704 23022 127.0.0.1 (21 Jan 2011 14:55:04 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 21 Jan 2011 14:55:04 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: t23g2000vby.googlegroups.com; posting-host=193.22.169.237; posting-account=vSccbgoAAACF54J3--3jB0Yu2dOVqDjG User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; en-us) AppleWebKit/533.19.4 (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4,gzip(gfe) Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit