iptables säännöt

[Pah0lain3]

Näitä olis tarkoitus vähän opiskella. Tarkoituksena olis yhdellä käyttöjärjestelmällä estää kaikki liikenne ilman vpn yhteyttä ja sallia ainoastaan vpn yhteydet.

Vähän näitä nyt googletellu ja paras ohje minkä löysin mikä viittaa omaan tarkoitukseen :

[TD]#!/bin/sh[/TD]
[TD]# by: "John Hazelwood" <jhazelwo@users.noreply.github.com>[/TD]
[TD]# iptables rules to only allow VPN traffic AND let user SSH to VPN server itself.[/TD]
[TD]# Use this on a CentOS/RedHat server you have set up to be a NAT firewall for your network. [/TD]
[TD]# This will force ALL Internet traffic to go over the VPN [/TD]
[TD]#    and will BLOCK ALL Internet TRAFFIC if VPN is not running![/TD]
[TD]# use `service iptables save` to save the rules to /etc/sysconfig/iptables[/TD]
[TD]# made [/TD]


[TD]VPNServer="172.217.3.256" # Change to ip or host of your VPN server[/TD]
[TD]wan="eth0"  # interface connected to the Internet[/TD]
[TD]lan="eth1"  # interface to your workstation or router[/TD]
[TD]tun="tun0"  # tunnel interface created by VPN client[/TD]


[TD]# Flush rules[/TD]
[TD]/sbin/iptables -F[/TD]
[TD]/sbin/iptables -F -t nat[/TD]


[TD]# Enable NAT[/TD]
[TD]/sbin/iptables -t nat -A POSTROUTING -o $tun -j MASQUERADE[/TD]
[TD]/sbin/iptables -t nat -A POSTROUTING -o $wan -j MASQUERADE  # Needed to SSH to VPN server[/TD]


[TD]# Allow SSH to the VPN server itself[/TD]
[TD]/sbin/iptables -A FORWARD -o $wan --destination $VPNServer --protocol tcp --dport 22 -j ACCEPT[/TD]
[TD]/sbin/iptables -A FORWARD -i $wan --source $VPNServer --protocol tcp --sport 22 -j ACCEPT[/TD]


[TD]# Allow VPN traffic[/TD]
[TD]/sbin/iptables -A FORWARD -i $lan --destination $VPNServer --protocol udp --dport 1194 -o $tun -j ACCEPT[/TD]
[TD]/sbin/iptables -A FORWARD -i $tun --source $VPNServer --protocol udp --sport 1194 -o $lan -j ACCEPT[/TD]


[TD]# Block non-VPN traffic across the WAN (Internet) interface (after VPN setup)[/TD]
[TD]/sbin/iptables -A FORWARD -i $wan -j DROP[/TD]
[TD]/sbin/iptables -A FORWARD -o $wan -j DROP[/TD]


[TD]# Allow VPN client to connect to VPN server[/TD]
[TD]/sbin/iptables -A INPUT -i $wan --source $VPNServer --protocol udp --sport 1194 -j ACCEPT[/TD]
[TD]/sbin/iptables -A OUTPUT -o $wan --destination $VPNServer --protocol udp --dport 1194 -j ACCEPT[/TD]


[TD]# Block non-VPN traffic across the WAN (Internet) interface (before VPN setup)[/TD]
[TD]/sbin/iptables -A INPUT -i $wan -j DROP[/TD]
/sbin/iptables -A OUTPUT -o $wan -j DROP

Tässä ohjeessa se ainakin kirjoittaa että nämä säännöt estäisivät kaiken ilman vpn kulkevat yhteydet ja sallii vain vpn yhteydet. Osaako joku katsoa tai silmäillä tuon läpi kun minä en pysty sanomaan onko nuo oikein.

Mutta mitään SSH:ta ei varmaan tarvi tässä tapauksessa sallia ? Ja miksi tuossa sallitaan vain tiettyjä d/sportteja ?

Eikö tämä viimeinen kohta vain riittäisi blokkaamaan ei vpn yhteydet ? Tarkoitan tätä ihan alinta ohjeessa olevaa sääntöä :

# Block non-VPN traffic across the WAN (Internet) interface (before VPN setup)
iptables -A INPUT -i $wan -j DROP
iptables -A OUTPUT -o $wan -j DROP

Wan kohdan joudun vain muuttamaan "lo" koska ne on vähän eri kuin ohjeessa. En ajatellu että ihan noin paljon sääntöjä joutuisin tekemään...

 

[Pah0lain3]

Edit: Jostain syystä nyt tuli hirveän huonoa copy pastea, mutta koitan vähän siistiä jos osaan.

Nyt se on vähän selvempi.

En aio kuitenkaan sallia SSH:ta ellei se ole aivan pakollista tässä omassa tavoitteessa. Jotenkin ajattelin että perus verkkoyhteydet olis ollu paljon helpompi kieltää ja sallia pelkät vpn yhteydet.

 

[Hyrava]

Tuo portti 1194 on VPN-yhteyden käyttämä portti eli sallitaan vain VPN-liikenne. Tuo konfiguraatio on tosiaan jollekin reitittävälle koneelle tarkoitettu jossa toinen interface on internetiin ja toinen sille konelle joka tuota kautta ottaa yhteyden. Sen takia siinä varmaan on tuo SSH-porttikin avattu.

Itse varmaan lähestyisin tuota niin että ensin flushataan olemassaolevat säännöt:
/sbin/iptables -F

Sitten oletuksena blokataan kaikki (default policy):
/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT DROP

Ja tämän jälkeen avataan tarvittavat yhteydet ulkomaailmaan eli sallitaan eth-portista liikenne vpn-serverille ja sallitaan koneelta liikenne tun-deviceen joka on siis se vpn-putki.

 

[Pah0lain3]

Tuo portti 1194 on VPN-yhteyden käyttämä portti eli sallitaan vain VPN-liikenne. Tuo konfiguraatio on tosiaan jollekin reitittävälle koneelle tarkoitettu jossa toinen interface on internetiin ja toinen sille konelle joka tuota kautta ottaa yhteyden. Sen takia siinä varmaan on tuo SSH-porttikin avattu.

Itse varmaan lähestyisin tuota niin että ensin flushataan olemassaolevat säännöt:
/sbin/iptables -F

Sitten oletuksena blokataan kaikki (default policy):
/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT DROP

Ja tämän jälkeen avataan tarvittavat yhteydet ulkomaailmaan eli sallitaan eth-portista liikenne vpn-serverille ja sallitaan koneelta liikenne tun-deviceen joka on siis se vpn-putki.

Taidan vähän testailla näitä. Eiköhän näillä ohjeilla jotain saa aikaiseksi, kiitos.

 

[Pah0lain3]

Tuo portti 1194 on VPN-yhteyden käyttämä portti eli sallitaan vain VPN-liikenne. Tuo konfiguraatio on tosiaan jollekin reitittävälle koneelle tarkoitettu jossa toinen interface on internetiin ja toinen sille konelle joka tuota kautta ottaa yhteyden. Sen takia siinä varmaan on tuo SSH-porttikin avattu.

Itse varmaan lähestyisin tuota niin että ensin flushataan olemassaolevat säännöt:
/sbin/iptables -F

Sitten oletuksena blokataan kaikki (default policy):
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT DROP

Ja tämän jälkeen avataan tarvittavat yhteydet ulkomaailmaan eli sallitaan eth-portista liikenne vpn-serverille ja sallitaan koneelta liikenne tun-deviceen joka on siis se vpn-putki.

