HTTPS firewall rule

Question

Setting up Firewall rule for HTTPS websites on basic stateless packet filter firewall

This seems like a stupid question, but how do I set up a firewall rule to allow HTTPS on a basic packet filter firewall? The purpose is I want to be able to browse to sites like https://twitter.com and have all images load etc. How can I set up this rule?

I have the rules set up like so:

yourPC-[highport] --> SSLserver:443

src ip      any
dest ip     any
src port    any
dst port    443
inbound     block
outbound    allow

SSLServer:443 -->YourPC-[highport]

src ip      any
dest ip     any
src port    443
dst port    any
inbound     allow
outbound    block

The outbound traffic seems OK, but I am dropping packets like this (This example is loading a twitter page, the akamai content):

23.9.229.210:443 > XXX.XXX.XXX.XXX:62712, AS Seq=###, Ack=-### -Black List Defense

• How should I set up the rule to allow loading https websites? (is it not working because of the order in which the rules are read by the firewall?)

Other Details:

• these rules are for the packet filter built into my router
• this is not a stateful firewall

Many thanks

Answer 1

Assuming that you're setting up the firewall to allow you to access SSL websites, then how you configure the firewall depends on whether the firewall is stateful or not.

as @TerryChia says the ports on your local machine are ephemeral so the connection is

yourPC-[highport] --> SSLserver:443

and the return path is

SSLServer:443 -->YourPC-[highport]

So if your firewall is extremely old-school the way to set this up would be to allow all traffic from a source port of 443 to all high ports on your machine.

However almost all firewalls these days are stateful, which means that they can recognise when a packet is part of an established connection.

So you just have to allow your PC to connect to 443 outbound and then for inbound you allow all traffic that relates to established connection

e.g. for iptables

sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Answer 2

Are you setting up this firewall on your server or your client? Your rules (outbound only, destination restricted) suggest client settings [and looks correct BTW], but you question and comment suggest server settings.

I know very little about firewalls, and some time ago asked this question on SF to address an elementary doubt of mine. From the answers I got, I may say that your server firewall should have:

src ip (any)
src port (443)
inbound allow

To disallow anyone from trying to connect to it through a port other than 443 (warning: you should enable the SSH/etc port too, or you'll be locked out of your server). Do this if your concern is with protecting the server. The outbound and dest rules will limit what requests from your server to somewhere else will be available, so set them according to your needs.

If your concern is with protecting the client, then you should restrict the destination port (and, even better, the ip as well) to 443 and disallow inbound connections (assuming your client is not expecting them). So your client firewall should have:

dest ip (any [or your server's])
dstn port (443)
inbound block
outbound allow

Note: also explained in that other question, a stateful firewall will allow a machine that received a request to send a response to the same ip/port regardless of the outbound settings, and vice versa, that's why your config does not need to worry about ephemeral ports. Ex.: client sends a packet to server (src: 55680, dest: 443), client firewall accepts (outbound ok, dstn ok), packet is sent; the response comes to the same 55680 port, but the firewall lets it through - rule to block inbound does not apply here, since it's a response to a request that initiated in the client machine.

That's why, counter-intuitively, you use outbound rules to protect the client, even though you're worried about incoming packets. While also blocking all inbound packets, and still having the ones that matter - the responses to your requests - arriving normally.

Answer 3

The arbitrary ports you are seeing in your logs are known as Ephemeral ports.

This isn't a situation specific to HTTPS. Any communications with a server will involve your client using an ephemeral port to communicate with a defined port on the server side.

If you want to restrict access to web servers listening on port 443, simply direct your firewall to drop packets with a source port of 443. Why you would want to do this is a mystery to me.

Answer 4

This seems like a stupid question, but how do I set up a firewall rule to allow HTTPS on a basic packet filter firewall?

There are generally no stupid questions and this is a fairly legitimate question to ask, so no need to apologise. Let me try and explain this as plainly as possible, without necessarily sacrificing clarity and correctness.

Note: While you ask for a solution I will provide you with some background as to why you may not want to do what you're attempting. If you fully understand the consequences of your question and all that it entails I suspect my answer may not be one that you seek. Should you however want to understand why the configuration is not all that great, by all means, continue to read.

It has already been explained that what you see are the so called ephemeral ports. These are dynamically allocated by the network stack in your operating system. Why is my operating system using these high-numbered ports instead of 443 you may ask?

There are several reasons, allow me to highlight a few that may help you in understanding why this isn't necessarily a problem.

1. Browsing (network) efficiency
2. Security (permissions)

If you were to enforce your operating system (and client software) to use only port 443 you'd significantly reduce the opportunity for the OS and browser to use network parallelism, something that is utilised to increase the speed of page-loading. You see, there are a number of limitations in how HTTP works as a protocol such as a single requests at a time. Using multiple connections to download content is one way to help overcome this limitation; as is HTTP-pipelining.

The second reason mentioned above is about security. Most operating systems consider ports below 1024 (0-1023) privileged. In order for a user-land application to bind (use) one of these ports additional privileges are required by the application (such as running with administrative privileges, or using a particular capability in Linux, see this.).

What you've identified isn't usually considered an issue (for HTTP) with modern operating systems as their respective network stacks will know which packets are related to which packets.

If you're still concerned and simply not convinced by either of the provided answers for your question you could do attempt the following. Investigate if your browser can be limited to a certain range of ephemeral ports such as 51000-51100. Then create a rule to allow only these ports to be used as src-port in combination with dst-port 443.

However, note that restricting your operating system and client software to these ports may have unforeseen consequences as there may be other applications using these ephemeral ports you just assigned.

TL;DR - Don't worry about the ephemeral ports used when browsing, trust that the operating system handles associated and related packets correctly. Enforce dst-port and be happy with that. :-)