Pomoc Kontener Owncloud+Fail2ban Behind Proxy Problem

Ciangi

System Engineer
Q Specialist
24 Styczeń 2016
122
26
28
31
QNAP
TVS-ECxx80
Ethernet
1 GbE
Model serwera: QNAP TS-251+


Witam,

mam problem z banowaniem adresow IP przez Fail2ban. Filtr na wykrywanie w fail2ban dziala poprawnie, tzn. gdy ktos np. 5 razy zle poda login i haslo to go poprawnie banuje:

np. iptables kontenera wyglada tak:

INPUT ..... DROP tcp -- 31.0.80.229 0.0.0.0/0 tcp dpt:80

virtual host w Apache w qnapie skonfigurowalem tak:
Kod:
<VirtualHost *:80>
  ProxyPreserveHost On
  ProxyPass / http://192.168.50.10:84/
  ProxyPassReverse / http://192.168.50.10:84/
  ServerName test.com
  DocumentRoot "/share/CACHEDEV1_DATA/Web/error"
</VirtualHost>

tzn. ze po wpisaniu "Client Validation" (port 80) laczy mi sie bezposrednio (do panelu logowania ownclouda) z kontenerem, ktory zawiera ownclouda.

i teraz konfiguracja virtual hosta apache kontenera:
Kod:
<VirtualHost *:80>
  DocumentRoot /var/www/site

  <Directory /var/www/site/>
      Options Indexes FollowSymLinks MultiViews
      AllowOverride All
      Order deny,allow
      Allow from all
  </Directory>

  RemoteIPHeader X-Forwarded-For
  RemoteIPTrustedProxy 172.17.238.1


  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined

</VirtualHost>

adres ip 172.17.238.1, bo pod tym adresem jest widoczny dla tego kontenera qnap.

I teraz oczywiscie mod_remoteip jest wlaczony itd. ponadto w konfiguracji apache kontenera dodalem:

LogFormat "%h %l %u %t \"%r\" %>s %O" common
,bo apache napisal, ze:

# Note that the use of %{X-Forwarded-For}i instead of %h is not recommended.
# Use mod_remoteip instead.
#

wiec uzywam mode remoteip i %h zamiast %{X-Forwarded-For}i

i teraz tak w logach apache kontenera poprawnie pokazuje mi adres IP, czyli :

Kod:
31.0.80.229 - - [17/Jul/2017:14:31:33 +0200] "POST /index.php/login HTTP/1.1" 303 741 "-" "Mozilla/5.0 (Android 5.1; Mobile; rv:51.0) Gecko/51.0 Firefox/51.0"

i dodatkowo logi ownclouda rowniez widza wszystko ok, czyli:

Kod:
{"reqId":"WVqdioulekCWym1NVVEZ","level":2,"time":"2017-07-17T14:31:33+02:00","remoteAddr":"31.0.80.229","user":"--","app":"core","method":"POST","url":"\/index.php\/login","message":"Login failed: 'dhdhd' (Remote IP: '31.0.80.229')"}

Wiec skoro wszystko wydaje sie w porzadku, iptables regula dodana itd. to dlaczego nadal z adresu 31.0.80.229 jestem w stanie nadal móc probowac logowac sie na ownclouda????????


Proszę o wszelkie wskazówki i dziękuję za odpowiedzi

Pozdrawiam
 
Właśnie najpierw ogólnie wszystko próbowałem robić po SSLu ( tak mialem ustawione domyslnie ) i rowniez porty 443 blokowalo w taki sam sposob jak opisalem powyzej. Nastepnie gdzies cos mi przeskoczylo na jakims forum, ze moga byc problemy po SSLu zeby wychwycic adres IP jak cos stoi behind proxy ( w sumie tak jak juz mowilem, wszystko w logach pokazywalo poprawnie, ze po SSLu tez widzialo IP i fail2ban blokowal w iptables, wiec sie zdziwilem jak to przeczytalem) i dlatego wszystko zaczalem testowac przy wymuszeniu ownclouda po porcie 80.
Reasumujac, dzialanie fail2ban w przypadku 80 i 443 portu dziala tak samo, czyli niby banuje, ale nadal "widze" strone logowania i moge sie logowac.
Jeszcze o jednej waznej rzeczy nie powiedzialem.

