🚀 go-pugleaf

On 24.03.2014 19:41, Marcin Wilk wrote:
> 
> Potrzebuję uruchomić coś rodzaju urządzenia do zarządzania dostępami do
> SSH do wielu maszyn z linux.

Siema

Tradycyjnie: dołącz linuxy do serwerka ldap, lub zakładaj konta i uprawnienia
puppetem lub innym tego typu automatem.


> Założenia:
> - wielu użytkowników którzy posiadają różne dostępy do róznych maszyn
> - każdy z użytkowników bezpośrednio po IP ma dostęp tylko do serwera
> pośredniczącego
>
> - za pomocą serwera pośredniczącego uzyskują dostęp do innych maszyn
> zarówno ssh jak i sftp.
> 
> W jaki sposób najlepiej podejść do tematu ?

Wg Twoich założeń, jak ktoś schaczy serwer pośredniczący, ma wjazd wszędzie i z uprawnieniami wszystkich.
Trochę to słabe, dlatego właśnie nikt nie rozdaje uprawnień na serwerze pośredniczącym,
który zazwyczaj jest wystawiony w świat .

Na serwerze pośredniczącym co najwyżej można zrobić logownia komnd, połączeń i tym podobne,

SSH pozwala forwardować porty, i do tego można serwer pośredniczący wykorzystać,
aczkolwiek openvpn byłby dużo wygodniejszy, jeśli serwer pośredniczący miałby służyć jedynie zmianie IP.

-- 
  MG

Dnia poniedziałek, 24 marca 2014 22:47, tombo napisał(a):

>> Założenia:
>> - wielu użytkowników którzy posiadają różne dostępy do róznych maszyn
>> - każdy z użytkowników bezpośrednio po IP ma dostęp tylko do serwera
>> pośredniczącego
>>
>> - za pomocą serwera pośredniczącego uzyskują dostęp do innych maszyn
>> zarówno ssh jak i sftp.
>> 
>> W jaki sposób najlepiej podejść do tematu ?
> 
> Wg Twoich założeń, jak ktoś schaczy serwer pośredniczący, ma wjazd
> wszędzie i z uprawnieniami wszystkich.

Dlaczego?

-- 
| pozdrawiam / greetings | powered by Debian, FreeBSD and CentOS |
|  Kajetan Staszkiewicz  | jabber,email: vegeta()tuxpowered net  |
|        Vegeta          | www: http://vegeta.tuxpowered.net     |
`------------------------^---------------------------------------'

On 25/03/14 10:02, Kajetan Staszkiewicz wrote:
> Dnia poniedziałek, 24 marca 2014 22:47, tombo napisał(a):
> 
>>> Założenia:
>>> - wielu użytkowników którzy posiadają różne dostępy do róznych maszyn
>>> - każdy z użytkowników bezpośrednio po IP ma dostęp tylko do serwera
>>> pośredniczącego
>>>
>>> - za pomocą serwera pośredniczącego uzyskują dostęp do innych maszyn
>>> zarówno ssh jak i sftp.
>>>
>>> W jaki sposób najlepiej podejść do tematu ?
>>
>> Wg Twoich założeń, jak ktoś schaczy serwer pośredniczący, ma wjazd
>> wszędzie i z uprawnieniami wszystkich.
> 
> Dlaczego?
> 

Ponieważ:
- ludzie będą mieć na nim swoje klucze do logowania się na serwerach
docelowych (jak ktoś przejmie serwer, przejmie klucze)
- będą na nim wpisywać swoje hasła, które wystarczy zrzucić do pliku,
przez jakąś zmodyfikowaną wersje sshd


-- 
Michał Rydlikowski

Dnia wtorek, 25 marca 2014 14:02, Michal Rydlikowski napisał(a):

> On 25/03/14 10:02, Kajetan Staszkiewicz wrote:
>> Dnia poniedziałek, 24 marca 2014 22:47, tombo napisał(a):
>> 
>>>> Założenia:
>>>> - wielu użytkowników którzy posiadają różne dostępy do róznych maszyn
>>>> - każdy z użytkowników bezpośrednio po IP ma dostęp tylko do serwera
>>>> pośredniczącego
>>>>
>>>> - za pomocą serwera pośredniczącego uzyskują dostęp do innych maszyn
>>>> zarówno ssh jak i sftp.
>>>>
>>>> W jaki sposób najlepiej podejść do tematu ?
>>>
>>> Wg Twoich założeń, jak ktoś schaczy serwer pośredniczący, ma wjazd
>>> wszędzie i z uprawnieniami wszystkich.
>> 
>> Dlaczego?
>> 
> 
> Ponieważ:
> - ludzie będą mieć na nim swoje klucze do logowania się na serwerach
> docelowych (jak ktoś przejmie serwer, przejmie klucze)
> - będą na nim wpisywać swoje hasła, które wystarczy zrzucić do pliku,
> przez jakąś zmodyfikowaną wersje sshd

Wiem, że na ludzką głupotę to nie pomoże, ale jest coś takiego jak 
forwardowanie kluczy. Więc ani klucze, ani hasła do nich nie muszą być na 
serwerze, co najwyżej mogą.

-- 
| pozdrawiam / greetings | powered by Debian, FreeBSD and CentOS |
|  Kajetan Staszkiewicz  | jabber,email: vegeta()tuxpowered net  |
|        Vegeta          | www: http://vegeta.tuxpowered.net     |
`------------------------^---------------------------------------'

