Forum Debian Users Gang

Nicram · 2016-02-27 09:56:50

[quote=Jacekalex]Tak to działało do niedawna, ale teraz coś się zmieniło w ipsecie, już pokazuje timeouty (jak w poleceniu tworzenia dałem [b]timeout 3600[/b]), ale nikt jeszcze nie dostał 86400, więc nie wiem, czy bierze 3600 z domyślnej wartości, czy z regułki nr 2 w przykładzie.
Jutro będę znał więcej szczegółów. :D[/quote]
Przy tworzeniu ipseta podanie timeoutu ustawia go defaultowo.
Teraz jak dodasz do ipseta coś bez podawania timeoutu to zostanie wykorzystany defaultowy, jak podasz jakąś wartość to zostanie ustawiona ta

Jacekalex · 2016-02-27 12:05:27

[quote=Nicram][quote=Jacekalex]Tak to działało do niedawna, ale teraz coś się zmieniło w ipsecie, już pokazuje timeouty (jak w poleceniu tworzenia dałem [b]timeout 3600[/b]), ale nikt jeszcze nie dostał 86400, więc nie wiem, czy bierze 3600 z domyślnej wartości, czy z regułki nr 2 w przykładzie.
Jutro będę znał więcej szczegółów. :D[/quote]
Przy tworzeniu ipseta podanie timeoutu ustawia go defaultowo.
Teraz jak dodasz do ipseta coś bez podawania timeoutu to zostanie wykorzystany defaultowy, jak podasz jakąś wartość to zostanie ustawiona ta[/quote]
Zgadza się, już mam wyniki:

Kod:

ipset list wypad
Name: wypad
Type: hash:net
Revision: 6
Header: family inet hashsize 1024 maxelem 65535 timeout 3600
Size in memory: 2848
References: 4
Members:
103.56.112.243 timeout 1852
212.83.135.73 timeout 65582
183.60.48.25 timeout 84252
61.153.107.73 timeout 84190
180.97.215.72 timeout 3520
91.122.27.205 timeout 58601
194.63.140.74 timeout 61191
193.104.41.141 timeout 52225
1.93.1.142 timeout 48393

Po prostu w działaniu ipseta zaszła chyba malutka zmiana, ale to na szczęście nie jest żaden poważny problem.

Ostatnio edytowany przez Jacekalex (2016-02-27 12:38:40)

Nicram · 2016-02-27 14:29:18

Z drugiej strony, takie ustawianie bana już na pierwszym połączeniu na tak długi czas to chyba w pewnych sytuacjach może być strzałem w kolano. Co jeśli z szybkości źle wprowadzimy hasło? ssh zamknie połączenie a my w tym czasie będziemy nawiązywali drugie i ban na cały dzień.
fakt, tu przydaje się "dodatkowy" serwer.
ale moim zdaniem lepiej pierwszego timeouta ustawić na 60s, wtedy wiemy, że jak coś skopaliśmy za pierwszym razem to musimy chwilę odczekać a nie cały dzień. boty złapią się na te 60s.

Jacekalex · 2016-02-27 14:44:18

To nie jest regułka na usługi dla pacjentów, tylko na ochronę krytycznych usług, gdzie tylko zaufane osoby mogą się logować.

W praktyce opisana w wątku o ipset autoban konfiguracja stanowi elegancką "[url=http://x3.cdn03.imgwykop.pl/c3201142/comment_fbcrSdcfVIgpwYKVdm7GgAmlRWb8R69C,wat.jpg]śrutówkę[/url]" na skanery portów.

Zawsze też możesz łączyć różne moduły netfiltera do uzyskania pożądanego efektu, np:

Kod:

iptables -A INPUT -p tcp --dport 22 -m hashlimit \
  --hashlimit-mode srcip --hashlimit-above 3/minute --hashlimit-burst 1 -j SET --add-set wypad src --timeout 3600

Linux ma bardzo dużo narzędzi obrony przed potencjalnymi atakami, każdy może sobie dobrać takie, które najlepiej pasują do jego konfiguracji, pod warunkiem,
że jest świadom istnienia i zasady działania tych narzędzi.

Ja staram się na krytycznych usługach jak SSH czy *SQL w ogóle nie używać haseł tylko kluczy kryptograficznych w standardach SSH2, X509 albo PKCS#12,
w zależności od usługi.

Pozdro

Ostatnio edytowany przez Jacekalex (2016-02-27 14:49:36)

Nicram · 2016-02-28 14:52:26

chcę zrobić na serwerze brzegowym zabezpieczenie przed DDoS na DNS i NTP.
Z tym, że w sieci mam osobiście takie serwery i być może któryś z klientów też i nie chciałbym im tego blokować.
wymyśliłem, że zrobię to analogicznie ale chcę by pierwsze pakiety nie były blokowane a jeśli w przciągu 5 s pojawią się nowe to wówczas ban na dłużej.
zrobiłem coś takiego:

Kod:

# Generated by iptables-save v1.4.14 on Sun Feb 28 14:45:36 2016
*raw
:PREROUTING ACCEPT [623316849:486932354078]
:OUTPUT ACCEPT [659696:187238493]
-A PREROUTING ! -i lo -p udp -m multiport --dports 53,123 -m set --match-set ddos dst -j SET --add-set ddos dst --exist --timeout 3600
-A PREROUTING -d 192.9.32.0/21 ! -i lo -p udp -m multiport --dports 0,53,123 -j SET --add-set checkDDoS dst
-A PREROUTING -d 32.11.232.0/21 ! -i lo -p udp -m multiport --dports 0,53,123 -j SET --add-set checkDDoS dst
-A PREROUTING -m set --match-set checkDDoS dst -j SET --add-set checkDDoS dst --exist --timeout 60
COMMIT
# Completed on Sun Feb 28 14:45:36 2016
# Generated by iptables-save v1.4.14 on Sun Feb 28 14:45:36 2016
*filter
:INPUT ACCEPT [21615:3810964]
:FORWARD ACCEPT [111520904:87636931130]
:OUTPUT ACCEPT [122949:34821937]
:fail2ban-named-refused-tcp - [0:0]
:fail2ban-ssh - [0:0]
:fail2ban-ssh-ddos - [0:0]
-A INPUT -p tcp -m multiport --dports 53,953 -j fail2ban-named-refused-tcp
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh-ddos
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A FORWARD -p udp -m multiport --dports 53,123 -m set --match-set ddos dst -j DROP
-A FORWARD -d 32.11.232.192/28 -p udp -m udp --sport 123 -j DROP
-A FORWARD -d 32.11.232.192/28 -p udp -m udp --dport 123 -j DROP
-A FORWARD -p udp -m set ! --match-set servers dst -m multiport --dports 53,123 -m set --match-set checkDDoS dst -j DROP
-A fail2ban-named-refused-tcp -j RETURN
-A fail2ban-ssh -j RETURN
-A fail2ban-ssh-ddos -j RETURN
COMMIT
# Completed on Sun Feb 28 14:45:36 2016

zrobiłem ręcznie ipseta o nazwie ddos, gdzie właśnie w nocy walczyłem z tym ruchem.
na potrzeby zapobiegania zrobiłem ipseta checkDDoS i tu właśnie chcę limitować. checkDDoS ma defaultowo ustawiany timeout 5s.
chciałym aby pierwsze połączenie z sieci do ipka wewnątrz przeszło a jesli w ciągu 5 sekund pojawi się kolejne to wtedy update na kolejny czas i DROP dalej.
pomińmy na razie tego fail2bana i dropowanie 123 dla 32.11.232.192/28

to to powyżej zrobiłem nie przepuszcza pierwszego pakietu.
może jakiś mały fix i podpowiedź.
z góry dzięki.

Ostatnio edytowany przez Nicram (2016-02-28 14:53:52)

Jacekalex · 2016-02-28 14:58:04

:INPUT ACCEPT [21615:3810964][/quote]
Czy Ty pierwszy raz w życiu netfiltera konfigurujesz? :D

Pokaż lepiej wyniki w formacie:
Kod:
iptables -t raw -S
iptables -t filter -S
są dużo czytelniejsze, niż wyjście z iptables-save czy z iptables -Ln.
Kod:
:OUTPUT ACCEPT [122949:34821937]
tutaj też nie wypuszczałbym całego systemu, ale tylko niektóre usługi i programy, które dostępu do netu bezwzględnie potrzebują.
Dzięki modułom [b]owner[/b] i [b]cgroup[/b] filtrowanie OUTPUT jest dosyć banalne.

Te łańcuchy fail2ban* istnieją tylko w FW, czy jeszcze fail2ban w tle coś miesza?
Jak nie możesz żyć bez fail2bana, to zrób mu tablicę ipseta i niech pakuje adresy do tablicy ipseta, a nie robi burdel w regułach firewalla.

Skąd się biorą adresy w tablicy [b]ddos[/b] ipseta, których używasz jako dopasowania w pierwszej regule tablicy RAW?

Ostatnio edytowany przez Jacekalex (2016-02-28 15:06:31)
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)

Time (s)	Query
0.00015	SET CHARSET latin2
0.00004	SET NAMES latin2
0.00150	SELECT u., g., o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='18.216.53.7' WHERE u.id=1
0.00079	REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '18.216.53.7', 1732744963)
0.00056	SELECT * FROM punbb_online WHERE logged<1732744663
0.00070	DELETE FROM punbb_online WHERE ident='18.219.15.112'
0.00059	SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=28321 AND t.moved_to IS NULL
0.00006	SELECT search_for, replace_with FROM punbb_censoring
0.00112	SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=28321 ORDER BY p.id LIMIT 25,25
0.00078	UPDATE punbb_topics SET num_views=num_views+1 WHERE id=28321
Total query time: 0.00629 s

Forum Debian Users Gang

Ogłoszenie

#26 2016-02-27 09:56:50

Nicram - Użytkownik

Re: iptables - gdzie robię błąd

#27 2016-02-27 12:05:27

Jacekalex - Podobno człowiek...;)

Re: iptables - gdzie robię błąd

Kod:

#28 2016-02-27 14:29:18

Nicram - Użytkownik

Re: iptables - gdzie robię błąd

#29 2016-02-27 14:44:18

Jacekalex - Podobno człowiek...;)

Re: iptables - gdzie robię błąd

Kod:

#30 2016-02-28 14:52:26

Nicram - Użytkownik

Re: iptables - gdzie robię błąd

Kod:

#31 2016-02-28 14:58:04

Jacekalex - Podobno człowiek...;)

Re: iptables - gdzie robię błąd

Kod:

Kod:

#32 2016-02-29 14:13:51

Nicram - Użytkownik

Re: iptables - gdzie robię błąd

Kod:

#33 2016-02-29 17:34:57

Nicram - Użytkownik

Re: iptables - gdzie robię błąd

Kod:

#34 2016-02-29 17:51:42

Nicram - Użytkownik

Re: iptables - gdzie robię błąd

Kod:

Kod:

#35 2016-02-29 18:16:25

Jacekalex - Podobno człowiek...;)

Re: iptables - gdzie robię błąd

#36 2016-02-29 20:04:39

Nicram - Użytkownik

Re: iptables - gdzie robię błąd

Stopka forum

Informacje debugowania