Sławek Lipowski <s...@l...org> writes:

> W sensie pestką jest zrobienie DDoSu łącza rzędu 1Gbps, czy mojego
> 768kbps w domu, bo się pogubiłem? :)

Jeden diabel w praktyce.

>> Jasne. BTW: majac zupelnie niedomyslna konfiguracje IPv6 rowniez ktos
>> moze ominac regulki IPv4.
>
> Możesz napisać dokładnie co masz na myśli? Konkretne przykłady?

No... normalnie. Ludzie miewaja takze skonfigurowane IPv6. Wtedy robisz
po prostu ssh na taki adres IPv6, i regulki IPv4 sa ignorowane.

> Jak by nie było, to przecież temat nie tyczy się samego ssh i teza
> zakładająca, że nie trzeba się przejmować możliwością ominięcia
> firewalla, bo ssh jest bezpieczne jest co najmniej lekko nietrafiona.
> :)

Takiej nie stawiam. Po prostu ssh ma sie do tej sprawy dokladnie nijak,
po prostu trzeba "sie przejmowac" mozliwoscia uzyskania dostepu przy
uzyciu innych protokolow niz IPv4, niezaleznie od tego, czy wystawiamy
na swiat ssh czy nie.

>> Zdecydowanie bardziej ufam moim haslom i kluczom niz temu, ze nikt inny
>> nie bedzie w stanie uzyskac "mojego" IP.
>
> Jedno drugiego nie wyklucza. I jedno i drugie można potraktować jako
> kolejna warstwę zwiększającą bezpieczeństwo.

Generalnie jest tak, ze posiadanie zabezpieczenia silnego i duzo
slabszego niczym nie rozni sie od posiadania tylko tego silnego.
Oczywiscie do momentu, w ktorym ktos stwierdzi, ze to silne mozna
np. na jakis czas wylaczyc, bo przeciez jest jeszcze drugie.

>> BTW jak tam ze staloscia IP za granica albo w kafejce np. wifi?
>
> Za granicą - nie wiem, nie dane mi było sprawdzić. W kafejce (pijąc
> kawę, zakładam, że nie chodziło o kawiarenkę internetową :)) wole
> jednak operatora komórkowego niż otwarte darmowe wifi.

Oczywiscie chodzilo o kawiarenke opcjonalnie internetowa, w ktorej mozna
sie napic kawy, i w ktorej mozna podpiac swoja maszynke do sieci przez
np. wifi (nie proponuje korzystania z komputera kafejki). Nie ma zadnej
roznicy w bezpieczenstwie IP od operatora komorkowego oraz z takiej
cafe, tzn. obie sa calkowicie niebezpieczne i wymagaja bezpiecznego
dostepu, np. przez ssh.
--
Krzysztof Halasa

do góry

W dniu 11.08.2010 00:06, Lukasz Trabinski pisze:
> Sławek Lipowski<s...@l...org> wrote:
>
>
>> Możesz rozwinąć temat? Przez osiągalny rozumiesz, że da się nawiązać
>> połączenie TCP z demonem BGP? Nie do końca chyba rozumiem, co dokładnie
>> masz na myśli...
>
> Myśłałem, że się domyslisz... Napisałeś, cytuję:
>
> "Debiany podane poniżej przez ciebie nie wyglądają na Linuksy? Może jestem
> przewrażliwiony, ale dla mnie otwarty dostęp do snmp, czy ssh stanowi jednak
> problem "
>
> No to ja się pytam, czy otwarty port 179 nie stanowi dla ciebie problemu?
>
>

Ponowie pytanie. Co rozumiesz, przez otwarty? Dla mnie otwarty port TCP
to taki, z którym mogę nawiązać połączenie TCP. Nie udało mi się za
bardzo trafić na otwarty dla mnie port TCP 179, poza tymi dostawców, z
którymi mam sesje BGP + moje dla iBGP. Ale muszę przyznać, że nie
przyszło mi do głowy, żeby szukać. Jak by z definicji sesje BGP
konfiguruje się miedzy parą konkretnych adresów IP. Mam wrażenie, że
dalej nie bardzo wiem, co masz na myśli... Możesz opisać konkretny
przykład, który chodzi Ci po głowie?

--
Sławek Lipowski

do góry

Lazy <l...@g...com> writes:

