UFW IPv6 firewall open port VPS paano ayusin

Ang IPv6 firewall trap sa isang pangungusap

Pinoprotektahan ng iyong firewall ang IPv4. Ang iyong VPS ay halos tiyak na mayroon ding pampublikong IPv6 address, at maraming serbisyo ang nakikinig dito bilang default. Kung IPv4 lang ang sakop ng iyong firewall, o kung umaasa ka sa isang cloud firewall na nagfi-filter lang ng IPv4, ang bawat isa sa mga serbisyong iyon ay maaabot mula sa buong internet sa pamamagitan ng IPv6 habang ang iyong IPv4 side ay mukhang naka-lockdown. Sinusubukan mo ang isang port gamit ang curl, nakakakita ng tinanggihang koneksyon, at pakiramdam mo ay ligtas ka. Ang isang attacker ay kumokonekta sa parehong port sa pamamagitan ng IPv6 at basta na lang pumapasok.

Ipinapakita ng gabay na ito kung saan nanggagaling ang puwang na iyon sa isang normal na Ubuntu 24.04 VPS, kung paano eksaktong makita kung ano ang iyong inilalantad, at kung paano ito isasara. Ang UFW ay hindi ang kontrabida dito. Sa isang modernong pag-install ng Ubuntu, hinahawakan na ng UFW ang IPv6. Ang pagkakalantad ay nagmumula sa mga layer sa paligid nito, at mula sa mga serbisyong hindi mo alam na nakikinig.

Bakit naka-IPv6 ang VPS mo sa simula pa lang

Halos lahat ng VPS ngayon ay may kasamang public IPv6 address, kadalasan isang buong /64, kasabay ng IPv4 address nito. Tingnan ang sa iyo:

ip -6 addr show scope global

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
    inet6 2001:db8:2a::1/64 scope global

Ang 2001:db8:2a::1 na iyan ay routable mula sa kahit saang bahagi ng internet, tulad mismo ng IPv4 address mo. Ngayon, tingnan kung ano ang nakikinig:

sudo ss -tlnp

State   Recv-Q  Local Address:Port   Process
LISTEN  0       0.0.0.0:22           sshd
LISTEN  0       [::]:22              sshd
LISTEN  0       127.0.0.1:5432       postgres
LISTEN  0       [::]:8080            docker-proxy

Basahing mabuti ang column na Local Address. Ang 0.0.0.0:22 ay nangangahulugang "makinig sa bawat IPv4 address." Ang [::]:22 ay nangangahulugang "makinig sa bawat IPv6 address." Ang 127.0.0.1:5432 ay nakatali sa loopback at hindi talaga public, kaya ligtas ang linya ng Postgres. Ang dalawang linya ng [::] ay sumasagot sa buong internet sa pamamagitan ng IPv6, at ang docker-proxy ay iyong tipong nakalimutan mong sinimulan.

Karamihan sa mga daemon ay nagba-bind sa :: agad, dahil sa Linux, karaniwang tinatanggap din ng isang :: socket ang IPv4. Kaya ang default na posture ng isang bagong server ay "sumagot sa parehong stack, kahit saan." Ang firewall mo lang ang tanging nakaharang diyan, kaya naman ang firewall na isang stack lang ang nakikita ay isang tunay na problema.

Kung saan talaga nanggagaling ang IPv6 gap

May apat na karaniwang pinagmumulan. Sa isang partikular na box, maaaring isa lang o sabay-sabay na ilan ang naroon.

1. Isang cloud firewall na IPv4 lang ang pini-filter. Maraming provider firewall at security-group product ang lumaki sa paligid ng IPv4 at binabalewala ang IPv6 o kailangan ng hiwalay na IPv6 rules na ikaw mismo ang magdadagdag. Kung ang tanging firewall mo ay 'yung nasa provider dashboard at hindi nito sinasaklaw ang IPv6, bukas ang iyong [::] services anuman ang sabihin nito tungkol sa port 22 sa IPv4. Basahin ang firewall documentation ng provider mo at partikular na hanapin ang salitang IPv6.

2. Hand-rolled iptables na walang ip6tables. Ang iptables command ay gumagalaw lang sa IPv4 tables. Ang IPv6 ay may ganap na hiwalay na command, ip6tables, na may sarili nitong hiwalay na rules. Kung nagsulat ka ng firewall script na puno ng iptables -A INPUT ... lines at hindi mo kailanman isinulat ang katugmang ip6tables rules, walang laman ang iyong IPv6 firewall, at pinapayagan ng isang walang lamang INPUT chain na may default ACCEPT policy ang lahat:

sudo ip6tables -L INPUT -n

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Ang output na 'yan ang buong bitag sa isang screen. Naka-filter ang IPv4, tinatanggap ng IPv6 ang mundo.