Kiitos isosti avusta. Tämä oli suoraviivainen ohje ja toimi aivan kuten halusin.
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT DROP

Sudottaa täytyi vaan komennot, ja kun tcpdumppia pidin päällä rebootin jälkeen ei liikennettä näkyny eli ilman vpn palvelua ei toiminu mikään verkkoyhteys mihinkään. Eli täysin niinkuin halusin. Ei onneksi tarvinnut availla vpn ohjelmalle mitään erikseen, se hoiti sen automaattisesti kun laittoi vain päälle ohjelman. Se itse vpn ohjelma teki siis puuttuvat iptables säännöt ja yhdisti ihan normaalisti. Pelkäsin vähän että homma menee ihan puihin ja joudun alkaa tekemään kaikkeen erikseen omat sääntönsä, mutta nyt näyttää siltä että selain toimii normaalisti yms.

Eli kiitos tästä suoraviivaisesta ohjeesta.

 

[Pah0lain3]

Tuo portti 1194 on VPN-yhteyden käyttämä portti eli sallitaan vain VPN-liikenne. Tuo konfiguraatio on tosiaan jollekin reitittävälle koneelle tarkoitettu jossa toinen interface on internetiin ja toinen sille konelle joka tuota kautta ottaa yhteyden. Sen takia siinä varmaan on tuo SSH-porttikin avattu.

Itse varmaan lähestyisin tuota niin että ensin flushataan olemassaolevat säännöt:
/sbin/iptables -F

Sitten oletuksena blokataan kaikki (default policy):
/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT DROP

Ja tämän jälkeen avataan tarvittavat yhteydet ulkomaailmaan eli sallitaan eth-portista liikenne vpn-serverille ja sallitaan koneelta liikenne tun-deviceen joka on siis se vpn-putki.

Toimi aikansa, ei toimi enää. Tuli joku hämmentävä kernel panik eikä työpöydälle päässy enää, niin tökkäsin koko käyttöjärjestelmän uusiksi.
Nyt pari viikkoa kokeillu netistä löytyviä kaikenmaailman ohjeita niin iptables säännöillä kuin ufw:llä sekä gufw:llä. Mitenkään en nyt saa toimimaan tätä alkuperäistä ideaa enää. Joko kaikki toimii aina sääntöjen jälkeen tai mikään ei toimi. Tää on ihan hullua miten vaikeaa ja hankalaa noiden sääntöjen kanssa räplääminen on.

Käytän Arch linuxista tehtyä EndeavourOs tai Manjaroa Cinnamon työpöydällä. Mutta nyt tilanne on se että en millään saa mitään toimimaan.
Osaisko joku helpata luomaan pienet tai isommatkin säännöt ?

Interfacet on näin : Lo, enp3s0, tun0. Enp3s0 on se 192.168.xx.xx ja tun0 on vpn luultavasti se vpn putki. En tiedä onko interface tähän oikea termi, mutta tällä mennään.

Lo, luultavasti täytyy sallia että yhteydet toimii ? enp3s0 syntyvä verkkoliikkenne niin sisään kuin ulos olis tarkoitus blokata kokonaan ja kaikilta. tun0 on se mikä pitäisi olla auki molempiin suuntiin. Eli ainoastaan vpn yhteydet toimisi ja jos vpn putoaa niin minkään ei pitäisi toimia missään. Oon asentanu käyttistä nyt niin hemmetin monta kertaa uusiksi kun jostain syystä sääntöjä jotka on menneet pieleen, en ole saanu peruttua niitä enää millään. Toinen oli se että mitään sääntöjä ei koskaan tallentunu vaikka miten yritti iptables-save tai ufw reload komentoja tarjota.

Nyt varmaan järkevämpi on käyttää Timeshiftiä ja palauttaa sillä alkuperäiseen kohtaan kun kokeilut ei toimi. Nyt on vain siinä pisteessä että enää ei jaksa lyödä päätä seinään vaan on pakko tulla pyytämään paljon apuja. En nyt taida yhtään ymmärtää tätä sääntörulettia kun ei toimi.

By default client will connect to port 443. You can change connection mode, as you correctly noticed, on "Preferences" > "Protocols" window.
Port 1194 is a port that's recommended specifically for OpenVPN by IANA, in this sense it's the "official" OpenVPN port.
Our servers accept connections on ports 53, 80, 443, 1194, 2018 and more.

mm. tämmöistä ohjetta olen yrittäny soveltaa omiin tarkoituksiin kehnoin lopputuloksin. Sekä useita muita ohjeita jotka olis omaan tarkoituksiin sopivan oloisia.

How do I prevent VPN leaks using iptables? - IVPN Help

How do I prevent VPN leaks using iptables? We recommend using our Linux CLI app that offers an easy-to-use built-in Firewall solution that protects you from both IP and traffic leaks. Read on, if you would like to have a more granular Firewall configuration or prefer to use NetworkManager or a...

www.ivpn.net

sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT DROP

Tuo on hyvä alku, sitten menee sormet suuhun. Joitain sääntöjä olen onnistunu tekemään, esimerkiksi blokata sisääntuleva SSH liikenne, mutta sitten taas vaikka qbittorrent ulos tai sisään en saa mitenkään järkevästi toimimaan. Aina lopulta säännöt on niin sekavia, että myös 192.168.xxx.xxx enp3s0 liikenne on sallittu vaikkei oikeasti sääntöjen mukaan ole, ja tun0 vpn tunneli on aivan yhtä hukassa kuin minä.

Oppimismielessä tuo on ollut toistaiseksi ihan hauskaa, mutta nyt alkaa raja tulla vastaan. Kummallako nämä asiat on parempi toteuttaa, ufw säännöillä vai näillä iptables säännöillä ?

Jaksaisitteko avustaa ja kirjotella säännöt toimivaan muotoon niin että toimiskin joskus.

 

[mikajh]

Kummallako nämä asiat on parempi toteuttaa, ufw säännöillä vai näillä iptables säännöillä ?

Itse käytän iptables:ia (joka korvautunee nftables:illa piakkoin). ufw tekee sellaista shittiä, että sen tulkinta on mielestäni hankalaa jos vertaa käsin tehtyihin (ja dockerin luomiin) iptables-sääntöihin. Lisäksi se on aika rajoittunut, mikä voi toki riippua versiosta mitä käyttää.

Nuo policymuutkset aiheuttavat sen, että kaikki dropataan, mitä ei ole erikseen sallittu.
Etnernet-interfacea tarvitset ainakin sen verran. että saat vpn:n pystyyn. Sen jälkeen tarkoitus routata kaikki muu liikenne vpn:n kautta

 

[Pah0lain3]

Itse käytän iptables:ia (joka korvautunee nftables:illa piakkoin). ufw tekee sellaista shittiä, että sen tulkinta on mielestäni hankalaa jos vertaa käsin tehtyihin (ja dockerin luomiin) iptables-sääntöihin. Lisäksi se on aika rajoittunut, mikä voi toki riippua versiosta mitä käyttää.

Nuo policymuutkset aiheuttavat sen, että kaikki dropataan, mitä ei ole erikseen sallittu.
Etnernet-interfacea tarvitset ainakin sen verran. että saat vpn:n pystyyn. Sen jälkeen tarkoitus routata kaikki muu liikenne vpn:n kautta

Tuntuu kyllä että iptables on monipuolisempi kuin ufw, niin kyllä kanssa oma mielipide on kallistunu iptablesin puoleen. On vaan mahdottoman oloista saada toimimaan yhtään mitään.

