[+] W
Rozumiem, że to logi z wyłączonym firewallem.
chyba powinno pomóc jak wpiszesz ta regułkę
zamiast
a jak nie to w ostateczności
ale mam nadzieję, że pierwsza zadziała.
chyba powinno pomóc jak wpiszesz ta regułkę
Kod: Zaznacz cały
iptables -A INPUT -s 192.168.1.0/24 -p udp --sport 137 -j ACCEPT
Kod: Zaznacz cały
iptables -A INPUT -s 192.168.1.0/24 -p udp --dport 137 -m state --state NEW -j ACCEPT
Kod: Zaznacz cały
iptables -A INPUT -s 192.168.1.0/24 -p udp -m multiport --dport 1024:65535 -j ACCEPT
Już doszedłem do tego! W międzyczasie widzę Grzesiek, że też wpadłeś na dobry trop. Generalnie załatwiło sprawę dopisanie dwóch linijek:
No i teraz chodzi w obie strony.
[Dodano: 2009-07-01, 00:25]
Aha, zapomniałem, że tcpdump był na włączonym firewallu.
Kod: Zaznacz cały
iptables -A INPUT -s 192.168.2.0/24 -p udp --sport 137 -j ACCEPT
iptables -A INPUT -s 192.168.2.0/24 -p udp --sport 138 -j ACCEPT
[Dodano: 2009-07-01, 00:25]
Aha, zapomniałem, że tcpdump był na włączonym firewallu.
Witam.
Mam mały problem z sambą. Najwyraźniej nie rozumiem mechanizmów, na których to działa. Otóż, wszystkie usługi działają na poniższych ustawieniach (co dziwne nie jest) a samba nie. Pytanie dlaczego?
Otwieram dostęp do serwera dla wszystkich hostów w sieci lokalnej. Pakiety powiązane mogą wychodzić z serwera więc wszystko powinno hulać, a w przypadku samby tak nie jest.
Mam mały problem z sambą. Najwyraźniej nie rozumiem mechanizmów, na których to działa. Otóż, wszystkie usługi działają na poniższych ustawieniach (co dziwne nie jest) a samba nie. Pytanie dlaczego?
Kod: Zaznacz cały
i=/sbin/iptables
$i -X
$i -F
$i -Z
$i -P INPUT DROP
$i -P FORWARD DROP
$i -P OUTPUT DROP
$i -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$i -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$i -A INPUT -s 192.168.1.0/24 -m state --state NEW -j ACCEPT
$i -A INPUT -m state --state INVALID -j DROP
Otwieram dostęp do serwera dla wszystkich hostów w sieci lokalnej. Pakiety powiązane mogą wychodzić z serwera więc wszystko powinno hulać, a w przypadku samby tak nie jest.
Włącz sobie logowanie w iptables i będziesz wiedział co blokuje twój firewall.
Do tego logowanie do innego pliku i zawsze wiesz co się dzieje.
Kod: Zaznacz cały
#domyslnie LOG i Reject
iptables -A INPUT -i ! lo -j LOG --log-prefix "INPUT DROP " --log-ip-options --log-tcp-options
Dobrze, spróbuję w pracy. Jednak, czy powyższe reguły nie powinny po prostu przepuszczać całego ruchu wejściowego i wyjściowego dla sieci lokalnej? Działa dla wszystkiego oprócz samby. Efekt jest taki, że czasem jest połączenie a czasem nie.
Dodane:
/etc/rsyslog.conf
Nie loguje nic...
Log sam działa, bo jak regułkę loga dam jako pierwszą to logi się pojawiają. A więc pakiety wchodzą i wychodzą. Ktoś ma jakieś wytłumaczenie?
Dodane:
Po długich testach stwierdziłem empirycznie, że problemem był brak reguły.
Tylko no właśnie, taka konfiguracja jest bez sensu i w ogóle można sobie ustawić domyślnie OUTPUT na ACCEPT. A ja chcę kontrolować wyjście. Najdziwniejsze jest to, zawężanie powyższego polecenia, np.:
powoduje, że samba jest blokowana. Ba, przy próbie uruchomienia skrypt stoi w miejscu i nie chce wystartować. Pytanie dlaczego powyższa reguła to blokuje?
Dodane:
Już mam. Miej logi i przeglądaj logi:
/var/log/samba/log.nmbd
A więc należy na początek ustawić regułkę:
I działa. Mam nadzieje, że zaoszczędzi to na przyszłość czasu wszystkim tym co chcą mieć sambę i jednocześnie blokować wyjście.
Dodane:
Kod: Zaznacz cały
i=/sbin/iptables
$i -X
$i -F
$i -Z
$i -P INPUT DROP
$i -P FORWARD DROP
$i -P OUTPUT DROP
$i -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$i -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$i -A INPUT -s 192.168.1.0/24 -m state --state NEW -j ACCEPT
$i -A INPUT -i ! lo -j LOG --log-level debug --log-prefix "INPUT DROP " --log-ip-options --log-tcp-options
$i -A INPUT -m state --state INVALID -j DROP
Kod: Zaznacz cały
kern.=debug -/var/log/iptables
Log sam działa, bo jak regułkę loga dam jako pierwszą to logi się pojawiają. A więc pakiety wchodzą i wychodzą. Ktoś ma jakieś wytłumaczenie?
Dodane:
Po długich testach stwierdziłem empirycznie, że problemem był brak reguły.
Kod: Zaznacz cały
$i -A OUTPUT -m state --state NEW -j ACCEPT
Kod: Zaznacz cały
$i -A OUTPUT -d 192.168.1.0/24 -m state --state NEW -j ACCEPT
Dodane:
Już mam. Miej logi i przeglądaj logi:
/var/log/samba/log.nmbd
Kod: Zaznacz cały
send_netbios_packet: send_packet() to IP 127.0.0.1 port 137 failed
Kod: Zaznacz cały
$i -A INPUT -d 127.0.0.1 -j ACCEPT
Najpierw przeczytaj artykuł Microsoftu: http://support.microsoft.com/kb/298804
Tam masz informacje jakie porty i jaki typ portu jest wykorzystywany przy udostępnianiu plików i drukarek, ponieważ mam wrażenie że tu jest uprawiana jakaś zgaduj-zgadula.
Tam masz informacje jakie porty i jaki typ portu jest wykorzystywany przy udostępnianiu plików i drukarek, ponieważ mam wrażenie że tu jest uprawiana jakaś zgaduj-zgadula.
Hej, dzięki. Akurat to co jest napisane na tej stronie, to wiem (jakie porty TCP i UPD, zresztą wpuszczam wszystko co pochodzi z LANu). Jak pewnie przeczytałeś powyżej, problemem było wypuszczenie ruchu do pętli zwrotnej, a tego akurat na cytowanej przez Ciebie stronce nie ma. Zgaduj zgadule, fakt uprawiałem, dopóki nie zajrzałem do loga samby.