Linux Format - UK (2020-03)

(Antfer) #1
http://www.techradar.com/pro/linux March 2020 LXF260 51

Firewalls IN-DEPTH


a connection is established data can flow both ways.
FTP isn’t really used so much now (what did you just
use to send the nearly late disc image? – Ed), but in its
active form a client first connects to the server (usually
on port 21), then the server initiates a connection
(usually from its port 20) back to the client. All going
well, this establishes the control and data connections
respectively. If you’ve ever tried to use active mode FTP,
you’ll probably have had experience of it not working.
And most of the time when it doesn’t work is due to the

server not being able to successfully negotiate this data
connection. This may be due to the client being behind
a NAT (network address translation) router or a firewall.
NAT is a sort of a kludge that (in tandem with some
other kludges) enables machines behind, say, a home
router (which gets a single IP address from an ISP) to be
addressable to the outside world. Most home routers
make this easy enough to set up now, and some even
allow for it to be automatically configured (UPnP),
although this is potentially unsafe. In the case of active
FTP you’d configure the NAT layer to forward
connection attempts to your router’s port 20 to the
machine running the FTP client. A similar configuration
would often be required to use a lot of the tools of
yesteryear – sending files over MSN Messenger, peer-
to-peer filesharing, and some online gaming all used
to require that at least one party is able to accept
incoming connections.
NAT and home routers in general have perpetuated
the slightly incorrect notion that being behind one
improves security and is akin to being behind a firewall.
There are similarities, of course, but in an age where
IPv6 is slowly but ineluctably (check the boxout below)

n Linux we can display current connection
information using the ss command, which
replaces the old netstat command. This new
command can tell you all kinds of things about ports,
processes and sockets, and we’d encourage you to read
the man pages to learn more. For now, to just see which
TCP ports and UDP ports are listening, do:
$ ss -tulp
On a clean(ish) Ubuntu 18.04 install this returned:
netid Local Address:Port Peer Address:Port
udp 127.0.0.53%lo:domain 0.0.0.0:*
udp 192.168.122.126%ens3:bootpc 0.0.0.0:*
udp 0.0.0.0:ipp 0.0.0.0:*
udp 0.0.0.0:mdns 0.0.0.0:*
tcp 127.0.0.53%lo:domain 0.0.0.0:*
tcp 127.0.0.1:ipp 0.0.0.0:*
(some rows and columns and things relating to IPv6
have been dropped for brevity and Effy’s sanity).
If you run this with sudo, you’ll also see an additional
column detailing the actual process that’s listening. But
there’s no way this would fit in this column, so take our
word for it that these open ports concern systemd’s
DNS resolver, NetworkManager, the CUPS print service,
and Avahi (a network discovery protocol). We’ll also say
that there’s nothing wrong with these services being as
they are.
A rudimentary understanding of TCP connectivity is
helpful here. When you run a service, whether it’s a web
server, the SSH daemon or file sharing with Samba (or
Windows), the service opens up ports on a given
network interface (this could be the local loopback
interface, a real network card, or some kind of
virtualised network device). Users (or robots) can
connect to those services using an IP address and port
number(s). If you attempt to connect to a port number
where no service is running, the port is said to be
closed, and that connection will immediately be
rejected. If, on the other hand, you connect to an open
port, then a connection is established and (at least for a
while) you can communicate with the server. Depending
on the service, the first thing to do might be to
authenticate with the server – if you don’t do that
successfully the server will terminate the connection,
and then you won’t be able to communicate with it
further until you reconnect.
An important take-away is that TCP connections
have a direction, which allows us to differentiate
between incoming and outgoing connections, but once

Behind the scenes, ufw is just a whole lot of iptables chain rules, but the point is that you don’t
need to worry about all that.

If you’ve ever set up a home gateway that does NAT, you’ll probably
have used iptable’s MASQUERADE function.

O


NAT MISCONCEPTIONS


“NAT and home routers in general have


perpetuated the slightly incorrect notion


that being behind one improves security


and is akin to being behind a firewall”


5550March 2 h0r13h1 March 2020LXF260 51


Firewalls IN-DEPTH