Korvautuuko se tällä iptables-nft paketilla ? Semmoinen löytyy virallisista pakettilähteistä kyllä tuolta mutta sitäkö tarkoitit ?

 

[mikajh]

Tällä nimellä se on Debian/Ubuntussa nftables - Debian Package Tracker
Jos ufw:ssa on joku hyvä ominaisuus, niin se on eri tilojen tuki (esim. kotona, julkisessa verkossa jne), mikä voisi tässä tapauksessa olla avuksi

 

[mikajh]

Jos tuo vpn käyttää OpenVPN clientia, niin joitain täsmäohjeita voi löytyä. Tässä puhutaan tosin serveristä ja sinulla on client, mutta osin samoja sääntöjä niissä tarvitaan: How to configure iptables for openvpn
Joku aika takaperin jouduin itsekin lisäämään pari sääntöä, että OpenVPN-clientilla pääsi ulos, kun kaikki ulosmenevät yhteydet oli rajoitettu minimiin

E:
iptables -A INPUT -j ACCEPT -i tun+
iptables -A OUTPUT -j ACCEPT -i tun+

 

[Pah0lain3]

Tällä nimellä se on Debian/Ubuntussa nftables - Debian Package Tracker

No niinpäs löytyikin tuo nfttables. Täytyy siihenkin vähän tutustua jossain vaiheessa.

 

[mikajh]

Kovin montaa asiaa tuossa ei taida tarvita sallia
0. iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
1. DNS-kyselyt siihen saakka, että vpn on pystyssä, sen jälkeen ei niitäkään, esim.
iptables -A OUTPUT -j ACCEPT -p udp --dport 53
2. OpenVPN lähtevä liikenne, oletuksena UDP 1194
3. Nämä tarvittaneen, että ulosmenevään viestiin saadaan vastaus
iptables -A INPUT -j ACCEPT -m conntrack --ctstate ESTABLISHED,RELATED
iptables -A OUTPUT -j ACCEPT -m conntrack --ctstate ESTABLISHED,RELATED
4. iptables -A INPUT -j ACCEPT -i tun+
iptables -A OUTPUT -j ACCEPT -i tun+

 

[Pah0lain3]

Kovin montaa asiaa tuossa ei taida tarvita sallia
0. iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
1. DNS-kyselyt siihen saakka, että vpn on pystyssä, sen jälkeen ei niitäkään, esim.
iptables -A OUTPUT -j ACCEPT -p udp --dport 53
2. OpenVPN lähtevä liikenne, oletuksena UDP 1194
3. Nämä tarvittaneen, että ulosmenevään viestiin saadaan vastaus
iptables -A INPUT -j ACCEPT -m conntrack --ctstate ESTABLISHED,RELATED
iptables -A OUTPUT -j ACCEPT -m conntrack --ctstate ESTABLISHED,RELATED
4. iptables -A INPUT -j ACCEPT -i tun+
iptables -A OUTPUT -j ACCEPT -i tun+

Lopuksiko sitten sääntöjen tallennus sudo iptables-save ? Laitan nämä takuulla testiin kun kerkeän.
2 Kohdan OpenVPN menis jotenkin näin : sudo iptables -A OUTPUT -j ACCEPT -p udp --dport 1194 ? Järkeilin sen tuosta edellisestä laittamastasi säännöstä suoraan yläpuolelta.

Noista nfttableista sen verran että ymmärsin nämä nykyiset iptables säännöt pystyis "porttaamaan" nfttable säännöiksi "parilla" komennolla. Joten ei taida aivan turhaa kuitenkaan olla ja yrittää näitä iptablesseja vääntää nyt.

Pitääköhän vpn tunnelin olla päällä kun sääntöjä tekee ? Vai käyttöjärjestelmä vaan ihan "defaulttina" ? Onko tällä edes mitään vaikutusta ?

Takas sääntöihin, voinko vain jatkaa sääntöjen tekemistä tuohon sun listauksen perään vai täytyykö noissä huomioida joku tietty järjestys ensin ?
Esimerkiksi jos haluan blokata ssh vaikka näin ?
iptables -I INPUT -i enp3s0 -p tcp --dport 22 -j DROP
iptables -I INPUT -i enp3s0 -p udp --dport 22 -j DROP

Täytyykö se blokata myös tun0:ssa ? Vai onko säännöt taas nyt ihan väärin laitettu ? Kummassa ne nyt täytyy siis blokata, enp3s0:ssa vai tun0:ssa ?
iptables -I INPUT -i tun0 -p tcp --dport 22 -j DROP
iptables -I INPUT -i tun0 -p udp --dport 22 -j DROP

iptables -I INPUT -i tun0 -p tcp --dport 21-j DROP
iptables -I INPUT -i tun0 -p udp --dport 21 -j DROP
Täytyykö SSH blokata vain porteilla, sitä ei voi blokata palveluna eli SSH:na ? Jos voisi blokata dportin sijaan koko palvelun SSH ?

Mutta koko paketti olisi jotenkin näin (?) :

0. iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
1. DNS-kyselyt siihen saakka, että vpn on pystyssä, sen jälkeen ei niitäkään, esim.
iptables -A OUTPUT -j ACCEPT -p udp --dport 53
2. OpenVPN lähtevä liikenne, oletuksena UDP 1194
iptables -A OUTPUT -j ACCEPT -p udp --dport 1194 , onko näin oikein ?
3. Nämä tarvittaneen, että ulosmenevään viestiin saadaan vastaus
iptables -A INPUT -j ACCEPT -m conntrack --ctstate ESTABLISHED,RELATED
iptables -A OUTPUT -j ACCEPT -m conntrack --ctstate ESTABLISHED,RELATED
4. iptables -A INPUT -j ACCEPT -i tun+
iptables -A OUTPUT -j ACCEPT -i tun+
...
(Iso ISO kiitos vaivannäöstäsi)
...
5. Kielletään SSH sisäänpäin, mutta onko sääntö taas aivan väärin ?
iptables -I INPUT -i enp3s0 -p tcp --dport 22 -j DROP (enp3s0 vai tun0 ?)
iptables -I INPUT -i enp3s0 -p udp --dport 22 -j DROP (enp3s0 vai tun0 ?)
Täytyykö molemmat protokollat kieltää ? Ja täytyykö näille tehdä myös 3 kohdan mukaiset -m conntrack --ctstate ESTABLISHED,RELATED säännöt ? Jossain ohjeissa oli semmoisiakin ehdoteltu, mutta olettaisin että noita ei tarvita kun kielletään SSH sisään ?
6.
7.
8. Onko niin että nyt voi jatkaa sääntöjen listaamista tähän, riippuen kai että mitä sääntöjä on luomassa... ?
9.
10.

11. Sääntöjen tallennus
sudo iptables-save ? Onko oikea komento ?


Toinen hyvä tapa oli tehdä nämä asiat minkä hoksasin ainakin kerran aikaisemmin toimivan,..:

sudo nano /etc/iptables/vpn-rules.v4
*filter
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
-A OUTPUT -j ACCEPT -p udp --dport 53
-A OUTPUT -j ACCEPT -p udp --dport 1194
-A INPUT -j ACCEPT -m conntrack --ctstate ESTABLISHED,RELATED
-A OUTPUT -j ACCEPT -m conntrack --ctstate ESTABLISHED,RELATED
-A INPUT -j ACCEPT -i tun+
-A OUTPUT -j ACCEPT -i tun+
-A jne...

ctrl+x /y enter
sudo iptables-restore < /etc/iptables/vpn-rules.v4