> co do unikania przez blokowanie calego ipv6 to nie zgodze sie z tym ze
> to dobre rozwiazanie bo wiele uslug lokalnie moze uzywac wersji ipv6
> adresow
> i moze przestac dzialac np. lokalny resolver czy inne uslugi w
> wersjach v4 i v6 (pisali o tym w redhatowej bugzilli w 2004 roku)

Przeciwnie, to dobre rozwiazanie. Oczywiscie nie wyklucza to bledow
w sofcie, ale jesli nie uzywamy jakiegos protokolu, to nie powinnismy go
wlaczac. Dotyczy to dokladnie tak samo IPv6, IPX albo innego NetBEUI.

A bledy trzeba zglaszac i poprawiac. Od 2004 r. zestaw bledow zapewne
zmienil sie wielokrotnie.
--
Krzysztof Halasa

do góry

On 11 Sie, 00:28, Krzysztof Halasa <k...@p...waw.pl> wrote:
> Lazy <l...@g...com> writes:
> > co do unikania przez blokowanie calego ipv6 to nie zgodze sie z tym ze
> > to dobre rozwiazanie bo wiele uslug lokalnie moze uzywac wersji ipv6
> > adresow
> > i moze przestac dzialac np. lokalny resolver czy inne uslugi w
> > wersjach v4 i v6 (pisali o tym w redhatowej bugzilli w 2004 roku)
>
> Przeciwnie, to dobre rozwiazanie. Oczywiscie nie wyklucza to bledow
> w sofcie, ale jesli nie uzywamy jakiegos protokolu, to nie powinnismy go
> wlaczac. Dotyczy to dokladnie tak samo IPv6, IPX albo innego NetBEUI.

całkowite zablokowanie ipv6 na firewallu to nie to samo co jego
wylaczanie,
programy dalej beda tworzyc i probowac uzywac socketow ipv6,
a nawet lokalny ruch bedzie przy tej propozycji zablokowany

>
> A bledy trzeba zglaszac i poprawiac. Od 2004 r. zestaw bledow zapewne
> zmienil sie wielokrotnie.

to nie jest blad, ipv6 ma sie autokonfigurowac, a -P INPUT DROP moze
powodowac problemy,
a najlepszym sposobem na nieuzywanie ipv6 jest jego nie ładowanie

--
Lazy

do góry

W dniu 11.08.2010 00:12, Lazy pisze:
> On 10 Sie, 19:16, Sławek Lipowski<s...@l...org> wrote:
>> Temat do przemyślenia i mam nadzieję do rzeczowej dyskusji.
>>
>> http://lipowski.org/sieci-komputerowe/firewall-hacki
ng-atak-na-firewa...
> pamietam ze dosc dawno temu juz czytalem o identycznym pomysle na
> "obejscie" firewalla

Możesz podać jakieś namiary? Zapoznam się z ciekawością.

>>
>> Czy Waszym zdaniem da się przeprowadzić tego typu atak w węzłach PLIX i
>> AC-X? Czy zabezpieczacie się przed opisaną formą ataku posiadając łącze
>> np. od TP, Netii, ATMANa, czy dowolnego innego operatora?
> w samym plix nie dostaniemy całego internetu wiec i tak potrzebna jest
> jakas inna sesja,
> nie rozumiem tez jak to inne lacze mialo by nas zabezpieczyc przed
> nieskonfigurowanym firewallem ipv6,
> chyba ze mialo by to polegac na zrezygnowaniu z plixa ;)

Nie bardzo rozumiem skąd pomysł, że dodatkowe łącze miało by nas przed
tym zabezpieczyć? :)

> przy ipv4 tych otwartych na swiat (przynajmniej u operatorow
> uczestnikow te adresy sa rouowalne) jest rzeczywisc dosc duzo,
> przy sprzetowych rozwiazaniach moze to chyba ulatwic/umozliwic atak
> dos na routing engine, a przy jakims linuxie czy bsd wiele nie
> uzyskamy
>
> (...)
>
> co do unikania przez blokowanie calego ipv6 to nie zgodze sie z tym ze
> to dobre rozwiazanie bo wiele uslug lokalnie moze uzywac wersji ipv6
> adresow
> i moze przestac dzialac np. lokalny resolver czy inne uslugi w
> wersjach v4 i v6 (pisali o tym w redhatowej bugzilli w 2004 roku)

Jasne, troszkę przerysowałem. Faktycznie wycinanie ruchu na lo może
okazać się kiepskim pomysłem, ale to akurat załatwią 2 regułki dodatkowe.

