If you're a network administrator,
then you're probably using SNMP, or the Simple Network
Management Protocol, to be able to query and receive
information about the infrastructure devices
that are on your network.
This could be monitoring things like servers, switches,
firewalls, routers, or anything else
that may be connected to the network.
Unfortunately, not all versions of SNMP
provide the best security.
For example, SNMP version 1 and SNMP version 2
communicate over the network in the clear.
There's no encryption built into either of those SNMP versions.
If you're using SNMP, then you should be using SNMP version 3.
With version 3, we added encrypted communications,
so that everything sent across the network
would be private and secure.
Unfortunately, not all devices support SNMP version 3.
So check the documentation with your devices
to see what options might be available for you.
Another useful network hardening technique
is to protect your IP version 6 router advertisements.
We do this by using something called Router Advertisement,
or RA, guard.
This particular hardening technique
focuses on the router advertisements
that are sent with IPv6.
Router solicitations are sent by devices on the network,
and if a router sees that solicitation,
it will send back a router advertisement.
The security concern comes from this router advertisement.
Normally, it would come from a local router
that's on your subnet.
But an attacker could pretend to be a router, thereby
introducing the ability to perform on-path attacks
or denial of service.
Many switches have the ability to turn on router advertisement
guard, where they will validate all of the router
advertisements.
Through the use of these RA guard policies,
you can be assured that the devices on your network
would only be receiving router advertisements
from legitimate routers.
Another useful security technique on your switches
is the use of port security.
Port security prevents unauthorized users
from connecting to a switch and gaining access
to the rest of the network.
This would be based on the source MAC
address seen by a particular interface on a switch.
And if that MAC address doesn't match the configuration
that you have previously configured on that switch,
then you can make a decision on what you would
like to do with that traffic.
For example, you would set a configuration
on your switch that would configure
a maximum number of source MAC addresses
on a particular interface.
Normally, when a person is working on the network,
they would be connected using that MAC address.
But if someone else came along and disconnected that user
and plugged in their own device, a new MAC address
would be introduced to that interface.
The switch, then, monitors how many different MAC addresses
have been seen on a particular physical interface.
And if that number is exceeded, you
can choose to disable that interface
or send an alert to the administrator.
In previous videos, we've discussed
how ARP spoofing could be used to circumvent existing security
and create on-path attacks.
There is a way to prevent this in the switch
by using DAI, or Dynamic ARP Inspection.
This adds additional monitoring to the network
and adds to the security that normally is not
included with the address resolution protocol.
Dynamic ARP inspection starts with creating
a map of all of the devices on your network
and what their IP addresses might be.
It's able to collect this information
by using something called DHCP snooping, where it examines all
of the DHCP communication and begins building
a chart on what IP addresses are assigned to what MAC addresses.
The switch sees all of this ARP communication
and can then decide, based on the existing
chart, whether a particular ARP is legitimate or not.
And if that ARP request doesn't match what's already
in the switch, the switch can discard any invalid ARP
requests or responses.
On many of our modern network infrastructure devices,
we have different planes of operation.
The plane of the device that handles
the forwarding of traffic is considered
to be the data plane.
Inside of the device is a management plane
that allows us to configure the device.
We often refer to this as the control plane.
Since the control plane is responsible
for the configuration and the monitoring of this device,
it's a very important plane to secure.
We need to make sure that we're protected
against denial of service or someone
performing reconnaissance.
We also might want to configure quality of service
on our network, so that management traffic
to the control plane has priority over any other types
of traffic.
We could also do some firewalling,
so that not only are we prioritizing the management
traffic, we're also blocking any non-management traffic.
So if you know that all of your control plane traffic
is going to be SSH communication,
you can disable all other control plane
traffic that is non-SSH.
And to protect against denial of service or other types
of traffic flows being sent to the management plane,
you can rate limit any of the traffic that
is sent directly to that management port on the switch.
If you've ever connected to a public Wi-Fi hotspot,
you may have noticed that you have access to the internet,
but you don't have access to the other devices that might be
on that same wireless network.
This probably means that the network administrator
for this device has configured port isolation, which
limits or prevents any type of communication
between the different devices on that switch or access point.
Even if all of the devices are in the same VLAN,
if you've turned on port isolation,
there's no way to communicate between any of those devices.
You might also see this at home.
You'll notice that your home network can communicate
to the internet, but you're not able to communicate
to other homes in your neighborhood.
Or perhaps, you're in a hotel room
and your hotel room can communicate to the internet,
but you can't communicate with any of the other devices
in that hotel.
Another important best practice when
you're trying to harden a network
is to administratively disable any interfaces that
are not currently in use.
This prevents someone from walking into a conference
room or a break room, plugging into the network,
and gaining access to the internal network.
Many organizations take it a step further and implement
network access control using 802.1X.
This means that users would need valid authentication
before they were ever able to communicate on that network.
Every service running on a system
that needs to be accessed over the network
will have an open port.
Every open TCP or UDP port on this device
is a potential security concern, so we
want to be sure to close all unnecessary ports
and only leave the TCP and UDP ports open that need
access to those services.
You would, commonly, control this access with a firewall,
either a next generation firewall that's on the network
or, perhaps, also a firewall built into the operating
system on that server.
You also want to be sure that any unknown services
or services that may have been previously installed
have been either disabled or filtered from any network
communication.
When someone implements a new network service
but they're not quite sure which port number should be open,
they may configure a security policy
in a firewall to allow port 0 through port 65,535,
effectively, allowing access to every port number
on that device.
From a security perspective, you only
want to enable the ports that are
necessary for that application to work.
So you may want to use a port scanner such as Nmap
to see exactly what ports are open on that device
and limit your access controls and firewall
rules to only those ports.
If you've ever installed a new access point, a new switch,
a new router, or any other new device to the network,
you know that there is a default set of credentials that's
used for your initial login.
Sometimes these usernames and passwords
are "administrator" and "admin" or, simply, "admin"
and "admin."
This gives a remote user administrative access
to this device, allowing them to make
any change they would like to the configuration
of that system.
So of course, it would be important to change
the password to something that would not
be available to others or to create
a separate account for the administrator
and disable the default account on that system.
If you want to see what the default authentication might
be for some of your devices, you can
find a number of resources on the internet,
such as routerpasswords.com.
If you're planning to change the password on one
of these devices, we need to make
sure the password is something that is difficult for someone
else to know.
You want to have what's called a strong password, which
is one that adds so much complexity that it's not
something that's easily discovered.
Your focus should be on increasing
the entropy of that password.
Entropy is a measure of how unpredictable a particular
value might be.
So you don't want to use single words or obvious passwords,
like the name of your dog.
And you want to mix uppercase, lowercase,
and, perhaps, add other characters into the password.
You also want to be careful with replacing certain characters.
For example, replacing an O with a 0,
or replacing the letter t with the number 7 because attackers
already know that these techniques are in use,
and they're already planning their brute force software
to take those into account.
These days we tend to create passwords that
are eight characters or longer.
And very often, you can choose a phrase or set of words
to make your password even stronger.
One of the challenges we have with the DHCP, or the Dynamic
Host Configuration Protocol, is that there's no security built
into the DHCP specification.
We can add additional security in our switches
by enabling DHCP snooping.
This allows us to track IP addresses and MAC addresses
on this layer 2 device.
The switch would effectively become a DHCP firewall.
You would configure the switch to trust routers, switches,
DHCP servers, and anything else that is legitimately
handing out DHCP responses.
You would not want to have the switch trust
any of the other devices on your network,
such as other computers or devices that could be turned
in to unofficial DHCP servers.
With DHCP snooping, your switch is always
examining the DHCP conversations,
and it's building its own table as to what
IP addresses are associated with which
MAC addresses on that switch.
This allows the switch to filter out
any traffic that doesn't match that list of pre-assigned DHCP
assignments.
This allows the switch to filter out
any traffic that doesn't match this predefined list of IP
addresses and MAC addresses.
So if someone tries to statically assign
an IP address on their system, it
would be filtered by the switch.
Or if an attacker tries to create their own DHCP server
or send an invalid traffic pattern,
all of that communication will be automatically filtered
by DHCP snooping.
If you look at the configuration of a switch,
you would find that all access ports, which
are all devices that are not trunk interfaces,
are assigned to a specific VLAN.
This means the user connecting on that physical interface
on the switch will be added to the VLAN associated
with that port.
If we look at this VLAN configuration on my network,
you can see there are a number of interfaces, 24 fast Ethernet
interfaces and two gig interfaces.
All of those interfaces are configured with the default
VLAN, which is VLAN 1.
If I connect a device to fast ethernet port 0/14
and turn it on, it will automatically
be part of VLAN 1.
One of the challenges with having users on a default VLAN
is that there might be other administrative traffic
on that VLAN as well.
For example, control plane access
or management of the switch might
occur on the default VLAN.
From a security best practice, we
don't want to have our users on the same VLAN that's
used by our management traffic.
So we might want to have a separate VLAN created
on that switch that's just for our management communication.
We also might want to configure our switch
so that any of these interfaces that currently don't have
anything connected to them don't have a connection
into the default VLAN.
Instead, we might want to create a dead-end VLAN, or an impasse
VLAN, and assign any unused interfaces
to the dead-end VLAN.
This way.
If someone does find their way onto that interface--
they plug in their device and try to gain access
to the network--
they'll find they're on a VLAN that goes nowhere.
If you look in the internals of your switches,
and routers, and other network devices,
you'll find that they're not using a traditional operating
system.
Normally, there's not Linux, Windows, or some other OS
running on those devices.
Instead, they're running their own type of firmware.
And occasionally, there will be a need
to upgrade the firmware on those devices,
so that system is always up to date.
This usually happens when there's
some type of security vulnerability associated
with that firmware, so you have to upgrade
to the latest version to be able to patch that hole.
Unfortunately, the upgrade process
doesn't always go as planned.
And sometimes upgrading firmware can introduce other bugs,
or other problems, and you may need
to downgrade that firmware after identifying those problems.
Unfortunately, it's not always easy to find one of those older
versions of firmware.
So you want to be sure to keep a library of all of your devices
and all of the firmware that's running on those devices.
This will allow you to move to any particular firmware
version at any time, especially, if you run into a problem.
This idea of patching a system should not be a surprise.
It should be part of the normal procedures that you go through.
You want to be sure that you're able to keep up with the latest
version, so that your systems are not only stable,
but you fix any security problems
that may be introduced in the current version.
Some manufacturers will create service packs,
where you can introduce or install many different patches
all at one time.
Or you may just want to install patches
as they're updated every month.
Sometimes the manufacturer will introduce patches outside
of this normal scope, especially if it's
an emergency or a zero-day attack,
and they may create an out-of-band update
and require you to update as soon as possible.
As a network administrator, you need full and complete access
to your switches, routers, and other infrastructure devices.
But you may want to have other individuals in the organization
with their own access to this device,
but you may not want to give them administrative access.
Perhaps you only want them to be able to view statistics
on that device or to view the logs on that device.
In those cases, you may want to configure role-based access,
so you can create one role for administrators
and a different role for the help desk or management.
You may find that the switches, routers, firewalls,
and other devices you're using do allow the configuration
of specific roles.
So you could create an administrative group, a help
desk group, and an IT management group within your device
and then assign users to each of those groups.
You would then specify what those groups are able to access
and what parts of that system those groups would not
be able to access.
For example, the help desk may be able to view statistics.
And an API access group may not be
able to log in interactively.
You could even take this a step further
by creating a set of Access Control Lists, or ACLs.
This would allow or disallow access
to the system based on a number of tuples.
These would be groupings of categories
that might include source IP addresses, destination IP
addresses, port numbers, or anything else
you can use to make a decision on whether traffic
should be allowed or denied.
Maybe you'd like to restrict access
to a particular switch or router based
on a series of IP addresses.
Maybe you know that the network administrative team
is on a very specific VLAN, or set of IP address ranges,
and you might want to prevent all access to that device
if they don't come from that specific range.
You, obviously, want to be careful when configuring these
because if you're outside of your local VLAN
and you need access to this device,
you might be locked out of your own equipment.
You want to be sure that the access control lists are
strong enough to prevent unauthorized use,
but still allow you to be able to manage those devices.
One type of access control list is a firewall rule.
We may want to allow or disallow traffic
through our network based on a series of rules
that we can add to our firewall.
This list of rules is followed one at a time,
and if the traffic matches that particular rule,
then it follows the disposition that's in the action column.
When you get to the bottom of the list, on most firewalls,
there is an implicit deny, which means if none of these rules
match when you get to the bottom of the rule list,
that traffic is automatically dropped.
These implicit denies are, commonly,
not logged in a system.
That's why you'll find many firewall administrators will
add one final rule at the bottom.
That is in any IP to any IP over any port number
and any protocol will automatically
be denied, which is, effectively,
the same thing as an implicit deny,
except we are explicitly creating this deny rule.
Most firewalls are configured to log anything
that's in the rule base.
So by adding this explicit deny to the bottom of the list,
we can log any traffic that doesn't match any of the rules
inside of our firewall.
This is a very simple rule base for a layer four firewall.
The rules have a rule number, a remote IP address,
a remote port number, a local port number, a protocol,
and an action to follow.
Let's look at this first rule of the firewall.
We can see that any remote IP and any remote port
can communicate to a local port 22 over TCP
and that traffic would be allowed.
Since we know that TCP port 22 is for SSH traffic,
then this rule was, probably, set up to allow inbound SSH.
Rule number two is configured to allow any remote IP
address over any remote port number
to communicate to a local device over port 80 using TCP.
That traffic would be allowed.
TCP port 80 is commonly used by HTTP,
so this would allow traffic to a web server.
We have a rule right after that one
that includes TCP port 443, which would be the HTTPS
traffic to that web server.
And the last rule is an explicit deny.
This means if traffic does not match anything
in rule number one, number two, or number three,
we will deny that traffic and log it in the firewall.