On 25.03.2014 14:37, Kajetan Staszkiewicz wrote:

> Wiem, że na ludzką głupotę to nie pomoże, ale jest coś takiego jak 
> forwardowanie kluczy. Więc ani klucze, ani hasła do nich nie muszą być na 
> serwerze, co najwyżej mogą.

Odnośnie bezpieczeństwa przeforwardowanego ssh agenta:
  - zaloguj się jako user z przeforwardowanym ssh agentem
  - zobacz jak wyglądają zmienne środowiskowe SSH_AGENT_PID i SSH_AUTH_SOCK
  - jako root na drugiej sesji ustaw sobie takie same SSH_AGENT_PID i SSH_AUTH_SOCK jak ma user
  - zrób ssh  ztego roota jako user na jedną z maszyn na której user ma konto z kluczem, który znajduje się ssh agencie.


Odnośnie tego co napisał Michał, to ma on w zupełności rację. Na jednej z konferencji confidence w krakowie,
w przerwie ktoś pokazywał kawałek kodu w "c", który zrobi na konsoli to co w matrixie zrobiono Neo,
czyli przejęci możliwość czytania i pisania po konsoli.
Teoretycznie to samo można by zrobić w sesji ssh usera z roota
i nie tylko widzieć co pisze, ale także wpisać za użytkownika komendy na terminalu.
Co najważniejsze nie trzeba do tego modyfikować binarek systemu, co by było łatwe do wykrycia
( gdyby ktoś szukał :D )

