Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Strony: 1
Hej.
Nie mogę sobie poradzić z tym problemem. W sieci radzą, by połączenie do VNC zrobić przez tunel, ale to nic nie daje, bo - jeśli dobrze rozumiem - to tylko moja komunikacja z VNC będzie szyfrowana, a inne próby łączenia się nie zostaną ukrócone.
Zrobiłem sobie sprawdzanie w CRON, z jakich IP są błędne próby logowania na mój VPS. Jak pojawią się z danego IP min. 3 błędne próby, to automatycznie dodaję wpis do /etc/hosts.deny. To też jednak nie pomogło.
Nie wiem też, na jakiego użytkownika są połączenia, które w konsekwencji powodują błąd "Too many authentication failures" i konieczność zabicia vncserver-a. vncserver uruchamiam z użytkownika fx, lecz akurat na niego nie zauważam prób logowania.
Proszę o pomoc.
Offline
Chcesz zabezpieczyć cała maszynę czy tylko vnc?
Jak vnc to tunel ci wystarczy, jak cała maszynę to może hostdeny albo fail2ban?
Dobrze też używać niestandardowych portów
Offline
Plik /etc/hosts.deny to prehistoria starsza niż Ipchains, w czasach Iptables i NFtables do takich rzeczy używa się Ipseta albo Hashlimit.
Rzuć okiem na to:
https://forum.dug.net.pl/viewtopic.php?pid=269264
Offline
Hmm... dużo więc mam do poczytania.
A wiadomo może, jak sprawdzić, na którego użytkownika są te logowania, które blokują mi dostęp? Skoro vncserver uruchamiam z użytkownika fx, a na tego użytkownika nie ma błędnych logowań, to chyba na jakimś innym "działa" vnc. Jak go znaleźć?
(Wczoraj po południu uruchomiłem vncserver od nowa, bo znów był ten błąd. Przed chwilą, przy próbie uruchomienia vncviewer znów on wystąpił. Masakra jakaś!)
Offline
Sprawdziłem logi VNC i okazuje się, że próbują łączyć się tylko z 3 adresów IP:
129.232.147.210
163.172.198.143
50.225.42.82
Mam je już w /etc/hosts.deny, ale nic to nie pomogło :/
Offline
Jacekalex napisał(-a):
Plik /etc/hosts.deny to prehistoria starsza niż Ipchains, w czasach Iptables i NFtables do takich rzeczy używa się Ipseta albo Hashlimit.
Rzuć okiem na to:
https://forum.dug.net.pl/viewtopic.php?pid=269264
Offline
Po zrobieniu w iptables reguły DROP dla tych 3 adresów, pomogło :)
Offline
Hej!
Ktoś jest w stanie wyjaśnić, dlaczego "iptables -L -n" uruchamiane z crona (root) zwraca inny wynik, niż uruchamiane nie z crona (też root)?
Mam skrypt:
#!/bin/bash # blokowanie IP, które chcą się włamać na VNC logfile="/home/fx/.vnc/doscniewoli:1.log" if [ "$1" == "deny" ]; then for scam in `cat $logfile | grep -i "authentication failed from" | awk '{ print $7 }' | sort | uniq -c | awk '$1 >= 1 { print $1"_"$2 }'`; do echo "scam=${scam}" >> /root/bin/failedVNClogins_denied_cron.log scams=($(echo ${scam/_/ })) is_blocked=$(iptables -L -n | grep "DROP" | grep "${scams[1]}" | wc -l) if [ "$2" != "cron" ]; then echo -e "\n\nscam='$scam', scams[*]=(${scams[*]})" iptables -L -n | grep "DROP" | grep "${scams[1]}";>echo "--is_blocked=$is_blocked" else iptables -L -n | grep "DROP" | grep "${scams[1]}" >> /root/bin/failedVNClogins_denied_cron.log echo "${scams[1]} is_blocked=$is_blocked" >> /root/bin/failedVNClogins_denied_cron.log fi if [ $is_blocked -eq 0 ]; then iptables -A INPUT -s ${scams[1]} -j DROP iptables-save echo $(date "+%Y-%m-%d %H:%M")" denied access for ${scams[1]}" >> /root/bin/failedVNClogins_denied.log if [ "$2" != "cron" ]; then echo "-> blocking ${scams[1]}" echo $(date "+%Y-%m-%d %H:%M")" denied access for ${scams[1]}" fi fi done else <->cat $logfile | grep -i "authentication failed from" | awk '{ print $7 }' | sort | uniq -c | awk '$1 >= 1' fi
Gdy uruchamia się on z crona z prametrami "deny cron" to do pliku /root/bin/failedVNClogins_denied_cron.log wpisuje:
scam=11_100.2.41.106
100.2.41.106 is_blocked=0
scam=1_154.85.99.96
154.85.99.96 is_blocked=0
scam=10_211.144.146.13
211.144.146.13 is_blocked=0
scam=16_85.93.20.126
85.93.20.126 is_blocked=0
Gdy jednak uruchomię go sam z tymi samymi parametrami, to do pliku wpisuje:
scam=11_100.2.41.106
DROP all — 100.2.41.106 0.0.0.0/0
100.2.41.106 is_blocked=1
scam=1_154.85.99.96
DROP all — 154.85.99.96 0.0.0.0/0
154.85.99.96 is_blocked=1
scam=10_211.144.146.13
DROP all — 211.144.146.13 0.0.0.0/0
211.144.146.13 is_blocked=1
scam=16_85.93.20.126
DROP all — 85.93.20.126 0.0.0.0/0
85.93.20.126 is_blocked=1
Dlaczego tak się dzieje?
Ostatnio edytowany przez Blackhole (2018-08-25 12:11:14)
Offline
Naucz się korzystać z ipseta, hashlimit, connlimit i recent w firewallu, to CRON nie będzie już potrzebny do FW.
Tu masz "dzisiejszą listę obecności" z pewnego VPSa:
ipset list wypad Name: wypad Type: hash:net Revision: 6 Header: family inet hashsize 1024 maxelem 65535 timeout 3600 Size in memory: 24448 References: 6 Members: 185.143.223.220 timeout 72637 124.192.25.247 timeout 2788 113.160.131.55 timeout 360 107.170.211.76 timeout 28874 222.73.202.174 timeout 809 122.160.138.151 timeout 2036 37.49.230.134 timeout 29805 180.153.229.217 timeout 79796 27.72.113.179 timeout 65014 200.27.131.51 timeout 83128 212.0.149.84 timeout 67208 59.144.10.122 timeout 2819 212.247.225.154 timeout 81855 36.77.22.157 timeout 52654 193.93.218.42 timeout 83846 123.185.223.132 timeout 37102 113.64.92.55 timeout 64425 191.101.42.150 timeout 55566 181.225.100.58 timeout 2546 196.52.43.124 timeout 46917 116.31.116.44 timeout 28550 45.55.14.61 timeout 2291 95.135.43.163 timeout 81950 220.191.229.181 timeout 42966 54.38.193.170 timeout 1756 142.93.131.99 timeout 220 194.55.142.25 timeout 67937 186.228.76.90 timeout 40043 173.173.198.68 timeout 43738 113.165.167.16 timeout 63269 36.75.90.23 timeout 2585 5.188.10.76 timeout 75662 193.105.134.97 timeout 71468 114.67.143.38 timeout 84710 202.43.154.162 timeout 50930 94.244.20.47 timeout 75739 60.18.229.214 timeout 209 182.74.245.2 timeout 2523 190.38.77.44 timeout 34622 36.66.102.226 timeout 55536 36.73.14.41 timeout 85608 122.192.14.189 timeout 3240
SOA#1 xD
PS.
Jak już musisz koniecznie używać tak niebezpiecznej uslugi jak VNC, to lepiej wystaw ją na localhosta albo interfejs lokalny tunX serwera VPN, i łącz się przez tunel SSH albo OpenVPN.
Wtedy czy OpenSSH czy OpenVPN oferuje wygodne i bezpieczne logowanie kluczami SSH albo certyfikatami x509, a obie usługi są ddduuużżżooo bezpieczniejsze od demona VNC.
Rzuć okiem np na to:
https://cat.pdx.edu/platforms/linux/remote-access/vnc/
Pozdro
Ostatnio edytowany przez Jacekalex (2018-08-25 13:11:10)
Offline
Strony: 1