przyk

[Menel]

dokładnie a w szczególności jak jest się w wewnętrznej sieci..z innej maszyny z poza naszej sieci puścić skan na bramę i wtedy wyjdą perełki a jak mamy bramkę dziurawą to i pozamykane porty na lokalnym kompie gówno dadzą

[Hypnos]

cat /var/log/messages | grep -i skan | less

<tutaj data i godzina> hypnos-deb kernel: [ 5568.427801] skanowanie NullIN=wlan0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=173.194.44.23 DST=x.x.x.x LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=9579 PROTO=TCP SPT=443 DPT=59062 WINDOW=0 RES=0x00 RST URGP=0

173.194.44.23 to google, więc ponawiam pytanie o ten parametr -m bo zależy mi by logowało takie kwiatki, natomiast nie musi robić tego 10 razy na minutę. Mnie wychodzą takie perełki od czasu do czasu

[Yampress]

localhosta sie nie skanuje !!!!! 127.0.0.1

przeskanuj z innej maszyny IP swoje i wtedy zobacz.



poza tym gdybyś cokolwiek wiedział o tworzeniu reguł w iptables od razu byś wiedział , że

iptables -A INPUT -i lo -j ACCEPT

pozwala na ruch w obrębie pętli zwrotnej, a co za tym idzie będziesz widział otwarte porty skanując localhost z localhosta.

[Hypnos]

localhosta sie nie skanuje !!!!! 127.0.0.1 poza tym gdybyś cokolwiek wiedział...

Masz rację niewiele wiem. Dzisiaj mój pierwszy w życiu kontakt z iptables

[Menel]

ja tam siedzę za natem to mogę sobie nawet wszystko pootwierać u siebie na kompie ale dla zasady mam wszystko zawekowane a nóż komuś w mojej prywatnej sieci odbije i zacznie się bawić w hakiera

[mberg]

Osobiście zamiast modułu conntrack użyłbym -m state --state (NEW,ESTASBLISHED,INVALID,RELATED) dzięki temu nie trzeba definiować wszystkich bitow dla flag tcp - samo INALID klasyfikuje wszystkie możliwe kombinacje, które nie pasują do zsychronizowanego połączenia. Jeżeli chodzi o ilość modułów, to możesz używać ich dowolną ilość - należy tylko pamiętać, że jeśli na przykład definiujesz -m multiport --dports 22,23 to osobno musisz zdefiniować moduł dla src portów (-m multiport --sports ...).

Odnośnie sprawdzania portów: używaj plecenia netstat, które poda ci wszystkie porty (TCP/UDP), na których słuchają twoje usługi razem ze zbindowanymi portami, lub z którymi ustanowiono połączenie (opcjonalnie możesz użyć też lsof, sockety tak jak wszystko w linuxie to po prostu pliki). podczas skanowania , zależnie od tego czy podasz adres pętli zwrotnej czy swój prywatny adres dostępny w LAN-ie, wynik nmap'a będzie inny. Dla bezpieczeństwa warto jest włączać niektore usługi (jak daemony pocztowe) na pętlach zwrotnych - dostęp do takiej usługi dla klienta będzie możliwy tylko w momencie kiedy odpalisz odpowiedni tunel/VPN. Najlepiej też pobawić się z różnymi skanowaniami -sS -sA -sU, etc. Jakbyś chciał śledzić pakiety tworzone przez nmapa dla pewniejszego zrozumienia jego działania to polecam użycie opcji --packet-trace...lub po prostu odpalić sniffera.

[Hypnos]

Dzięki. Właśnie tak zrobiłem. Okazało się że reguły wychwytujące skanowanie (te z pierwszego mojego posta były błędne i skanowanie pozostawało niezauważone), odkryłem (hehe) , że zamiast wymieniać wszystkie flagi można użyć ALL lub wymienić tylko te które mają być sprawdzane po lewej stronie formuły a po prawej te, przy których bity mają być zapalone. Dodatkowo warto pobawić się w statystyki we własnej sieci i reguły, które są najczęściej używane dać wcześniej, by zoptymalizować szybkość zapory. Generalnie pożyczyłem sobie dwie książki i zgłębiam wiedzę na ten temat. Po przeczytaniu i sprawdzeniu tego na testowo skleconej sieci zrozumiałem swój błąd i poznałem siłę jaka drzemie w iptables. Dodatkowo zauważyłem że większość dostępnych w sieci skryptów jest po prostu błędnie napisana, lub inaczej mówiąc jeden skrypt bezmyślnie sklecony z kilku, kilkunastu innych (jak ten mój z pierwszego posta). Dopiero po zabawach z pcapdump'em i nmap'em widać, że to nie ma prawa działać i dlaczego. Dzięĸi i pozdrawiam