Dnia 11.08.2010 Pawel Malachowski <p...@n...niewazne> napisał/a:
> Wg mnie starasz się bronić tezę "argumentami" o hipotetycznym złym zarządzaniu
> stacją przesiadkową.

Mowie o praktyce, ktora wynika z ilustam przeprowadzonych audytow
bezpieczenstwa. Takie rzeczy, mimo ze nie powinny, sie zdarzaja. I niosa
wieksze ryzyko niz wystawione publicznie OpenSSH.

> Równie dobrze mogę nawiązać do pewnej dystrybucji Linuksa i swego czasu
> wątpliwej jakości kluczy SSH na niej generowanych. :)

To byly klucze nie tylko SSH, rowniez SSL dla OpenVPN :)

EOT, bo sie flejm robi.

--
* 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

W dniu 11.08.2010 11:10, Przemyslaw Frasunek pisze:
> Dnia 10.08.2010 Sławek Lipowski<s...@l...org> napisał/a:
>> Do niezabezpieczonej sieci wifi, bez żadnego nakładu sił, środków i
>> trudu, może podłączyć się dowolna osoba. A jak się podłączy, to może
>> rozgłosić nieświadomym jej użytkownikom prefix IPv6. ;)
>
> A co z tego wynika dla bezpieczenstwa SSH?
>

Starałem się powrócić do tematu dyskusji, bo nie o bezpieczeństwie SSH
miała być ta dyskusja.

--
Sławek Lipowski

do góry

W dniu 11.08.2010 11:08, Przemyslaw Frasunek pisze:
> (...)
> 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).
>
> (...)
>

Nie dostrzegam analogii do Krzyża.

Pewnie czasami ssh musi być wystawione i już. Rozumiem. Ale jeśli nie ma
takiej potrzeby i można ograniczyć dostęp do ograniczonej liczby IP, to
dlaczego tego nie robić?

--
Sławek Lipowski

do góry

On 11-8-2010 14:12, Pawel Malachowski wrote:
> Ograniczenie dostępu do TCP/179 tylko dla peerów to oczywista oczywistość.

Jak to chcesz ograniczać? Bo wiele ruterów w internecie, jak dostaje TCP
SYN z adresu, na który nie ma żadnej sesji, to wysyła TCP RST czy tam
inne refused. Więc po co to ograniczać bardziej?

--
Grzegorz Janoszka

do góry

Sławek Lipowski <s...@l...org> wrote:
> 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ą.

Ludzie bezpośrednio nie, to robią przede wszystkim automaty skanujące całe
sieci.

> Pojawiają się tez kolejne pytania. Czy np. takie
> wystawione na świat ssh nie będzie podatne na DDoS.

Jakiego typu DDoS? Bo poza wysyceniem łącza przed wszelkimi innymi
można się trywialnie obronić.

> Czy konfiguracja ssh pozwoli na przeprowadzenie ataku słownikowego?

Rozsądni admini mają zaimplementowaną automatyczną analizę logów
w czasie rzeczywistym, dzięki której atak zostanie odparty na poziomie
sieciowym po 3-4 próbie użycia hasła.

Z drugiej strony: który racjonalny admin używa haseł do usług typu SSH?
Sorry, ale jak ktoś nie używa kluczy/certyfikatów, to powinien przeżyć
na własnej skórze skutki udanego ataku słownikowego.

>> wyobrazasz sobie zdalny dostep do maszyny bez otwarcia jakiegos portu?
>
> Posiadanie zdalnego dostępu do maszyny nie musi sprawiać, że trzeba ten
> port otworzyć od razu na cały świat, prawda? W dobie powszechnego
> mobilnego dostępu do Internetu z możliwością przypisania do takiej
> usługi publicznego IP to naprawdę nie wydaje się być problemem.

Jest port-knocking, z którego można skorzystać z dowolnego systemu
operacyjnego z telnetem/nc/odpowiednikiem i działa naprawdę dobrze
(szczególnie, jeśli numery port(ów) są zależne od daty - co ładnie
ogranicza ataki typu traffic replay).


Poncki
--
Kto misiowi urwał ucho?

do góry

Sergiusz Rozanski <w...@s...com> wrote:
> 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.

Są botnety, które skanują cały zakres portów (po kilka/kilkanaście
z jednego IP), analizują bannery i przekazują informacje do innych
botów, które przeprowadzają już konkretny atak. Inna sprawa, że jest
to na razie mniejszość, chociaż trend jest widoczny. Zmiana portu
to jednak za mało (ale warto to zrobić, a na 22 zostawić honeypota).


Poncki
--
Kto misiowi urwał ucho?

do góry

Sławek Lipowski <s...@l...org> wrote:
> Generalnie odchodzimy od tezy. Teza w dużym uproszczeniu brzmi: mając
> domyślną konfigurację IPv6 na linuksie, ktoś mający z Tobą styk w L2
> może ominąć regułki netfiltera napisane wyłącznie dla IPv4. Naturalne
> wydaje się też, że bardziej podatnym na atak będzie system z otwartym
> ssh, niż ten san system bez wystawionego ssh.

Dotyczy to tylko sshd zabindowanych do *, jeśli masz zabindowane do
konkretnego adresu IPv4, to pojawienie się adresu v6 nie spowoduje,
że ssh zacznie magicznie na nim słuchać.

