In our next topic, we're going to be resolving hostnames or looking at
ways that we can make this a little bit better because, of course,
hostname resolution may cause us issues too.
Using our systemd tools and resolvectl, there is a lot that we're
able to diagnose and set right, as well as using more traditional
tools such as dig and getent. We begin by taking a look at our
nsswitch.conf, which can control the databases that we use and the
order in which we use them.
In an ideal world, we would search DNS before our local
files, but that's not the default settings.
It's your localhost file that is going to be queried
before DNS, and it's much easier to make an exploit on a
local file than it is DNS servers.
So we'll take a look at how that can cause us issues. Now using resolvectl,
which we're going to find on our newer system,
is part of our systemd ecosystem, and there's a lot that we can gather from
this tool. Using it by itself with no arguments, we've got a lot of
information that's printed out about name resolution. When we go through
and use resolvectl with the query subcommand, we can go through and check
the IP address of our hostname or the name of an IP address. If we want to
go through and take a look at the DNS settings that's being used by an
interface, we can do so, and we can also go through and change the DNS
server that is being used by specifying the DNS server in our argument list.
So it's a really, really useful command to be able to implement.
And we're going to go through and see this now at our command line where
we're able to check our name resolution by taking a look at the
/etc/nsswitch.conf, using the getent host command, using our dig command,
one of the traditional commands to be able to go through and resolve our
names to IP addresses, as well as the newer resolvectl. And here we are in
the glorious command line of our Alma Linux 8 system. As we go through and
use the grep command, I'm searching for a host from inside of my etc and
nsswitch.conf.
This then tells our system where to gain information from. And for
our host database, we're looking in files first,
then DNS, and then we're going to see actually, is it my
hostname? Now whilst this is the default,
it's not necessarily the very best way to have name resolution set up.
As I said in the slides,
it's far easier to make an exploit on a local file than it probably is
within DNS. At the moment, if we go through and ping www.ford.com, I'm just
looking for something quite short to ping here,
nothing to do really with Ford. And we can see then we're getting
a response coming back from the DNS name records, as I don't have
any local record for www.ford.com.
But, of course, we can make changes to that.
If I go through then and do a sudo vi /etc/hosts, when we take a look in this,
I can add in a new line and a new record for www.ford.com.
So if I go through and put in the IP address maybe of the Ubuntu
system, so 192.168.56.13, 13, and then www.ford.com, we've now got a
local record. And it's this local record that is going to be read
first. As I go through now and try and ping www.ford.com, we're going
to be getting a response coming from our Ubuntu system. Now this then
is easily exploited, and people might find ways of writing through to
your host file.
So if we go through and take a look at the /etc/nsswitch.conf, we can
move down and find our hosts entry and change this through to dns and
files, just swapping the order around.
We can go through and save this, but we're going to search now DNS before
we search our files. As I go back now and ping www.ford.com, you can see
I'm back to the standard IP address coming back. When I do a getent hosts,
we'll list all of our entries within our local host file, so we can see
we've still got the entry for ford, but even with getent hosts and then
querying www.ford.com, we can see the results coming back are the genuine
entries.
Next up, we're going to take a look at the resolvectl command, but I'm going
to have to leave my Alma Linux 8 system behind, as Red Hat‑based systems
don't support resolvectl at the moment. So I'm just leaving then my Alma
system and going on to my Ubuntu system.
The Ubuntu system does have this by default.
This is Ubuntu 20.04. And if I use the resolvectl command by itself,
I get a lot of information coming back about DNS and what we
understand about from our top‑level domains, as well as the
individual link configuration. I can quit out of this, and we can go
through and take a look a little bit more about what's available to
us when using resolvectl.
If I go through and use then my resolvectl, I can use my query
subcommand, and we can go through and query www, let's try
pluralsight.com. As we then go through and take a look at it, we can see
the records coming back for Pluralsight, so this is good.
We are able to actually use the one tool to do quite a bit,
but we can do a little bit more with this.
If we go through and use resolvectl, and using DNS, and then looking at enp0s3,
we can see the DNS server that we resolve to is 10.0.2.3.
Now with resolvectl, we always query the local DNS server. There is a DNS server
running on our local system, but this is really looking at where we forward our
requests through to. If we wanted to change this,
we could up arrow key and then go through and add in maybe the Cloudflare
DNS server. And once we have this in place, we can see that we get an
error because I forgot to put sudo in front of it, but we've seen this
before. We can easily repeat the last command and all of its arguments
with sudo, and bang, bang.
Now as I go back and read the information,
we can see that our first resolver now is 1.0.0.1. And how easy
it is to go through and make those changes,
especially when we remember to put sudo in front of it. But we can also go
through and look at some of our more traditional tools. If I go through
and actually look to see where we are resolving, remember these really are
just our forwarders. If I go through and take a look at dig
www.pluralsight.com, well then, dif, I did say dig,
I don't know why my fingers wanted to type something else, but we're
able to see then those same records coming back.
But importantly, we can see the server that was queried.
If we want to query a totally different server,
we can up arrow key and just add in then @, and we'll go to a Google server.
And we can see now the server is being returned where we queried, and we
should be getting the same information coming back, but we're able then to
actually specify the server to do the query.
So hopefully, this gives you an insight into some of the tools that
are available to you, both on the standard tools such with
nsswitch.conf and the getent command, as well as dig.
But on our newer systems such as the Ubuntu 20.04 system, we've got our resolvectl that does open up a lot of configuration to us.