На първо място, всички кредити отиват в @ЮкитеруАмано, тъй като тази публикация е базирана на настойнически сте публикували във форума. Разликата е, че ще се съсредоточа върху Арка, въпреки че вероятно ще работи за други дистрибуции въз основа на systemd.
Какво е Firehol?
firehol, е малко приложение, което ни помага да управляваме защитната стена, интегрирана в ядрото и неговия инструмент IPTABLES. На Firehol липсва графичен интерфейс, цялата конфигурация трябва да се извършва чрез текстови файлове, но въпреки това конфигурацията все още е проста за начинаещи потребители или мощна за тези, които търсят разширени опции. Всичко, което Firehol прави, е максимално да опрости създаването на правила на iptables и да осигури добра защитна стена за нашата система.
Инсталиране и конфигуриране
Firehol не е в официалните хранилища на Arch, затова ще се позовем AUR.
yaourt -S firehol
След това отиваме в конфигурационния файл.
sudo nano /etc/firehol/firehol.conf
И ние добавяме правилата там, можете да използвате estas.
Продължавайте да активирате Firehol за всяко стартиране. Доста просто със systemd.
sudo systemctl enable firehol
Започнахме Firehol.
sudo systemctl start firehol
Накрая проверяваме дали правилата на iptables са създадени и заредени правилно.
sudo iptables -L
Деактивирайте IPv6
Както firehol не се справя ip6tables и тъй като повечето от нашите връзки нямат поддръжка за IPv6, препоръката ми е да го деактивирате.
En Арка добавяме ipv6.disable = 1 към линията на ядрото във файла / etc / default / grub
...
GRUB_DISTRIBUTOR="Arch"
GRUB_CMDLINE_LINUX_DEFAULT="rw ipv6.disable=1"
GRUB_CMDLINE_LINUX=""
...
Сега регенерираме grub.cfg:
sudo grub-mkconfig -o /boot/grub/grub.cfg
En Debian стига с:
sudo echo net.ipv6.conf.all.disable_ipv6=1 > /etc/sysctl.d/disableipv6.conf
Не разбирам. Следвате ли урока и вече сте включили защитната стена и всички връзки са блокирани? Друго нещо Урокът за Arch е сложен, например никога не съм използвал sudo или yaourt Firewall. Обаче е Разбрано. Или може би някой нов ви пише и ще получи грешка. За Манджаро е по-правилно.
Докато казвате @felipe, следвайки урока и поставяйки във файла /etc/firehol/firehol.conf правилата, дадени от @cookie в пастата, вече ще имате проста защитна стена за защита на системата на основно ниво. Тази конфигурация работи за всеки дистрибутор, където можете да поставите Firehol, с особеността на всеки дистрибутор, който обработва услугите си по различни начини (Debian чрез sysvinit, Arch с systemd), а що се отнася до инсталацията, всеки знае какво има, в Arch трябва използвайте AUR и yaourt репозиториите, в Debian официалните са достатъчни и така в много други, просто трябва да потърсите малко в хранилищата и да адаптирате командата за инсталиране.
Мисля, че Юкитеру вече е изяснил вашите съмнения.
Сега, относно sudo и yaourt, от моя страна не считам sudo за проблем, просто трябва да видите, че той идва по подразбиране, когато инсталирате основната система на Arch; и yaourt е по избор, можете да изтеглите tarball, да го разархивирате и да инсталирате с makepkg -si.
благодаря, отбелязвам.
Нещо, което забравих да добавя към публикацията, но не мога да го редактирам.
https://www.grc.com/x/ne.dll?bh0bkyd2
На този сайт можете да тествате вашата защитна стена 😉 (отново благодаря на Yukiteru).
Проведох тези тестове на моя Xubuntu и всичко излезе перфектно! Каква наслада да използвам Linux !!! 😀
Всичко това е много добро ... но най-важното нещо липсва; Трябва да обясните как се създават правилата !!, какво означават те, как да създавате нови ... Ако това не е обяснено, това, което поставяте, е от малка полза: - /
Създаването на нови правила е лесно, документацията за firehol е ясна и много точна по отношение на създаването на персонализирани правила, така че четенето малко ще ви улесни да го персонализирате и адаптирате към вашите нужди.
Мисля, че първоначалната причина за публикацията @cookie като моята във форума беше да се даде на потребителите и читателите инструмент, който им позволява да дадат на компютрите си малко повече сигурност, всичко на основно ниво. Останалото остава за вас, за да се адаптирате към вашите нужди.
Ако прочетете връзката към урока на Yukiteru, ще разберете, че намерението е да се публикува приложението и конфигурацията на основна защитна стена. Поясних, че публикацията ми е само копие, фокусирано върху Арх.
И това е „за хората“? o_O
Опитайте Gufw на Arch: https://aur.archlinux.org/packages/gufw/ >> Щракнете върху Статус. Или ufw, ако предпочитате терминал: sudo ufw enable
Вече сте защитени, ако сте нормален потребител. Това е „за хората“ 🙂
Firehol наистина е Front-End за IPTables и ако го сравним с последния, това е доста човешко 😀
Считам ufw (Gufw е само негов интерфейс) като лош вариант по отношение на сигурността. Причина: за повече правила за сигурност, които написах в ufw, не можах да избегна, че при тестовете на защитната ми стена, както през мрежата, така и тези, извършвани с помощта на nmap, услуги като avahi-daemon и exim4 ще изглеждат отворени и само "стелт" атака беше достатъчна, за да знам най-малките характеристики на моята система, ядро и услуги, които е изпълнявала, нещо, което не ми се е случвало при използване на firehol или arno's firewall.
Е, не знам за вас, но както писах по-горе, използвам Xubuntu и защитната ми стена върви с GUFW и преминах ВСИЧКИ тестове на линка, които авторът постави без проблеми. Всички стелт. Нищо отворено. Така че, от моя опит ufw (и следователно gufw), те са чудесни за мен. Не съм критичен към използването на други режими за управление на защитната стена, но gufw работи безупречно и дава страхотни резултати за сигурността.
Ако имате някакви тестове, които според вас могат да хвърлят уязвимости в моята система, кажете ми какви са те и аз с удоволствие ще ги пусна тук и ще ви уведомя за резултатите.
По-долу коментирам нещо по темата ufw, където казвам, че грешката видях през 2008 г., използвайки Ubuntu 8.04 Hardy Heron. Какво вече са коригирали? Най-вероятното е, че е така, така че няма причина да се притеснявате, но дори и така, това не означава, че бъгът е бил там и бих могъл да го докажа, въпреки че не беше лошо да умра, само спрях демоните avahi-daemon и exim4 и проблемът вече е решен. Най-странното от всичко е, че проблем имат само тези два процеса.
Споменах факта като личен анекдот и дадох същото мнение, когато казах: «Смятам ...»
Поздрави 🙂
+1
@Yukiteru: Опитахте ли от собствения си компютър? Ако търсите от вашия компютър, нормално е да имате достъп до X сервизния порт, тъй като трафикът, който е блокиран, е от мрежата, а не от localhost:
http://www.ubuntu-es.org/node/140650#.UgJZ3cUyYZg
https://answers.launchpad.net/gui-ufw/+question/194272
Ако не, моля, докладвайте за грешка 🙂
Поздрави 🙂
От друг компютър, използващ мрежа Lan в случай на nmap, и чрез мрежата, използваща тази страница https://www.grc.com/x/ne.dll?bh0bkyd2Използвайки опцията за персонализирани портове, двамата се съгласиха, че avahi и exim4 слушат от мрежата, въпреки че ufw има конфигурирано блокиране.
Тази малка подробност за avahi-daemon и exim4 го реших, като просто деактивирах услугите и това е ... По това време не докладвах за грешка и мисля, че няма смисъл да го правя сега, защото това беше през 2008 г., използвайки Харди.
2008 г. беше преди 5 години; от Hardy Heron до Raring Ringtail има 10 * buntus. Същият тест на моя Xubuntu, направен вчера и повторен днес (август 2013 г.) дава перфектно във всичко. И аз използвам само UFW.
Повтарям: Имате ли допълнителни тестове за извършване? Правя го с удоволствие и съобщавам какво излиза от тази страна.
Направете SYN и IDLE сканиране на вашия компютър с помощта на nmap, което ще ви даде представа колко сигурна е вашата система.
Nmap човекът има повече от 3000 реда. Ако ми дадете командите да изпълнявам с удоволствие, ще го направя и ще докладвам резултата.
Хм, не знаех за 3000-те страници за nmap. но zenmap е помощ за изпълнението на това, което ви казвам, това е графичен интерфейс за nmap, но все пак опцията за SYN сканиране с nmap е -sS, докато опцията за празно сканиране е -sI, но точната команда I ще бъде.
Направете сканирането от друга машина, сочейки към ip на вашата машина с ubuntu, не го правете от собствения си компютър, защото не така работи.
LOL !! Моята грешка около 3000 страници, когато бяха редове 😛
Не знам, но мисля, че GUI за това в GNU / Linux за управление на защитната стена би било нещо разумно и да не оставяте всичко непокрито, както в ubuntu или всичко, покрито като във Fedora, трябва да сте добър xD или нещо конфигурирайте проклетите алтернативи на убиеца xD hjahjahjaja Малко е, че се бия с тях и отворения jdk, но в крайна сметка вие също трябва да спазвате принципа на целувката
Благодарение на всички препъни камъни, които се случваха в миналото с iptables, днес мога да разбера niverl raw, тоест да говоря с него директно, както идва от завода.
И не е нещо толкова сложно, много е лесно да се научи.
Ако авторът на публикацията ми позволи, ще публикувам откъс от скрипта на защитната стена, който използвам в момента.
## Правила за почистване
IPTABLES-F
IPTABLES-X
iptables -Z
IPTABLES -t NAT -F
## Задайте политика по подразбиране: DROP
iptables -P INPUT DROP
iptables -P ИЗХОДНО ПАДАНЕ
iptables -P НАПРЕД ПАДАНЕ
# Работете на localhost без ограничения
iptables -А ВЪВЕЖДАНЕ -i lo -j ПРИЕМАНЕ
iptables -A ИЗХОД -o lo -j ПРИЕМ
# Оставете машината да отиде в мрежата
iptables -A INPUT -p tcp -m tcp –sport 80 -m conntrack –ctstate СВЪРЗАНИ, УСТАНОВЕНИ -j ПРИЕМАТ
iptables -A ИЗХОД -p tcp -m tcp -dport 80 -j ACCEPT
# Вече и за защита на уебсайтове
iptables -A INPUT -p tcp -m tcp –sport 443 -m conntrack –ctstate СВЪРЗАНИ, УСТАНОВЕНИ -j ПРИЕМАТ
iptables -A ИЗХОД -p tcp -m tcp -dport 443 -j ACCEPT
# Позволете пинг отвътре навън
iptables -A ИЗХОД -p icmp –icmp -тип ехо -заявка -j ПРИЕМАНЕ
iptables -A INPUT -p icmp –icmp -type echo -reply -j ACCEPT
# Защита за SSH
#iptables -I INPUT -p tcp –dport 22 -m conntrack –ctstate NEW -m limit –limit 30 / minute –limit-burst 5 -m comment –comment "SSH-kick" -j ACCEPT
#iptables -A INPUT -p tcp -m tcp –dport 22 -j LOG –log-prefix „SSH ACCESS ATTEMPT:“ –log-level 4
#iptables -A INPUT -p tcp -m tcp –dport 22 -j ИЗПУСКАНЕ
# Правила за amule за разрешаване на изходящи и входящи връзки на порта
iptables -A INPUT -p tcp -m tcp –dport 16420 -m conntrack –ctstate NEW -m comment –comment "aMule" -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp –sport 16420 -m conntrack –ctstate СВЪРЗАН, УСТАНОВЕН -m коментар –коментар „aMule“ -j ПРИЕМ
iptables -A INPUT -p udp –dport 9995 -m comment –comment "aMule" -j ACCEPT
iptables -A OUTPUT -p udp -sport 9995 -j ACCEPT
iptables -A INPUT -p udp -dport 16423 -j ACCEPT
iptables -A OUTPUT -p udp -sport 16423 -j ACCEPT
Сега малко обяснение. Както можете да видите, има правила с DROP политиката по подразбиране, нищо не излиза и не влиза в екипа, без да сте им казали.
След това се предават основите, localhost и навигацията до мрежата от мрежи.
Виждате, че има и правила за ssh и amule. Ако изглеждат добре как се справят, могат да направят другите правила, които искат.
Номерът е да се види структурата на правилата и да се приложи към определен тип порт или протокол, било то udp или tcp.
Надявам се да разберете това, което току-що публикувах тук.
Трябва да направите публикация, в която да го обясните 😉 би било чудесно.
Имам въпрос. В случай, че искате да отхвърлите http и https връзките, поставих:
сървър "http https" капка?
И така нататък с всяка услуга?
благодаря