GNUMP3d: hasła, reverse-proxy ⌜ Technologia ⌟
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!