> uwazam tez ze nie powinienes sie obrazac jesli ktos ciebie posadzi o
> spamerstwo, wiadomo promowac sie jakos trzeba, ale nie jest to
> zagadnienie ani nowe, ani szczegolnie niebezpieczne i nie ma sie co
> dziwic ze sie niektórym nie podoba robienie z tego jakiegos odkrycia i
> widza w tym chytry plan
>
> --
> Lazy
>

Nie natrafiłem jakoś do tej pory na nic na ten temat, ale też jakoś
wybitnie oczytany nie jestem, to fakt. Pozwoliłem sobie cos na ten temat
napisać, jeśli temat jest faktycznie ogólnie znany, to może rzeczywiście
niepotrzebnie.

Co do obrażania się... Zawsze miło jest nie być obrażanym. Przyjmuję do
wiadomości Twoją argumentację. Jak widać na przykładzie Twojej
wypowiedzi, da się to też wyjaśnić w kulturalny sposób.

--
Sławek Lipowski

do góry

W dniu 11.08.2010 00:20, Krzysztof Halasa pisze:
> (...)
> No... normalnie. Ludzie miewaja takze skonfigurowane IPv6. Wtedy robisz
> po prostu ssh na taki adres IPv6, i regulki IPv4 sa ignorowane.

Aha ok. Jakoś podświadomie przyjąłem, że masz na myśli omijanie tych
regułek korzystając z IPv4.

>> Jak by nie było, to przecież temat nie tyczy się samego ssh i teza
>> zakładająca, że nie trzeba się przejmować możliwością ominięcia
>> firewalla, bo ssh jest bezpieczne jest co najmniej lekko nietrafiona.
>> :)
>
> Takiej nie stawiam. Po prostu ssh ma sie do tej sprawy dokladnie nijak,
> po prostu trzeba "sie przejmowac" mozliwoscia uzyskania dostepu przy
> uzyciu innych protokolow niz IPv4, niezaleznie od tego, czy wystawiamy
> na swiat ssh czy nie.
> (...)

Dokładnie.

--
Sławek Lipowski

do góry

Dnia 10.08.2010 Marek Kierdelewicz <m...@p...pl> napisał/a:
>>> Te Debiany podane poniżej przez ciebie nie wyglądają na Linuksy? Może
>>> jestem przewrażliwiony, ale dla mnie otwarty dostęp do snmp, czy ssh
>>> stanowi jednak problem.
>
>>No ale czego chcesz wlasciwie od ssh? To jest _secure_ shell, jak
>>wyobrazasz sobie zdalny dostep do maszyny bez otwarcia jakiegos portu?
>
> Brak acl/firewallingu portu 22 kończy się atakiem słownikowym /
> bruteforce z azjatyckich serwerów lub rozsianych po inecie botnetów.

A ktoś normalny trzyma jeszcze ssh na 22?
Przecież to usługa niepubliczna i nie interkonektowa, nie musi stać na 80
czy 25 jak www czy mx.
Skanowanie+bf to wynik skanowania po szerokości, nie 1 hosta na porty.
bf zdalny to _tylko_ hasła default, na reszte nie starczy życia.
Jedyny problem to dziury w implementacjach i zagrożenia z tym zwiazane,
ale firewall na to też poddatny jak sam ssh.

--
"A cóż to za sens kupować samochód, żeby jeździć po asfalcie?
Tam, gdzie jest asfalt, nie ma nic ciekawego, a gdzie jest
coś ciekawego, tam nie ma asfaltu".
Strugaccy - Poniedziałek zaczyna się w sobotę.

do góry

W artykule Marek Kierdelewicz napisał(a):

>>> Te Debiany podane poniżej przez ciebie nie wyglądają na Linuksy? Może
>>> jestem przewrażliwiony, ale dla mnie otwarty dostęp do snmp, czy ssh
>>> stanowi jednak problem.
>
>>No ale czego chcesz wlasciwie od ssh? To jest _secure_ shell, jak
>>wyobrazasz sobie zdalny dostep do maszyny bez otwarcia jakiegos portu?
>
> Brak acl/firewallingu portu 22 kończy się atakiem słownikowym /
> bruteforce z azjatyckich serwerów lub rozsianych po inecie botnetów.

Ano.