3. Docker na nagpa-publish ng ports na diretso sa lagpas ng iyong firewall. Kapag pinatakbo mo ang docker run -p 8080:80, naglalagay ang Docker ng sarili nitong rules na nauuna sa UFW, kaya naaabot ang isang published port kahit sinasabi ng ufw status na denied ang port na 'yun, at sa modern Docker, ganito rin ang nangyayari sa IPv6. Ipinapaliwanag ng Bakit nilalampasan ng Docker ang UFW, at kung paano i-filter nang maayos ang container ports ang mekanismo at ang mga fix. Tingnan ang ang mga basics ng Docker Compose sa isang VPS para sa kung paano dine-declare ang mga published port na ito.

4. UFW na naka-switch off ang IPv6. Kayang hawakan ng UFW ang IPv6, pero kapag sinabihan lang ito. Suriin ang switch:

grep IPV6 /etc/default/ufw

Ang modern Ubuntu ay may kasamang IPV6=yes, kaya inilalapat ng UFW ang bawat rule sa parehong stack. Kung makikita mo ang IPV6=no, mula sa isang lumang image o lumang guide, ang bawat UFW rule na isinulat mo ay para lang sa IPv4, at ang IPv6 ay naiiwang unmanaged.

Tingnan nang eksakto kung ano ang inilalantad mo

Huwag manghula. Sukatin ito mula sa labas. Ilista muna ang iyong mga listener at tandaan ang bawat isa na nakatali sa :::

sudo ss -tlnp | grep '::'

Pagkatapos, mula sa ibang machine, kumonekta sa pampublikong IPv6 address ng server at subukan ang isang port na pinaniniwalaan mong sarado:

curl -6 -v http://[2001:db8:2a::1]:8080/

Kung nagbalik iyon ng pahina o banner, bukas ang port sa IPv6. Ang saradong port ay nagbibigay sa iyo ng Connection refused o timeout. Para sa kumpletong larawan, i-scan ang IPv6 address gamit ang nmap mula sa labas ng server:

nmap -6 2001:db8:2a::1

Bawat port na iniulat ng nmap bilang bukas sa IPv6 ay port na maaabot ng buong internet, anuman ang ipinakita ng iyong IPv4 scan. Ang paghahambing ng IPv4 at IPv6 scans nang magkatabi ay ang pinakamabilis na paraan para mahanap ang puwang: anumang bukas sa -6 ngunit sarado sa IPv4 ay isang serbisyo na hindi nasasaklaw ng iyong firewall.

Isara ang gap

Siguraduhing sakop ng UFW ang parehong stack, at default ay i-deny. Kumpirmahin ang switch, pagkatapos ay mag-set ng default-deny inbound policy at payagan lang ang kailangan mo:

sudo sed -i 's/^IPV6=no/IPV6=yes/' /etc/default/ufw
sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

Kung aktibo na ang UFW noong i-flip mo ang IPV6=yes, hindi magkakabisa ang pagbabago hangga't hindi mo pinapatakbo ang sudo ufw reload.

Inililista ng ufw status ang bawat rule nang dalawang beses, isang plain at isang may (v6) suffix. Kapag nakita mo ang mga (v6) line, pini-filter na ng UFW ang IPv6:

22/tcp                     ALLOW IN    Anywhere
22/tcp (v6)                ALLOW IN    Anywhere (v6)

Kung mano-mano mong mina-manage ang iptables, i-mirror ang bawat rule sa ip6tables, o lumipat sa nftables, na ang inet tables ay sumasaklaw sa IPv4 at IPv6 sa iisang lugar at inaalis ang buong klase ng pagkakamaling ito. Ang isang inet filter table ng nftables ang pinakamalinis na solusyon kapag ikaw mismo ang sumusulat ng rules.

I-bind sa loopback ang mga serbisyong ayaw mong maging pampubliko. Ang database, admin panel, o metrics endpoint ay bihirang mangailangan ng pampublikong address. I-bind ito sa 127.0.0.1 at ::1 para hindi ito makinig sa isang routable address sa simula pa lang. Para sa Postgres, i-set ang listen_addresses = 'localhost'. Para sa isang app server, i-bind ito sa 127.0.0.1 at maglagay ng reverse proxy sa harap nito. Mas mainam na isara ang listener kaysa i-firewall ito, dahil wala nang mararating.

Huwag umasa sa UFW para bantayan ang mga published port ng Docker. I-publish ang container ports sa isang partikular na address sa halip na sa bawat interface, halimbawa -p 127.0.0.1:8080:80, para ang port ay maabot lang mula sa host at sa anumang sinasadya mong i-proxy dito. Kapag ang isang container ay talagang kailangang maging pampubliko, ilagay ito sa likod ng isang Traefik reverse proxy at i-publish lang ang proxy, hindi ang bawat app.

