Изпечатай

[Neoromantic]

Ситуацията е следната:
eth0: xxx.xxx.xxx.xxx //външен реален
eth1: 192.168.0.1

iptables -A POSTROUTING -t nat -s 192.168.0.0/24 -j SNAT --to-source xxx.xxx.xxx.xxx

Ще бъде ли добре да напиша:

#iptables -N firewall
#iptables -A firewall -m state --state ESTABLISHED, RELATED -j ACCEPT
#iptables -A firewall -m state --state NEW -i ! eth0 -j ACCEPT
#iptables -A INPUT -j block
#iptables -A FORWARD -j block
// от примера който е показан в статията
Искам да знам дали това ще бъде правилно?

[Dean79]

Доста простичък firewall, но ще свърши работа...май.
Аз те съветвам да филтрираш само определени портове.

[Neoromantic]

Ами аз имам следните отворени портове:

22 TCP
139 netbios ssn
445 microsoft ds

Откъде може да ми дойде атака?

445 microsoft ds

ne ti preporachvam da otvarqsh tozi port tam varvi virusat Slammer makar da nemoje da te zarazi teb ti shte zarazqvash drugite tova e moito mnenie

Добави и тези 3 реда ако искаш да спреш някой който се опитва да те сканира за отворени портове :

# iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
# iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
# iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

[Dean79]

Отворените ти портове ги филтрирай.

Dark Avenger: това въобще не е вярно.

free: за съжаление, така няма да спреш всякакво сканиране. Примерно SYN scan (nmap -sS) праща пакет със SYN, а не със SYN-FIN флагове вдигнати, което няма да се match-не от тези правила.

със -tcp-flags SYN SYN ефективно ще счупиш всякакво SYN сканиране, но други методи ще минат (stealth FIN, Xmas tree). Естествено, набухаш ли такова правило никой хост няма да успее да се свърже към теб (поне по tcp).

Анти-скенерските мерки са много сложна тема за разговор, може да се спретне една дискусия, обаче определено нещата не могат да се решат с няколко правила в iptables (освен ако не те урежда да имаш машина, до която не трябва да се осъществява никаква връзка - дори за домашен потребител това е брутален вариант - ще се прецакат всякакви p2p/skype/ftp transfers/irc DCC/dc++/etc неща)

Портовете 445 и 139 са съответно за netbios resolving (nmbd) и samba. Ако не шерваш нищо през самба дори няма нужда да ги филтрираш (а и в рамките на твоята локална мрежа не е особено желателно). Просто спри smbd/nmbd.

22/tcp е портът, който обикновено се използва от ssh. Ако не се връзваш отдалечено към твоята машина можеш да го филтрираш (но го направи културно с REJECT а не с DROP, за да не ти се сърдят някои хора '> )

/offtopic

Извинявам се за offtopic-a Gateway точно този въпрос ме измъчваше за SYN,SYN дали не пречи на някои p2p програми??значи счупих се да чета за този пусти iptables та то си е цяла наука да си настроиш firewall под Linux но въпреки всичко много ме радва,схване ли идеята човек после няма спирачки   '>

Ахм, пречи на всеки, който се опита да установи tcp връзка с теб, предполагам ще пречи и на някои п2п функции..

[VladSun]

Ето ти една Стара тема.

'>

ПП: Пробвай след това с ShieldsUP

[VladSun]

И тъй като напоследък много се радвам на recent-patch-a '> :

Примерен код

# SSH bruteforce attack protection $ipt -A INPUT -p tcp --dport 22 -m state --state RELATED,ESTABLISHED -j ACCEPT $ipt -A INPUT -p tcp --dport 22 -s 127.0.0.1 -j ACCEPT $ipt -A INPUT -p tcp --dport 22 -s XXX -j ACCEPT $ipt -A INPUT -p tcp --dport 22 -s YYY -j ACCEPT $ipt -A INPUT -p tcp --syn --dport 22 -m recent --name bad_ssh --update --seconds 60 -j DROP $ipt -A INPUT -p tcp --syn --dport 22 -m recent --name bad_ssh --set -j ACCEPT

Това ти позволява осъществяване на една единствена сесия към порт 22 в рамките на 60 сек. Ако през тия 60 сек. се пробваш с втора сесия, то почват нови 60 сек. на блокаж '> И всичко това "per IP"

XXX, YYY са ти IP-та, на които имаш вяра '> Можеш да слагаш колкото си искаш подобни редове.
Сега някой ще каже, че по ключ е по-добре да се достъпва SSH, но това не във всички случаи е най-удобния вариант.

ПП: Не забравяй да инсталираш recent-match-a като модул защото ще трябва да му задаваш по-големи стойности за IP-таблиците (по подр. е 100).

Хм, интересно, нямах идея за тва...

Тия хора кво ли не взеха да тикат в ядрото, крайно време е да спрат да merge-ват разни пачове и да направят една-две версии в която да има само bugfixing...

[VladSun]

/офф
Е, то recent-match-a е доста старичък (2003 г.) '>

За идеята за филтриране на ssh bruteforce мазни по такъв начин имах предвид.

А иначе за време в секунди, за което стои в списъка не знаех че можело. Имах някаква смътни спомени че може по броя получени вече match-нати пакети, но не и на база време. Както и да е, който чете той знае, който не чете - гледа учудено '>

[VladSun]

@ gat3way
1. прав си - и по брой пакети става (може и комбинация време-пакети) '>
2. аз пък имах предвид твоите думи "...Тия хора кво ли не взеха да тикат в ядрото, крайно време .. и т.н. "

По този начин, recent-match-a може да се използва вместо limit-match-a навсякъде, където това не е свързано с ограничаване на брой съобщения в логовете. Така защитите стават "по IP" и се избягва DoS при сработване на защитата.
Естествено има и лоша страна '> :
- не съм разглеждал лично кода на recent-match-a, но според коментарите, които съм чел търсенето по ИП става линейно '> .
- до колкото видях от опит, след като едно ИП влезе в списъка, то то не се маха никога (освен при изтриване на правилата или при експлицитно изтриване от списъка). T.e. няма логическа връзка между iptables правилата и списъците с ИП-та. По-естествено би било след изтичане на времето за съществуване на определено правило (логически), то съответното ИП да се маха от списъка. За съжаление според мен не е така (може би греша ?).