Forum Debian Users Gang

gracz1010 · 2018-02-04 11:08:19

Witam wszystkich
Dopiero się ucze więc prosze o wyorzumiałość ; )
Loguje się na konto robocze (brak uprawnień, wyłączone logowanie po hasłach.) poprzez ssh. Możliwość logowania do roota wyłączona (w razie potrzeby zrobione osobne konto z uprawnieniami sudo). Czy fail2ban jest potrzebny? Słyszałem że logując przez ssh ataki typu brute force mamy z głowy. Czy to prawda?

Jacekalex · 2018-02-04 21:07:19

Taki brute-force się zdarzają nawet, jak masz logowanie po hasłach wyłączone, po prostu nie wszystkie booty skrypciarzy pisane są bezbłędnie i z należytą starannością.

Przy czym nie czaję, do czego tu potrzebny fail2ban, jeśli sam Netfiter ma dosyć zabawek, żeby ochronić demona SSH.

Ostatnio edytowany przez Jacekalex (2018-02-07 23:10:59)

gracz1010 · 2018-02-07 13:10:11

Dziękuje bardzo za odpowiedź. Ucze się od niedawna metodą prób i błędów więc póki co to straszny amator ze mnie ;)
Generalnie to firewall przepuszcza tylko określoną pule IP na zmienionych portach i zastanawiam się, czy w takim wypadku takie coś jest mi w ogóle potrzebne?
Nie ukrywam, że zależy mi na jak najprościejszym rozwiązaniu i jeśli da się to zrobić tylko w iptablesie (o ile jest to w ogóle potrzebne) to cieszyłbym się, jeśli nakierowałby mnie Pan na dobrą droge. Pozdrawiam

yossarian · 2018-02-07 13:52:03

Kiedyś używałem czegoś działającego na podobnej do tego zasadzie:

Kod:

-N IN_SSH
-A INPUT -p tcp --dport ssh -m conntrack --ctstate NEW -j IN_SSH
-A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 3 --seconds 10 -j DROP
-A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 4 --seconds 1800 -j DROP
-A IN_SSH -m recent --name sshbf --set -j ACCEPT

gracz1010 · 2018-02-07 14:26:36

Dobrze to interpretuje?

1. Zezwól na połączenie ssh
2/3. (Tutaj mam wątpliwości) 3 błędne próby = ban 10 s. czy 3 błębne próby w przeciągu 10 sec = ban forever?
4. Zezwól na połączenie jeśli nie zostało odfiltrowane przez powyższe reguły

Czy próby logowania są zapisywane w logach? bany są zapisywane w pamięci ram/w plikach? wolałbym aby pamięć nie została przepełniona bez mojej wiedzy.
Druga sprawa - jeśli logować przez ssh moge się tylko z mojeg IP to są jakieś realne szanse, że potencjalnemu napastnikowi uda wykonać się brute force? (pomijamy rzeczy takie jak backdoor na moim PC)

arecki · 2018-02-07 18:05:16

Tak mniej więcej:
1. Tworzy nowy łańcuch IN_SSH
2. Każde nowe połączenie ssh kieruje do łańcucha IN_SSH
3. Jeśli w ciągu 3 sekund zostaną zarejestrowane 3 nowe połączenia to każde kolejne jest porzucane
4. Jeśli w ciągu 1800 sekund zostaną zarejestrowane 4 nowe połączenia to każde kolejne będzie porzucane
5. Jeśli paczka przeszła pomyślnie przez powyższe sprawdziany to jest akceptowana.

http://compilefailure.blogspot.com/2011/04/better-s … ion-with.html
https://wiki.archlinux.org/index.php/simple_stateful_firewall
http://pcserver.uk/iptrecent.htm

Ostatnio edytowany przez arecki (2018-02-07 18:07:51)

morfik · 2018-02-07 19:21:27

gracz1010 napisał(-a):
Dobrze to interpretuje?

A do manuala nie możesz zajrzeć? Np tu:
http://ipset.netfilter.org/iptables-extensions.man.html#lbBW

Iptables to nie pole do interpretacji, tam zachodzą konkretne operacje. xD

Jacekalex · 2018-02-07 23:05:14

Ja kiedyś dawno temu (dokładnie całe 13 sekund temu), na jednym VPS miałem tak:

Kod:

-N SSH
iptables  -A INPUT -p tcp -m tcp -m multiport --dports 11541,23486 -m connlimit --connlimit-upto 10 --connlimit-mask 0 --connlimit-saddr -j SSH
iptables  -A SSH -m hashlimit --hashlimit-upto 5/hour --hashlimit-burst 2 --hashlimit-mode srcip --hashlimit-name ssh -j ACCEPT
iptables  -A SSH -j RETURN

Ponieważ jednak taki numer mnie też potrafi mocno przyblokować, małe uzupełnienie było potrzebne:

Kod:

ipset create brama hash:net maxelem 65535 timeout 86400 
iptables -t raw -I PREROUTING -m set --match-set brama src -j ACCEPT
iptables -I  INPUT -m set --match-set brama src -j ACCEPT

i taki mały skrypcik:
cat /etc/profile.d/sshbrama.sh

Kod:

#!/bin/sh


if [ -n "$SSH_CLIENT" ]; then 
    if [ "`id -u`" -eq 0 ]; then

    FROMIP=$(echo $SSH_CLIENT |awk '{print $1}' )
    ipset add brama $FROMIP  timeout  86400  --exist;
       fi
fi

Ilekroć zaloguję się na SSH do powłoki systemowej na konto root, automatycznie mój adres IP (z którego się połączyłem), jest dodawany do tablicy brama ipseta.

SOA#1