> Nawet jeżeli ktoś lubi pamiętać hasła o imponującej trudności i
> zawiłości to i tak zyska megabajty logów do przejrzenia (nieudane
> logowania). Świetna lektura do poduszki dla każdego administratora
> sieci. Niech koledzy z otwartym portem 22 na linuxach się pochwalą ile
> im przyrasta dziennie plik /var/log/messages.

Nie wszyscy mają redhatopodobne zabawki, więc przytoczę przyrost
/var/log/auth.log:

mainsrv:~# grep sshd /var/log/auth.log | wc -l
15
mainsrv:~# head -n 1 /var/log/auth.log
Aug 8 05:54:01 mainsrv CRON[6590]: pam_unix(cron:session): session opened for user
root by (uid=0)
mainsrv:~#

Jak widać z 3 dni mam całe 15 linijek. Ale może dlatego, że korzystam
z fail2ban? Poza tym mamy 21 wiek. Wystarczy logwatch czy inny analogiczny
soft i do przeczytania jest ładny raport, a nie zestaw logów.

> Brak aclowania/firewallingu własnej infrastruktury to
> nieodpowiedzialność.

Jak możesz to firewallujesz i tyle. Nie czepiałbym się zbytnio tych co nie
firewallują. Widocznie mają ku temu powody. Oczywiście pomijając tych co
bez powodu po prostu guzik robią ;)

> Jasne, rozumiem, że większość z nas ma lapka, modem 3g i telefon, który
> czasem zadzwoni. Zawsze jednak istnieją vpny i inne alternatywne
> rozwiązania na bezpieczny dostęp zdalny.

SSH to również bezpieczny dostęp zdalny.

pozdr,
fEnIo

--
,''`. Bartosz Fenski | mailto:f...@d...org | pgp:0x13fefc40 | irc:fEnIo
: :' : 32-050 Skawina - Glowackiego 3/15 - malopolskie v. - Poland
`. `' phone:+48602383548 | proud Debian maintainer and user
`- http://fenski.pl | xmpp:f...@j...org | rlu:172001

do góry

On 11-8-2010 0:42, Lazy wrote:
> to nie jest blad, ipv6 ma sie autokonfigurowac, a -P INPUT DROP moze
> powodowac problemy,
> a najlepszym sposobem na nieuzywanie ipv6 jest jego nie ładowanie

Co pod koniec 2010 roku, kiedy do momentu, gdy w IANA braknie adresów IP
jest około 300 dni, nie jest zbyt rozsądnym pomysłem.

--
Grzegorz Janoszka

do góry

Dnia 10.08.2010 Sławek Lipowski <s...@l...org> napisał/a:
> Wystarczy zostawić otwarty port 22 na świat żeby przekonać się, że będą
> trafiać w niego próby logowania ze świata. Z jakiegoś powodu ludzie
> jednak próbują. Pojawiają się tez kolejne pytania. Czy np. takie
> wystawione na świat ssh nie będzie podatne na DDoS. Czy konfiguracja ssh
> pozwoli na przeprowadzenie ataku słownikowego?

Pomysly powszechnego blokowania SSH porownalbym do radykalizmu obrocow krzyza
na Krakowskim Przedmiesciu. Szczegolnie, ze od ostatniego istotnego bledu
implementacyjnego w OpenSSH minelo prawie 10 lat, a od tego czasu wprowadzono
tez mechanizmy minimalizujace skutki udanego wykonania kodu (PrivSep).

Jesli zas chodzi o VPN, to przestrzegalbym przed hurraoptymizmem.
IPSEC jest bardzo skomplikowanym zestawem protokolow, ktore w dodatku
w duzej mierze sa implementowane przez jadro systemu, a zatem potencjalny
blad implementacyjny niesie za soba duzo wieksze ryzyko niz w przypadku
userlandowego i privsepowanego sshd.

Powyzsza uwaga w mniejszym stopniu tyczy sie userlandowych implementacji
VPN, takich jak OpenVPN. Mimo wszystko jednak, nie stosuja one mechanizmow
separacji uprawnien, a korzystaja z zewnetrznych, niekoniecznie dobrze
przeaudytowanych bibliotek (np. liblzo).

Reasumujac -- z mojego punktu widzenia, bezpieczniej miec wystawione na swiat
SSH, niz korzystac z IPSECa lub innych VPNow.

--
* Fido: 2:480/124 ** WWW: http://www.frasunek.com ** NICHDL: PMF9-RIPE *
* Jabber ID: v...@n...pl ** PGP ID: 2578FCAD ** HAM-RADIO: SQ5JIV *

do góry