UFW IPv6 VPS பாதுகாப்பு ஓட்டை எப்படி அடைப்பது

IPv6 ஃபயர்வால் விலை ஒரு வாக்கியத்தில்

உங்கள் ஃபயர்வால் IPv4-ஐ பாதுகாக்கிறது. உங்கள் VPS-க்கு கிட்டத்தட்ட நிச்சயமாக ஒரு பொது IPv6 முகவரியும் உள்ளது. பல சேவைகள் இயல்பாக அதில் கேட்கின்றன. உங்கள் ஃபயர்வால் IPv4-ஐ மட்டும் கையாளுகிறது. அல்லது நீங்கள் IPv4-ஐ மட்டும் வடிகட்டும் கிளவுட் ஃபயர்வாலை நம்புகிறீர்கள். அப்படியானால், அந்த ஒவ்வொரு சேவையும் IPv6 வழியாக இணையம் முழுவதிலும் இருந்து அணுகக்கூடியதாக இருக்கும். ஆனால் உங்கள் IPv4 பக்கம் பூட்டப்பட்டதாகத் தெரியும். நீங்கள் ஒரு போர்ட்டை curl கொண்டு சோதிக்கிறீர்கள். இணைப்பு நிராகரிக்கப்பட்டதைப் பார்க்கிறீர்கள். பாதுகாப்பாக உணர்கிறீர்கள். ஒரு தாக்குநர் அதே போர்ட்டிற்கு IPv6 வழியாக இணைக்கிறார். உள்ளே நுழைந்து விடுகிறார்.

இந்த வழிகாட்டி ஒரு சாதாரண Ubuntu 24.04 VPS-ல் இந்த இடைவெளி ஏன் ஏற்படுகிறது என்பதைக் காட்டுகிறது. நீங்கள் என்ன வெளிப்படுத்துகிறீர்கள் என்பதைத் துல்லியமாக எப்படிப் பார்ப்பது என்பதையும் விளக்குகிறது. இந்த இடைவெளியை எப்படி மூடுவது என்பதையும் கூறுகிறது. UFW இங்கே பிரச்சினைக்குக் காரணம் அல்ல. நவீன Ubuntu நிறுவலில் UFW ஏற்கனவே IPv6-ஐ கையாள்கிறது. இந்த வெளிப்பாடு அதனைச் சுற்றியுள்ள அடுக்குகளால் ஏற்படுகிறது. நீங்கள் கேட்பதை அறியாத சேவைகளாலும் ஏற்படுகிறது.

உங்கள் VPS முதலில் ஏன் IPv6-இல் உள்ளது

இன்று கிட்டத்தட்ட ஒவ்வொரு VPS-ம் அதன் IPv4 முகவரியுடன் சேர்த்து ஒரு பொது IPv6 முகவரியை, பெரும்பாலும் ஒரு முழு /64-ஐயும் வழங்குகிறது. உங்களுடையதை சரிபார்க்கவும்:

ip -6 addr show scope global

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

அந்த 2001:db8:2a::1 இணையத்தின் எந்தப் பகுதியிலிருந்தும் அணுகக்கூடியது, உங்கள் IPv4 முகவரியைப் போலவே. இப்போது எது கேட்டுக்கொண்டிருக்கிறது என்று பார்க்கவும்:

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

Local Address நெடுவரிசையை கவனமாக வாசிக்கவும். 0.0.0.0:22 என்றால் "ஒவ்வொரு IPv4 முகவரியிலும் கேட்கிறது" என்பதாகும். [::]:22 என்றால் "ஒவ்வொரு IPv6 முகவரியிலும் கேட்கிறது" என்பதாகும். 127.0.0.1:5432 loopback-உடன் பிணைக்கப்பட்டுள்ளது மற்றும் பொதுவானது அல்ல, எனவே Postgres வரி பாதுகாப்பானது. அந்த இரண்டு [::] வரிகள் IPv6 வழியாக முழு இணையத்திற்கும் பதிலளிக்கின்றன, மேலும் docker-proxy வரி நீங்கள் தொடங்கியதை மறந்துவிட்டீர்கள் என்பதை உணர்த்தும் வகையானது.