Jos ei toiminu, niin palauttaa alkuperäiset säännöt.
iptables-restore < /etc/iptables/iptables.rules ..Tai joku scriptin pätkä joka hoitaisi automaattisesti kaikki nopeasti...

Tästäkään ei vaan ole takuita toimiiko enää mikään sääntö, se on jokseenkin sekavaa palautella ja ihmetellä toimiiko mikään enää.


Pahoittelut nyt vielä viestistä @mikajh kun on vähän sekava viesti, mutta siinä on vielä jokunen kiperä sääntökohta ja pari pohdintaa koko hommasta. Katsastaisitko että onko nuo kysymäni ja lisäämäni kohdat vielä ok ? Sitten voisin uskaltaa jo näitä kokeilemaankin.

 

[Hyrava]

SSH kulkee oletuksena TCP:n päällä. Kannattaa ajatella tuota palomuuria niin että kaikki on oletuksena kiinni (DROP-sääntö) ja sitten vaan avataan halutut portit. Eli ensin kaikki kiinni sillä default-drop-säännöllä ja sitten avataan esim ssh halutusta paikasta.

Ja jos haluat jostain ulkopuolelta ottaa yhteyttä VPN:llä niin pitää INPUT-säännössä olla VPN:n käytämä portti, eli ulkopuolinen client ottaa yhdeyden SISÄÄNpäin.

Localhost eli lo kannattaa sallia joka suuntaan, kaikki saattaa suunnilleen toimia hyvin ilmankin mutta sitten yhtäkkiä tulee mystisiä juttuja jos tuo on estetty. Toki sitä voi blokata mutta pitää tietää mitä tekee.

Tuo Related/established -sääntö kannattaa ehkä tehdä vain kertaalleen, sallimaan kaiken related ja established -liikenteen eikä jokaiselle portille / palvelulle / hostille / interfacelle erikseen.

Ja itse teen nuo sännöt /etc/network/if-pre-up.d/iptables -tiedostoon debian-varianteissa, toimii sieltä ainakin suoraan ilman mitään iptables-save / iptables-restore -kikkailua.

 

[mikajh]

Korvautuuko se tällä iptables-nft paketilla ?

Tuo paketti on yhteensopivuuskerros, jolla iptables-ruleja voi käyttää, vaikka koneessa on jo nftables

 

[Pah0lain3]

SSH kulkee oletuksena TCP:n päällä. Kannattaa ajatella tuota palomuuria niin että kaikki on oletuksena kiinni (DROP-sääntö) ja sitten vaan avataan halutut portit. Eli ensin kaikki kiinni sillä default-drop-säännöllä ja sitten avataan esim ssh halutusta paikasta.

Ja jos haluat jostain ulkopuolelta ottaa yhteyttä VPN:llä niin pitää INPUT-säännössä olla VPN:n käytämä portti, eli ulkopuolinen client ottaa yhdeyden SISÄÄNpäin.

Localhost eli lo kannattaa sallia joka suuntaan, kaikki saattaa suunnilleen toimia hyvin ilmankin mutta sitten yhtäkkiä tulee mystisiä juttuja jos tuo on estetty. Toki sitä voi blokata mutta pitää tietää mitä tekee.

Tuo Related/established -sääntö kannattaa ehkä tehdä vain kertaalleen, sallimaan kaiken related ja established -liikenteen eikä jokaiselle portille / palvelulle / hostille / interfacelle erikseen.

Ja itse teen nuo sännöt /etc/network/if-pre-up.d/iptables -tiedostoon debian-varianteissa, toimii sieltä ainakin suoraan ilman mitään iptables-save / iptables-restore -kikkailua.

Kiitos hyvästä viestistä. Katsotaanpas.

Eli kun alussa on nämä DROP-säännöt niin näiden jälkeen täytyy sallia molempiin suuntiin tuo localhost, vai voiko localhostin sallia vielä kaikkien sääntöjen jälkeenkin ? Niiden ei tarvitse olla sen ihmeellisemmässä järjestyksessä noiden sääntöjen ? Ja nuo samat DROP säännöt siis pudottaa myös sen SSH nyt sitten pois käytöstä ellei sitä erikseen sallita ? Sitä taisit tarkoittaa. Jos ne lo 2 sääntöä laittais heti perään niin noissa säännöissä olis itselle vähän selvempi järjestys ainakin.
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP Nämä siis pudottaa pois kaiken(ssh, ftp jne)? Ja halutut on avattava erikseen kuten vpn sisään, ulos tai ssh jompaankumpaan suuntaan.

Sallitaanko lo näin ? (@mikajh laittama ohje, yritin vain muokata lo muotoon)
-A INPUT -j ACCEPT -i lo
-A OUTPUT -j ACCEPT -i lo

Ja seuraavaksi loput säännöt niin pitäisi toimia. Ai niin se VPN sisäänpäin.
iptables -I INPUT -i tun+ -p udp --dport 1234 -j ACCEPT (enp3s0 vai tun0 & udp vai tcp ?)
Olisko se sääntö sitten näin, mutta kumpi protokolla ja kumpaan interfaceen, jotenkin olettaisin että tun+, mutta protokollaa en tiedä. Sitte alkaiski vissiinkin olla sääntöruletti kasassa että voipi lähteä kokeilemaan kohta. Tarviiko tuo vpn sisään muita sääntöjä kaveriksi enää ? Ulos on jo tuolla sääntö.
Mutta on siellä myös -A INPUT -j ACCEPT -i tun+ ,eli sisäänpäin jo sallittuna. Tarviiko tuossa enää erikseen sääntöä ja porttia sallia ?

Kiitos molemmille hyvistä vastauksista, odottelen vielä jos tulee tarkennettavaa tai muuta vielä mitä täytyy lisätä sääntöihin niin en aivan vielä lähde koittelemaan.

 

[Pah0lain3]

Kutakuinkin kaikki näyttäis toimivan nyt.

Ihmettelin vähän aikaa tota tallennusta miksi se heivas aina talletetut säännöt pois. No bootin jälkeen se käytti eri tiedostoa mihin säännöt talletin. Eli säännöt pitikin tallettaa oikeaan tiedostoon niin nyt ne pysyvät myös bootin yhteydessä.

Säännöt tein kerran hyväksi huomatulla tavalla eli näin.

sudo nano /etc/iptables/vpn-rules.v4

*filter
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP

-A INPUT -j ACCEPT -i lo
-A FOWWARD -j ACCEPT -i lo
-A OUTPUT -j ACCEPT -o lo

-A OUTPUT -j ACCEPT -p udp --dport 53
-A OUTPUT -j ACCEPT -p udp --dport 1194

-A INPUT -j ACCEPT -m conntrack --ctstate ESTABLISHED,RELATED
-A OUTPUT -j ACCEPT -m conntrack --ctstate ESTABLISHED,RELATED

-A INPUT -j ACCEPT -i tun+
-A OUTPUT -j ACCEPT -o tun+

-A INPUT -i tun+ -p udp --dport xxx -j ACCEPT
COMMIT


ctrl+x / y enter
sudo iptables-restore < /etc/iptables/vpn-rules.v4

sudo iptables-save ei riittäny koska ne talletettiin tuonne vpn-rules.v4 paikkaan. Sen takia bootin jälkeen säännöt oli aina hukassa. Säännöt täytyi siirtää oikeaan paikkaan ja tallettaa niin toimi. sudo iptables-save -f /etc/iptables/iptables.rules toimi lopulta. Jotenkin tuon tallentamisen onnistuin mokaamaan kerta toisensa jälkeen ennenkuin tajusin.

