Először is, az összes kredit az @YukiteruAmano, mert ez a bejegyzés a oktatói te posztoltál a fórumon. A különbség az, hogy erre fogok koncentrálni Bolthajtás, bár valószínűleg más disztrók esetében is működni fog systemd.
Mi az a Firehol?
firehol, egy kis alkalmazás, amely segít a kernelbe integrált tűzfal és eszközének kezelésében iptables. A Firehol nem rendelkezik grafikus felülettel, minden konfigurálást szöveges fájlokon keresztül kell végrehajtani, de ennek ellenére a konfigurálás még mindig egyszerű a kezdő felhasználók számára, vagy nagy teljesítményű azok számára, akik haladó lehetőségeket keresnek. A Firehol mindössze annyit tesz, hogy a lehető legnagyobb mértékben leegyszerűsíti az iptables szabályok létrehozását, és jó tűzfalat tesz lehetővé a rendszerünk számára.
Telepítés és konfigurálás
A Firehol nincs a hivatalos Arch tárházakban, ezért hivatkozni fogunk rá AUR.
yaourt -S firehol
Ezután megyünk a konfigurációs fájlhoz.
sudo nano /etc/firehol/firehol.conf
És ott hozzáadjuk a szabályokat, amelyeket használhat te vagy.
Aktiválja folyamatosan a Firehol programot minden indításhoz. Nagyon egyszerű a systemd-vel.
sudo systemctl enable firehol
Elindítottuk a Fireholt.
sudo systemctl start firehol
Végül ellenőrizzük, hogy az iptables szabályok megfelelően lettek-e létrehozva és betöltve.
sudo iptables -L
Tiltsa le az IPv6-ot
Mivel a firehol nem kezeli ip6tables és mivel kapcsolataink többségének nincs támogatottsága IPv6, az a javaslatom, hogy tiltsa le.
En Bolthajtás hozzátesszük ipv6.disable = 1 az / etc / default / grub fájlban található kernel sorra
...
GRUB_DISTRIBUTOR="Arch"
GRUB_CMDLINE_LINUX_DEFAULT="rw ipv6.disable=1"
GRUB_CMDLINE_LINUX=""
...
Most regeneráljuk a grub.cfg:
sudo grub-mkconfig -o /boot/grub/grub.cfg
En Debian elég a következőkkel:
sudo echo net.ipv6.conf.all.disable_ipv6=1 > /etc/sysctl.d/disableipv6.conf
Nem ertem. Kövesse az oktatóanyagot, és már fut a tűzfal, és letiltotta az összes kapcsolatot? Egy másik dolog Az Arch bemutatója összetett, például soha nem használtam sudo vagy yaourt tűzfalat. Azonban érthető. Vagy esetleg valaki új ír yaourt, és hibát fog kapni. Manjaro számára ez helyesebb.
Ahogy mondod @felipe, a bemutatót követve és az /etc/firehol/firehol.conf fájlba beillesztve a @cookie által beillesztett szabályokat, máris lesz egy egyszerű tűzfalad, amely alapszintű védelmet nyújt a rendszer számára. Ez a konfiguráció minden olyan disztribúciónál működik, ahová felteheti a Firehol-t, az egyes disztrók sajátosságával különféle módon kezeli szolgáltatásait (Debian a sysviniten keresztül, Arch az systemd-vel), és ami a telepítést illeti, mindenki tudja, mi van, az Arch-ban meg kell használja az AUR és a yaourt repókat, a Debianban a hivatalosak elegendőek az Ön számára, és így sok másban csak egy kicsit kell keresgélnie a tárakban, és adaptálnia kell a telepítési parancsot.
Azt hiszem, Yukiteru már tisztázta a kételyeidet.
A sudo-ról és a yaourt-ról a magam részéről nem tartom problémának a sudo-t, csak látom, hogy alapértelmezés szerint az Arch alaprendszerének telepítésekor jön létre; és a yaourt opcionális, letöltheti a tarball-ot, kicsomagolhatja és telepítheti a makepkg -si paranccsal.
Köszönöm, tudomásul veszem.
Valami, amit elfelejtettem hozzáadni a bejegyzéshez, de nem tudom szerkeszteni.
https://www.grc.com/x/ne.dll?bh0bkyd2
Ezen a webhelyen tesztelheti a tűzfalát thanks (ezúton is köszönet Yukiterunak).
Futtattam ezeket a teszteket a Xubuntun, és minden tökéletesen sikerült! Milyen öröm a Linux használata !!! 😀
Minden, ami nagyon jó ... de a legfontosabb hiányzik; El kell magyaráznod, hogyan jönnek létre a szabályok !!, mit jelentenek, hogyan hozhatnak létre újakat ... Ha ezt nem magyarázzák el, akkor kevéssé hasznos az, amit te tettél: - /
Az új szabályok létrehozása egyszerű, a firehol dokumentációja világos és nagyon pontos az egyedi szabályok létrehozása szempontjából, így egy kicsit elolvasva könnyebben testre szabhatja és alkalmazkodhat az Ön igényeihez.
Úgy gondolom, hogy a @cookie-hozzászólás kezdeti oka, mint az enyém a fórumban, az volt, hogy a felhasználóknak és az olvasóknak olyan eszközt adtak, amely lehetővé teszi számukra, hogy egy kicsit nagyobb biztonságot nyújtsanak a számítógépeiknek, mindezt alap szinten. A többit elhagyják, hogy alkalmazkodhasson az igényeihez.
Ha elolvassa a Yukiteru oktatóanyagra mutató linket, rájön, hogy az alkalmazás és az alapvető tűzfal konfigurációjának nyilvánosságra hozatala a cél. Tisztáztam, hogy a hozzászólásom csak Arch-ra összpontosított másolat.
És ez az "emberek számára" szól? o_O
Próbálja ki a Gufw-t az Arch-on: https://aur.archlinux.org/packages/gufw/ >> Kattintson az Állapot elemre. Vagy ufw, ha a terminált kedveli: sudo ufw enable
Ön már védett, ha normál felhasználó. Ez „az emberek számára”
A Firehol valóban az IPTable-k front-endje, és ha összehasonlítjuk az utóbbival, akkor eléggé emberi
Az ufw-t (a Gufw csak egy kezelőfelülete) a biztonság szempontjából rossz lehetőségnek tartom. Ok: Az ufw-ben írt további biztonsági szabályok esetében nem tudtam megakadályozni, hogy a tűzfalam tesztjein mind az interneten keresztül, mind azoknál, amelyeket az nmap használatával hajtottam végre, az olyan szolgáltatások, mint az avahi-daemon és az exim4, nyitva jelennek meg, és csak egy "lopakodó" támadás elegendő volt a rendszerem, a rendszermagom és az általam futtatott szolgáltatások legkisebb jellemzőinek megismeréséhez, ami nem történt meg velem firehol vagy arno tűzfal használatával.
Nos, nem tudok rólad, de ahogy fentebb írtam, az Xubuntut használom, a tűzfalam pedig a GUFW-vel megy, és sikeresen megfeleltem a link MINDEN tesztjét, amelyet a szerző gond nélkül tett. Minden lopakodás. Semmi nincs nyitva. Tehát tapasztalatom szerint az ufw (és ezért a gufw) nagyszerűek nekem. Nem vagyok kritikus a többi tűzfal vezérlési móddal szemben, de a gufw hibátlanul működik és nagyszerű biztonsági eredményt ad.
Ha van olyan tesztje, amely úgy gondolja, hogy sérülékenységeket dobhat a rendszerembe, mondja el, hogy mik azok, és én örömmel lefuttatom őket itt, és tájékoztatom az eredményeket.
Az alábbiakban megjegyzek valamit az ufw témáról, ahol azt mondom, hogy a hibát, amelyet 2008-ban láttam, az Ubuntu 8.04 Hardy Heron használatával. Mit javítottak már ki? A legvalószínűbb, hogy ez a helyzet, tehát nincs miért aggódni, de még így sem jelenti azt, hogy a hiba ott volt, és meg tudtam mutatni, bár nem volt rossz dolog meghalni, csak a démonokat állítottam meg: avahi-daemon és exim4, és már probléma megoldódott. A legfurcsább az egészben, hogy csak ennek a két folyamatnak volt a problémája.
Személyes anekdotaként említettem a tényt, és ugyanezt a véleményt mondtam, amikor azt mondtam: "Úgy gondolom ..."
Üdvözlet 🙂
+1
@Yukiteru: Saját számítógépéről próbálta ki? Ha a számítógépéről néz, normális, hogy hozzáférhet az X szervizporthoz, mivel a blokkolt forgalom a hálózaté, nem pedig a localhostja:
http://www.ubuntu-es.org/node/140650#.UgJZ3cUyYZg
https://answers.launchpad.net/gui-ufw/+question/194272
Ha nem, kérjük, jelentsen egy hibát 🙂
Üdvözlet 🙂
Nmap esetén egy másik Lan hálózatot használó számítógépről, és ezen az oldalon az interneten keresztül https://www.grc.com/x/ne.dll?bh0bkyd2Az egyéni portok opcióval mindketten egyetértettek abban, hogy az avahi és az exim4 a netről hallgat, annak ellenére, hogy az ufw blokkolása konfigurálva volt.
Az avahi-daemon és az exim4 kis részletét úgy oldottam meg, hogy egyszerűen letiltottam a szolgáltatásokat, és ennyi ... Akkor még nem jelentettem hibát, és úgy gondolom, hogy nincs értelme ezt most megtenni, mert ez visszatért 2008-ban Hardy segítségével.
2008 5 évvel ezelőtt volt; Hardy Herontól a Raring Ringtailig 10 * buntus van. Ugyanez a teszt a Xubuntun, amelyet tegnap készítettem és ma (2013. augusztus) megismételtem, mindenben tökéleteset ad. És csak az UFW-t használom.
Ismétlem: Van-e további tesztje? Örömmel csinálom, és beszámolok arról, mi jön ki erről az oldalról.
Végezzen SYN és IDLE vizsgálatot a számítógépén az nmap segítségével, amely képet ad arról, hogy mennyire biztonságos a rendszere.
Az nmap embernek több mint 3000 vonala van. Ha megadod a parancsokat, hogy örömmel hajtsam végre, akkor megteszem, és jelenteni fogom az eredményt.
Hmm nem tudtam a nmap 3000 ember oldaláról. de a zenmap segítség ahhoz, hogy azt tegyem, amit mondok, ez az nmap grafikus kezelőfelülete, de az nmap SYN vizsgálatának lehetősége továbbra is -sS, míg az üresjárati vizsgálat opciója -sI, de a pontos parancs Leszek.
Végezze el a beolvasást egy másik gépről, a gép ip-jére mutatva az ubuntuval, ne a saját pc-jéről végezze, mert ez nem így működik.
LOL !! Tévedésem körülbelül 3000 oldalról, amikor sorok voltak 😛
Nem tudom, de úgy gondolom, hogy a GNU / Linux-ban a tűzfal kezelésére szolgáló GUI valami körültekintő lenne, és nem hagyna mindent fedetlenül, mint az ubuntuban, vagy mindent, amit fedora, mint a fedora, akkor jónak kell lenned xD, vagy valami, hogy konfiguráld az átkozott gyilkos alternatívákat xD hjahjahjaja Kevés, hogy harcolok velük és a nyílt jdk-val, de végül neked is meg kell tartanod a csók elvét
Hála az összes botlásnak, ami a múltban történt az iptables-szel, ma már meg tudom érteni a niverl raw-t, vagyis közvetlenül beszélek vele, ahogy a gyárból származik.
És ez nem olyan bonyolult, nagyon könnyen megtanulható.
Ha a bejegyzés szerzője megengedi, felteszek egy kivonatot a jelenleg használt tűzfal szkriptből.
## Szabálytisztítás
iptables-F
iptables-X
iptables -Z
iptables -t nat -F
## Alapértelmezett házirend beállítása: DROP
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
# Korlátozások nélkül működjön a localhoston
iptables -A BEMENET -i lo -j ELFOGADÁS
iptables -A KIMENET -o lo -j ELFOGADÁS
# Engedje meg, hogy a gép az internetre lépjen
iptables -A INPUT -p tcp -m tcp –sport 80 -m conntrack –ctstate KAPCSOLÓDÓ, LÉTREHOZOTT -j ACCEPT
iptables -A KIMENET -p tcp -m tcp –port 80 -j ELFOGADÁS
# Már a webek biztonsága érdekében is
iptables -A INPUT -p tcp -m tcp –sport 443 -m conntrack –ctstate KAPCSOLÓDÓ, LÉTREHOZOTT -j ACCEPT
iptables -A KIMENET -p tcp -m tcp –port 443 -j ELFOGADÁS
# Hagyja pingelni belülről kifelé
iptables -A OUTPUT -p icmp –icmp típusú echo-request -j ACCEPT
iptables -A BEMENET -p icmp –icmp típusú visszhang-válasz -j ACCEPT
# Az SSH védelme
#iptables -I INPUT -p tcp –port 22 -m conntrack –ctstate NEW -m limit –limit 30 / perc –limit-burst 5 -m comment –komment "SSH-kick" -j ACCEPT
#iptables -A INPUT -p tcp -m tcp –port 22 -j LOG –log-prefix "SSH ACCESS ATTEMPT:" –log-level 4
#iptables -A BEMENET -p tcp -m tcp –port 22 -j DROP
# Az amule szabályai a kimenő és bejövő kapcsolatok engedélyezéséhez a porton
iptables -A BEMENET -p tcp -m tcp –port 16420 -m conntrack –állapot ÚJ -m megjegyzés –megjegyzés „aMule” -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp –sport 16420 -m conntrack –ctstate KAPCSOLÓDÓ, LÉTREHOZOTT -m megjegyzés –komment "aMule" -j ACCEPT
iptables -A BEMENET -p udp –port 9995 -m megjegyzés –megjegyzés „aMule” -j ACCEPT
iptables -A KIMENET -p udp –sport 9995 -j ACCEPT
iptable -A INPUT -p udp -dport 16423 -j ACCEPT
iptables -A KIMENET -p udp –sport 16423 -j ACCEPT
Most egy kis magyarázat. Mint láthatja, alapértelmezés szerint a DROP házirendnek vannak szabályai, semmi sem távozik és nem lép be a csapatba anélkül, hogy elmondaná nekik.
Ezután átadják az alapokat, a localhostot és a navigációt a hálózatok hálózatához.
Láthatja, hogy az ssh-re és az amule-ra is vannak szabályok. Ha jól néznek ki, hogyan teljesítenek, megalkothatják a kívánt szabályokat.
A trükk az, hogy megnézzük a szabályok felépítését, és egy adott típusú portra vagy protokollra vonatkoznak, legyen az udp vagy tcp.
Remélem, meg tudja érteni ezt, amit csak ide tettem fel.
Készítsen egy bejegyzést, amely elmagyarázza great nagyon jó lenne.
Kérdésem van. Abban az esetben, ha el akarja utasítani a http és a https kapcsolatokat, feltettem:
szerver "http https" csepp?
És így tovább bármely szolgáltatással?
Köszönöm