Networks enable computers to share information and work together from all across the world. This allows for the creation of many impactful applications like the web, email, file sharing, secure shell, voice and video chat, online games, etc.
Unfortunately the Internet also allows for many types of security attacks. Most attacks target the application layer, exploiting issues with the particular application layer software, but some target the more foundational layers in some way.
We have seen that packet sniffing programs such as Wireshark (and the terminal version TShark) can see packets coming through a network.
This includes packets that are destined for the computer the packet sniffer is running on. This alone can be a problem, since it can allow one application (such as a piece of malware) to "spy" on another.
However, packet sniffers can also be used to see packets destined for other machines on the same LAN. This is out of necessity in wireless networks since routers work by broadcasting packets out. Clients then filter out the packets that are not for them, and pass those that are to the appropriate application.
Packet sniffers can see two sorts of information:
The solution to the second problem is to encrypt all sensitive data using something like TLS. However, TLS does not prevent against the first problem. In order to avoid this, you could use a Virtual Private Network (VPN).
A VPN can be used for several different purposes. The basic idea is that you connect your machine to a VPN server somewhere else, and it acts as a go-between for your machine to connect to other parts of the Internet.
With a VPN, you are still using the public Internet, but all of your traffic is being "tunneled" through the VPN. This means that from an outsider's perspective, the VPN server is the only machine you are communicating with.
The machines you are talking to through the VPN, and which ports you are using, is being sent through the VPN and is normally encrypted.
One main use a VPN is to allow members of an organization to connect to the organization's networked resources from off-site. For instance, UMW has several network services that are only available to users on UMW's network. This is to decrease the number of machines that could connect to these services.
In order to allow staff to access these services, UMW has a VPN. By connecting to the VPN, your traffic comes from on campus and so you can access these services. The VPN client requires authentication and may have other restrictions (like scanning your PC for malware).
There are also VPN services that just offer anonymity and security on the Internet. These can also allow your machine to appear as if it is coming from another geographic region to get around content restrictions.
Many applications rely on authenticating users with a username and password. Checking that a user's name and password match what is expected is called authentication.
With authentication we transmit the username and password from the client to the server. Of course these should be encrypted to prevent anyone from reading them as they are transmitted.
Once the server receives the username and password, it could simply compare the two to what is stored in the database. However, it is very bad practice to store passwords in readable plain text anywhere. The reason is that, if the server is compromised, an attacker could read all user's passwords. Because many people reuse passwords, an attacker could use these to access other services.
Instead, passwords should be stored as hashed values. A hash is a one-way cryptographic function. When we hash a password, we get some scrambled text out. Because it is one-way, it's not easy to go back from the hash to the original password. Hashes also must be repeatable - the same password must always hash to the same value.
However, there is one extra step which is taken, called salting. To see why salting is needed, imagine that you are an attacker and recovered a database of usernames and passwords. The passwords are hashed, so you can't just read them all. However, you do know which hash function is used (there aren't that many and you can tell which is used from the application's code).
Because you know the hash, you can just apply that hash to thousands of the most common passwords people use and see if those hashed values are in the database. This is called a "dictionary attack" since an attacker tries lots of passwords, like words from a dictionary.
For example, imagine a user has picked "abcdef" as their password. Also, let's say that MD5 is being used as a hash. Then the hashed value of the password is:
$ echo "abcdef" | md5sum 5ab557c937e38f15291c04b7e99544ad -
So the database would store this value for the user's password. You as the attacker will surely try putting "abcdef" through the hash. You will then search the database and find any user's who have used "abcdef" as their password.
The purpose of a salt is to make the same password hash to different values in a repeatable way. The basic idea is that, when a password is first made, we pick a random string along with it. The random string is called the "salt". We then append this string to the password before we hash it.
For example, suppose two users both are using the password "abcdef". When their accounts are created, they will get different salts, let's say "wH1rXoEZ" and "ZLXeYPbw". Now their passwords will hash to different values:
$ echo "abcdef:wH1rXoEZ" | md5sum c29d318dab6372613dabc23eee0110cb - $ echo "abcdef:ZLXeYPbw" | md5sum 50c0284a82686f0d7d653f69c22903b0 -
Using a salt prevents users with the same passwords having the same hash values. It also keeps the database from having hashed values based on known or very weak passwords.
Because the salt is necessary to perform the hash, it must be stored in the database as well. When an account is created, we follow these steps:
Then when a user needs to be authenticated, we follow these steps:
Publicly accessible services are constantly bombarded with login attempts.
One step that server machines can take to reduce their chances of being attacked is to reduce the number of applications listening on ports.
We have seen that when we create a server application, we must listen on a particular port and accept connections as they come in. Ideally, only legitimate clients will connect to our server, but it's likely that an attacker will attempt to connect as well.
How can an attacker know what ports we have applications on? It can use a program called a port scanner. A port scanner works by basically trying to connect to a machine on every port and seeing which connections fail and which succeed.
A port scanner can be used for legitimate purposes, such as performing a security audit, or seeing what applications a server supports. However, it can also be used to scan for vulnerabilities in a machine.
A vulnerability is a bug in a piece of hardware or software that can be turned into an access point for an attacker. For example, a particular application might accept SQL input as-is, making it susceptible to SQL-injection attacks. If an attacker sees that your server is listening on the port this application uses, it can try to attack your machine in this way.
There are also port sweeper programs which scan a range of domains or IPs for a particular port number. This allows an attacker to search the Internet for machines with a particular vulnerability.
A firewall is a system that filters traffic out of a network based on various rules. Firewalls are built into network devices like routers, and are also included in hosts.
When a router receives a packet, it will check its firewall rules before forwarding the packet on. If there is a rule saying the packet should be dropped, then it will not be forwarded on.
Rules can filter out packets based on a variety of criteria such as the sender or port. Because forwarding is done in hardware, these firewall checks are done in hardware as well. The firewalls included in routers are called hardware firewalls for this reason.
There are also firewalls included inside of operating systems that can provide further filtering. These run in software as a part of the operating system and are sometimes called software firewalls.
By default firewalls often disallow incoming traffic on all but ephemeral ports. This is why we had to modify the Google Cloud firewall to allow us to create servers. Firewalls generally come with default rules like this that can be changed by the user.
A very "brute force" sort of approach an attacker can take is with a Denial of Service (DoS) attack. Here an attacker simply sends so many packets to a server that it is overwhelmed and can no longer meaningfully respond to its clients.
When a server accepts a connection from a client, it typically launches a new process or thread for handling that connection. When there are a very large number of connections, the number of processes or threads will be so large that none of them can finish their work in a reasonable amount of time.
A DoS attack does not allow an attacker to access private information, or take control of a server, it just allows the attacker to take the server down until it is fixed.
One potential solution to a DoS attack is to just disallow connections from the machine causing the trouble with a firewall rule.
Attackers can get around this defense by using a Distributed Denial of Service (DDoS) attack. This is the same idea as a regular DoS attack, except it is not just one machine flooding the server, but a team of them.
Often DDoS attacks come from "botnets" which are networks of machines that are infected with malware. If an attacker can get a piece of malware onto lots of different people's computers, it can use those computers to bombard a target with requests from all directions at once.
It is impossible to completely avoid the potential for a DoS attack. Servers try to classify traffic as legitimate or illegitimate or not based on factors such as the sender, port and protocol. They can then try to filter out the suspicious traffic. Servers can also throttle clients that make too many requests in a short amount of time.
Copyright © 2024 Ian Finlayson | Licensed under a Attribution-NonCommercial 4.0 International License.