Alkuun oli @mikajh tehny pari pientä jäynää tuonne sekaan , kun oli -i säännössä kahdessa tai kolmessa eri rivissä, eikä nuo säännöt menny läpi. Jostain muistin kokeilla -o, ja OUTPUT kun sopi hyvin mun ajattelutavalla yhteen niin päätin kokeilla. Sitten kaikki säännöt hyväksyttiin. Nyt ne tässä viestissä on siinä muodossa että ne kelpas käyttöön. Laitoin myös nuo localhost säännöt mukaan.

Tuosta alimmaisesta säännöstä en ole varma täytyykö sen olla mukana, kuitenkin sisään vpn on sallittu ja nyt sallin vielä erikseen tietyn portinkin sisään niin oliko se turhaa vai ei sallia tuo portti erikseen tun0:ssa ? Olisko viisaampi ottaa se INPUT sääntö pois ja sallia vain 1 portti sisään vai ymmärränkö tuota sääntöä vieläkin väärin? Mutta sääntöjen järjestyksellä ei taida olla merkistystä ollenkaan. Tarkistelin sääntöjä komentorivillä, niin se antoi ne ihan hujan hajan eri järjestyksessä.

Mutta nopeilla testeillä, vpn yhteys toimii ja dnsleaktest.com ym testisivuilla sain ihan oikeanlaista tulosta. VPN palvelun ollessa off ei toiminu sivut selaimessa ollenkaan. Komentorivillä ei pysty päivittämäänkään mitään, jos vpn tunneli on alhaalla. Eli ainakin äskeisillä pikkunopeilla testeillä säännöt teki aivan sen mitä toivoinkin. Eli voisin olettaa että ssh eikä muutkaan tässä vaiheessa ylimääräiset ei ole auki ollenkaan ? Kun tarvin, ne täytyy sallia erikseen myöhemmin käyttöä varten. Kuulostaa jo hyvältä !

Jos @mikajh @Hyrava tai joku muu osaava kattelis tän viestin nuo säännöt läpi että kaiken pitäis olla ok niin voihan olla tähän ongelmaan löysitte ratkaisun vieläpä nopeasti. Siispä suuret kiitokset teille !

1 asia mietityttää vielä kuitenkin paljon, kuinka paljon otan takkiin turvallisuudessa vs default distroasennus ? Eli jos nyt vaikka asennan Manjaron, enkä osaa laitella gufw, tai ufw ym päälle, eli ihan vaan default asetuksilla asennuksen jälkeen vetelisin menemään. Täytyykö sääntöjä luoda lisää ja kiristellä vielä ? Vai onko muutos jo pikkuisen parempaan päin ?

Kiitos !

 

[Hyrava]

Kutakuinkin kaikki näyttäis toimivan nyt.

Ihmettelin vähän aikaa tota tallennusta miksi se heivas aina talletetut säännöt pois. No bootin jälkeen se käytti eri tiedostoa mihin säännöt talletin. Eli säännöt pitikin tallettaa oikeaan tiedostoon niin nyt ne pysyvät myös bootin yhteydessä.

Säännöt tein kerran hyväksi huomatulla tavalla eli näin.

sudo nano /etc/iptables/vpn-rules.v4

*filter
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP

-A INPUT -j ACCEPT -i lo
-A FOWWARD -j ACCEPT -i lo
-A OUTPUT -j ACCEPT -o lo

-A OUTPUT -j ACCEPT -p udp --dport 53
-A OUTPUT -j ACCEPT -p udp --dport 1194

-A INPUT -j ACCEPT -m conntrack --ctstate ESTABLISHED,RELATED
-A OUTPUT -j ACCEPT -m conntrack --ctstate ESTABLISHED,RELATED

-A INPUT -j ACCEPT -i tun+
-A OUTPUT -j ACCEPT -o tun+

-A INPUT -i tun+ -p udp --dport 61739 -j ACCEPT
COMMIT


ctrl+x / y enter
sudo iptables-restore < /etc/iptables/vpn-rules.v4

sudo iptables-save ei riittäny koska ne talletettiin tuonne vpn-rules.v4 paikkaan. Sen takia bootin jälkeen säännöt oli aina hukassa. Säännöt täytyi siirtää oikeaan paikkaan ja tallettaa niin toimi. sudo iptables-save -f /etc/iptables/iptables.rules toimi lopulta. Jotenkin tuon tallentamisen onnistuin mokaamaan kerta toisensa jälkeen ennenkuin tajusin.

Alkuun oli @mikajh tehny pari pientä jäynää tuonne sekaan , kun oli -i säännössä kahdessa tai kolmessa eri rivissä, eikä nuo säännöt menny läpi. Jostain muistin kokeilla -o, ja OUTPUT kun sopi hyvin mun ajattelutavalla yhteen niin päätin kokeilla. Sitten kaikki säännöt hyväksyttiin. Nyt ne tässä viestissä on siinä muodossa että ne kelpas käyttöön. Laitoin myös nuo localhost säännöt mukaan.

Tuosta alimmaisesta säännöstä en ole varma täytyykö sen olla mukana, kuitenkin sisään vpn on sallittu ja nyt sallin vielä erikseen tietyn portinkin sisään niin oliko se turhaa vai ei sallia tuo portti erikseen tun0:ssa ? Olisko viisaampi ottaa se INPUT sääntö pois ja sallia vain 1 portti sisään vai ymmärränkö tuota sääntöä vieläkin väärin? Mutta sääntöjen järjestyksellä ei taida olla merkistystä ollenkaan. Tarkistelin sääntöjä komentorivillä, niin se antoi ne ihan hujan hajan eri järjestyksessä.

Mutta nopeilla testeillä, vpn yhteys toimii ja dnsleaktest.com ym testisivuilla sain ihan oikeanlaista tulosta. VPN palvelun ollessa off ei toiminu sivut selaimessa ollenkaan. Komentorivillä ei pysty päivittämäänkään mitään, jos vpn tunneli on alhaalla. Eli ainakin äskeisillä pikkunopeilla testeillä säännöt teki aivan sen mitä toivoinkin. Eli voisin olettaa että ssh eikä muutkaan tässä vaiheessa ylimääräiset ei ole auki ollenkaan ? Kun tarvin, ne täytyy sallia erikseen myöhemmin käyttöä varten. Kuulostaa jo hyvältä !

Jos @mikajh @Hyrava tai joku muu osaava kattelis tän viestin nuo säännöt läpi että kaiken pitäis olla ok niin voihan olla tähän ongelmaan löysitte ratkaisun vieläpä nopeasti. Siispä suuret kiitokset teille !

1 asia mietityttää vielä kuitenkin paljon, kuinka paljon otan takkiin turvallisuudessa vs default distroasennus ? Eli jos nyt vaikka asennan Manjaron, enkä osaa laitella gufw, tai ufw ym päälle, eli ihan vaan default asetuksilla asennuksen jälkeen vetelisin menemään. Täytyykö sääntöjä luoda lisää ja kiristellä vielä ? Vai onko muutos jo pikkuisen parempaan päin ?

Kiitos !

Noniin, käydääs säännöt läpi:
- Aluksi kielletään kaikki
- sallitaan kaikki loopback/localhost-liikenne eli lo
- (kirjoitusvirhe FORWARD -säännössä)
- Sallitaan lähtevät yhteydet portteihin 53 ja 1194 kaikista interfaceista
- Sallitaan tulevat ja lähtevät established tai related -yhteydet
- Sallitaan kaikki tulevat ja lähtevät VPN-tunneliyhteydet (tun-device)
- Sallitaan tuleva udp/61739 VPN:stä (turha, koska sallittiin jo kaikki VPN-putken liikenne)