PS.
Jeżeli masz na VPSie IPv6, to tak samo robisz na IPv6.

Pozdro

Ostatnio edytowany przez Jacekalex (2018-03-05 17:20:36)

yossarian · 2018-02-08 13:34:48

gracz1010 napisał(-a):
Dobrze to interpretuje?

1. Zezwól na połączenie ssh
2/3. (Tutaj mam wątpliwości) 3 błędne próby = ban 10 s. czy 3 błębne próby w przeciągu 10 sec = ban forever?
4. Zezwól na połączenie jeśli nie zostało odfiltrowane przez powyższe reguły

Czy próby logowania są zapisywane w logach? bany są zapisywane w pamięci ram/w plikach? wolałbym aby pamięć nie została przepełniona bez mojej wiedzy.
Druga sprawa - jeśli logować przez ssh moge się tylko z mojeg IP to są jakieś realne szanse, że potencjalnemu napastnikowi uda wykonać się brute force? (pomijamy rzeczy takie jak backdoor na moim PC)

To nie działa na zasadzie jakiegoś banowania i tworzenia listy zbanowanych adresów.
Po prostu zbyt często nawiązywane nowe połączenia zostają zostają odrzucane przez netfilter.
Można to sobie podejrzeć w /proc (wirtualnym systemie plików). Przykładowo:

Kod:

cat /proc/net/xt_recent/sshbf

Do bardziej zaawansowanych ustawień można użyć narzędzia ipset

Jacekalex · 2018-02-08 22:51:26

Do bardziej zaawansowanych ustawień można użyć narzędzia ipset

Oj tam, oj tam, zaawansowanych ;)

Ipset najlepiej się sprawdza w tablicy RAW, na "portierni".

Tu jest metoda:
https://forum.dug.net.pl/viewtopic.php?pid=269383#p269383

A tu ostatni rezultat z jednego VPSa:

Kod:

root ~> ipset list wypad
Name: wypad
Type: hash:net
Revision: 6
Header: family inet hashsize 1024 maxelem 65535 timeout 3600
Size in memory: 12536
References: 5
Number of entries: 27
Members:
148.153.39.186 timeout 3451
202.29.215.226 timeout 60759
222.186.139.109 timeout 73503
113.102.213.237 timeout 598
45.76.45.199 timeout 82555
95.42.248.53 timeout 46342
212.237.46.179 timeout 43131
52.226.66.5 timeout 64074
211.60.83.218 timeout 83068
59.125.19.171 timeout 75906
125.160.224.67 timeout 64234
63.246.129.181 timeout 2590
60.190.104.228 timeout 2258
121.244.36.226 timeout 78579
60.23.29.186 timeout 3099
121.97.63.210 timeout 54396
5.188.10.179 timeout 84263
52.165.134.213 timeout 63621
220.178.61.54 timeout 658
89.218.138.250 timeout 50977
190.3.118.166 timeout 73530
200.111.8.59 timeout 56797
116.196.121.141 timeout 2684
122.176.97.120 timeout 49259
158.140.171.4 timeout 60287
190.72.57.144 timeout 68541
67.78.200.86 timeout 67059

Pozdro

Ostatnio edytowany przez Jacekalex (2018-02-08 22:52:17)

gracz1010 · 2018-02-09 13:13:24

Dziękówa Panowie za odpowiedzi. Powiedzcie mi jeszcze z czystej ciekawości - załóżmy, że nie zabezpieczam w żadnen sposób demona ssh przed brute force (oczywiście nie mam zamiaru tego robić-bezpieczenstwa nigdy mało) ale firewall przepuszcza tylko moje IP na zmienionym porcie ssh, to czy istnieje jakieś realne zagrożenie atakiem? Na logike wydaje mi się, że nie ale wole podopytać bardziej ogarniętych w temacie

Forum Debian Users Gang

Ogłoszenie

#1 2018-02-04 11:08:19

gracz1010 - Nowy użytkownik

Fail2ban, ssh - debian 8 bezpieczeństwo

#2 2018-02-04 21:07:19

Jacekalex - Podobno człowiek...;)

Re: Fail2ban, ssh - debian 8 bezpieczeństwo

#3 2018-02-07 13:10:11

gracz1010 - Nowy użytkownik

Re: Fail2ban, ssh - debian 8 bezpieczeństwo

#4 2018-02-07 13:52:03

yossarian - Szczawiożerca

Re: Fail2ban, ssh - debian 8 bezpieczeństwo

Kod:

#5 2018-02-07 14:26:36

gracz1010 - Nowy użytkownik

Re: Fail2ban, ssh - debian 8 bezpieczeństwo

#6 2018-02-07 18:05:16

arecki - Użytkownik

Re: Fail2ban, ssh - debian 8 bezpieczeństwo

#7 2018-02-07 19:21:27

morfik - Cenzor wirtualnego świata

Re: Fail2ban, ssh - debian 8 bezpieczeństwo

gracz1010 napisał(-a):

#8 2018-02-07 23:05:14

Jacekalex - Podobno człowiek...;)

Re: Fail2ban, ssh - debian 8 bezpieczeństwo

Kod:

Kod:

Kod:

#9 2018-02-08 13:34:48

yossarian - Szczawiożerca

Re: Fail2ban, ssh - debian 8 bezpieczeństwo

gracz1010 napisał(-a):

Kod:

#10 2018-02-08 22:51:26

Jacekalex - Podobno człowiek...;)

Re: Fail2ban, ssh - debian 8 bezpieczeństwo

Kod:

#11 2018-02-09 13:13:24

gracz1010 - Nowy użytkownik

Re: Fail2ban, ssh - debian 8 bezpieczeństwo

Stopka forum