aconnectionisestablisheddatacanflowbothways.
FTPisn’treallyusedsomuchnow(whatdidyoujust
usetosendthenearlylatediscimage?–Ed),butinits
activeformaclientfirstconnectstotheserver(usually
onport21),thentheserverinitiatesaconnection
(usuallyfromitsport20)backtotheclient.Allgoing
well,thisestablishesthecontrolanddataconnections
respectively.Ifyou’veevertriedtouseactivemodeFTP,
you’llprobablyhavehadexperienceofitnotworking.
Andmostofthetimewhenitdoesn’tworkisduetothe

servernotbeingabletosuccessfullynegotiatethisdata
connection.Thismaybeduetotheclientbeingbehind
aNAT(networkaddresstranslation)routerorafirewall.
NATisasortofakludgethat(intandemwithsome
otherkludges)enablesmachinesbehind,say,ahome
router(whichgetsasingleIPaddressfromanISP)tobe
addressabletotheoutsideworld.Mosthomerouters
makethiseasyenoughtosetupnow,andsomeeven
allowforittobeautomaticallyconfigured(UPnP),
althoughthisispotentiallyunsafe.Inthecaseofactive
FTPyou’dconfiguretheNATlayertoforward
connectionattemptstoyourrouter’sport 20 tothe
machinerunningtheFTPclient.Asimilarconfiguration
wouldoftenberequiredtousealotofthetoolsof
yesteryear–sendingfilesoverMSNMessenger,peer-
to-peerfilesharing,andsomeonlinegamingallused
torequirethatatleastonepartyisabletoaccept
incomingconnections.
NATandhomeroutersingeneralhaveperpetuated
theslightlyincorrectnotionthatbeingbehindone
improvessecurityandisakintobeingbehindafirewall.
Therearesimilarities,ofcourse,butinanagewhere
IPv6isslowlybutineluctably(checktheboxoutbelow)

n Linux we can display current connection
information using the ss command, which
replaces the old netstat command. This new
command can tell you all kinds of things about ports,
processes and sockets, and we’d encourage you to read
the man pages to learn more. For now, to just see which
TCP ports and UDP ports are listening, do:
$ ss-tulp
Onaclean(ish)Ubuntu18.04installthisreturned:
netid LocalAddress:Port PeerAddress:Port
udp 127.0.0.53%lo:domain 0.0.0.0:
udp 192.168.122.126%ens3:bootpc 0.0.0.0:

udp 0.0.0.0:ipp 0.0.0.0:
udp 0.0.0.0:mdns 0.0.0.0:

tcp 127.0.0.53%lo:domain 0.0.0.0:
tcp 127.0.0.1:ipp 0.0.0.0:

(some rows and columns and things relating to IPv6
have been dropped for brevity and Effy’s sanity).
If you run this with sudo, you’ll also see an additional
column detailing the actual process that’s listening. But
there’s no way this would fit in this column, so take our
word for it that these open ports concern systemd’s
DNS resolver, NetworkManager, the CUPS print service,
and Avahi (a network discovery protocol). We’ll also say
that there’s nothing wrong with these services being as
they are.
A rudimentary understanding of TCP connectivity is
helpful here. When you run a service, whether it’s a web
server, the SSH daemon or file sharing with Samba (or
Windows), the service opens up ports on a given
network interface (this could be the local loopback
interface, a real network card, or some kind of
virtualised network device). Users (or robots) can
connect to those services using an IP address and port
number(s). If you attempt to connect to a port number
where no service is running, the port is said to be
closed, and that connection will immediately be
rejected. If, on the other hand, you connect to an open
port, then a connection is established and (at least for a
while) you can communicate with the server. Depending
on the service, the first thing to do might be to
authenticate with the server – if you don’t do that
successfully the server will terminate the connection,
and then you won’t be able to communicate with it
further until you reconnect.
An important take-away is that TCP connections
have a direction, which allows us to differentiate
between incoming and outgoing connections, but once


Behind the scenes, ufw is just a whole lot of iptables chain rules, but the point is that you don’t
need to worry about all that.

If you’ve ever set up a home gateway that does NAT, you’ll probably
have used iptable’s MASQUERADE function.

O


NAT MISCONCEPTIONS


“NAT and home routers in general have


perpetuated the slightly incorrect notion


that being behind one improves security


and is akin to being behind a firewall”

Free download pdf