1.3.3 - Network threats, firewalls and proxies

1.3.3 - Network threats, firewalls and proxies

Connecting a system creates routes for useful communication and for attacks. This lesson follows the mechanisms behind common threats, then explains how firewalls, proxies, encryption and other controls reduce particular risks while leaving limits that still need attention.

How network threats cause harm

Security protects confidentiality (only authorised people see data), integrity (data is not improperly altered) and availability (authorised users can obtain the service). An attack can affect more than one of these. A stolen account may expose records and allow changes; a flood of requests may stop legitimate users working without stealing any records.

An attacker, sometimes described as a hacker, may seek unauthorised access by exploiting a software flaw or obtaining credentials. Authorised security testing has a different purpose and permission. A virus is malicious code that attaches to other code or files and spreads when its host is executed. Other malware can spread without that mechanism. Spyware secretly monitors activity or collects information, such as keystrokes, creating a route to stolen credentials. Anti-virus tools seek malicious infected code and anti-spyware tools seek unwanted monitoring software; these functions can be included in a wider anti-malware product. Scanning and updates reduce risk, but cannot guarantee detection of every new threat.

Phishing uses a deceptive message or site to persuade a person to reveal information or perform an action. A plausible “payroll update” email might link to a false login page. Pharming redirects a person towards a false site, for example through compromised DNS information or local name-resolution settings, even when the person typed the expected name. Phishing's principal mechanism is deception of the user; pharming's is redirection. Both can produce credential theft.

A denial-of-service attack overwhelms a service or exhausts a resource, preventing legitimate requests being handled. A distributed denial-of-service attack uses many sources, making a simple one-source block insufficient. Filtering and rate controls may help, but a local firewall cannot restore upstream bandwidth that has already been saturated.

SQL injection occurs when untrusted input is treated as part of a database command. If a login service builds a query by concatenating a submitted string into its SQL, specially formed input can change the command's meaning. Parameterised queries keep input as data and command structure separate. Least-privilege database permissions reduce the damage possible if a flaw remains. The database and security lessons teach further detail; the network-security point is the entry route and the matching control, not an instruction to attack a real service.

For a college portal, staff training and verification of unexpected requests address phishing; patched software reduces exploitable flaws; strong unique passwords and multi-factor authentication reduce account compromise. Multi-factor authentication requires an additional factor beyond the password, but a user can still be tricked into approving an attacker’s request. A control reduces a stated mechanism; “install security” is not an explanation.

Filtering traffic with a firewall

A firewall applies rules to network traffic, permitting or blocking communication. It may be software on a device or a network appliance. Rules can consider direction, source/destination address, port and protocol; more capable firewalls may inspect additional information and track connection state. A port identifies an application endpoint, not a physical hole in a router.

Suppose a small organisation needs public access to a web server but wants its database reachable only from that server. A simplified policy could allow Internet requests to the web service, permit the web server's required connection to the database, and deny unsolicited Internet connections directly to the database. The database's existence is not a reason to make its port public. Administrators need to understand the required paths before writing rules, or they can accidentally block legitimate work.

Here is a deliberately simplified ordered packet-filter policy. The first matching rule determines the decision; traffic unmatched by a permit is denied. It omits the connection-state rules a real deployment would need.

OrderDirectionConditionDecision
1Inbound from InternetDestination web server, TCP destination port 443Permit
2Inbound from InternetAny other destination or portDeny

A request to the web server on TCP port 443 matches rule 1. A request directly to the internal database on port 5432 reaches rule 2 and is denied. The filter does not prove that every permitted web request is harmless. An application can receive malicious input over an allowed connection. A firewall also does not automatically remove malware already running on a machine, and an overly broad permit rule can leave services exposed.

Continue this lesson.

You’re previewing NovaLearn without an account. Create a free account to read the rest.

Create free account