Béton brut

GNUMP3d: hasła, reverse-proxy

2011-07-27

Aktualizacja bez głowy

Instalując wczoraj trochę nowych zabawek na domowym serwerze zauważyłem, że nowa wersja GNUMP3d nie posiada już dostępnej wcześniej autoryzacji. Wcześniejsze wersje takową posiadały, ale jak stwierdzili sami autorzy, kod osiągnął stan FUBAR i został całkowicie wycięty, jak przeżarta gangreną noga.

Podrapałem się po ryju i pomyślałem do siebie. Spodobało mi się i pomyślałem jeszcze raz. Wpisałem w Google tekst dostępny w domyślnym szablonie GNUMP3d – bam! – dostęp do tysięcy plików muzycznych, których właściciele nie zauważyli, że aktualizacja usunęła moduł autoryzacji i mają rozpięte rozporki.

To pierwsza nauka. Nie aktualizujcie oprogramowania na serwerach bez choćby szybkiego rzucenia okiem na ChangeLog.

Co zrobić, żeby się skryć za hasłem, jeśli system nie ma wbudowanego mechanizmu? Dwie rzeczy.

reverse-proxy

Proxy to ogólnie serwisy pośredniczące. Większość Zwykłych Użytkowników zna proxy jako to coś, co się wpisuje do przeglądarki, co przyśpiesza transfer, większość trolli zna proxy jako sposób na „ukrycie się”, co pozwala im być prawdziwymi wojownikami klawiatury.

Zasada działania jest prosta. W lokalnej (więc szybkiej) sieci znajduje się serwer, którego pytamy np. o Onet.pl, on znów patrzy w Internet, czy strona się mocno zmieniła od ostatniej wizyty i oddaje użytkownikowi część wiadomości bez ich pobrania.

Reverse-proxy działa na odwrotnej zasadzie, co jest najmniejszym zdziwieniem świata. Wyobraźmy sobie, że mamy na naszym serwerze dwie czy trzy usługi, które generują HTML (czyli da się je badać przeglądarką), a które znajdują się na portach, które nie są dostępne z różnych powodów. Mamy więc np. gnump3d odpalone na porcie :8888 i transmission-daemon odpalone na porcie :9091. Konfigurujemy reverse-proxy tak, aby odpowiadało na żądania z portu :80 (czyli standardowego) i serwowało nam informacje z usług, które są ukryte za firewallem. Tak więc jeśli piszemy w przeglądarce music.fuse.pl, to żądanie trafia do daemona HTTP na moim domowym serwerze, reverse-proxy przesyła je „do tyłu” do 127.0.0.1:8888, odbiera wynik i oddaje znów na :80. Tada.

Kluczowy do zrozumienia całości jest ten oto schemat: 1

BASIC AUTH

Teraz dostęp do autoryzacji. Najprostszym sposobem jest użycie metody autoryzacji po HTTP zwanej BASIC AUTH. To nic innego jak dodanie do nagłówków żądania informacji o użytkowniku i haśle. Nie jest to kryptograficzny Everest, jeżeli nie robimy reverse-proxy dla SSL, to poślemy swoje hasło w czystym tekście. Natomiast działa wszędzie i działa zawsze.

Część, w której robi się copy-paste

Ponieważ nie umiem już Apache2, wkleję konfigurację dla lighttpd.

$HTTP["host"] == "music.fuse.pl" {
  auth.backend = "plain"
  auth.backend.plain.userfile = "/SCIEŻKA/DO/PLIKU"
  auth.require = ( "/" =>
   (
    "method" => "basic",
    "realm" => "Password protected area",
    "require" => "user=XYZ"
   )
  )
proxy.balance = "round-robin"
proxy.debug = 1
  proxy.server  = ( 
        "" => ( 
                ( "host" => "127.0.0.1", "port" => "8888" )
        ) 
  )
}

W miejsce ścieżki do pliku podstawiamy własny plik w formacie

user:hasło

W require możemy zawęzić listę użytkowników, jeżeli używamy tego samego pliku z hasłami do kilku autoryzacji.

Ponowne uruchomienie serwera i już jesteście gotowi. Sprawdźcie też, czy macie załadowane odpowiednie moduły w głównej konfiguracji lighttpd (mod_proxy, mod_auth).

Kurde load-balance

Głupio byłoby nie wspomnieć. Taka konfiguracja może służyć też load-balancingowi, czyli rozkładaniu ruchu i obciążenia na kilka maszyn. Gdybym miał w domu dwa serwery z tą samą muzyką, odpalił na nich GNUMP3d i wskazał oba w sekcji proxy.server, to ruch byłby przekazywany na przemian 2 to do jednego, to do drugiego, co w teorii zmniejszyłby obciążenie.

Kawa mi się skończyła.
„Notka podczas jednej kawy™” może nastąpić ponownie bez ostrzeżenia!

  1. lubię i nie umiem rysować, so sue me
  2. lub zgodnie z wybranym algorytmem