பெரும்பாலான daemons இயல்பாகவே ::-உடன் பிணைகின்றன, ஏனெனில் Linux-இல் ஒரு :: socket பொதுவாக IPv4-ஐயும் ஏற்கும். எனவே புதிய server-ன் இயல்பான நிலை "இரண்டு stacks-இலும், எல்லா இடங்களிலும் பதிலளி்கிறது" என்பதாகும். உங்கள் firewall மட்டுமே அதற்கு முன்னால் இருக்கிறது, அதனால்தான் ஒரே ஒரு stack-ஐ மட்டுமே பார்க்கும் firewall ஒரு உண்மையான பிரச்சனையாகும்.

IPv6 இடைவெளி உண்மையில் எங்கிருந்து வருகிறது

நான்கு பொதுவான ஆதாரங்கள் உள்ளன. ஒரு குறிப்பிட்ட சேவையகத்தில் இவற்றில் ஒன்று அல்லது பலவும் ஒரே நேரத்தில் இருக்கலாம்.

1. IPv4 ஐ மட்டும் வடிகட்டும் கிளவுட் ஃபயர்வால். பல வழங்கி ஃபயர்வால்கள் மற்றும் security-group தயாரிப்புகள் IPv4 சூழலில் உருவாக்கப்பட்டவை. அவை IPv6 ஐ புறக்கணிக்கின்றன அல்லது நீங்கள் கைமுறையாகச் சேர்க்க வேண்டிய தனி IPv6 விதிகள் தேவைப்படுகின்றன. வழங்கியின் டாஷ்போர்டில் உள்ள ஃபயர்வால் மட்டுமே உங்களிடம் இருந்து, அது IPv6 ஐ கவர் செய்யவில்லை என்றால், IPv4 இல் port 22 பற்றி அது என்ன சொன்னாலும் உங்கள் [::] சேவைகள் திறந்தே இருக்கும். உங்கள் வழங்கியின் ஃபயர்வால் ஆவணங்களைப் படியுங்கள். குறிப்பாக IPv6 என்ற வார்த்தையைத் தேடுங்கள்.

2. ip6tables இல்லாத கைமுறை iptables. iptables கட்டளை IPv4 அட்டவணைகளை மட்டுமே தொடுகிறது. IPv6 க்கு தனி கட்டளை உள்ளது: ip6tables. இதற்கு தனி விதிகள் உள்ளன. நீங்கள் iptables -A INPUT ... வரிகள் நிறைந்த ஃபயர்வால் ஸ்கிரிப்டை எழுதிவிட்டு, தொடர்புடைய ip6tables விதிகளை எழுதவில்லை என்றால், உங்கள் IPv6 ஃபயர்வால் காலியாக உள்ளது. இயல்புநிலை ACCEPT கொள்கையுடன் காலியான INPUT chain அனைத்தையும் அனுமதிக்கிறது:

sudo ip6tables -L INPUT -n

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

அந்த வெளியீடு ஒரே திரையில் முழு சிக்கலையும் காட்டுகிறது. IPv4 வடிகட்டப்படுகிறது. IPv6 அனைத்தையும் ஏற்கிறது.

