In the simplest terms, a firewall is a peice of software that reads the contents of a packet as it attempts to enter and leave a device.

Some networks are set up with special routers who's only purpose is to run this software, and receive incoming traffic, inspect it, and pass it on (or drop it) based on if it thinks it's safe.

How firewalls work, well that's a little more complicated.

Essentially, most designs come down to a giant flowchart of rules. Each step in the flow chart will perform some task based on the information being inspected, and will make a decision based on the result. Generally, the decision will be to either

1.) Drop the packet, meaning to not let it pass, and move on

2.) Accept the packet, meaning to let it pass and move on

3.) Jump to a new rule, meaning divert into an alternative branch of the flow chart

4. Pass, meaning to just do nothing and the let the next rule decide.

Most of the time you'll set up a chain of rules so that if you pass every step, you get to go to the next one, but if you fail you get dropped. This is like a logical and. "You must be this tall to ride AND you must be wearing your swim trumks"

Sometimes you'll do the opposite, where success means you're accepted, and failure means you get passed along. This is a logical OR "You must pay full price OR have a coupon"

Jumping is most helpful when you want rules to only apply to certain types of packets. So, if for example you wanted to detect when someone was uploading a file to your file server, as opposed to browsing a website hosted on your network, you might have extra rules to make sure the file they're trying to send is safe and normal before giving it the all clear. But those rules don't make sense when looking at website browsing traffic, so we branch to the file upload rules when we detect it happening.

What the rules actually look like can be pretty complex too, but because speed is a priority you often do your simplest checks first to try and reduce the amount of times you have to do your more complex checks. If a packet is going to be dropped the objective is to detect and drop it asap so as not to waste resources.

The simplest and most common rule checks whether a specific value is at a specific location. It's like saying "is the third letter in this sentence an 'l'. The third letter was not an l, do we fail the rule and move on. Sometimes these rules get a little more complex. We might want to check if any one of several values exist in a particular location. We want an OR. The problem is, we are in the middle of a large AND, how do we resolve this?

To do this, we'd do some jumping magic. We jump to a chain of OR rules. Then, instead of accepting the packet, we go back to where we jumped from, and treat the jump statement like a sungle rule that either came back true or false. This very powerful technique is like having parentheses and let's us make very nuanced and deeply nested queries out of very simple and thus very quick parts.

The next most complicated rule is not just a matching rule, but a pattern rule. Rather than look for a value in a single place, we ask does this value occur anywhere in a range of places. Because firewalls are often designed to be minimal and fast, there are many implementation that cut even this basic function just to be better at doing the most simple queries. The solution, we use multiple firewalls at once. An example of one of these more complicated firewalls is called Snort. Snort let's you do all kinds of complex pattern based queries looking for complex patterns of data in anything you might want to examine in a packet. Of course, it's slower, but it's unbelievably powerful and is the backbone of every secure network.

Final though, we get to the mack daddy of firewall rules. Stateful inspection. Sometimes we aren't just looking at a pattern in a single piece of data, in a single packet. Sometimes we need to find a pattern across multiple packets. Sometimes we store information from one packet to help analyze the packets that come after it. Now we're not just slowing down, now we're using memory. That's a big and expensive cost for something that's supposed to examine everything, so we usually reserve it for critical needs and systems, or only inspect a random sampling of traffic this way. In either case, stateful inspection is the king. There's no part of a session or protocol you can't examine that way. Any question you want to ask, any criteria you want to use, stateduk will get you there. It's just slow and expensive and only useful in a tiny tiny minority of cases.