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?

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

Dnia 10.08.2010 Jacek Politowski <s...@n...istnieje> napisał/a:
> I czym _praktycznie_ różni się taki np. VPN od SSH?
> Poza, potencjalną, niejawnością protokołu?

Gorszym przedaudytowaniem, implementacja czesciowo po stronie jadra,
brakiem separacji uprawnien, a w konsekwencji - wieksza iloscia bledow
implementacyjnych. :)

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

On Aug 11, 9:26 am, Grzegorz Janoszka <Grzeg...@nie-lubie-
spamu.Janoszka.pl> wrote:
> 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.

a co to ma wspolnego ze soba ?
posiadanie nieskonfigurowanego ipv6 nie przyblizy jakos gotowosci do
ipv6

--
Lazy

do góry

Dnia 10.08.2010 Jacek Politowski <s...@n...istnieje> napisał/a:

>> Zawsze jednak istnieją vpny i inne alternatywne
>> rozwiązania na bezpieczny dostęp zdalny.
>
> I czym _praktycznie_ różni się taki np. VPN od SSH?
> Poza, potencjalną, niejawnością protokołu?

Miejscem terminacji ruchu?
Zpsucie RAS-a może być mniej szkodliwe niż zpsucie rutera z ważną sesją.

Jak już klikam, wrzucę kamyczek do całości dyskusji. Oryginalnie przedstawiony
problem widzę tak:
1. SSH na ruterze brzegowym jest przydatne.
2. Publiczne wystawienie tego SSH
- na dziś może szkodzić minimalnie (syf w logach, prowokowanie podwyższonej
konsumpcji
zasobów, która może zagrozić podstawowej roli systemu)
- w przyszłości może zaszkodzić bardziej (jakiś 0 day bug np.)
stwarza więc ryzyko.
3. Mając na uwadze 2., SSH na ruterze brzegowym warto ograniczyć do zaufanych IP
(hosty przesiadkowe).
4. Implementując ograniczenie z p.3. ktoś mnie rozgarnięty może przegapić domyślne
allow na IPv6.
5. Rezygnacja z implementacji ograniczenia z p.3. przy argumentacji, że stykówka i
tak nie jest
rozgłaszana na świat, stwarza kolejne ryzyko, bo wpływ na ew. rozgłoszenie ma
wiele podmiotów
poza nami.

Zatem jawnie zdefinowane ograniczenie dostępu do usługi SSH do wybranych
hostów (o ile to nie shellownia) adresuje ryzyka 2. i 5.

Tak że ruter zdalnego dostępu, przez który uzyskujemy dostęp do sieci
zarządzania i dopiero tamtędy SSH-ujemy się na docelowy system, wydaje
mi się zupełnie koszernym rozwiązaniem. ;)


--
Paweł Małachowski

do góry

Dnia 11.08.2010 Pawel Malachowski <p...@n...niewazne> napisał/a:
> Jak już klikam, wrzucę kamyczek do całości dyskusji. Oryginalnie przedstawiony
problem widzę tak:
[...]

Zasadniczo sie z Toba zgadzam, ale:

> - w przyszłości może zaszkodzić bardziej (jakiś 0 day bug np.)

Ile widziales bledow typu preauth w SSH, od kiedy wprowadzono PrivSep?
Czy nie bardziej sie boisz tego typu bledow w implementacji BGP, czy
remote DoSow w implementacji firewalla?

> 3. Mając na uwadze 2., SSH na ruterze brzegowym warto ograniczyć do zaufanych IP
(hosty przesiadkowe).

Czym? Firewallem, ktory moze byc (i czesto bywal) podatny na remote DoS?
No chyba, ze archaiczne tcpwrappers.

> Tak że ruter zdalnego dostępu, przez który uzyskujemy dostęp do sieci
> zarządzania i dopiero tamtędy SSH-ujemy się na docelowy system, wydaje
> mi się zupełnie koszernym rozwiązaniem. ;)

Z dokladnoscia do bledow w implementacji VPN i ryzyk z tym zwiazanych.

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

Dnia 11.08.2010 Przemyslaw Frasunek <v...@f...lublin.pl> napisał/a:

> Ile widziales bledow typu preauth w SSH, od kiedy wprowadzono PrivSep?
> Czy nie bardziej sie boisz tego typu bledow w implementacji BGP, czy
> remote DoSow w implementacji firewalla?

Ograniczenie dostępu do TCP/179 tylko dla peerów to oczywista oczywistość.
A ACL-ki na normalnych gratach zrobi Ci jakiś ASIC.

> Czym? Firewallem, ktory moze byc (i czesto bywal) podatny na remote DoS?
> No chyba, ze archaiczne tcpwrappers.

Nie firewalujmy, bo kod firewalla może mieć bugi? Wg Ciebie z zestawu:
1. serwer z sshd wystawionym na świat
2. serwer z sshd i firewallem dropującym połączenia SSH z niezaufanych hostów
opcja 2. stwarza większe możliwości zaatakowania systemu, bo ma firewalla,
który może miec np. DoSa w kodzie reasemblacji pakietów? :D

