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
Cześć.
Chciałbym zapytać Was o opinię dotyczącą blokowania np. 50.000 adresów IP (wiadomo jakich).
Lepszym sposobem jest użycie pliku /etc/hosts.deny (format zapisu 'ALL: 1.2.3.4') czy
zastosowanie pliku blocked_ips dostępnego w konfiguracji DNSCrypt-Proxy?
Który ze sposobów jest według Was lepszy? Macie jakieś doświadczenia? W tym przypadku chodzi o zwykły desktop
na którym są testowane różne rozwiazania.
A przy okazji. Też macie bład OCSP przy próbie wejścia na stronę DUG? Kod błędu: SEC_ERROR_OCSP_SERVER_ERROR.
Odkomentowanie opcji dotyczącej odpytywania serwerów OCSP w ustawieniach przegladarki rozwiazuje ten problem.
Pozdro.
P.S.: prosze nie wspominać np. narzędzia ipset i tym podobnych.
Ostatnio edytowany przez wiarus (2022-03-10 10:19:32)
Offline
Nie wiem jakie adresy masz na myśli ale nie lepiej zrobić sobie peerguardian'a w oparciu o iptables i ipset (albo nftables)? xD
Offline
Cześć Morfik.
A prosiłem o nie pisanie o ipset i tym podobnych rozwiązaniach ;- )
Jeśli chodzi o adresy IP to powiedzmy, że chodzi o "malicious actors" i wszystko co się z tym wiąże.
No wiec, która z wymienionych metod, jest odpowiedniejsza, bardziej skuteczna (chociaż to zle słowo)?]
Pozdrawiam.
Edycja: a co z OCSP? Spotykasz/spotkałeś się z takim problemem? (Być może chodzi o stosowanie 'hard-fail' i stąd ten błąd u mnie przy próbie ładowania strony DUG...)
Ostatnio edytowany przez wiarus (2022-03-09 17:56:16)
Offline
Można i bez ipset, bo ipset jest uzupełnieniem iptables, a nftables bez problemu to robi natywnie, przykład:
table netdev traffic-control { set autoban { type ipv4_addr size 128000 flags dynamic,timeout timeout 1h } chain INGRESS { type filter hook ingress device "bond0" priority 0; policy accept; iif != "lo" ip saddr @autoban update @autoban { ip saddr timeout 1d } counter drop iif != "lo" tcp dport 22 add @autoban { ip saddr } counter drop } }
To działa w taki sposób, że jak ktoś się połączy na port 22, to jego ip zostanie dodane do listy autoban z czasem wygaśnięcia na 1h, a połączenie naturalnie zostanie zablokowane. Jak ten sam IP będzie chciał się łączyć znowu w czasie tej 1h, to odświeży sobie blokadę ale tym razem deadline będzie wynosił 24h xD.
Można też dodaj sobie IP na stałe. Poniżej przykładowa lista (generowana co dzień z list.iblocklist.com):
# cat /etc/nftables/sets/nft_set-bt_spyware.nft #!/usr/sbin/nft -f define bt_spyware = { 2.60.13.132, 4.21.117.128-4.21.117.159, 4.21.149.0-4.21.149.31, 4.43.44.32-4.43.44.63, 4.43.44.128-4.43.44.143, 4.43.119.0-4.43.119.127, ... 222.189.238.210, 222.216.28.25, 222.223.183.30, 222.237.76.91, 238.209.5.182, } add set ip raw-set bt_spyware { type ipv4_addr; flags interval; auto-merge; elements = $bt_spyware }
i reguły do blokowania:
# cat /etc/nftables/sets.nft #!/usr/sbin/nft -f create table ip raw-set #delete table ip raw-set create chain ip raw-set PREROUTING { type filter hook prerouting priority -301; policy accept; } create chain ip raw-set OUTPUT { type filter hook output priority -301; policy accept; } create chain ip raw-set peerblock-in create chain ip raw-set peerblock-out include "./sets/nft_set-bt_level1.nft" include "./sets/nft_set-bt_spyware.nft" include "./sets/nft_set-bt_webexploit.nft" include "./sets/nft_set-whitelist.nft" add rule ip raw-set PREROUTING meta iif !="lo" jump peerblock-in add rule ip raw-set OUTPUT meta oif !="lo" jump peerblock-out add rule ip raw-set peerblock-in ip saddr @whitelist counter accept add rule ip raw-set peerblock-out ip daddr @whitelist counter accept add rule ip raw-set peerblock-in ip saddr @bt_webexploit counter drop add rule ip raw-set peerblock-out ip daddr @bt_webexploit counter drop add rule ip raw-set peerblock-in ip saddr @bt_spyware counter drop add rule ip raw-set peerblock-out ip daddr @bt_spyware counter drop #add rule ip raw-set peerblock-in ip saddr @bt_level1 tcp sport vmap { 80:accept, 443:accept } counter drop #add rule ip raw-set peerblock-in ip saddr @bt_level1 udp sport vmap { 80:accept, 443:accept } counter drop #add rule ip raw-set peerblock-out ip daddr @bt_level1 tcp dport vmap { 80:accept, 443:accept } counter drop #add rule ip raw-set peerblock-out ip daddr @bt_level1 udp dport vmap { 80:accept, 443:accept } counter drop add rule ip raw-set peerblock-in ip saddr @bt_level1 tcp sport != { 80, 443 } counter drop add rule ip raw-set peerblock-in ip saddr @bt_level1 udp sport != { 80, 443 } counter drop add rule ip raw-set peerblock-out ip daddr @bt_level1 tcp dport != { 80, 443 } counter drop add rule ip raw-set peerblock-out ip daddr @bt_level1 udp dport != { 80, 443 } counter drop
Wrzuciłem przykłady, które akurat u mnie działają (wcześniej na iptables, teraz na nftables), by było łatwiej się zorientować WTF.
Także z nftables to jest banalnie proste. xD
Ostatnio edytowany przez morfik (2022-03-09 20:47:42)
Offline
Cześć.
Urbinek, ja używam tego narzędzia a pytanie, które zadałem dotyczy innych możliwości blokowania adresów IP.
Po prostu, jak wspomniałem, jest to zwykły desktop do testowania różnych rozwiązań. To wszystko.
W sposobach - o które pytam - nie ma przecież problemu aktualizacji listy tych adresów (zwykły skrypt plus cron itd.)
No cóż, nie otrzymałem odpowiedzi, ale dzięki za info :- )
Pozdrawiam.
Offline
Wiesz - gwoździa możesz wbić kombinerkami, butem, polanem... ale uwierz mi, młotek jest lepszy.
Offline
Strony: 1