3. உங்கள் ஃபயர்வாலைத் தாண்டி நேரடியாக port-களை வெளியிடும் Docker. நீங்கள் docker run -p 8080:80 ஐ இயக்கும்போது, Docker அதன் சொந்த விதிகளை UFW இன் விதிகளுக்கு முன்பாகச் செருகுகிறது. எனவே ufw status அந்த port மறுக்கப்பட்டதாகக் கூறினாலும் கூட வெளியிடப்பட்ட port அணுகக்கூடியதாக இருக்கும். நவீன Docker இல் இது IPv6 வழியாகவும் பொருந்தும். Docker ஏன் UFW ஐ தவிர்க்கிறது மற்றும் container port-களை எவ்வாறு சரியாக வடிகட்டுவது என்பது இயங்குமுறையையும் தீர்வுகளையும் விளக்குகிறது. இந்த வெளியிடப்பட்ட port-கள் எப்படி அறிவிக்கப்படுகின்றன என்பதற்காக ஒரு VPS இல் Docker Compose அடிப்படைகள் ஐப் பார்க்கவும்.

4. IPv6 முடக்கப்பட்ட UFW. UFW IPv6 ஐ கையாளுகிறது, ஆனால் அதற்குக் கட்டளையிடப்பட்டால் மட்டுமே. இந்த நிலைமாற்றியை சரிபார்க்கவும்:

grep IPV6 /etc/default/ufw

நவீன Ubuntu இல் IPV6=yes இருக்கும். எனவே UFW ஒவ்வொரு விதியையும் இரண்டு stack-களுக்கும் பயன்படுத்துகிறது. நீங்கள் IPV6=no ஐப் பார்த்தால், அது பழைய இமேஜ் அல்லது பழைய வழிகாட்டியிலிருந்து வந்திருக்கலாம். அப்படியானால், நீங்கள் எழுதிய ஒவ்வொரு UFW விதியும் IPv4 க்கு மட்டுமே பொருந்தும். IPv6 கட்டுப்பாட்டின்றி விடப்படுகிறது.

நீங்கள் வெளிப்படுத்துவது என்ன என்பதைத் துல்லியமாகப் பாருங்கள்

ஊகிக்க வேண்டாம். வெளியிலிருந்து அளவிடுங்கள். முதலில் உங்கள் listener-களைப் பட்டியலிடுங்கள். :: உடன் பிணைக்கப்பட்ட ஒவ்வொன்றையும் குறித்து வைங்கள்:

sudo ss -tlnp | grep '::'

பிறகு, வேறொரு கணினியிலிருந்து, server-ன் பொது IPv6 முகவரியுடன் இணைங்கள். மூடப்பட்டிருப்பதாக நீங்கள் நம்பும் ஒரு port-ஐ முயற்சிக்கவும்:

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

அது ஒரு பக்கத்தையோ அல்லது banner-ஐயோ திருப்பி அனுப்பினால், அந்த port IPv6-ல் திறந்திருக்கிறது. மூடப்பட்ட port உங்களுக்கு Connection refused அல்லது timeout தரும். முழுமையான கண்ணோட்டத்திற்கு, server-க்கு வெளியிலிருந்து அந்த IPv6 முகவரியை nmap கொண்டு ஸ்கேன் செய்யவும்:

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

nmap IPv6 வழியாகத் திறந்ததாகத் தெரிவிக்கும் ஒவ்வொரு port-ம் இணையம் முழுவதும் அணுகக்கூடிய ஒரு port ஆகும். உங்கள் IPv4 ஸ்கேன் எதைக் காட்டியதா என்பது பொருட்டல்ல. IPv4 மற்றும் IPv6 ஸ்கேன்களைப் பக்கவாட்டில் ஒப்பிடுவது இடைவெளியைக் கண்டுபிடிக்க விரைவான வழியாகும்: -6-ல் திறந்திருந்தாலும் IPv4-ல் மூடப்பட்டிருக்கும் எதுவோ உங்கள் firewall விடுவித்த ஒரு service ஆகும்.

இடைவெளியை மூடுக

UFW இரண்டு ஸ்டாக்குகளையும் கவர் செய்யவும், மற்றும் மறுப்பதை இயல்புநிலையாக அமைக்கவும். மாற்றத்தை உறுதிப்படுத்திக்கொள்ளவும், பின்னர் உள்வரும் டிராபிக்கிற்கு மறுப்பு இயல்புநிலையை அமைத்து, உங்களுக்குத் தேவையானவற்றை மட்டும் அனுமதிக்கவும்:

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

நீங்கள் IPV6=yes ஐ மாற்றும்போது UFW ஏற்கனவே செயலில் இருந்தால், நீங்கள் sudo ufw reload ஐ இயக்கும் வரை அந்த மாற்றம் நடைமுறைக்கு வராது.

ufw status ஒவ்வொரு விதியையும் இரண்டு முறை பட்டியலிடுகிறது; ஒருமுறை சாதாரணமாக, மற்றொருமுறை (v6) பின்னொட்டுடன். நீங்கள் (v6) வரிகளைப் பார்த்தால், UFW IPv6 ஐ வடிகட்டுகிறது:

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

நீங்கள் iptables ஐ கைமுறையாக நிர்வகித்தால், ஒவ்வொரு விதியையும் ip6tables இல் பிரதிபலிக்கவும், அல்லது nftables க்கு மாறவும். அதன் inet அட்டவணைகள் IPv4 மற்றும் IPv6 இரண்டையும் ஒரே இடத்தில் கவர் செய்கின்றன, மேலும் இந்தத் தவறுகளின் வகையை முற்றிலுமாக நீக்குகின்றன. நீங்கள் விதிகளை நேரடியாக எழுதும்போது, ஒரே ஒரு nftables inet வடிகட்டி அட்டவணைதான் மிகச் சுத்தமான தீர்வு.

பொதுவில் வெளிப்படுத்த விரும்பாத சேவைகளை loopback உடன் பிணைக்கவும். ஒரு தரவுத்தளம், நிர்வாகப் பேனல், அல்லது மெட்ரிக்ஸ் endpoint ஆகியவற்றிற்கு பொதுவான முகவரி தேவையில்லை. அதை 127.0.0.1 மற்றும் ::1 உடன் பிணைக்கவும், அப்போது அது ரூட் செய்யக்கூடிய முகவரியில் கேட்காது. Postgres க்கு, listen_addresses = 'localhost' ஐ அமைக்கவும். ஆப் சர்வருக்கு, அதை 127.0.0.1 உடன் பிணைத்து, முன்னால் ஒரு ரிவர்ஸ் ப்ராக்ஸி வைக்கவும். கேட்கும் சேவையை மூடுவது அதை ஃபயர்வால் செய்வதை விட சிறந்தது, ஏனெனில் அப்போது அங்கு அணுகத் தேவையான ஒன்றே இருக்காது.

Docker வெளியிடப்பட்ட போர்ட்களைப் பாதுகாக்க UFW ஐ நம்ப வேண்டாம். கொள்கலன் போர்ட்களை ஒவ்வொரு இடைமுகத்திற்கும் பதிலாக ஒரு குறிப்பிட்ட முகவரிக்கு வெளியிடவும், உதாரணமாக -p 127.0.0.1:8080:80, அப்போது அந்தப் போர்ட் ஹோஸ்ட் மற்றும் நீங்கள் வேண்டுமென்றே ப்ராக்ஸி செய்யும் இடங்களிலிருந்து மட்டுமே அணுகக்கூடியதாக இருக்கும். ஒரு கொள்கலன் உண்மையில் பொதுவாக இருக்க வேண்டும் என்றால், அதை ஒரு Traefik ரிவர்ஸ் ப்ராக்ஸிக்குப் பின்னால் வைத்து, ஒவ்வொரு ஆப்பையும் அல்லாமல் ப்ராக்ஸியை மட்டும் வெளியிடவும்.

உங்கள் ப்ரொவைடர் ஃபயர்வாலில் IPv6 விதிகளைச் சேர்க்கவும், அல்லது அது IPv6 க்கான உங்கள் ஃபயர்வால் அல்ல என்பதை ஏற்றுக்கொண்டு, அந்த வேலையை ஹோஸ்டில் உள்ள UFW அல்லது nftables செய்யட்டும்.