>> Tak że ruter zdalnego dostępu, przez który uzyskujemy dostęp do sieci
>> zarządzania i dopiero tamtędy SSH-ujemy się na docelowy system, wydaje
>> mi się zupełnie koszernym rozwiązaniem. ;)
>
> Z dokladnoscia do bledow w implementacji VPN i ryzyk z tym zwiazanych.

Jakie widzisz? Poza DoS-em na koncentrator VPN i odcięciem od sieci zarządzania.


--
Paweł Małachowski

do góry

Dnia 11.08.2010 Pawel Malachowski <p...@n...niewazne> napisał/a:
> Ograniczenie dostępu do TCP/179 tylko dla peerów to oczywista oczywistość.
> A ACL-ki na normalnych gratach zrobi Ci jakiś ASIC.

Oj, Pawmal. Zrobiles sie zbyt enterprajsowy.

> Nie firewalujmy, bo kod firewalla może mieć bugi? Wg Ciebie z zestawu:
> 1. serwer z sshd wystawionym na świat
> 2. serwer z sshd i firewallem dropującym połączenia SSH z niezaufanych hostów
> opcja 2. stwarza większe możliwości zaatakowania systemu, bo ma firewalla,
> który może miec np. DoSa w kodzie reasemblacji pakietów? :D

Tak, tak wlasnie uwazam.

> Jakie widzisz? Poza DoS-em na koncentrator VPN i odcięciem od sieci zarządzania.

Remote roota na koncentratorze VPN nie bierzesz pod uwage?

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

Dnia 11.08.2010 Przemyslaw Frasunek <v...@f...lublin.pl> napisał/a:

>> Nie firewalujmy, bo kod firewalla może mieć bugi? Wg Ciebie z zestawu:
>> 1. serwer z sshd wystawionym na świat
>> 2. serwer z sshd i firewallem dropującym połączenia SSH z niezaufanych hostów
>> opcja 2. stwarza większe możliwości zaatakowania systemu, bo ma firewalla,
>> który może miec np. DoSa w kodzie reasemblacji pakietów? :D
>
> Tak, tak wlasnie uwazam.

Serio? Ale masz jakieś wsparcie?

>> Jakie widzisz? Poza DoS-em na koncentrator VPN i odcięciem od sieci zarządzania.
> Remote roota na koncentratorze VPN nie bierzesz pod uwage?

Tak - ale jakie są skutki? Redukcja do wariantu z publicznie dostępnym SSH:
atakujący uzyska dostęp do portu usługi SSH.


--
Paweł Małachowski

do góry

Dnia 11.08.2010 Pawel Malachowski <p...@n...niewazne> napisał/a:
> Tak - ale jakie są skutki? Redukcja do wariantu z publicznie dostępnym SSH:
> atakujący uzyska dostęp do portu usługi SSH.

Mowisz o przypadku idealnym. Ja postuluje, ze:

1) zainstaluje sniffer i bedzie spokojnie czekal na jakas nieszyfrowana
komunikacje (np. management po HTTP);

2) poskanuje sobie siec i popatrzy, czy przypadkiem z VPN nie ma dostepu
do czegos znacznie ciekawszego niz tylko SSH;

3) popatrzy, czy na serwerze VPN nie ma przypadkiem jakiegos agenta
do backupow, ktory przez przypadek pozwala na zdalne wykonywanie
komend na innych maszynach, na ktorych jest zainstalowany (np. Bacula
i wspolne hasla do bacula-fd dla wszystkich maszyn);

itd. Mozliwosci jest wiele ;)

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

Dnia 11.08.2010 Przemyslaw Frasunek <v...@f...lublin.pl> napisał/a:

>> Tak - ale jakie są skutki? Redukcja do wariantu z publicznie dostępnym SSH:
>> atakujący uzyska dostęp do portu usługi SSH.
>
> Mowisz o przypadku idealnym. Ja postuluje, ze:
>
> 1) zainstaluje sniffer i bedzie spokojnie czekal na jakas nieszyfrowana
> komunikacje (np. management po HTTP);
>
> 2) poskanuje sobie siec i popatrzy, czy przypadkiem z VPN nie ma dostepu
> do czegos znacznie ciekawszego niz tylko SSH;
>
> 3) popatrzy, czy na serwerze VPN nie ma przypadkiem jakiegos agenta
> do backupow, ktory przez przypadek pozwala na zdalne wykonywanie
> komend na innych maszynach, na ktorych jest zainstalowany (np. Bacula
> i wspolne hasla do bacula-fd dla wszystkich maszyn);
>
> itd. Mozliwosci jest wiele ;)

Wg mnie starasz się bronić tezę "argumentami" o hipotetycznym złym zarządzaniu
stacją przesiadkową.

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


--
Paweł Małachowski

do góry