Poncki
--
Kto misiowi urwał ucho?

do góry

W dniu 11.08.2010 15:43, Tomasz Piłat pisze:
> Sławek Lipowski<s...@l...org> wrote:
>> Generalnie odchodzimy od tezy. Teza w dużym uproszczeniu brzmi: mając
>> domyślną konfigurację IPv6 na linuksie, ktoś mający z Tobą styk w L2
>> może ominąć regułki netfiltera napisane wyłącznie dla IPv4. Naturalne
>> wydaje się też, że bardziej podatnym na atak będzie system z otwartym
>> ssh, niż ten san system bez wystawionego ssh.
>
> Dotyczy to tylko sshd zabindowanych do *, jeśli masz zabindowane do
> konkretnego adresu IPv4, to pojawienie się adresu v6 nie spowoduje,
> że ssh zacznie magicznie na nim słuchać.
>
> Poncki

Zgadza się, nie twierdzę bynajmniej, że jest inaczej. :) Tak właśnie to
opisałem.

--
Sławek Lipowski

do góry

W dniu 11.08.2010 15:27, Tomasz Piłat pisze:
> (...)
> Poncki

Wszystko co piszesz jest ok. Natomiast trzeba pamiętać, że atak może
przeprowadzić także jakiś klient sieci, w której administrator co prawda
skonfigurował jakoś iptables, ale nic więcej w kwestii bezpieczeństwa
nie zrobił. To nie są bynajmniej odosobnione przypadki przecież. To, że
można coś łatwo zrobić nie znaczy bynajmniej, że wszyscy to robią, czy
nawet że wiedzą, że powinni to zrobić.

--
Sławek Lipowski

do góry

Przemysław Gubernat wrote:

> W dniu 2010-08-10 19:16, Sławek Lipowski pisze:
>> Temat do przemyślenia i mam nadzieję do rzeczowej dyskusji.
>>
>> http://lipowski.org/sieci-komputerowe/firewall-hacki
ng-atak-na-firewall-
ipv6/
>>
>> 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?
>>
> Tak BTW ktoś miły w PL-IX'ie "udostępnia" IPv6, a AFAIR w umowie jest to
> zabronione.
>
> [spliter]:~$traceroute6 ftp.ac.pld-linux.org
> traceroute to ftp.agmk.pld-linux.org (2001:6a0:159::120) from
> 2001:7f8:42:0:21b:21ff:fe06:311d, 30 hops max, 16 byte packets
> 1 2001:7f8:42:0:223:7dff:fefb:8165 (2001:7f8:42:0:223:7dff:fefb:8165)
> 34.52
> ms 13.529 ms 14.724 ms
> 2 icm.link1.rs1.ipv6.plix.pl (2001:7f8:42::a500:8664:1) 17.278 ms
> 17.151 ms 28.58 ms
> 3 2001:6a0:1:1::2 (2001:6a0:1:1::2) 14.509 ms 14.673 ms 15.398 ms
> 4 cl-36.waw-01.pl.sixxs.net (2001:6a0:200:23::2) 17.51 ms 17.364 ms
> 15.696 ms
> 5 2001:6a0:159::120 (2001:6a0:159::120) 19.691 ms 18.443 ms 17.43 ms
>
>
Tunel broker projektu SixXS jest w sieci ICM i korzysta z jego adresacji.
Nie jest to więc "udostępnianie" IPv6, a jedynie własnej adresacji.

kuchar@kuchar:~$ whois 2001:6a0:159::120
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.p
df

% Note: This output has been filtered.
% To receive output for a database update, use the "-B" flag.

% Information related to '2001:6a0:159::/48'

inet6num: 2001:6a0:159::/48
netname: SIXXS-NET-AGW2-SIXXS
descr: SixXS assignment to end-user AGW2-SIXXS
descr: This prefix is routed to 2001:6a0:200:23::2
country: PL
admin-c: SIXT1-RIPE
tech-c: SIXT1-RIPE
remarks: rev-srv: ns1.agmk.net.
status: ASSIGNED
remarks: This object was automatically generated by SixXS
remarks: For more details, query whois.sixxs.net for this object
remarks: More information can be found at http://www.sixxs.net/
remarks: Abuse reports should go to a...@s...net
mnt-by: SIXXS-MNT
mnt-lower: SIXXS-MNT
source: RIPE # Filtered

role: Six Access Technical Role Account
address: SixXS
address: Kelvinstraat 63
address: 6716 BV Ede
address: The Netherlands
phone: +31 318 648688
fax-no: +31 318 643334
e-mail: i...@s...net
admin-c: JRM1-RIPE
admin-c: PBVP1-RIPE
tech-c: JRM1-RIPE
tech-c: PBVP1-RIPE


nic-hdl: SIXT1-RIPE


remarks: More information can be found at http://www.sixxs.net/


remarks: Abuse reports should go to a...@s...net


remarks: Other enquiries to i...@s...net


mnt-by: SIXXS-MNT


source: RIPE # Filtered





% Information related to '2001:6a0::/34AS8664'





route6: 2001:6a0::/34


descr: PL-ICM-PUB


origin: AS8664


mnt-by: ICM-PL


source: RIPE # Filtered



--
Marcin Kucharczyk

do góry