Jesli dodalbym do reguly iptables:
INPUT .....
DROP tcp -- 172.17.238.1 0.0.0.0/0 tcp dpt:80

,gdzie adres IP powyzej odpowiada adresowi IP qnapa ( dla kontenera ) wtedy nikt nie moze polaczyc sie ze strona, czyli adres ip np. 31.0.80.229 , 38.20.80.439 itd.

I teraz nie wiem czy to jest stan porzadany czy tez nie?

bo wskazywaloby to na to ze pomimo w logach widze adresy publiczne to tak czy srak kazdy klient laczy sie z kontenerem poprzez adres IP hosta qnapa. Tylko teraz pytanie, dlaczego tak sie dzieje? Znaczy sie dlaczego tak sie dzieje to w sumie logiczne, ale dlaczego kontener interpretuje kazdego klienta z adresem IP hosta qnapa zamiast z jego adresem publicznym skoro go przeciez widzi.
 
Kod:
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
f2b-owncloud  all  --  0.0.0.0/0            0.0.0.0/0
DROP       tcp  --  31.0.80.229          0.0.0.0/0            tcp dpt:443
DROP       tcp  --  31.0.80.229          0.0.0.0/0            tcp dpt:80

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain f2b-owncloud (1 references)
target     prot opt source               destination
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Oczywiscie odnosnie tych linijek DROP sa dodane recznie przeze mnie - docelowo jezeli fail2ban banuje, dodaje je do Chain f2b-owncloud.

poza tym - na damski parasol w vhoscie kontenera przekierowanie proxy ? to bez sensu jak dla mnie, jaki jest powód tego wpisu ?

RemoteIPTrustedProxy 172.17.238.1 to nie jest przekierowanie proxy. to jest dodanie adresu IP jako zaufanego serwera proxy. Bez tej linijki w logach zawsze uzyskam adres IP hosta qnapa, czyli 172.17.238.1. Czyli dzieki tej linijce jestem w stanie uzyskac w logach apacha kontenera publiczne adresy IP.
 
dropy powinny być na poczatku - allow na końcu
upload_2017-7-18_17-39-37.png


iptables, order of rules - do I understand it right?
 
Ok.
Usunalem caly Chain f2b-owncloud z INPUTa. Odpalilem net w komie, dodalem bana na nowy IP i nadal moge się łączyć ....

iptables:

Kod:
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       tcp  --  31.0.80.229          0.0.0.0/0            tcp dpt:443
DROP       tcp  --  31.0.80.229          0.0.0.0/0            tcp dpt:80
DROP       tcp  --  31.0.68.15           0.0.0.0/0            tcp dpt:80
DROP       tcp  --  31.0.68.15           0.0.0.0/0            tcp dpt:443

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain f2b-owncloud (0 references)
target     prot opt source               destination
RETURN     all  --  0.0.0.0/0            0.0.0.0/0
 
nadal to samo.... ( IP inne bo jak wylacze i wlacze neta to Plus daje inne IP)
Kod:
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       tcp  --  31.0.80.229          0.0.0.0/0            tcp dpt:443
DROP       tcp  --  31.0.80.229          0.0.0.0/0            tcp dpt:80
DROP       tcp  --  31.0.68.15           0.0.0.0/0            tcp dpt:80
DROP       tcp  --  31.0.68.15           0.0.0.0/0            tcp dpt:443

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
DROP       tcp  --  31.0.44.252          0.0.0.0/0            tcp dpt:443
DROP       tcp  --  31.0.44.252          0.0.0.0/0            tcp dpt:80

Chain f2b-owncloud (0 references)
target     prot opt source               destination
RETURN     all  --  0.0.0.0/0            0.0.0.0/0
Tylko czekaj, zebym sie upewnil, ze dobrze siebie rozumiemy... ja listuje wynik zapytania:
# iptables -L -n

