52 LXF260 March 2020 http://www.linuxformat.comIN-DEPTH Firewalls
becoming the norm, it becomes a slightly more
dangerous misconception. Readers of this magazine will
probably be aware that IPv4 addresses consist of four
‘octets’ (groups of 8 bits), usually written decimally (as
the numbers 0-255) and separated by dots. Readers will
probably also be aware (see LXF235 & LXF200) that the
registries around the world that assign these addresses
have to all intents and purposes run out, and that the
global adoption of IPv6 (which provides more addresses
than there are atoms on the surface of the Earth 100
times over) is the way forward.
NAT found its niche because traditionally ISPs would
only assign one IP address per household. Home
routers would assign (or control freaks would set up
statically) IP addresses from a reserved block (those
beginning with 10, 192.168 or sometimes 172) so that
everyone behind the router had their own IP address.NAT, or more technically IP masquerading, remaps the
destination addresses on incoming packets and source
addresses on outgoing packets, so that machines
behind the router can talk to the outside world.
In order for services running on those machines to
be accessible from the outside world (i.e. for inbound
connections to be established) one further step is
required: our router needs to marshall traffic meant for
our internally running service accordingly. This is usually
(variations on NAT do this differently) achieved through
port forwarding, where the user explicitly specifies a
port on the router’s external (public) IP address to
forward to an internal IP address and port.
NAT works by maintaining a table of mappings
between internal ports and addresses, and external
ports and addresses. New entries are made for each
outgoing connection, and old entries are deleted once
the connection dies, otherwise the table would get
intractably large. As connections arrive at either side of
the router, this table is checked, and if a match is found,
relevant addresses in the packet are translated.
It sounds like a bit of a rigmarole, and it is. But what
has this to do with firewalls? Well, everything, since what
is a firewall if not a router whose goal is to filter out
unwanted traffic and route wanted traffic appropriately?
Both are just packet filters at the end of the day.
And if we still haven’t yet convinced you that relying
on home routers and NAT to protect you isn’t smart,
here’s another argument. These do nothing to stop
outgoing connections to rogue sites. If you trust
everyone on your network and everything running on
their machines, then there’s no issue, except perhaps
that you’re too trusting. Otherwise a firewall is probably
prudent. Blocking outgoing SMTP traffic (except to mail
servers you trust) is sensible, and for your peace of
mind you can also block connections to your locally
running services from outside.Firewalls through the ages
In the early days of the Linux kernel, there was a firewall
known as ipfwadm. This was superseded by ipchains.
This was replaced in Kernel 2.4 with the netfilter
framework, and the relevant portions of that were
controlled by the iptables command. Iptables differed
from its predecessors because it allowed stateful packet
filtering, so as well as simple rules, connection attempts
could be governed based on the state of other
connections. For example, in our active FTP example
earlier, the kernel on the server would know that the
data connection attempt to the client was related to the
client’s initial control connection. And it’s the same in
passive FTP (where the client instigates the data
connection to port 2024 on the server). Having stateful
rules to permit these connections is more secure than
doing them classically, i.e. by enabling all inbound traffic
to port 20 on the client, or all inbound traffic on the
server’s port 2024, respectively.
The statefulness of iptables is particularly useful
if you’re setting up a firewall on a remote system. A
common error is to add a rule that accidentally outlaws,
say, the SSH connection you’re using to administer the
system. If you don’t have local access to remedy this,
then you’re in something of a predicament. So a wise
sysadmin would always start with a rule, such as:THE SLOW BUT SURE IPv6 ROLLOUT
NAT breaks one of the original core principles of the internet – end-
to-end connectivity. In the absence of port forwarding or other
workarounds, it’s impossible for two hosts behind NAT routers to
communicate. With IPv6 and its massive address space (two to the
power of 128 addresses), NAT is all but obviated, since every device
can have a guaranteed unique IP address. And in the absence of a
firewall there is nothing to stop any Thomas, Richard or Harold on
the internet from connecting to your services.
Some ISPs in the UK have finally got around to deploying IPv6, and
customers are naturally concerned that all of a sudden services that
were running internally are now available to the world. In general
there’s no need to panic – IPv6 home routers (sane ones anyway)
have a firewall that prevents all incoming connections to the LAN.
However, if you are running IPv6 services that you only want
machines on your LAN to connect to, then restricting incoming
connections, either through the service itself or through a firewall, is
still a good idea. The situation is no different for IPv4.
If you are concerned about how accessible you are over IPv6, then
you could do a lot worse than Tim Chappell’s IPv6 scanner at
https://ipv6.chappell-family.com/ipv6tcptest. Note that this will
scan your computer, so you probably shouldn’t do this on a
computer that isn’t yours. The scan is harmless (you can check
the source), but a keen-eyed sysadmin might get concerned if
they detect it.This IPv6 scanner doesn’t work if you don’t have an IPv6 address.52 LXF260March 2020 5550March 213023
IN-DEPTH Firewalls
becoming the norm, it becomes a slightly more
dangerous misconception. Readers of this magazine will
probably be aware that IPv4 addresses consist of four
‘octets’ (groups of 8 bits), usually written decimally (as
the numbers 0-255) and separated by dots. Readers will
probably also be aware (see LXF235 & LXF200) that the
registries around the world that assign these addresses
have to all intents and purposes run out, and that the
global adoption of IPv6 (which provides more addresses
than there are atoms on the surface of the Earth 100
times over) is the way forward.
NAT found its niche because traditionally ISPs would
only assign one IP address per household. Home
routers would assign (or control freaks would set up
statically) IP addresses from a reserved block (those
beginning with 10, 192.168 or sometimes 172) so that
everyone behind the router had their own IP address.NAT, or more technically IP masquerading, remaps the
destination addresses on incoming packets and source
addresses on outgoing packets, so that machines
behind the router can talk to the outside world.
In order for services running on those machines to
be accessible from the outside world (i.e. for inbound
connections to be established) one further step is
required: our router needs to marshall traffic meant for
our internally running service accordingly. This is usually
(variations on NAT do this differently) achieved through
port forwarding, where the user explicitly specifies a
port on the router’s external (public) IP address to
forward to an internal IP address and port.
NAT works by maintaining a table of mappings
between internal ports and addresses, and external
ports and addresses. New entries are made for each
outgoing connection, and old entries are deleted once
the connection dies, otherwise the table would get
intractably large. As connections arrive at either side of
the router, this table is checked, and if a match is found,
relevant addresses in the packet are translated.
It sounds like a bit of a rigmarole, and it is. But what
has this to do with firewalls? Well, everything, since what
is a firewall if not a router whose goal is to filter out
unwanted traffic and route wanted traffic appropriately?
Both are just packet filters at the end of the day.
And if we still haven’t yet convinced you that relying
on home routers and NAT to protect you isn’t smart,
here’s another argument. These do nothing to stop
outgoing connections to rogue sites. If you trust
everyone on your network and everything running on
their machines, then there’s no issue, except perhaps
that you’re too trusting. Otherwise a firewall is probably
prudent. Blocking outgoing SMTP traffic (except to mail
servers you trust) is sensible, and for your peace of
mind you can also block connections to your locally
running services from outside.Firewalls through the ages
In the early days of the Linux kernel, there was a firewall
known as ipfwadm. This was superseded by ipchains.
This was replaced in Kernel 2.4 with the netfilter
framework, and the relevant portions of that were
controlled by the iptables command. Iptables differed
from its predecessors because it allowed stateful packet
filtering, so as well as simple rules, connection attempts
could be governed based on the state of other
connections. For example, in our active FTP example
earlier, the kernel on the server would know that the
data connection attempt to the client was related to the
client’s initial control connection. And it’s the same in
passive FTP (where the client instigates the data
connection to port 2024 on the server). Having stateful
rules to permit these connections is more secure than
doing them classically, i.e. by enabling all inbound traffic
to port 20 on the client, or all inbound traffic on the
server’s port 2024, respectively.
The statefulness of iptables is particularly useful
if you’re setting up a firewall on a remote system. A
common error is to add a rule that accidentally outlaws,
say, the SSH connection you’re using to administer the
system. If you don’t have local access to remedy this,
then you’re in something of a predicament. So a wise
sysadmin would always start with a rule, such as:THESLOWBUTSUREIPv6 ROLLOUT
NATbreaksoneoftheoriginalcoreprinciplesoftheinternet–end-
to-endconnectivity.Intheabsenceofportforwardingorother
workarounds,it’simpossiblefortwohostsbehindNATroutersto
communicate.WithIPv6anditsmassiveaddressspace(twotothe
powerof 128 addresses),NATisallbutobviated,sinceeverydevice
canhaveaguaranteeduniqueIPaddress.Andintheabsenceofa
firewallthereisnothingtostopanyThomas,RichardorHaroldon
theinternetfromconnectingtoyourservices.
SomeISPsintheUKhavefinallygotaroundtodeployingIPv6,and
customersarenaturallyconcernedthatallofasuddenservicesthat
wererunninginternallyarenowavailabletotheworld.Ingeneral
there’snoneedtopanic–IPv6homerouters(saneonesanyway)
haveafirewallthatpreventsallincomingconnectionstotheLAN.
However,ifyouarerunningIPv6servicesthatyouonlywant
machinesonyourLANtoconnectto,thenrestrictingincoming
connections,eitherthroughtheserviceitselforthroughafirewall,is
stillagoodidea.ThesituationisnodifferentforIPv4.
IfyouareconcernedabouthowaccessibleyouareoverIPv6,then
youcoulddoalotworsethanTimChappell’sIPv6scannerat
https://ipv6.chappell-family.com/ipv6tcptest.Notethatthiswill
scanyourcomputer,soyouprobablyshouldn’tdothisona
computerthatisn’tyours.Thescanisharmless(youcancheck
thesource),butakeen-eyedsysadminmightgetconcernedif
theydetectit.This IPv6 scanner doesn’t work if you don’t have an IPv6 address.