உண்மையில் மூடப்பட்டுள்ளதை சரிபார்க்கவும்

உங்கள் மாற்றங்களுக்குப் பிறகு அதே வெளிப்புற சோதனையை மீண்டும் இயக்கவும்:

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

முன்பு பதிலளித்த போர்ட் இப்போது நிராகரிக்க அல்லது காலக்கெடு முடிய வேண்டும். nmap அதை filtered அல்லது closed என அறிவிக்க வேண்டும். ஒரு போர்ட் இன்னும் திறந்திருந்தால், மேலே உள்ள நான்கு ஆதாரங்களையும் மீண்டும் சரிபார்க்கவும்: :: உடன் இன்னும் இணைக்கப்பட்டிருக்கும் ஒரு சேவைக்கு முன் எந்த விதியும் இல்லை, UFW க்கு முன் அமர்ந்திருக்கும் ஒரு Docker விதி, அல்லது IPv6 ஐ ஒருபோதும் பார்த்திராத ஒரு வழங்குநர் ஃபயர்வால்.

உணர்திறன் கொண்ட சேவைகளை பொது இணையத்திலிருந்து முற்றிலும் விலக்கி வைப்பது இன்னும் பலமானது. SSH மற்றும் நிர்வாக பேனல்களை ஒரு WireGuard VPN க்குப் பின் வைக்கவும் மற்றும் அவற்றின் போர்ட்களுக்கு ஃபயர்வால் போடவும், அவை சுரங்கப்பாதையில் மட்டுமே பதிலளிக்கும். அப்போது IPv6 வெளிப்பாடு கேள்வி அவற்றுக்கு பொருந்தாது. பொதுவில் இருக்கும் எதையும் தாக்கும் பிரூட்-ஃபோர்ஸ் ஸ்கேன்களை மெதுவாக்க, ஒரு default-deny ஃபயர்வாலுக்கு மேல் SSH க்கு முன் Fail2ban ஐ அடுக்கவும்.

போர்ட்கள் உங்களுக்கு புதியதாக இருந்தால், போர்ட்கள் என்ன மற்றும் சேவைகள் எவ்வாறு கேட்கின்றன என்பது முதலில் படிக்க வேண்டிய அடிப்படை விளக்கம்.

FAQ

UFW இயல்பாக IPv6 ஐத் தடுக்கிறதா?

நவீன Ubuntu 24.04 நிறுவலில், ஆம். UFW ஆனது IPV6=yes ஐ /etc/default/ufw இலிருந்து படித்து ஒவ்வொரு விதியையும் IPv4 மற்றும் IPv6 இரண்டிற்கும் பயன்படுத்துகிறது. மேலும் ufw status ஆனது IPv6 விதிகளை (v6) பின்னொட்டுடன் காட்டுகிறது. IPV6=no ஆக இருக்கும்போது (பழைய படிமத்திலிருந்தோ அல்லது பழைய பயிற்சி வழிகாட்டியிலிருந்தோ), நீங்கள் IPv4 ஐ மட்டுமே வடிகட்டும் வழங்குநர் ஃபயர்வாலையை நம்பும்போது, அல்லது Docker ஒரு போர்ட்டை UFW ஐத் தாண்டி வெளியிடும்போது இந்தச் சிக்கல் ஏற்படுகிறது. grep IPV6 /etc/default/ufw உடன் இந்த நிலைமாற்றியைச் சரிபார்க்கவும்.

எனது VPS IPv6 இல் எதை வெளிப்படுத்துகிறது என்பதை நான் எப்படிச் சரிபார்க்க முடியும்?