Melkein laittaisin tuon portin 1194 vain fyysiselle interfacelle mutta tuossa tapauksessa sillä ei ole oikeastaan merkitystä, tuskin VPN-putken läpi kuitenkaan tulee toista VPN-putkea joten itse ihan kauneuden vuoksi lisäisin sille interfacen.

Jos noilla säännöillä toimii kuten pitää niin sanoisin että paljoa tuota tiukemmaksi tuota ei järkevästi saa, toki ihan paranoidiversionkin voisi tehdä jossa kaikki on kiinni ja interface- ja porttikohtaisesti availtaisiin reikiä mutta... Töissä meillä on suunnilleen jokaisessa säännössä portti ja interface määritelty, jopa suoraan ip-osoitteitakin mutta se nyt on vähän eri asia, alkaa olla jo työtä ylläpitää kun on tuhansia rivejä iptables-sääntöjä.

 

[Pah0lain3]

Noniin, käydääs säännöt läpi:
- Aluksi kielletään kaikki
- sallitaan kaikki loopback/localhost-liikenne eli lo
- (kirjoitusvirhe FORWARD -säännössä)
- Sallitaan lähtevät yhteydet portteihin 53 ja 1194 kaikista interfaceista
- Sallitaan tulevat ja lähtevät established tai related -yhteydet
- Sallitaan kaikki tulevat ja lähtevät VPN-tunneliyhteydet (tun-device)
- Sallitaan tuleva udp/xxxx VPN:stä (turha, koska sallittiin jo kaikki VPN-putken liikenne)

Melkein laittaisin tuon portin 1194 vain fyysiselle interfacelle mutta tuossa tapauksessa sillä ei ole oikeastaan merkitystä, tuskin VPN-putken läpi kuitenkaan tulee toista VPN-putkea joten itse ihan kauneuden vuoksi lisäisin sille interfacen.

Jos noilla säännöillä toimii kuten pitää niin sanoisin että paljoa tuota tiukemmaksi tuota ei järkevästi saa, toki ihan paranoidiversionkin voisi tehdä jossa kaikki on kiinni ja interface- ja porttikohtaisesti availtaisiin reikiä mutta... Töissä meillä on suunnilleen jokaisessa säännössä portti ja interface määritelty, jopa suoraan ip-osoitteitakin mutta se nyt on vähän eri asia, alkaa olla jo työtä ylläpitää kun on tuhansia rivejä iptables-sääntöjä.

Eli 1194 sääntöön lisätä "iface" joka varmaankin on tässä tapauksessa tuo enp3s0, ei lo eikä tun+ ? Ei tule mitään toisia vpn putkia kyllä. Enköhän saa sen lisättyä. Sain näköjään vielä kopioitua sen kirjoitusvirheen tännekkin. Onneksi se risukasaki paistaa aurinkoon joskus.

Oisko se niinkin yksinertainen homma, että tuon viimeisimmän säännön jättäisin paikalleen, mutta ottaisin pois sen joka salliikin kaiken sisään ? Eli tämän(kö) -A INPUT -j ACCEPT -i tun+ ? Joudunko silloin heti tuolle mainitsemallesi tielle missä joutuu availemaan kaikille portit erikseen? Taitaa aikalailla joutua. Mutta sun tekstistä nyt kuitenkin sain kuvan että ei se haitaksikaan ole vaikka onkin kaikki sisään sallittuna?? Eli melkein nyt toistaiseksi voin napsia sen ylimääräisen turhan säännön vain pois.

 

[Hyrava]

Eli 1194 sääntöön lisätä "iface" joka varmaankin on tässä tapauksessa tuo enp3s0, ei lo eikä tun+ ? Ei tule mitään toisia vpn putkia kyllä. Enköhän saa sen lisättyä. Sain näköjään vielä kopioitua sen kirjoitusvirheen tännekkin. Onneksi se risukasaki paistaa aurinkoon joskus.

Oisko se niinkin yksinertainen homma, että tuon viimeisimmän säännön jättäisin paikalleen, mutta ottaisin pois sen joka salliikin kaiken sisään ? Eli tämän(kö) -A INPUT -j ACCEPT -i tun+ ? Joudunko silloin heti tuolle mainitsemallesi tielle missä joutuu availemaan kaikille portit erikseen? Taitaa aikalailla joutua. Mutta sun tekstistä nyt kuitenkin sain kuvan että ei se haitaksikaan ole vaikka onkin kaikki sisään sallittuna?? Eli melkein nyt toistaiseksi voin napsia sen ylimääräisen turhan säännön vain pois.

Juu, 1194-portin sääntöön interfaceksi enp3s0 eli se interface jossa liikenne fyysisesti kulkee.

Niin, ja itseasiassa tuossa yöllä tuli ajateltua liian työnäkökulmasta, eli kaikki VPN-liikenne olisi varmasti luotettua liikennettä. Tuo miten tuon tunnelin muuraus kannattaa tehdä riippuu esimerkiksi siitä onko tunnelin toisessa päässä internet vai joku luotettuna pitämäsi laite josta ei tule ylimääräisiä yhteyksiä. jos tuo VPN on joku NordVPN tai vastaava jolla vaan haluaa esim piilottaa sijaintinsa niin toisessa päässä tosiaan on internet eli silloin ainakin itse pistäisin kaikki INPUT-säännöt putkesta oletuksena kiinni ja availisin tarpeen mukaan. Ylipäätään yleensä tulevat yhteydet ovat suurempi riski, itsellänikin on joissakin laitteissa OUTPUT-sääntönä ACCEPT eli kaikki ulos menevä sallitaan koska pidän kyseisiä laitteita sen verran turvallisina etteivät omin päin availe yhteyksiä ulospäin.

Tarkempi säätäminen siis vaatii tarkempaa tietoa mitä tuolla halutaan saada aikaiseksi.

 

[Pah0lain3]

Juu, 1194-portin sääntöön interfaceksi enp3s0 eli se interface jossa liikenne fyysisesti kulkee.

Niin, ja itseasiassa tuossa yöllä tuli ajateltua liian työnäkökulmasta, eli kaikki VPN-liikenne olisi varmasti luotettua liikennettä. Tuo miten tuon tunnelin muuraus kannattaa tehdä riippuu esimerkiksi siitä onko tunnelin toisessa päässä internet vai joku luotettuna pitämäsi laite josta ei tule ylimääräisiä yhteyksiä. jos tuo VPN on joku NordVPN tai vastaava jolla vaan haluaa esim piilottaa sijaintinsa niin toisessa päässä tosiaan on internet eli silloin ainakin itse pistäisin kaikki INPUT-säännöt putkesta oletuksena kiinni ja availisin tarpeen mukaan. Ylipäätään yleensä tulevat yhteydet ovat suurempi riski, itsellänikin on joissakin laitteissa OUTPUT-sääntönä ACCEPT eli kaikki ulos menevä sallitaan koska pidän kyseisiä laitteita sen verran turvallisina etteivät omin päin availe yhteyksiä ulospäin.

Tarkempi säätäminen siis vaatii tarkempaa tietoa mitä tuolla halutaan saada aikaiseksi.

En pitäisi luotettuina mitään laitteita itseni kohdalla. Mutta kyllä, ymmärrän tuon kyllä että omat laitteet todennäköisemmin on luotetumpia, kuin suoraan ulkoa tulevat mahdolliset yhteydet. Mutta tässä tapauksessa toistaiseksi tunnelin toisessa päässä on internet. Eli kiinni se kannattaa kyllä laittaa ja availla tarpeen mukaan.

