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/.
Witam!
Temat wiele razy poruszany, ale nie znalazłem tej konkretnej sytuacji (na pewno jest, bo mój ojciec miał na starym serwerze :D)
Serwer (klasy Serwer :D) - 2 karty sieciowe
eth0
eth1
eth0 ma być drogą do internetu
eth1 ma być drogą do mordoru (czyt. użytkowników)
Na razie "ma być" (bo chwilowo nie jest, ale przygotowuję go do okienka na życie) :D
http://gmclan.org/uploader/6184/firewall.txt
3 linijka jest zahaszowana, bo kolidowała z "blokowaniem portów"
Konkretnie moje blokowanie portów blokuje porty wszystkim - wewnątrz i na zewnątrz (chyba, że jest źle napisany i nie odblokowuje) - zresztą
http://gmclan.org/up6184_0_netwall.html
To ten pseudo-blokador :D
Chodzi mi o przykład jak blokować odpowiednio, by np. ktoś mógł spingować (serwer), ale nie mógł wejść na SSH (z zewnątrz)
Z góry dziękuję
Fervi
Offline
ekhm... patrząc na temat wątku i ostatnie zdanie... co ma wspólnego blokowanie portów z protokołem icmp?
Offline
Chodzi o przykład
Jak już będę wiedział jak to zablokować, to sobie dopiszę wszelkie reguły. Może być SSH jak ktoś chce
Fervi
Offline
na telefonie mi się fatalnie czyta a pisze jeszcze gorzej, ale coś w stylu (zakładając że br0 to twoje wyście do ungwenoru):
zablokuj połączenia przychodzące (INPUT) z interfejsu br0 z protokołem tcp na konkretny port (czyli dany port niewidoczny dla świata)
brakuje ci określenia interfejsu w regułach firewalla.
btw. domyślną polityką dla INPUT jest accept więc nie wiem cp ta trzecia linijka przeszkadzała... ale w tym pliczku nie widzę usuwania poprzednich reguł - może jakiś syf tam został
Ostatnio edytowany przez ethanak (2014-09-01 12:35:53)
Offline
Np. tak:
iptables -t filter -P INPUT DROP iptables -t filter -P FORWARD DROP iptables -t filter -P OUTPUT ACCEPT iptables -t filter -N tcp iptables -t filter -N udp iptables -t filter -N icmp_in iptables -t filter -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -t filter -A INPUT -i lo -j ACCEPT iptables -t filter -A INPUT -m conntrack --ctstate INVALID -j DROP iptables -t filter -A INPUT -p icmp -m conntrack --ctstate NEW -j icmp_in iptables -t filter -A INPUT -p udp -m conntrack --ctstate NEW -j udp iptables -t filter -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j tcp iptables -t filter -A INPUT -p tcp -j REJECT --reject-with tcp-reset iptables -t filter -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable iptables -t filter -A INPUT -j REJECT --reject-with icmp-proto-unreachable
I wrzucasz se regułkę od pingu do łańcucha do icmp_in:
iptables -t filter -A icmp_in -p icmp -i eth0 -j ACCEPT
Se ją dostosuj jak chcesz i tyle. Póki nie wrzucisz reguł do łańcuchów tcp/udp ten filter się będzie zachowywał jak zwykły klient z możliwością jego pingowania z interfejsu eth0. Jak masz strefę zaufaną, np. ten interfejs eth1, to sobie dorób odpowiednie regułki w łańcuchach tcp,udp,icmp_in by przepuszczał wszystkie pakiety ze stanem NEW z tego interfejsu:
iptables -t filter -A tcp -p tcp -i eth1 -j ACCEPT iptables -t filter -A udp -p udp -i eth1 -j ACCEPT iptables -t filter -A icmp_in -p icmp -i eth1 -j ACCEPT
I tyle.
Offline
#/bin/bash echo 1 > /proc/sys/net/ipv4/ip_forward iptables -F iptables -F -t nat iptables -F -t mangle iptables -P INPUT DROP iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT iptables -A INPUT -i eth0 -j ACCEPT iptables -A INPUT -i eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p tcp -i eth1 --dport 80 -j ACCEPT iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
to jest fragment mojego FW na dedyku
eth0 to if wewnętrzny
eth1 to if zewnętrzny
tą regułą otwierasz port:
iptables -A INPUT -p tcp -i eth1 --dport 80 -j ACCEPT
Ostatnio edytowany przez ramsi1986 (2014-09-01 18:03:29)
Offline
Co wyście się na te MASQUERADE uparli? Macie wszyscy zmienny IP z Neostrady czy co?
Dobry zwyczaj (jeśli masz stały adres IP, a podejrzewam że wszyscy w tym przypadku macie) to:
-j SNAT --to-source=mój.zewnętrzny.adres.ip
Przydaje się szczególnie, jeśli masz więcej niż jeden adres IP, a chcesz puścić maszyny za NAT-em konkretnym adresem
Offline
Może się uparli dla wygody, jak zmienią miejsce zamieszkania czy coś, to net im będzie działał OOTB i nie będą musieli przestawiać adresu w iptables. xD A poza tym co za różnica?
Offline
Maskarada jest po prostu wygodniejsza, jak masz jedną rurkę i jeden adres, mniej z nią kombinowania.
Jak jest tych adresów kilka, to też może być, ale nie musi być wygodniejsza, zależy, co pacjent chce dokładnie osiągnąć.
Offline
Cytatliwy cytat z Wielkiej Xięgi Proroka Manuala o iptables traktującej, rozdział o MASQUERADE:
It should only be used with dynamically assigned IP (dialup) connec‐
tions: if you have a static IP address, you should use the SNAT target.
I dalej wyjaśnione mniej więcej dlaczego.
Ale kto by tam te mądre księgi czytał... czytanie to dla cieniasów jest!
Offline
Księga to jedno, praktyka to drugie, ja zawsze najpierw sprawdzam MASQUERADE, jak nie teges, to wtedy SNAT, i zazwyczaj wszystko chodzi, jak powinno.
Trudniej będzie z Nftables, bo tam na razie maskarady chyba nie dowieźli.
Offline
W tej samej książce chyba piszą, też:
It is still possible to use the MASQUERADE target instead of SNAT even though you do have a static IP, however, it is not favorable since it will add extra overhead, and there may be inconsistencies in the future which will thwart your existing scripts and render them "unusable".
Ja kiedyś nawet się próbowałem dowiedzieć co się kryje pod tym "extra overhead" ale nikt nie wie. xD
Offline
Ja nawet kiedyś wiedziałem (co prawda dotyczyło to ipchains a nie iptables) - ale to było zbyt dawno aby pamiętać o co chodziło. Coś tam mi się majaczy na temat tablic conntrack ale to moga byc tylko majaczenia :)
Offline