Kiedyś napisałem sobie skrypcik, do przesiadania się po ssh przez maszynki,
jedyna bezpieczna opcja to forwardowanie portu przez serwer pośredniczący,
może wtedy być skompromitowany, jeśli ktoś zaingeruje choć w jeden pakiet
to ssh to wykryje .
(wpomniany skrypcik leży w tej paczuszce http://debian.atman.pl/debian/dists/squeeze/main/binary-amd64/dossh_0.1~20120727130938.gbpa0f196_all.deb )

-- 
  MG

On 2014-03-25, tombo <tombo-marek@o2.pl> wrote:
[...]
> Odnośnie tego co napisał Michał, to ma on w zupełności rację. Na jednej z konferencji confidence w krakowie,
> w przerwie ktoś pokazywał kawałek kodu w "c", który zrobi na konsoli to co w matrixie zrobiono Neo,
> czyli przejęci możliwość czytania i pisania po konsoli.

No shit, Sherlock! A screen to co robi od prawie trzydziestu lat?

> Kiedyś napisałem sobie skrypcik, do przesiadania się po ssh przez maszynki,

Eee... Cały skrypt? Na 230 linii? Ja to załatwiam konfigiem klienta SSH
(opcją ProxyCommand) i netcatem.

> jedyna bezpieczna opcja to forwardowanie portu przez serwer pośredniczący,

Uwaga na nisko przelatujące kwantyfikatory.

-- 
Secunia non olet.
Stanislaw Klekot

On 26.03.2014 00:43, Stachu 'Dozzie' K. wrote:
> On 2014-03-25, tombo <tombo-marek@o2.pl> wrote:
> [...]
>> Odnośnie tego co napisał Michał, to ma on w zupełności rację. Na jednej z konferencji confidence w krakowie,
>> w przerwie ktoś pokazywał kawałek kodu w "c", który zrobi na konsoli to co w matrixie zrobiono Neo,
>> czyli przejęci możliwość czytania i pisania po konsoli.
> 
> No shit, Sherlock! A screen to co robi od prawie trzydziestu lat?

Nie zrozumiałeś. Ktoś ma otwarte tty( jakieś tam terminal). A Ty się mu wpinasz nie ważne co ma wyżej.
Screen ma zaimplementowane wysyłanie znaczków i pobieranie z różnych terminali,
to trochę co innego.

>> Kiedyś napisałem sobie skrypcik, do przesiadania się po ssh przez maszynki,
> 
> Eee... Cały skrypt? Na 230 linii? Ja to załatwiam konfigiem klienta SSH
> (opcją ProxyCommand) i netcatem.

Też sprytne i robi co trzeba (forwaduje pakiety). Ale mój skrypcik ma więcej opcji :P.

-- 
  MG

Dnia środa, 26 marca 2014 00:03, tombo napisał(a):

> jedyna bezpieczna opcja to forwardowanie portu przez serwer
> pośredniczący, może wtedy być skompromitowany, jeśli ktoś zaingeruje choć
> w jeden pakiet to ssh to wykryje .

Twoje twierdzenie jest inwalidą. Wystarczy, że zrobię przekierowanie dla  
nowego użytkownika, który jeszcze nie ma zaakceptowanego podpisu serwera. 
Łyknie takie połączenie jak indyk kluski. A niektórzy łykną nawet dla 
starego serwera.

-- 
| pozdrawiam / greetings | powered by Debian, FreeBSD and CentOS |
|  Kajetan Staszkiewicz  | jabber,email: vegeta()tuxpowered net  |
|        Vegeta          | www: http://vegeta.tuxpowered.net     |
`------------------------^---------------------------------------'

On 26/03/14 10:12, Kajetan Staszkiewicz wrote:
> Dnia środa, 26 marca 2014 00:03, tombo napisał(a):
> 
>> jedyna bezpieczna opcja to forwardowanie portu przez serwer
>> pośredniczący, może wtedy być skompromitowany, jeśli ktoś zaingeruje choć
>> w jeden pakiet to ssh to wykryje .
> 
> Twoje twierdzenie jest inwalidą. Wystarczy, że zrobię przekierowanie dla  
> nowego użytkownika, który jeszcze nie ma zaakceptowanego podpisu serwera. 
> Łyknie takie połączenie jak indyk kluski. A niektórzy łykną nawet dla 
> starego serwera.
> 

Jak chcesz całkowicie postawić na bezpieczeństwo, to:

- dostęp tylko po VPN'ie (który daje dostęp do "wirtualnej" sieci - a
nie do sieci fizycznej, tak że każdy serwer z którym ktoś ma się łączyć
po ssh, też łączy się po VPN'ie i ma na sztywno w ipsec'u ustawiony
wewnętrzny adres IP - w efekcie nic nie może go zespoofować + blokujesz
na firewallu serwera VPN każdy inny ruch wewnątrz tej "wirtualnej" sieci
niż klient -> serwer:ssh)

- podpisanie wszystkich serwerów swoim kluczem gpg (monkeysphere) - jak
by ktoś jednak znalazł dziurę w IPSEC'u

- logowanie tylko certyfikatami, żadnych haseł (najlepiej w ogóle
uniemożliwiasz zmianę/dodanie klucza i dostarczasz żądaną ilość tokenów,
z wgranym odpowiednim kluczem)

- dostarczasz zaszyfrowaną płytkę (archiwum zaszyfrowane gpg za pomocą
hasła) ze wyżej wymienionymi kluczami i plikami konfiguracyjnymi, z
hasłem które podałeś innym kanałem komunikacji (jak np sms)

-- 
Michał Rydlikowski