Wylistuje rowniez w razie w # iptables -L -n -t nat :
Kod:
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
DNAT       udp  --  0.0.0.0/0            127.0.0.11           udp dpt:53 to:127.0.0.11:58741
DNAT       tcp  --  0.0.0.0/0            127.0.0.11           tcp dpt:53 to:127.0.0.11:36528

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
SNAT       udp  --  127.0.0.11           0.0.0.0/0            udp spt:58741 to::53
SNAT       tcp  --  127.0.0.11           0.0.0.0/0            tcp spt:36528 to::53
 
blokuj całą grupę

iptables -A INPUT -s 31.0.0.0/24 -j DROP
iptables -A OUTPUT -d 31.0.0.0/24 -j DROP

a przeładowałeś iptables po zmianie ? zwykle /etc/init.d/firewall reload badz przez service ...

poza tym jedno mnie zastanawia :
bo robisz reverse proxy - to maskuje adres IP (?) - co widać w logu apache'a w kontenerze ? tail -f /var/log/apache2/access.log

u mnie patrząc ze strony systemu który jest wewnątrz :
Kod:
○ → tail -f /var/log/apache2/access.log
147.135.208.202 - - [18/Jul/2017:19:17:07 +0200] "GET /sonarr/api/config/ui HTTP/1.1" 200 646 "http://p.seph.ovh/   " "Mozilla/5.0 (Linux; Android 4.4.2; Che2-L11 Build/HonorChe2-L11) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.125 Mobile Safari/537.36"
147.135.208.202 - - [18/Jul/2017:19:17:07 +0200] "GET /sonarr/api/system/status HTTP/1.1" 200 771 "http://p.seph.ovh/     " "Mozilla/5.0 (Linux; Android 4.4.2; Che2-L11 Build/HonorChe2-L11) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.125 Mobile Safari/537.36"

147.135.208.202 - adres mojego serwera VPS

w systemie zewnątrz:
Kod:
202.ip-147-135-208.eu:80 94.254.247.88 - - [18/Jul/2017:19:17:15 +0200] "GET /sonarr/signalr/poll?transport=longPolling&connectionToken=CBVymeuJsGq6Q56aSwYkG8KAVL73rKZJpSYbbjoOIyDTUYbnttvNxtNFVVZMpOG121vwoup%2Fr4QRBxgxWQ6zwCa05a6S553GttBfgiMoDNuyhrAYiaYwzcuEPEi50xM41EsjAOhlYIdajCY0Sh0ehtnCRlef1FG%2Fm8w9d4QeoFFV6cAtB8MP%2BH7%2FziqgjP%2FRcHhXBENdO5CB692hgv6xdZ6Q8tV8b%2FurtKdG8aD0F4CztblWvG5X4pm38aJf7IiyYOqizI7FR%2BqGuNX2QrQsnCFXyo3S2V8F61fzFC61Mu0iibD9wrc7fYn2Yw2uJ9dR&messageId=d-605EDF82-BN%2C6B5%7CBa%2C0%7CBb%2C0&tid=1&_=1500398137248 HTTP/1.1" 200 252 "http://p.seph.ovh/     " "Mozilla/5.0 (Linux; Android 4.4.2; Che2-L11 Build/HonorChe2-L11) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.125 Mobile Safari/537.36"

94.254.247.88 - IP z mojej komórki
 
tylko to w kontenerze posiadam...
Kod:
root@f64fed9d902e:/# /etc/init.d/
apache-htcacheclean     fail2ban                mountall.sh             ondemand                sendsigs
apache2                 halt                    mountdevsubfs.sh        procps                  single
bootmisc.sh             hostname.sh             mountkernfs.sh          rc                      umountfs
checkfs.sh              hwclock.sh              mountnfs-bootclean.sh   rc.local                umountnfs.sh
checkroot-bootclean.sh  killprocs               mountnfs.sh             rcS                     umountroot
checkroot.sh            mountall-bootclean.sh   networking              reboot                  urandom
wiec uzywam # /etc/init.d/networking restart