Nythän tuo mitä halusin saada aikaiseksi oli vähän väärin, kun kaikki tun+ sallittiin sisään ja ulos. Vain se enp3s0 blokattiin. Kun jälkeenpäin miettii nyt lisää ymmmärrystä saaneena, niin viisaampihan se olis vielä tehdä niin että tun+ sisään ulos kiinni ja ulospäin avattaisiin selaimelle ym pakollisille tiet ulkomaailmaan. Se vaan on niin hankala toteuttaa. Vähän olen "nyyppä" ja sekoillut näiden sääntöjen kanssa oikein tosissaan.

Tuo oikeastaan voisi olla seuraava oppimiskäyrän boostaus, että laitan nuo tun+:ssat kiinni ja yritän avata selaimelle 443 portin? http se 80 portti onko pakollinen avata myös jos haluaa vain S liikenteen sallia? Yhteys on kuitenkin tunneloitu, joten vois kai sen http liikenteenkin sallia ihan huolettomasti? Tuolloin ei tarvitsi miettiä onko ssh jääny auki vahingossa. Mitä olet mieltä ? Tai edes sisäänpäin laittaa kiinni, ja ulospäin voi varmaan olla auki, niin sen turvallisuuden näkökulmasta tämä vois olla semmoinen "optimaalisen" hyvä kotiratkaisu ?

 

[Miika]

Jos tuolla koneella tehään webisurffausta joka puolelle internettiä, niin salli tun-interfacessa sisään established ja related (tätä voi vielä koventaa source portteja määrittelemällä). Jos sitten jossakin portissa haluat pitää jotain palvelua, niin avaat sen erikseen vaikka ilman tilatietoa.

Ulospäin voisi ensi alkuun sallia portit TCP/80, TCP/443 ja UDP/53 (+jotain ICMP-protokollia?). Siitä sitten vaan surffailemaan ja tcpdumpilla katsomaan, mihin muihin portteihin kone tahtoisi mennä. Esim. komennolla "sudo tcpdump -i tun0 -nn src host 1.2.3.4", jossa oletetaan, että sun VPN-interface on tun0 ja VPN:n IP 1.2.3.4. Jos johokin lähtevään pyyntöön ei tule vastausta, on joko vastapää nurin tai iptables estää. Toki, jos haluaa lokia iptablesista, niin sitten LOG-rimpsuja sopiviin kohtiin.

Tietyn sovelluksen salliminen Linuxin palomuurissa on kenties mahdollista, mutta ei ole koskaan ollut sellaiseen tarve. Google kertonee onnistuuko ja miten.

 

[Pah0lain3]

Jos tuolla koneella tehään webisurffausta joka puolelle internettiä, niin salli tun-interfacessa sisään established ja related (tätä voi vielä koventaa source portteja määrittelemällä). Jos sitten jossakin portissa haluat pitää jotain palvelua, niin avaat sen erikseen vaikka ilman tilatietoa.

Ulospäin voisi ensi alkuun sallia portit TCP/80, TCP/443 ja UDP/53 (+jotain ICMP-protokollia?). Siitä sitten vaan surffailemaan ja tcpdumpilla katsomaan, mihin muihin portteihin kone tahtoisi mennä. Esim. komennolla "sudo tcpdump -i tun0 -nn src host 1.2.3.4", jossa oletetaan, että sun VPN-interface on tun0 ja VPN:n IP 1.2.3.4. Jos johokin lähtevään pyyntöön ei tule vastausta, on joko vastapää nurin tai iptables estää. Toki, jos haluaa lokia iptablesista, niin sitten LOG-rimpsuja sopiviin kohtiin.

Tietyn sovelluksen salliminen Linuxin palomuurissa on kenties mahdollista, mutta ei ole koskaan ollut sellaiseen tarve. Google kertonee onnistuuko ja miten.

Semmoisen homman nyt huomasin että linuxin eli käyttöjärjestelmän päivityksiä ei saa millään ilveellä tulemaan. Pitäis varmaan manuaalisti jokainen asennella, mutta siihen ei kukaan halua lähteä Normaalisti sudo pacman -Syu lataa ja asentaa kaikki käyttöjärjestelmän päivitkset, mutta nyt vain terminaali sanoo että kaikki on "ok", vaikkei ole. Eiköhän tässä ajassa olisi jokusen päivityksen täytyny ilmaantua kun niitä yleensä tulee melkein päivittäin. Varmuudeksi odotin näin kauan, niin olen aika varma että missaan jokaisen päivityksen.

Eli joku on luultavasti liian tiukasti tukittu. Mitähän kautta nuo päivityset tapaa tulla ? Tarttee nyt joku sääntö luoda. Google ei antanu tulosta siihen miksei linuxille tuu päivityksiä. Mutta syyhän taitaa olla tuo kun on dropattu melkein kaikki "ylimääräinen", eli jotain tarvitsis sallia, mutta mitähän ? Tuo on vähän outoa. Eikö 80 ole http liikennöintiä varten ja 443 https varten, joten niitä tuskin tässä kohtaa tarvitsee ? Terminaalissa käyttöjärjestelmän päivittäminen ei taida tarvita ftp, ssh tai mitään telnet yhteyksiä/portteja ? Vai miten tuo update käytännössä toimii ? Vai liittyykö tuo ICMP jotenkin tähän kohtaan ? En vain taaskaan yhtään tiedä.

 

[Hyrava]

Semmoisen homman nyt huomasin että linuxin eli käyttöjärjestelmän päivityksiä ei saa millään ilveellä tulemaan. Pitäis varmaan manuaalisti jokainen asennella, mutta siihen ei kukaan halua lähteä Normaalisti sudo pacman -Syu lataa ja asentaa kaikki käyttöjärjestelmän päivitkset, mutta nyt vain terminaali sanoo että kaikki on "ok", vaikkei ole. Eiköhän tässä ajassa olisi jokusen päivityksen täytyny ilmaantua kun niitä yleensä tulee melkein päivittäin. Varmuudeksi odotin näin kauan, niin olen aika varma että missaan jokaisen päivityksen.

Eli joku on luultavasti liian tiukasti tukittu. Mitähän kautta nuo päivityset tapaa tulla ? Tarttee nyt joku sääntö luoda. Google ei antanu tulosta siihen miksei linuxille tuu päivityksiä. Mutta syyhän taitaa olla tuo kun on dropattu melkein kaikki "ylimääräinen", eli jotain tarvitsis sallia, mutta mitähän ? Tuo on vähän outoa. Eikö 80 ole http liikennöintiä varten ja 443 https varten, joten niitä tuskin tässä kohtaa tarvitsee ? Terminaalissa käyttöjärjestelmän päivittäminen ei taida tarvita ftp, ssh tai mitään telnet yhteyksiä/portteja ? Vai miten tuo update käytännössä toimii ? Vai liittyykö tuo ICMP jotenkin tähän kohtaan ? En vain taaskaan yhtään tiedä.

Google tiesi kertoa parissa sekunnissa:
Depends on the mirror you use; either HTTP (80) or FTP (21)

Eli sinulla pitää olla se related, established määriteltynä muurissa ja sitten ulospäin pitää sallia joko http tai ftp, riippuen mistä mirrorista noita päivityksiä olet pacmanin määritellyt hakemaan. Jos oikein paranoidiksi alkaa, niin voisi selvittää päivityspalvelimien osoitteet ja laittaa nuo portit auki vain kun ne osoitteet ovat kohdeosoitteena.

 