sudo ss -tlnp ஐ இயக்கவும். உள்ளமை முகவரி [::] உடன் தொடங்கும் ஒவ்வொரு கேட்பவரையும் குறித்துக் கொள்ளவும். இது ஒவ்வொரு IPv6 இடைமுகத்திலும் பதிலளிக்கிறது என்பதற்குப் பொருளாகும். பிறகு, வேறொரு கணினியிலிருந்து, சேவையகத்தின் பொது IPv6 முகவரியை curl -6 -v http://[YOUR:IPV6::ADDR]:PORT/ உடன் நேரடியாகச் சோதிக்கவும், அல்லது அதை nmap -6 YOUR:IPV6::ADDR உடன் ஸ்கேன் செய்யவும். IPv6 ஸ்கேனில் ஒரு போர்ட் திறந்திருந்து IPv4 இல் மூடியிருந்தால், அதுதான் உங்கள் குறைபாடு.

UFW அதைத் தடுக்கப்பட்டதாகக் கூறும்போது ஏன் எனது Docker கொள்கலனின் போர்ட்டை அணுக முடிகிறது?

நீங்கள் ஒரு போர்ட்டை -p உடன் வெளியிடும்போது, Docker அதன் சொந்த ஃபயர்வால் விதிகளை UFW இன் விதிகளுக்கு முன்னால் செருகுகிறது. எனவே ufw status அதை மறுக்கப்பட்டதாகப் பட்டியலிட்டாலும், வெளியிடப்பட்ட போர்ட் அணுகக்கூடியதாகவே இருக்கும். இது IPv4 இல் நிகழ்கிறது. Docker இன் IPv6 ஆதரவு இயக்கத்தில் இருக்கும்போது IPv6 இலும் நிகழ்கிறது. -p 127.0.0.1:8080:80 போன்ற ஒரு குறிப்பிட்ட முகவரிக்கு வெளியிடவும், அல்லது கொள்கலனை ஒரு ரிவர்ஸ் ப்ராக்ஸிக்குப் பின்னால் வைத்து ப்ராக்ஸியை மட்டும் வெளியிடவும்.

எனது IPv4 ஃபயர்வால் வலுவாக இருந்தால் எனக்கு இன்னும் IPv6 ஃபயர்வால் தேவையா?

ஆம். IPv4 மற்றும் IPv6 ஆகியவை தனித்தனி ஃபயர்வால் விதிகளைக் கொண்ட தனித்தனி நெட்வொர்க் ஸ்டாக்குகள். சரியான IPv4 விதிகளின் தொகுப்பு IPv6 போக்குவரத்திற்கு ஒன்றும் செய்யாது. உங்கள் VPS க்கு பொது IPv6 முகவரி இருந்தால், மற்றும் ஏறக்குறைய அனைத்திற்கும் இருந்தால், ஒரு IPv6 ஃபயர்வால் விதி அல்லது லூப்பேக் பைண்டிங் அதை நிறுத்தும் வரை :: இல் கேட்கும் எந்தச் சேவையும் IPv6 வழியாக அணுகக்கூடியதாகவே இருக்கும்.

ஒரு சேவையை IPv4 க்கு மட்டும், அல்லது localhost க்கு மட்டும் கேட்கச் செய்வது எப்படி?

சேவையின் சொந்த உள்ளமைவில் அதன் பைண்ட் முகவரியை அமைக்கவும். IPv4 லூப்பேக்கிற்கு மட்டும் 127.0.0.1 க்கு பைண்ட் செய்யவும், அல்லது IPv6 கேட்பவர் இல்லாமல் அனைத்து IPv4 முகவரிகளுக்கும் 0.0.0.0 க்கு பைண்ட் செய்யவும். Postgres ஆனது listen_addresses ஐப் பயன்படுத்துகிறது, SSH ஆனது ListenAddress ஐப் பயன்படுத்துகிறது. பெரும்பாலான ஆப் சேவையகங்கள் ஒரு host அல்லது bind நிலைமாற்றியை வெளிப்படுத்துகின்றன. முடிவை sudo ss -tlnp உடன் உறுதிப்படுத்தவும். Local Address இனி [::] ஐக் காட்டவில்லை என்பதைச் சரிபார்க்கவும்.