Magdagdag ng IPv6 rules sa iyong provider firewall, o tanggapin na hindi ito ang iyong firewall para sa IPv6 at hayaan ang UFW o nftables sa host na gawin ang trabahong iyon.

I-verify na sarado nga

Gawin ulit ang parehong outside test pagkatapos ng mga pagbabago mo:

curl -6 -v http://[2001:db8:2a::1]:8080/
nmap -6 2001:db8:2a::1

Ang port na sumagot kanina ay dapat tumanggi na o mag-time-out, at dapat iulat ng nmap na filtered o closed ito. Kung may port na bukas pa rin, balikan ang apat na source sa itaas: isang service na naka-bind pa rin sa :: na walang rule sa harap, isang Docker rule na nasa unahan ng UFW, o isang provider firewall na hindi man lang nakakita ng IPv6.

Mas malakas ang proteksyon kung tuluyang ilalayo sa public internet ang mga sensitibong serbisyo. Ilagay ang SSH at admin panels sa likod ng WireGuard VPN at i-firewall ang kanilang mga port para sumagot lamang sila sa tunnel, at ang isyu ng pagkaka-expose sa IPv6 ay hihinto nang umiral para sa kanila. Para pabagalin ang mga brute-force scan na tumatama sa anumang nananatiling public, patungan ng Fail2ban sa harap ng SSH ang default-deny na firewall.

Kung ang ports mismo ay bago sa iyo, kung ano ang ports at kung paano nakikinig ang mga serbisyo ang panimulang dapat basahin.

FAQ

Hinaharang ba ng UFW ang IPv6 bilang default?

Sa modernong pag-install ng Ubuntu 24.04, oo. Binabasa ng UFW ang IPV6=yes mula sa /etc/default/ufw at inilalapat ang bawat panuntunan sa parehong IPv4 at IPv6, at ipinapakita ng ufw status ang mga panuntunan ng IPv6 na may (v6) na hulapi. Lumalabas ang bitag kapag IPV6=no (mula sa lumang imahe o lumang tutorial), kapag umaasa ka sa provider firewall na sumasala lang ng IPv4, o kapag nag-publish ang Docker ng port na lampas sa UFW. Suriin ang switch gamit ang grep IPV6 /etc/default/ufw.

Paano ko susuriin kung ano ang inilalantad ng aking VPS sa IPv6?

Patakbuhin ang sudo ss -tlnp at pansinin ang bawat listener na ang lokal na address ay nagsisimula sa [::], ibig sabihin ay sumasagot ito sa bawat IPv6 interface. Pagkatapos, mula sa ibang makina, direktang subukan ang pampublikong IPv6 address ng server gamit ang curl -6 -v http://[YOUR:IPV6::ADDR]:PORT/, o i-scan ito gamit ang nmap -6 YOUR:IPV6::ADDR. Anumang port na bukas sa IPv6 scan pero sarado sa IPv4 ang iyong puwang.

Bakit ko naaabot ang port ng aking Docker container kahit sinasabi ng UFW na ito ay nakaharang?

Naglalagay ang Docker ng sarili nitong mga firewall rule na nauuna sa UFW kapag nag-publish ka ng port gamit ang -p, kaya naaabot ang naka-publish na port kahit nakalista ito bilang denied sa ufw status. Nangyayari ito sa IPv4, at sa IPv6 din kapag naka-on ang suporta ng Docker para sa IPv6. Mag-publish sa isang partikular na address tulad ng -p 127.0.0.1:8080:80, o ilagay ang container sa likod ng reverse proxy at i-publish lang ang proxy.

Kailangan ko pa ba ng IPv6 firewall kung solid ang aking IPv4 firewall?

Oo. Ang IPv4 at IPv6 ay magkahiwalay na network stack na may magkahiwalay na firewall rule. Ang perpektong set ng IPv4 rules ay walang nagagawa para sa IPv6 traffic. Kung ang iyong VPS ay may pampublikong IPv6 address, at halos lahat ay mayroon, kung gayon ang anumang serbisyong nakikinig sa :: ay mananatiling naaabot sa pamamagitan ng IPv6 hanggang sa pigilan ito ng isang IPv6 firewall rule o isang loopback binding.

Paano ko gagawing makinig ang isang serbisyo sa IPv4 lang, o sa localhost lang?

Itakda ang bind address ng serbisyo sa sarili nitong config. I-bind sa 127.0.0.1 para sa IPv4 loopback lang, o 0.0.0.0 para sa lahat ng IPv4 address na walang IPv6 listener. Gumagamit ang Postgres ng listen_addresses, ang SSH ay gumagamit ng ListenAddress, at karamihan sa mga app server ay naglalantad ng host o bind flag. Kumpirmahin ang resulta gamit ang sudo ss -tlnp at suriin na ang Local Address ay hindi na nagpapakita ng [::].