Ero on siinä että puhdas NAT yrittää ohjata kaiken perille, jos vain osaa. Eli siinä menee ne ei toivotutkin.
Simppeli palomuuri toimiin päinvastoin, päästää ne minkä se uskoo olevan haluttuja.
Ainoastaan jos se NAT on conffattu tekemään noin. Tuollaiselle ei nykypäivänä juurikaan käyttökohteita ole. Jo yhden hypoteettisen kohteen kerroinkin.
Ei se palomuuri tee mitään uskoon perustuvia päätöksiä. Se tekee juuri sen mitä siltä pyydetään ja jättää tekemättä mitä ei ole pyydetty. Palomuurin voi conffata väärin kuten kaiken muunkin. Mutta mitään arpomista se palomuuri ei tee. NAT sen sijaan saatta tehdä arpomista portin suhteen. Jos sisäverkossa 192.168.1.10, 192.168.1.11 ja 192.168.1.12 muodostavat https yhteyden vaikka io-tech:n samaan aikaan ja jostain syystä kaikki kolme on onnistunu arpomaan vastaanottavaksi portiksi 32000, niin se nat arpoo tilalle jotkin vapaat portit mutta pitää kirjaa siitä lähteen osoitteesta ja portista, lisää myöhemmin kirjanpidosta.
Nykyisin kun aletaan viritellä julkiseen verkkoon konetta, niin ihan ensimmäisenä (tämä linux puolelta) varmistetaan että iptablesissa INPUT ketjun sääntö on reject tai drop.
Seuraavaksi siihen INPUT ketjuun luodaan sääntö joka sallii RELATED ja ESTABLISHED liikenteen jolloin meillä on itkumuuri pystyssä joka sallii liikennöinnin minne tahansa interwebbiin, mutta ei salli sitään mitään muuta liikennettä kuin sen mikä on sisältä muodostettu ja siihen liittyvän liikenteen. Ja näin meillä on siis hyvin yksinkertainen palomuuri joka on täysin riittävä valtaosalle kotikäyttäjistä.
Tämä on monessa distrossa nykyisin jo ihan vakiona toteutettu, eli käyttäjän ei edes tartte tehdä mitään.
Tuon perään sitten viritetään masquerade natti, jolloin se nattikin on automaattisesti turvallinen. Sun täytyy muistaa että monet docut interwebissä voi olla hyvinkin vanhoja, kuten jo aiemmin linkkaamani RFC natista joka oli vuodelta 1999, eka RFC natista on vuodelta 1994. Näiden vuosien aikana on tapahtunut paljon kehitystä ja monet ongelmat joita tuohon aikaan NAT:n kanssa on ollut, on ratkastu jo aikapäiviä sitten. Sellaista dynaamista docua ei ole joka olisi automaattisesti ajantasalla aina.
Ja vaikka se INPUT ketju olisi accept tilassa niin edelleenkään peli ei ole menetetty koska siinä koneella pitää olla joku portti auki ottamassa vastaan sisääntulevia yhteyksiä. Ja vaikka olisikin auki, niin se portti pitää olla kuuntelemassa joko kaikki osoitteita, tai sitten sitä ulkoverkon osoitetta, sitten vasta ulkoa saadaan yhteys siihen koneen tarjoamaan palveluun. Koneella saattaa olla paljonkin portteja kuuntelemassa, mutta jos ne on kaikki mäpätty joko 127.0.0.1 taikka sisäverkon ip:lle, niin ei niihin pääse ulkoa käsiksi.
Yksi moneen NATissa riskiä lisää se että sen yhden julkisen IPn perässä voi olla monia kohteita, joten yhtä IPtä pommittamalla kohteena useita portteja jotka kuuntelee.
Täysin väärää tulkintaa. Ei se yksi moneen natti tee mitään tommoista että yrittää väkisin reitittää sitä sisääntulevaa liikennettä kaikkialle sisäverkkoon. Jos oikein kovasti yrittää niin EHKÄ tuollaisen viritelmän saisi rakennettua mutta sehän olisi täysin typerä viritys.
Toinen riski että jos 1-moneen NATin takaa jokin laite kommunikoi vihamielisen kohteen kanssa, joka voi sitten kohdistaa hyökkäyksen juuri tähän IPhen ja sen takana oleviin laitteisiin.
Ei voi kohdistaa. Se voi kohdistaa ainoastaan siihen koneeseen josta se rööri on avattu ja ainoastaan siihen porttiin josta on yhteys avattu. Se reititin/gateway/palomuuri/nat pitää kirjaa kaikista yhteyksistä mitkä on muodostettu ja välittää liikennettä ainoastaan sinne mistä on pyydetty.
Tuossa jo kerrottiin DMZ:sta. Se DMZ pitää erikseen määrittää yhteen osoitteeseen, jolloin sinne välitetään sitten kaikki muu sisään suuntautuva liikenne jos välttämättä halutaan niin tehdä.
Eli jos surffailee PCllä jollain vihamielisellä sivustolla, niin sivustonylläpidon pahisten aloittama hyökkäys voi kohdistua myös kotiverkon epämääräisiin IoT laitteisiin.
Ei voi. Se kohdistuu ainoastaan siihen koneeseen josta se yhteys on luotu. Jos se yhteyden luonut kone on reikäjuustoa esim selaimen osalta, niin on mahdollista että sen selaimen reikäisyyden takia sitten vaarantuu koko sisäverkko niin että se kone joka vuotaa toimii ns. välittäjänä sinne sisäverkkoon. Mutta melko teoreettinen skenaario. Jos tuollaista pelkää niin sitten ei kannata moista laitetta sisäverkkon kytkeä.
En tarkoita että tuollaisen NATin takana olisi sama kuin suoraan julkisessa netissä, NAT ei osaa kaikkea reittittää kohteelle, mistä syntyy se turvallisuuden tunne.
Kyllä se NAT käytännössä nykyisin osaa välittää lähes kaiken pyydetyn liikenteen. Oli joskus aika kun tiettyjen palveluiden kanssa oli ongelmia, mutta esim. iptables sisältää moneen sellaiseen palveluun ns. helper moduulin. Lisäksi tuollaiset palvelut alkaa olla poistumassa jotka tarvitsee kuuntelevan portin sinun päässä toimiakseen. Esim. kohta selaimet ei enää tue ftp:tä.
IPSEC on käsittääkseni tänäkin päivänä sellainen että se menee NAT:n kanssa rikki, eli ei voida käyttää. Mutta IPSEC on mielestäni vanhentunut muutenkin ja nykyisin käytetään jotain muuta VPN.
EDIT: Jooh eli IPSEC on nykyisin mahdollinen jopa natin takaa, eli ei edes tämä ole ongelma enää.
Koska 1-moneen NAT ei muuten osaisi reitittään niitä paketteja perille, niin tarvitaan jokin konstti millä kerrotaan (tai käyttäjä käsin, mutta käyttäjällä ei välttämättä kykyä, ei välttämättä edes pääsyä).
Kehittymyt moderni NAT voi osata jotain arpoa itsekkin mutta NAT ongelman takia sovelluksissa ja palveluissa jodutaan keksimään kiertoteitä.
Nykyisin on hyvin vähän tavan käyttäjän softia jotka ihan pakolla vaatii kuuntelevan portin. Suosituin tällainen on ehdottomasti torrent. Jos ei ole pääsyä kuuntelevaan porttiin, turskan seedaus ei onnistu kaikille, se onnistuu vain niille joilla on kuunteleva portti auki ja sinä saat avattua sen putken siihen kohteeseen.
Koska kaikki tietää mihin käyttöön turskia seedataan, (linux distroja tietenkin) niin en pidä kovin tärkeänä että tämä menee natin takia "rikki". Samoin myös ajattelee varmaan suurin osa operaattoreista jotka kuluttajille työntää defaulttina natin päälle.
Ongelmallinen 1-moneen NAT on sen takia että julkisia osoitteita ei ole riittävästi jakaa asiakkaille.
Juuri tuota ongelmaa vartenhan se nat on nykyisin olemassa, joten ei ole mitään ongelmaa.
Jos sisäverkossa on laitteita joilla ei ole liikennettä julkiseen nettiin, niin todennäköisesti NAT ei niille osaa mitään julkisesta netistä tulevia paketteja reitittää.
Ei kyse ole siitä ettei se osaa, sen ei tartte eikä edes pidä välittää mitään paketteja sisäverkkoon ellei ole erikseen pyydetty.
Lue tuosta ja sisäistä se. Jeesuksen aikainen docu, mutta edelleen ihan käypänen. Se kuva varsinkin hyvä. Se purkki kun saa paketin, niin se sönkii siitä paketin headerista kohde IP:n, kohde portin, lähde IP:n, lähde portin ja lähde MAC osoitten, noin pelkistettynä. Laittaa ne kirjanpitoon ja korvaa lähde tiedot omilla tiedoillaan eli omalla julkisella ip:llä, vapaalla olevalla portilla ja omalla MAC osoitteella ja lähettää paketin kohti kohdetta. Ja sitten kun kohteesta tulee vastaus, niin se korvaa paketissa olevat omat tietonsa lähde tiedoilla ja välittää vastauspaketin lähteelle.
Tuota rööriä pidetään juuri sen aikaa auki kuin on tarvis. Josta jouhevasti päästäisiin esim. tcp:n kättelyihin, mutta se on jo eri aihe kokonaan. Yhteyksille on myös jotkut vakio timeoutit, että ne suljetaan jos ei ole sulkua pyydetty ja sitä ei käytetä tai yhteys kuolee jostain syystä.
Tästä päästään siihen että noita yhteyksiä ei voida muodostaa äärettömästi, vaan sen verran kuin on vapaita portteja, eli jotain alle 65535. Eli jos natin takana on hiton iso verkko, niin voi tulla ongelmia. Kotikäytössä tuskin tällaista tilannetta kovin helposti saadaan aikaiseksi.
None of the hosts on the supported network behind the masquerade router are ever directly seen; consequently, you need only one valid and routable IP address to allow all hosts to make network connections out onto the Internet. This has a downside; none of those hosts are visible from the Internet and you can't directly connect to them from the Internet; the only host visible on a masqueraded network is the masquerade machine itself. This is important when you consider services such as mail or FTP. It helps determine what services should be provided by the masquerade host and what services it should proxy or otherwise treat specially.
Ehkä joskus on ollut aika että nat on ollut ihan erillinen kikkare, nykyisin se on kuitenkin osa palomuuria tai palomuuri on osa nattia.
Ja normaali kuluttaja saa turvallisen natin aikaiseksi esim linuksin netfilter:llä ihan muutamalla säännöllä.
Tuossa docussa sivutaan myös yhtä syytä miksi NAT on saanut huonon maineen.
Third, IP masquerade will have some impact on the performance of your networking. In typical configurations this will probably be barely measurable. If you have large numbers of active masquerade sessions, though, you may find that the processing required at the masquerade machine begins to impact your network throughput. IP masquerade must do a good deal of work for each datagram compared to the process of conventional routing. That 386SX16 machine you have been planning on using as a masquerade machine supporting a dial-up link to the Internet might be fine, but don't expect too much if you decide you want to use it as a router in your corporate network at Ethernet speeds.
Joskus esim ADSL purkeissa oli niin lussua rautaa, että ne kyykkäsi kun alettiin ajaa enempi yhteyksiä sen natin läpitte, prosessori teho ei riittänyt taikka muisti loppui kesken pitämään kirjaa kaikesta. Varsinkin joku turskan kalastus on sellainen että yhteyksiä saattaa olla satoja auki ja koko purkki menee yksinkertaisesti kyykkyyn joka näkyy sitten ihan kaikessa liikenteessä.
Nykyisin kehitys on kehittynyt niin paljon että tuo ei juurikaan ole enää ongelma.
Jotkut asiat tahtoo jäädä myytteinä pyörimään vuosikymmeniksi. Monelle realtek verkkopiiri on edelleen kirosana. Samoin nat on joillekkin kirosana.
Ei se viimeisin kerneli mitään lisäarvoa tuollaisessa tuo. Jos tuote toimii kuten sen on luvattu toimivan ei sitä firmistä ole järkevää alkaa päivittämään.
Kyllä se tuo, esim wireguardin. IPv6 tuki on myös vuosien aikana parantunut. Mutta ihan peruskäyttöön tuo kyllä riittäisi ihan hyvin. Lisäksi purkin tarjoamat fyytsörit alkaa olla happamia, eli parasta ennen päiväys ummessa.
Mutta juuri kuten sanoit. Tämähän toki pätee myös IPv6:n ei siinä mitään. mm. Kuusitunnelin kanssa tulee sitten "reitittävä" yhteys, kun on erikseen käyttö ja reititys osoitteet, haha.
docs.hetzner.com
ungleich.ch
www.ripe.net
