Forum Debian Users Gang

Cześć, dzięki za odpowiedź.

Mam właśnie taką regułę, jaką podałeś, w firewall'u (na razie zakomentowana), ale podałem "szybszy" do napisania na forum wariant :-) Po zwiększeniu tej wartości można też zastosować taką regułę, która powinna wyłapać nietypowe wartości:

-A PREROUTING -p tcp -m conntrack --ctstate NEW -m tcpmss ! --mss 536:65535 -j DROP

Nie jest to lepsze rozwiązanie, ze względu na łańcuch PREROUTING? To tylko przykład.

W każdym razie, sprawdzę później tę wartość '536' i odkomentuję wspomnianą regułę.

Ostatnio edytowany przez wiarus (2021-08-26 10:08:54)

Ok, dzięki. Czyli, w sumie, pozostaje reguła, którą napisałeś w poprzedniej wiadomości (do czasu przejścia na nft).

Pozdro.

Co do  CVE-2019-11479, to tu piszą, że to już dawno załatane:
https://vuldb.com/?id.136652

Także zarówno Gentuś jak i OpenWRT mam już raczej odporne:
np router:

OpenWrt 21.02-SNAPSHOT, r16263-4003eeab35
Linux Router 5.4.137 #0 Mon Aug 2 20:42:46 2021 mips GNU/Linux

Pozdro

Ostatnio edytowany przez Jacekalex (2021-08-26 19:20:54)

Hmm, po przeanalizowaniu doszedłem do wniosku, że coś tutaj chyba jednak nie działa za dobrze. xD

Generalnie to piszą, że ten net.ipv4.tcp_min_snd_mss ma zmienić po cichu wartość MSS na tę którą się tutaj określi. No to sprawdziłem jak sprawa wygląda przy pomocy maszyny wirtualnej, gdzie do trasy domyślnej dodałem sobie advmss 100. Ten parametr ma wymusić w pakietach SYN ustawienie MSS na 100. No i potem z maszyny wirtualnej próbowałem połączyć się via ssh na mojego kompa. Podejrzałem co tam wireshark zanotował, no i widzę MSS w pakiecie SYN ustawiony na 100, a nie 536 (być może to jest to zwiększenie MSS po cichu). xD

Próbowałem przepisać wszystkie ustawienia od MSS w sysctl, tj. te poniższe:

# sysctl -a | egrep -i "mss|mtu"
net.ipv4.ip_forward_use_pmtu = 0
net.ipv4.ip_no_pmtu_disc = 0
net.ipv4.route.min_adv_mss = 536
net.ipv4.route.min_pmtu = 536
net.ipv4.route.mtu_expires = 600
net.ipv4.tcp_base_mss = 536
net.ipv4.tcp_min_snd_mss = 536
net.ipv4.tcp_mtu_probe_floor = 536
net.ipv4.tcp_mtu_probing = 1

net.ipv6.conf.all.accept_ra_mtu = 1
net.ipv6.conf.all.mtu = 1280
net.ipv6.conf.default.accept_ra_mtu = 1
net.ipv6.conf.default.mtu = 1280
net.ipv6.route.min_adv_mss = 1220
net.ipv6.route.mtu_expires = 600

No i przy próbie połączenia dalej widzę w pakiecie SYN z maszyny wirtualnej MSS 100.

Nie wiem czy MSS jest ustawiony jedynie w pakiecie i po tym jak trafia do kernela, to ten mu go zwiększa, bo nawet jeśli robi to po chichu, to nie ma tego jak zweryfikować. xD Za to reguła na zaporze łapie ten zaniżony MSS:

# nft list table inet raw
table inet raw {
        chain PREROUTING {
                type filter hook prerouting priority raw; policy accept;
                tcp flags & (syn | rst) == syn tcp option maxseg size 1-500 counter packets 51 bytes 3060 drop
        }

        chain OUTPUT {
                type filter hook output priority raw; policy accept;
        }
}

Więc teoretycznie ta regułka poprawia bezpieczeństwo, bo blokuje ten niski MSS zanim kernel coś z tym pakietem będzie później robił.

Także nie wiem co o tym myśleć ale sobie te regułkę na wszelki wypadek zostawię. xD