Først og fremst går alle studiepoeng til @YukiteruAmano, fordi dette innlegget er basert på tutorial du la ut på forumet. Forskjellen er at jeg skal fokusere på Arch, selv om det sannsynligvis vil fungere for andre distros basert på systemd.
Hva er Firehol?
firehol, er et lite program som hjelper oss med å administrere brannmuren integrert i kjernen og dens verktøy iptables. Firehol mangler et grafisk grensesnitt, all konfigurasjon må gjøres gjennom tekstfiler, men til tross for dette er konfigurasjonen fortsatt enkel for nybegynnere, eller kraftig for de som leter etter avanserte alternativer. Alt som Firehol gjør er å forenkle etableringen av iptables-regler så mye som mulig og muliggjøre en god brannmur for systemet vårt.
Installasjon og konfigurasjon
Firehol er ikke i de offisielle Arch repositories, så vi vil referere til AUR.
yaourt -S firehol
Deretter går vi til konfigurasjonsfilen.
sudo nano /etc/firehol/firehol.conf
Og vi legger til reglene der, du kan bruke det er du.
Fortsett å aktivere Firehol for hver oppstart. Ganske enkelt med systemd.
sudo systemctl enable firehol
Vi startet Firehol.
sudo systemctl start firehol
Til slutt bekrefter vi at iptables-reglene er opprettet og lastet riktig.
sudo iptables -L
Deaktiver IPv6
Som firehol ikke takler ip6 -tabeller og siden de fleste av våre forbindelser ikke har støtte for IPv6, min anbefaling er å deaktivere den.
En Arch vi legger til ipv6.disable = 1 til kjernelinjen i / etc / default / grub-filen
...
GRUB_DISTRIBUTOR="Arch"
GRUB_CMDLINE_LINUX_DEFAULT="rw ipv6.disable=1"
GRUB_CMDLINE_LINUX=""
...
Nå regenererer vi grub.cfg:
sudo grub-mkconfig -o /boot/grub/grub.cfg
En Debian nok med:
sudo echo net.ipv6.conf.all.disable_ipv6=1 > /etc/sysctl.d/disableipv6.conf
Jeg forstår ikke. Følger du opplæringen, og du har allerede brannmuren i gang og blokkerte alle tilkoblingene? En annen ting En opplæring for Arch er kompleks, for eksempel har jeg aldri brukt sudo eller yaourt Firewall. Men det er forstått. Eller kanskje noen nye skriver deg og vil få en feil. For Manjaro er det mer riktig.
Som du sier @felipe, følger du opplæringen og legger i /etc/firehol/firehol.conf-filen reglene gitt av @cookie i limen, du vil allerede ha en enkel brannmur for å beskytte systemet på et grunnleggende nivå. Denne konfigurasjonen fungerer for enhver distro der du kan plassere Firehol, med den spesielle egenskapen til hver distro, den håndterer tjenestene på forskjellige måter (Debian gjennom sysvinit, Arch med systemd) og når det gjelder installasjonen, vet alle hva de har, i Arch må du bruk AUR og yaourt repos, i Debian er de offisielle nok, og så i mange andre, trenger du bare å søke litt i repositoriene og tilpasse installasjonskommandoen.
Jeg tror Yukiteru allerede har avklart tvilen din.
Nå, om sudo og yaourt, for min del anser jeg ikke sudo som et problem, du må bare se at det kommer som standard når du installerer Archs basesystem; og yaourt er valgfritt, du kan laste ned tarball, pakke den ut og installere med makepkg -si.
Takk skal jeg merke.
Noe som jeg glemte å legge til innlegget, men jeg kan ikke redigere det.
https://www.grc.com/x/ne.dll?bh0bkyd2
På dette nettstedet kan du teste brannmuren din (takk igjen til Yukiteru).
Jeg kjørte testene på Xubuntu og alt kom perfekt ut! For en fryd å bruke Linux !!! 😀
Alt som er veldig bra ... men det viktigste mangler; Du må forklare hvordan reglene er opprettet !!, hva de betyr, hvordan du lager nye ... Hvis det ikke blir forklart, er det lite du bruker av det du legger: - /
Å lage nye regler er enkelt, firehol-dokumentasjonen er tydelig og veldig presis når det gjelder å lage tilpassede regler, så å lese litt vil gjøre det enkelt for deg å tilpasse det og tilpasse det til dine behov.
Jeg tror den første grunnen til @cookie-innlegget som mitt i forumet, var å gi brukere og lesere et verktøy som lar dem gi datamaskinene litt mer sikkerhet, alt på et grunnleggende nivå. Resten blir liggende på drift for at du skal tilpasse deg dine behov.
Hvis du leser lenken til Yukiteru-opplæringen, vil du innse at intensjonen er å offentliggjøre applikasjonen og konfigurasjonen av en grunnleggende brannmur. Jeg presiserte at innlegget mitt bare var en kopi med fokus på Arch.
Og dette er "for mennesker"? o_O
Prøv Gufw på Arch: https://aur.archlinux.org/packages/gufw/ >> Klikk på Status. Eller ufw hvis du foretrekker terminal: sudo ufw aktivere
Du er allerede beskyttet hvis du er en vanlig bruker. Det er 'for mennesker' 🙂
Firehol er virkelig en front-end for IPTables, og hvis vi sammenligner det med sistnevnte, er det ganske menneskelig 😀
Jeg anser ufw (Gufw er bare et grensesnitt for det) som et dårlig alternativ når det gjelder sikkerhet. Årsak: For flere sikkerhetsregler som jeg skrev i ufw, kunne jeg ikke unngå at i testene av brannmuren min både via nettet og de jeg utførte ved hjelp av nmap, ville tjenester som avahi-daemon og exim4 virke åpne, og bare en "stealth" -angrep var nok til å kjenne de minste egenskapene til systemet mitt, kjernen og tjenestene jeg kjørte, noe som ikke har skjedd med meg ved hjelp av firehol eller Arnos brannmur.
Vel, jeg vet ikke om deg, men som jeg skrev ovenfor bruker jeg Xubuntu, og brannmuren min følger med GUFW, og jeg har bestått ALLE testene av lenken som forfatteren satte uten problemer. Alt snik. Ingenting åpent. Så etter min erfaring ufw (og derfor gufw) gjør jeg det fantastisk. Jeg er ikke kritisk til å bruke andre moduser for brannmurkontroll, men gufw fungerer feilfritt og gir gode sikkerhetsresultater.
Hvis du har noen tester som du tror kan føre til sårbarheter i systemet mitt, kan du fortelle meg hva de er, og jeg vil gjerne kjøre dem her og fortelle deg resultatene.
Nedenfor kommenterer jeg noe om emnet ufw, der jeg sier at feilen jeg så i 2008, ved bruk av Ubuntu 8.04 Hardy Heron. Hva har de allerede rettet opp? Det mest sannsynlige er at det er slik, så det er ingen grunn til bekymring, men allikevel betyr det ikke at feilen var der, og jeg kunne bevise det, selv om det ikke var en dårlig ting å dø, stoppet jeg bare demonene avahi-daemon og exim4, og allerede løst problem. Det rareste av alt er at bare de to prosessene hadde problemet.
Jeg nevnte faktum som en personlig anekdote, og jeg ga den samme oppfatningen da jeg sa: «Jeg vurderer ...»
Hilsen 🙂
+1
@Yukiteru: Prøvde du det fra din egen datamaskin? Hvis du ser fra PC-en din, er det normalt at du får tilgang til X-serviceporten, siden trafikken som er blokkert er nettverkets, ikke localhost:
http://www.ubuntu-es.org/node/140650#.UgJZ3cUyYZg
https://answers.launchpad.net/gui-ufw/+question/194272
Hvis ikke, vennligst rapporter en feil 🙂
Hilsen 🙂
Fra en annen datamaskin som bruker et Lan-nettverk i tilfelle nmap, og via Internett ved hjelp av denne siden https://www.grc.com/x/ne.dll?bh0bkyd2Ved å bruke alternativet tilpassede porter var begge enige om at avahi og exim4 lyttet fra nettet, selv om ufw hadde konfigurert blokkeringen.
Jeg løste den lille detalj av avahi-daemon og exim4 ved å bare deaktivere tjenestene, og det er det ... Jeg rapporterte ikke om en feil på den tiden, og jeg tror ikke det er fornuftig å gjøre det nå, for det var tilbake i 2008, ved hjelp av Hardy.
2008 var for 5 år siden; fra Hardy Heron til Raring Ringtail er det 10 * buntus. Den samme testen på Xubuntu, gjort i går og gjentatt i dag (august 2013) gir perfekt i alt. Og jeg bruker bare UFW.
Jeg gjentar: Har du noen ekstra tester å utføre? Jeg gjør det med glede og rapporterer hva som kommer ut av denne siden.
Gjør en SYN- og IDLE-skanning av PCen din ved hjelp av nmap, som vil gi deg en ide om hvor sikkert systemet ditt er.
Nmap-mannen har mer enn 3000 linjer. Hvis du gir meg kommandoene om å utføre med glede, vil jeg gjøre det, og jeg vil rapportere resultatet.
Hmm, jeg visste ikke om de 3000 mannsidene for nmap. men zenmap er en hjelp til å gjøre det jeg sier deg, det er en grafisk frontend for nmap, men fremdeles er alternativet for SYN-skanning med nmap -sS, mens alternativet for inaktiv skanning er -sI, men den eksakte kommandoen Jeg vil være.
Gjør skanningen fra en annen maskin som peker på ip på maskinen din med ubuntu, ikke gjør det fra din egen pc, for det er ikke slik det fungerer.
LOL !! Min feil på 3000 sider, da de var linjer 😛
Jeg vet ikke, men jeg tror at en GUI for det i GNU / Linux for å administrere brannmuren ville være noe forsiktig og ikke å la alt være avdekket som i ubuntu eller alt dekket som i fedora, du burde være god xD, eller noe for å konfigurere de forbaskede mordaralternativene xD hjahjahjaja Det har lite at jeg kjemper med dem og den åpne jdk, men til slutt må du også holde prinsippet om kyss
Takket være alle snublene som skjedde tidligere med iptables, kan jeg i dag forstå niverl raw, det vil si snakke direkte til ham når det kommer fra fabrikken.
Og det er ikke noe så komplisert, det er veldig lett å lære.
Hvis forfatteren av innlegget tillater meg, vil jeg legge ut et utdrag av brannmurskriptet jeg bruker for øyeblikket.
## Regler rengjøring
iptables-F
iptables-X
iptables -Z
iptables -t nat -F
## Angi standard policy: DROP
iptables -P INNGANG DROP
iptables -P UTGANG DROP
iptables -P FORDARD DROP
# Operer på localhost uten begrensninger
iptables -A INNGANG -i lo -j ACCEPT
iptables -A UTGANG -o lo -j GODTAK
# La maskinen gå på nettet
iptables -A INNGANG -p tcp -m tcp –sport 80 -m konneksjon –statstat RELATERT, OPPRETTET -j ACCEPT
iptables -A UTGANG -p tcp -m tcp –port 80 -j ACCEPT
# Allerede for å sikre nett
iptables -A INNGANG -p tcp -m tcp –sport 443 -m konneksjon –statstat RELATERT, OPPRETTET -j ACCEPT
iptables -A UTGANG -p tcp -m tcp –port 443 -j ACCEPT
# Tillat ping fra innsiden og ut
iptables -A OUTPUT -p icmp –icmp-type ekko-forespørsel -j ACCEPT
iptables -A INNGANG -p icmp –icmp-type ekko-svar -j ACCEPT
# Beskyttelse for SSH
#iptables -JEG INNGANG -p tcp –port 22 -m konneksjon –statstat NYTT -m grense –begrens 30 / minutt –begrens-burst 5 -m kommentar –kommentar “SSH-kick” -j ACCEPT
#iptables -A INNGANG -p tcp -m tcp –port 22 -j LOG –logg-prefiks "SSH TILGANGSPRØVE:" –logg-nivå 4
#iptables -A INNGANG -p tcp -m tcp –port 22 -j DROP
# Regler for amule for å tillate utgående og innkommende tilkoblinger på porten
iptables -A INNGANG -p tcp -m tcp –port 16420 -m tilkobling –ctstate NY -m kommentar –kommentar “aMule” -j ACCEPT
iptables -A UTGANG -p tcp -m tcp –sport 16420 -m konneksjon –ctstate RELATERT, ESTABLISERT -m kommentar –kommentar “aMule” -j ACCEPT
iptables -A INNGANG -p udp –dport 9995 -m kommentar –kommentar “aMule” -j ACCEPT
iptables -A OUTPUT -p udp –sport 9995 -j GODTAK
iptables -A INNGANG -p udp –dport 16423 -j ACCEPT
iptables -A OUTPUT -p udp –sport 16423 -j GODTAK
Nå en liten forklaring. Som du kan se, er det reglene med DROP-policyen som standard, ingenting forlater og kommer inn i teamet uten at du forteller dem.
Deretter blir grunnleggende bestått, localhost og navigering til nettverket av nettverk.
Du kan se at det også er regler for ssh og amule. Hvis de ser bra ut hvordan de blir gjort, kan de lage de andre reglene de vil ha.
Trikset er å se strukturen til reglene og gjelde for en bestemt type port eller protokoll, det være seg udp eller tcp.
Jeg håper du kan forstå dette som jeg nettopp la ut her.
Du bør lage et innlegg som forklarer det 😉 ville være flott.
Jeg har et spørsmål. I tilfelle du vil avvise http- og https-tilkoblinger, legger jeg:
server "http https" slipp?
Og så videre med noen tjenester?
Takk