nowe iptables:
Kod:
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       tcp  --  31.0.80.229          0.0.0.0/0            tcp dpt:443
DROP       tcp  --  31.0.80.229          0.0.0.0/0            tcp dpt:80
DROP       tcp  --  31.0.68.15           0.0.0.0/0            tcp dpt:80
DROP       tcp  --  31.0.68.15           0.0.0.0/0            tcp dpt:443
DROP       all  --  31.0.0.0/24          0.0.0.0/0

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
DROP       tcp  --  31.0.44.252          0.0.0.0/0            tcp dpt:443
DROP       tcp  --  31.0.44.252          0.0.0.0/0            tcp dpt:80
DROP       all  --  0.0.0.0/0            31.0.0.0/24

Chain f2b-owncloud (0 references)
target     prot opt source               destination
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

aktualny przyklad logu apacha z kontenera:

Kod:
31.0.44.252 - - [18/Jul/2017:19:29:29 +0200] "GET /index.php/login HTTP/1.1" 200 2853 "-" "Mozilla/5.0 (Android 5.1; Mobile; rv:51.0) Gecko/51.0 Firefox/51.0"

log ownclouda ( rowniez z kontenera ):
Kod:
{"reqId":"EcxoLvEFJemd52JawxVk","level":2,"time":"2017-07-18T19:31:47+02:00","remoteAddr":"31.0.44.252","user":"--","app":"core","method":"POST","url":"\/index.php\/login","message":"Login failed: 'xhxhd' (Remote IP: '31.0.44.252')"}
 
Forward i f2b-owncloud to samo ....
tylko teraz tak, dlaczego jezeli dodam regule:
iptables -D INPUT -p tcp --dport 80 -s 172.17.238.1 -j DROP

to wtedy nie moge sie zalogowac? w sensie nie laduje w ogole strony? Wyglada na to jakby to proxy do konca nie dzialalo?? bo identyfikuje kazdego klienta jako adres IP 172.17.238.1 ?? czyli co, access.log i logi ownclouda oszukuja?
Nie wiem czy to cos robi, ale zaczalem grzebac troche w konfiguracji vhosta kontenera:
zamienilem
CustomLog ${APACHE_LOG_DIR}/access.log combined
na
CustomLog ${APACHE_LOG_DIR}/access.log "%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-agent}i\" \"[XF %{X-Forwarded-For}i]\""
w vhoscie nadal mialem ustawione:
Kod:
  RemoteIPHeader X-Forwarded-For
  RemoteIPTrustedProxy 172.17.238.1
w wyniku z logu apacha :
Kod:
172.17.238.1 - - [18/Jul/2017:23:05:03 +0200] "GET /index.php/login HTTP/1.1" 200 2109 "-" "Mozilla/5.0 (Android 5.1; Mobile; rv:51.0) Gecko/51.0 Firefox/51.0" "[XF -]"

i teraz jeszcze jeden myk zrobilem w taki sposob ze Custom Log jak wyzej podmieniony, ale zmienilem jeszcze:
Kod:
  RemoteIPHeader X-Real-IP
  RemoteIPTrustedProxy 172.17.238.1

i wynik apache loga:
Kod:
172.17.238.1 - - [18/Jul/2017:23:15:22 +0200] "GET /cron.php HTTP/1.1" 200 20 "-" "Mozilla/5.0 (Android 5.1; Mobile; rv:51.0) Gecko/51.0 Firefox/51.0" "[XF 31.0.69.175]"

Przy tych kombinacjach, nadal mam dostep do strony logowania ....

Nie wiem w ogole o co tu chodzi... Znaczy ogolnie wynika ze iptables dziala, tylko problem jest ciagle z tymi adresami ... moze tak byc ze apache w logach pokazuje adres publiczny a iptables widzi ze wszyscy klienci to adres ip 172.17.238.1 ??
 