[Pah0lain3]

Google tiesi kertoa parissa sekunnissa:
Depends on the mirror you use; either HTTP (80) or FTP (21)

Eli sinulla pitää olla se related, established määriteltynä muurissa ja sitten ulospäin pitää sallia joko http tai ftp, riippuen mistä mirrorista noita päivityksiä olet pacmanin määritellyt hakemaan. Jos oikein paranoidiksi alkaa, niin voisi selvittää päivityspalvelimien osoitteet ja laittaa nuo portit auki vain kun ne osoitteet ovat kohdeosoitteena.

Kiitos kun viitsitte ja jaksatte auttaa. Jotenkin kuvittelin että täytyisi joku portti avata sisäänpäin kun kerran päivitysten täytyy saapua "jostain minulle", Mutta kiva kun kerroit, kokeilen avata ulospäin. Ja varmaan tuo vpn interfacesta availlaan, oletan ainakin. Mutta tähän saakka olin kuvitellu että http (80) & 443 (https) on selaimien liikennöintiä varten ainoastaan eikä sieltä kulkisi mitään muuta esimerkiksi käyttiksen päivityksiä, mutta näköjään samasta portista kulkee muutakin "juttua" samalla. Luulin että näille päivityksille on joku oma porttinsa, tai ryhmä portteja mitä täytyy aukoa. Nyt on taas vähän hölmö fiilis.

No mutta, kokeilen avata tun+ (vpn putki) portit 80 & 443 ulospäin ainoastaan. related, established sääntöhän on aiemmin jo luotu tuolla ylempänä. Sitä ei tarvinnu enää luoda ? Sain hieman viitteitä yhdestä reddit keskustelusta että nuo portit (80 & 443) luultavasti täytyy olla avoinna. Mutta mistä voin varmistua asiasta ? Ottamalla distron tekijöihin yhteyttä, vai ihan vain googlettamalla ? Se tieto varmaan löytyis myös käyttiksen jostain tiedostosta jos osais kaivella mutta en nyt oikein sitä handlaa.

Eli voisin lisätä sääntöihin
-A OUTPUT -j ACCEPT -o tun+ -p tcp --dport 80
-A OUTPUT -j ACCEPT -o tun+ -p tcp --dport 443
Näiden sääntöjen nyt ymmärtääkseni pitäis riittää, jos ne on oikeinkaan?
Protokollasta en ole varma. Vai onko parempi että tuohon ei sotketa interfacea ollenkaan ?

Hauskahan siihen sääntöön olisi laittaa mukaan jonkinlainen destination source (ehkä) joka antaisi ottaa niihin tiettyihin ip osoitteisiin ainoastaan. Mutta mistäs ne ip osoitteet sitten osaa kaivaa, tcpdumpilla ? Jos siihen halutaan ip osoite mukaan niin menisikö se jotenkin näin :
iptables -A OUTPUT -j ACCEPT -o tun+ -p tcp -d XXX.XXX.XXX.XXX --dport 443 ?
iptables -A OUTPUT -j ACCEPT -o tun+ -p tcp -d XXX.XXX.XXX.XXX --dport 80 ?

Voiko nuo portit laittaa yhteen ja samaan sääntöön ? DNS siellä on sallittu 53 portista, tarvitaanko jotain muuta erikoista ? Ai joo, nyt tuosta säännöstä unoihtui interface. Varmaan edelleen täytyy käyttää sitä vpn tunnelia eli tun+. Lisäsin interfacen sääntöön, mutta onko se interfacekin väärä säännössä eli täytyykö olla se enp3s0, ei tun0 ?

Hankalia juttuja taas, mutta olen äärettömän kiitollinen kaikkien vaivannäöstä. Kyllä tämä on paljon selvempää kuitenkin kuin aikaisemmin


E: Tässä on nyt aikaisemmat sekä uudet säännöt ehdolla.

-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP

-A INPUT -j ACCEPT -i lo
-A FOWWARD -j ACCEPT -i lo
-A OUTPUT -j ACCEPT -o lo

-A OUTPUT -j ACCEPT -p udp --dport 53
-A OUTPUT -j ACCEPT -o enp3s0 -p udp --dport 1194

-A INPUT -j ACCEPT -m conntrack --ctstate ESTABLISHED,RELATED
-A OUTPUT -j ACCEPT -m conntrack --ctstate ESTABLISHED,RELATED

-A OUTPUT -j ACCEPT -o tun+
* Aikaisemmat säännöt oli tässä


* Tässä on ne uusien sääntöjen vaihtoehdot käyttöjärjestelmän päivitysten sallimiseksi -
-A OUTPUT -o tun+ -p tcp --dport 80 -j ACCEPT
-A OUTPUT -o tun+ -p tcp --dport 443 -j ACCEPT

tai mukaan laitetaan -d [ip osoite]

iptables -A OUTPUT -o tun+ -p tcp -d  XXX.XXX.XXX.XXX --dport 443  -j ACCEPT
iptables -A OUTPUT -o tun+ -p tcp -d  XXX.XXX.XXX.XXX --dport 80  -j ACCEPT


XXX.XXX.XXX.XXX = Se tai ne ip osoitteet, mistä käyttöjärjestelmän päivitykset ladataan (näiden sääntölisäysten tarkoitus).

Tuo olisi näiden sääntölisäysten jälkeen se tämän hetkinen kokonaisuus. Miltä näyttää noin ikäänkuin ? Menikö aivan pieleen tuo sääntö ?

E2: Nyt aikaisemmin luodut säännöt taitaa olla niinkuin ne oikeasti on. Eli iface addattu 1194 sääntöön ja poistettu turhat säännöt. Sekä mahdolliset uudet säännöt näkyy tässä myös.

E3: Ei tuo voi nyt noin mennäkkään. Siellä on sallittu jo ulos tun+, ja nyt yritän ehdotella uudelleen tiettyjen porttien uudelleen avaamista ulospäin kun ulos tun+ on jo sallittu. Täytyykö ne sittenkin sallia enp3s0 interfaceen ? Ei mun ymmärryksen mukaan, tuon alkuperäis sääntöjen mukaan päivitysten täytyisi kyllä toimia ? En nyt lähellekkään ymmärrä tätä taas.

E 4 : Vielä kerran, ja pahoittelut. Kyllähän se toimiikin ilman näitä uusia mietittyjä sääntöjä. Nyt sain könttänä päivityksiä ilman että tein sääntömuutoksia. Nyt oli päivityksissä näköjänsä vain jokin hiljaisempi kausi. Näin tässä ajattelinkin kun sain kaikki säännöt tähän listattua että nyt on jotain hämärää jossain kun kuitenkin oli aiemmin jo sallittu ulospäin vpn putkessa kaikki, joten erikseen ei tarvitse sallia mitään. Aiemminhan se oli niin että kumpaankaan suuntaan ei sallittu mitään. Sitten lennosta muutin hommaa ja nythän ulospäin on sallittu kaikki mutta sisäänpäin ei mitään. Sekoilin itse nyt näiden sääntöjen kanssa.

Mutta hyvää harjoitusta. Ehkä laitan takaisin niin että edes ulospäin ei sallita mitään ja kaikki täytyy sallia erikseen ja tässä luultavasti on se pohja säännöille mitä tarvitsee tehdä ? Täytynee taas pystyttää virtuaalikonetta että voin harjoitella erilaisia mahdollisuuksia. Minun moka, kiitos ja anteeksi. Muistin että päivityksiä on kaikenaikaa, mutta tulikin könttänä pidemmän ajan hiljaiselon jälkeen.