4

Preamble: So, before I actually ask the question, I'd like to point out that I'm somewhat apprehensive about posting this because even as I'm typing this out it it feels like I'm asking someone to just tell me the switch config I need, which isn't the case. I already have the main switch configuration finalised and ready to go back to the client, but they've asked me to verify the /entire/ config they're going to actually apply to the switches, not just the application-specific stuff, hence the question below. Anyway, now that's over, on to the actual question.


I've been developing an application for a client which will run on a bunch of load-balanced AWS servers running Debian 7.5 which will only be accessible on port 80 for the application itself from all addresses, and port 22 for SSH from just our office and the office of the client's outsourced AWS management team.

The client's security policy is needfully restrictive as the servers will contain sensitive business data, so the network configuration needs to be locked down for incoming and outgoing connections from all servers as much as possible. I've already outlined the requirements for this part and it's been agreed between myself and the AWS team. However, they have asked me to verify the final configuration they are going to apply and this includes the following lines:

Source          Destination     Protocol  Ports        Service          Action  Description
0.0.0.0/0       192.168.0.0/16  TCP       1024-65535   Ephemeral Ports  Allow   Allows inbound return traffic from the Internet
192.168.0.0/16  0.0.0.0/0       TCP       32768-65535  Ephemeral Ports  Allow   Allows outbound responses to clients on the Internet (for example, serving web pages to people visiting the web servers in the subnet)

Unfortunately, the network layer is the one aspect of the OSI model about which I know very little. I was vaguely aware that some services use ephemeral ports for the actual worker connections after the initial request to the service's well-known port has been established, but I'm not sure which services actually need these ports to be open on the public interfaces of servers in order for those servers to function correctly. The comment implies that 32768-65535 are required for web servers to function, but I've had authoritative responses from them in the past which have later turned out to be wrong, so I want to confirm this assertion.

Do either of nginx or sshd require the ephemeral ports to be open in order for them to perform their functions correctly, or does all activity always happen only on the ports they have been configured to use (eg, 80 and 443, and 22 respectively)? Would closing the ephemeral ports to traffic prevent services like apt from functioning correctly (which I believe usually uses HTTP on port 80 to interact with its sources)?

Additionally, they have added the following two lines regarding DNS queries to the configuration:

Source          Destination     Protocol  Ports  Service  Action  Description
0.0.0.0/0       192.168.0.0/16  TCP/UDP   53     DNS      Allow   Allows inbound DNS query from anywhere
192.168.0.0/16  0.0.0.0/0       TCP/UDP   53     DNS      Allow   Allows outbound DNS queries to anywhere

Now, we're not running DNS daemons on these servers, so I'm pretty sure we can discount the first line entirely, but would closing 53 to either in- or outbound traffic prevent the servers from resolving host names correctly? I have to admit I've never actually looked into how DNS actually works that closely as I've never needed to. :s Suppose now's a good time to start!

But yeah, the tl;dr summary:

Will closing ports 1024-65535 to all traffic, both inbound and outbound, prevent any of nginx, sshd, DNS queries, or any core operating system utilities from functioning correctly on Debian servers?

2
  • consider blocking inbound only - the problem is not with the servers - they will work but for client side utilities that might be using the network. The rest will function as expected (e.g. sshd on 22, HTTP on 80, etc).
    – thanasisk
    Sep 11, 2014 at 16:22
  • When you say client-side utilities, what do you mean? dig and its ilk, or services like monitoring software, etc? Sep 11, 2014 at 16:28

1 Answer 1

4

Definition of a socket pair:

Communicating local and remote sockets are called socket pairs. Each socket pair is described by a unique 4-tuple consisting of source and destination IP addresses and port numbers, i.e. of local and remote socket addresses.[3][4] In the TCP case, each unique socket pair 4-tuple is assigned a socket number, while in the UDP case, each unique local socket address is assigned a socket number.

On the server side, the port is usually fixed by the protocol/application being used. For instance, SSH 22 and DNS 53.

On the client side, the one initiating the connection to the server, it has to pick a source port to fulfil its part of that 4-tuple needed to uniquely identify a connection. Clients usually pick a random port in the 1025-65535 range. I believe this is what they are calling ephemeral ports?

Some protocols (e.g. RPC portmap) will have a server listening on a fixed port, a client will connect and request a specific service, the listener will provide a port where the client should connect (usually random, within a range) and spawn the service on that port. This is just an example of a more complex arrangement for server ports, but in no way it requires specific source ports from the client side to be used. They are supposed to be random.

Filtering on the source port is kind of awkward. The listing your posted do not show if they are filtering the source or the destination ports. If you really want to harden your firewall, default to a block=all policy and let only the necessary ports in. I would not mess with restricting which source ports can be used, unless you are looking for trouble (e.g. clients not being able to connect) or extra work (i.e. complex firewall rules).

It seems in the first listing they are specifying the random of random ports that clients can use. Why do they care?

8
  • 1
    According to Wikipedia, the 32768-65535 range is what's used by Linux machines by default. Windows Server 2003 uses 45000-and-something-to-65535, but if I'm understanding you right, then the outgoing range should be 1024-65535 as the return port number is chosen by initiator of the request, not the recipient, and that needs to cover all possibilities, which means the full 1024-65535 range. Is that right? If so, I think they've got port numbers for the two entries swapped around. Sep 11, 2014 at 16:47
  • 1
    Correct. The initiator picks up a local random port number not in use by any other local application and uses it as the source port for his endpoint of the TCP connection. If they really want to bother with it, they should allow "src port 1024-65535" destined to any of the server ports (in which case, they'd better also filter on the destination port, which is most important in this case).
    – gtirloni
    Sep 11, 2014 at 16:49
  • OK, so, since the ephemeral ports are required for responses to requests on port 80 to be able to get back to the client, then in order to comply with their security policy we're going to need some complicated firewall rules that close 1024-65535 to all traffic which is initiated on those ports, but allow responses to requests on ports 22 and 80 to be sent back on 1024-65535. I'm glad I don't have to set this it up… O.o That said, I'm really getting the feeling that I should read a CCNA book at some point! Sep 11, 2014 at 16:58
  • 1
    Tell them they are making the firewall rules too complex and they should explain they need them, one by one ;)
    – gtirloni
    Sep 11, 2014 at 16:59
  • 1
    It's worth noting that Cisco ACL's often do filter based on source port. The reason is that you can use the well known port of a service to allow response traffic. eg: Port 22 destination inbound, and port 22 source outbound. That allows both halves of a SSH transaction to work, without any need to define ephemeral port ranges. And despite the switches not having any concept of session states. (ie: They're not stateful firewalls: en.wikipedia.org/wiki/Stateful_firewall) Sep 11, 2014 at 18:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .