Изпечатай

[User13]

Споделям примерен файл с правила за защитна стена на стандартна работна станция.
Има доста обстойни коментари и правила, които са неактивни.
Освен това искам да си кажете мнението, за подобна машина, коя политика по подразбиране за INPUT е по-добра и по-оптимална.
За сървър разбирам, че винаги се препоръчва DROP.

Код:

# Generated by iptables-save v1.6.0 on Sat May 20 20:13:37 2017
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]

# Veriga za loga
# :LOGNDROP - [0:0]

# Accepts all established inbound connections
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# If the line above doesn't work, you may be on a castrated VPS whose provider has not made
# available the extension, in which case an inferior version can be used as last resort:
# -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT

# The third rule will drop all traffic with an "INVALID" state match. Traffic can fall into four
# "state" categories: NEW, ESTABLISHED, RELATED or INVALID and this is what makes this a
# "stateful" firewall rather than a less secure "stateless" one. States are tracked using the
# "nf_conntrack_*" kernel modules which are loaded automatically by the kernel as you add rules.
-A INPUT -m conntrack --ctstate INVALID -j DROP
# This rule will drop all packets with invalid headers or checksums, invalid TCP flags,
# invalid ICMP messages (such as a port unreachable when we did not send anything to the host),
# and out of sequence packets which can be caused by sequence prediction or other similar attacks.
# The "DROP" target will drop a packet without any response,
# contrary to REJECT which politely refuses the packet.
# We use DROP because there is no proper "REJECT" response to packets that are INVALID,
# and we do not want to acknowledge that we received these packets.
# ICMPv6 Neighbor Discovery packets remain untracked,
# and will always be classified "INVALID" though they are not corrupted or the like.
# Keep this in mind, and accept them before this rule! iptables -A INPUT -p 41 -j ACCEPT

# Allow ping
#  note that blocking other types of icmp packets is considered a bad idea by some
#  remove -m icmp --icmp-type 8 from this line to allow all kinds of icmp:
#  https://security.stackexchange.com/questions/22711
# -A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT
# If not work
# -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
# or
# "Hide" your computer
# If you are running a desktop machine, it might be a good idea to block some incoming requests.
# Block ping request
# Current Enabled in sysctl
# net.ipv4.icmp_echo_ignore_all = 1

# Otvaryane na portove SSH, DNS - Server i drugi
# -A INPUT -p tcp --dport 22 -j ACCEPT
# or
# -A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT
# -A INPUT -p udp --dport 53 -j ACCEPT
# Open Port Transmission / ktorrent
-A INPUT -p tcp --dport 51413 -j ACCEPT
-A INPUT -p udp --dport 51413:51415 -j ACCEPT

# Drop za vsichki ostanali
-A INPUT -j DROP

# Izpolzva otdelna veriga za loga. Podhodyashto za INPUT DROP
# Log i drop za vsichki paketi, koito ne sa markirani v syshtestvuvashti pravila.
# Moje i konkretni pravila da se prehvyrlyat vuv verigata za log sys -j LOGNDROP
# -A INPUT -j LOGNDROP
# Za da raboti se izkl. -A INPUT -j DROP

#LOG - Zadavane na limit za lognatite paketi i syobshtenieto za tyah, kakto i metod za obrabotka.
# -A LOGNDROP -p tcp -m limit --limit 5/min -j LOG --log-prefix "Denied TCP: " --log-level 7
# -A LOGNDROP -p udp -m limit --limit 5/min -j LOG --log-prefix "Denied UDP: " --log-level 7
# -A LOGNDROP -p icmp -m limit --limit 5/min -j LOG --log-prefix "Denied ICMP: " --log-level 7

# Pravilo za verigata LOGNDROP
# -A LOGNDROP -j DROP

# Logging
# In the above examples none of the traffic will be logged. If you would like to log dropped packets to syslog,
# this would be the quickest way:
# -A INPUT -m limit --limit 5/min -j LOG --log-prefix "IPT Dropped: " --log-level 7
# Predi praviloto: -A INPUT -j DROP

COMMIT
# Completed on Sat May 20 20:13:37 2017

[growchie]

Да попитам, каква е идеята да имаме правило DROP в края на чейна, при положение, че просто политиката може да бъде DROP? Заради логването ли нещо? Не знам, но така правилата ти трябва да миксират DROP, ACCEPT, LOG и CHAIN таргети, а при политика DROP пишеш само ACCEPT, CHAIN или LOG таргети. По-четимо ми се струва. Освен това бих препоръчал да не се месят DROP и REJECT в една верига. В случая както е ползвано не мисля, че ще излезе проблем.

[User13]

По принцип не е проблем да се реализира лога и с INPUT - DROP.
Иначе специално за политиката по подразбиране за INPUT, примерно Ubuntu препоръчват ACCEPT. Arch препоръчват DROP, като създават и допълнителни вериги за TCP и UDP.
Общо взето дистрибуциите са разделени по отношение на политиката по подразбиране за INPUT. От друга страна за UFW, политиката е DROP.
Иначе за стена само с едно две правила има ли смисъл първо да се блокира всичко? Това дали няма да товари процесора допълнително?

[growchie]

Еми ти така и така го товариш със state правилото. То винаги се изпълнява първо, при DROP и при ACCEPT. Разлика май няма.

[User13]

Модифициран и преведен от от мен файл за защитна стена.
Ползван източник: https://wiki.archlinux.org/index.php/Simple_stateful_firewall
INPUT по подразбиране DROP:

Код:

*filter
# Политиката по подразбиране за веригата INPUT e DROP, за да се предотврати
# нежелан трафик поради някакъв пропуск в правилата. Премахване на целия трафик
# и определяне на това което е разрешено.
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

# Допълнителни потребителски вериги.
:TCP - [0:0]
:UDP - [0:0]
# Ако е необходим лог се активира.
# :LOGNDROP - [0:0]
# :LOGNREJECTUDP - [0:0]
# :LOGNREJECTTCP - [0:0]
# :LOGNREJECT - [0:0]

# Гарантираме, че приемаме само тези пакети, които искаме.
# Първото правило добавено във веригата INPUT, ще позволи само трафик, който
# принадлежи на установени съединения, или нов действителен трафик, свързан
# с тези съединения, такива като ICMP грешки или ехо отговори (пакети, които
# хоста връща при PING). Някои ICMP съобщения са много важни и помагат да се
# управляват претоварванията и MTU, те се приемат с това правило.
# Състоянието на връзката ESTABLISHED предполага, че при настройването на
# правилото или друго правило преди това е разрешило първоначалния опит за
# свързване (--ctstate NEW) или връзката вече е била активна
# (например активна отдалечена SSH връзка)
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# Ако има проблем с работата по dhcp (renewal time) да се активира:
# -A INPUT -p udp -m udp --sport 68 --dport 67 -j ACCEPT
# ------------------------------------------------------------------------------
# Забележка: DHCP заявките се изпращат от порт 68 на сървъра към порт 67
# на локалната машина. Понеже за изходящия трафик всичко е разрешено, обратното
# правило не е необходимо.
# ------------------------------------------------------------------------------

# Второто правило ще приеме целия трафик от интерфейса "loopback" (lo),
# който е необходим за много приложения и услуги.
# ------------------------------------------------------------------------------
# Забележка: Можете да добавите повече доверени интерфейси тук като "eth1",
# ако не искате / ще има нужда от трафик филтриран от защитната стена, но знайте,
# че ако имате NAT настройка, която пренасочва всякакъв вид трафик към този
# интерфейс от която и да е друга мрежа (да речем рутер), трафикът ще премине
# независимо от каквито и да било други настройки, които имате.
# ------------------------------------------------------------------------------
-A INPUT -i lo -j ACCEPT

# Третото правило ще забрани целия трафик за състояние маркирано като "INVALID"
# Трафика може да бъде маркиран в четири "състояния" категории: NEW,
# ESTABLISHED, RELATED или INVALID. Състоянията се проследяват с помощта на
# "nf_conntrack_ *" модули на ядрото, които се зареждат автоматично от него.
# ------------------------------------------------------------------------------
# Забележка: Това правило ще DROP всички пакети с невалидни заглавки или
# контролни суми, невалидни TCP флагове, невалидни съобщения ICMP
# (като port unreachable, когато ние не изпрати нищо към хоста), а също така и
# пакетите с последователност, която може да бъде предизвикана от прогнозни
# последователности или други подобни атаки.
# В "DROP" целта ще drop пакет без никакъв отговор, въпреки
# REJECT, което учтиво отказва пакета. Ние използваме DROP, защото няма правило
# за правилен "REJECT" отговор на пакети, които се считат за невалидни, а ние
# не искаме да признаем, че сме получили тези пакети.
# ICMPv6 Neighbor Discovery пакети остават непроследени и винаги ще бъдат
# класифицирани "INVALID" и ако те не са повредени или други подобни. Имайте
# това предвид, и ги приемайте преди това правило!
# -А INPUT -р 41 -j ACCEPT
# ------------------------------------------------------------------------------
-A INPUT -m conntrack --ctstate INVALID -j DROP

# Следващото правило ще приеме всички нови входящи ехо искания ICMP, известни
# още като пинг. Само първият пакет ще се смята за NEW, а останалите ще бъдат
# обработени от RELATED,ESTABLISHED правилото. Тъй като компютърът не е рутер,
# няма друг ICMP трафик със състояние NEW, който трябва да се допуска.
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT

# Прикачваме новосъздадените вериги TCP и UDP към веригата на INPUT, за да се
# обработят всички нови входящи връзки. След като връзката е приета TCP или UDP
# верига, тя се обработва от RELATED/ESTABLISHED правилото за трафик.
# TCP и UDP веригите или ще приемат нови входящи връзки, или учтиво ще ги
# отхвърлят. Нови TCP връзки трябва да бъдат започнати със SYN пакети.
# ------------------------------------------------------------------------------
# Забележка: NEW но не SYN е единственият невалиден TCP флаг който не е
# обхванат от INVALID състояниеto. Причината за това е, защото те са рядко
# злонамерени пакети, и те не трябва просто да бъдат премахвани. Вместо това,
# просто не ги приемаме, като ги отхвърляме с TCP RESET от следващото правило.
# ------------------------------------------------------------------------------
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP

# Отхвърляме TCP връзки с TCP RESET пакети и UDP потоци с ICMP port unreachable
# съобщения, ако портовете не се отворени. Това имитира подразбиране Linux
# (RFC съвместимo) поведение и позволява на подателя бързо да прекъснете връзката
# и да почисти.
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset

# За други протоколи, ние добавяме окончателно правило към веригата INPUT да
# отхвърли всичкия останал входящ трафик с icmp protocol unreachable съобщения.
# Това имитира поведението по подразбиране на Linux.
-A INPUT -j REJECT --reject-with icmp-proto-unreachable

# ------------------------------------------------------------------------------
# Отваряне на необходимите портове за входящи съединения.
# ------------------------------------------------------------------------------
# To allow remote SSH connections (on port 22):
# -A TCP -p tcp --dport 22 -j ACCEPT
# Transmission
-A TCP -p tcp --dport 51413 -j ACCEPT
-A UDP -p udp --dport 51413 -j ACCEPT
# За приемане на входящи TCP съединения на порт 80 за web server:
# -A TCP -p tcp --dport 80 -j ACCEPT
# За приемане на входящи TCP съединения на порт 443 за web server (HTTPS):
# -A TCP -p tcp --dport 443 -j ACCEPT
# За приемане на входящи UDP потоци на порт 53 за DNS server:
# -A UDP -p udp --dport 53 -j ACCEPT

# ------------------------------------------------------------------------------
# Правила за лог
# ------------------------------------------------------------------------------
# 1. Лог за всички пакети, които не са маркирани в съществуващи правила.
# Намираме правило "-A INPUT -j REJECT --reject-with icmp-proto-unreachable" и
# заменяме ""с -A INPUT -j LOGNREJECT или -A INPUT -j LOGNDROP
# 2. Прехвърляне на конкретни правила към веригата за лог "-j LOGNREJECTUDP".
# Пример: Намираме правило "-j REJECT --reject-with icmp-port-unreachable" и
# заменяме с "-j LOGNREJECTUDP" или съответно директно за DROP с -j LOGNDROP

# Задаване на лимит за логнатите пакети и съобщение за тях,
# както и метод за обработка. Аналогично и за друга лог верига.
# -A LOGNDROP -p tcp -m limit --limit 5/min -j LOG --log-prefix "Denied TCP: " --log-level 7
# -A LOGNDROP -p udp -m limit --limit 5/min -j LOG --log-prefix "Denied UDP: " --log-level 7
# -A LOGNDROP -p icmp -m limit --limit 5/min -j LOG --log-prefix "Denied ICMP: " --log-level 7

# Правила за веригите за лога: LOGNDROP / LOGNREJECT
# -A LOGNDROP -j DROP
# -A LOGNREJECTUDP -j REJECT --reject-with icmp-port-unreachable
# -A LOGNREJECTTCP -j REJECT --reject-with tcp-reset
# -A LOGNREJECT -j REJECT --reject-with icmp-proto-unreachable

COMMIT
# ------------------------------------------------------------------------------
# ПРЕПОРЪКИ
# ------------------------------------------------------------------------------
# "Скриване" на компютъра ви
# За настолна машина, може би е добре да блокирате някои входящи заявки.
# Блокиране на ping request
# Да се активира в sysctl
# net.ipv4.icmp_echo_ignore_all = 1

[petar258]

Важно за да не се сблъскате със странни проблеми. Трябва да се пропускат по протокол icmp във верига input: destination unreachable(type 3, code 0-1 и code 4), source quench(type 4 code 0), time exceeded(type 11 code 0), parameter problem(type 12 code 0), echo reply(type 0 code 0), при доставчици които ползват pppoe - echo request(type 8 code 0). За да минават заявките по dhcp трябва да е разрешен source port 68 към destination port 67 протокол udp за локалната мрежа във верига input.

[growchie]

Аз имам и едно друго правило което ползвам за подредбата на правилата. Оставям файърлола да поработи известно време и гледам къде има най-много пакети. Правилата с най-голям трафик ги качвам нагоре, тия които са най-рядко използвани - последни. В началото е трудно да се определи. Важно е да се знае, че пакет се траверсва до първо съвпадение.
Forward DROP е излишно ако имаш net.ipv4.ip_forward = 0 в sysctl.conf, както е по подразбиране. Тази верига се обработва само ако рутинг алгоритъма реши, че пакетът не е за тази машина и трябва та напусне към вътрешната/външната мрежа.

[User13]

По принцип не би трябвало да има проблем с DHCP поради правилото -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Тоест DHCP ще работи. Единствено може да възникне проблем с renewal time.
Добавянето на това правило:
-A INPUT -p udp -m udp --sport 68 --dport 67 -j ACCEPT
би трябвало да реши този проблем.
DHCP заявките се изпращат от порт 68 на сървъра към порт 67 на локалната машина. Понеже за изходящия трафик всичко е разрешено, обратното правило не е необходимо.

Относно разрешаването на повече ICMP codes не съм забелязал в различните примери в интернет, това да се прави масово. Това всеки сам трябва да прецени според нуждата.

Относно net.ipv4.ip_forward = 0 в sysctl.conf
Не е сигурно дали във всяка дистрибуция това е забранено. Добра практика е да се забрани в стената а дори да се дублира със sysctl не мисля, че е проблем.

Ето при мен на Manjaro как изглежда по подразбиране sysctl, само последното правило е добавено от мен:

Код:

]# sysctl --system
* Applying /usr/lib/sysctl.d/50-coredump.conf ...
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %e
* Applying /usr/lib/sysctl.d/50-default.conf ...
kernel.sysrq = 16
kernel.core_uses_pid = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.all.promote_secondaries = 1
net.core.default_qdisc = fq_codel
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
* Applying /etc/sysctl.d/50-max_user_watches.conf ...
fs.inotify.max_user_watches = 16384
* Applying /etc/sysctl.d/90-firewall.conf ...
net.ipv4.icmp_echo_ignore_all = 1

Примерния код по горе е редактиран, добавен е коментар за правилото за DHCP.