Tylko teraz tak. Czy jest mozliwosc, jezeli w kontenerze fail2ban zbanuje IP, przekazanie informacji do hosta ( qnapa ) zeby takowy adres zbanowal?? zwracam uwage tutaj na slowa przekazanie informacji.
 
A jakas podpowiedz moglbym dostac ? :)

bo to co ja wymyslilem nie wiem czy jest to dobry sposob, czyli:

fail2ban w kontenerze banuje ( lapie publiczny adres IP ) i zapisuje ten adres IP do pliku (do ktorego ma rowniez dostep QNAP ), nastepnie w qnapie ustawiam w crontabie zeby co np. minute sprawdzal i pobieral zawartosc tego pliku, czyli np. adresy ip zapisane osobno w kazdej linii i ustawial pod nie DROPa w iptables?

czy jest jakies latwiejsze/lepsze rozwiazanie ?
 
fail2ban w kontenerze banuje ( lapie publiczny adres IP ) i zapisuje ten adres IP do pliku (do ktorego ma rowniez dostep QNAP )
To mnie ciekawi, jak to zrobić

nastepnie w qnapie ustawiam w crontabie zeby co np. minute sprawdzal i pobieral zawartosc tego pliku, czyli np. adresy ip zapisane osobno w kazdej linii i ustawial pod nie DROPa w iptables
można - ale tu jest pare problemów:
1. program zapisze IPka, a cron go odczyta w tym momencie - błąd
2. co z powtarzalnymi banami ?

ja zbanowałem na głównym routerze całą maskę Chin, Indonezji i mam to z głowy ;)
 
Znaczy sie w ogole tak, jedno sprostowanie, w konfiguracji kontenera apacha ustawilem nie:
LogFormat "%h %l %u %t \"%r\" %>s %O" common

tylko
LogFormat "%a %l %u %t \"%r\" %>s %O" common

i teraz wlasnie dzieki temu pokazuja mi sie w logach access.log publiczne adresy IP, a nie maskowane. takze jak fal2ban banuje to wlasnie "banuje" publiczne IP, w sensie niby "banuje" bo dodaje ragulke w iptables na ten konkretny publiczny adres IP, ale z racji, ze qnap maskuje ipki to iptables w kontenerze nie zadziala.
Wiec, mam informacje od fail2ban na konkretny publiczny adres ip i moge go poprawnie przekazac do pliku.

Co do problemow 1. i 2. na razie nic nie przychodzi mi do glowy.

Tylko teraz jeszcze jedno, jezeli apache potrafi wychwycic publiczny adres IP ( %a ) to czy w iptables nie ma jakiejs mozliwosci ustawienia zeby widzial polaczenia klientow jako wlasnie "%a" a nie "%h"? Bo wychodzi teraz na to, ze iptables jak przychodzi polaczenie to widzi kazdego klienta jako "%h", czyli adres ip qnapa.
Finalnie, znalazlem rozwiazanie, ktore dziala i nie wymaga kontaktu z QNAPem:

is there a better way to do what im trying to do at the server level

I don't know if its better, but I prefer this:

  1. create for every IP a new file, structured like deny/198.51.100.201
  2. use the following code in your .htaccess to block the IP:

    RewriteCond %{REMOTE_ADDR} ^([0-9]{1,3})\.
    RewriteCond /usr/www/{your_path}/deny/%{REMOTE_ADDR} -f
    RewriteRule . - [F]

Jakbym mogl jeszcze prosic o potwierdzenie, czy takie zastosowanie jest bezpieczne.

Oczywiscie jeszcze w fail2ban musze ustawic actionban w taki sposob zeby tworzyl plik o nazwie ip, czyli pewnie cos w stylu touch /usr/www/{your_path}/deny/<ip>

W razie co, temat mozna uznac za rozwiazany.
 
jesli umieścisz to .httaccess to KAŻDE połączenie będzie odczytywało ten plik - będzie to wolniejsze
lepiej wrzucić to do pliku konfiguracyjnego apache'a w etc - to będzie dużo szybsze rozwiązanie.
 
  • Lubię to
Reakcje: Ciangi