Welcome to the Power Users community on Codidact!
Power Users is a Q&A site for questions about the usage of computer software and hardware. We are still a small site and would like to grow, so please consider joining our community. We are looking forward to your questions and answers; they are the building blocks of a repository of knowledge we are building together.
Data transfer between computer system ports, as unidirectional or bidirectional
I understand that with computer systems (non virtual or virtual), data between the network of two or more computer systems can come in via a port and can come out via a port.
Is it common to filter computer ports to work unidirectionally instead bidirectionally? I mean, is it common to set firewall rules for ports to transfer data in only one direction (only inwards with incoming data or only outwards with outgoing data)?
1 answer
is it common to set firewall rules for ports to transfer data in only one direction (only inwards with incoming data or only outwards with outgoing data)?
No.
At least not strictly as stated.
There is a very simple reason for this: TCP (which is used for much traffic on the Internet, and which is one of the few protocols in the TCP/IP stack which has a concept of logical "ports") requires bidirectional communication in order to even establish a connection. This is the SYN/SYN-ACK/ACK sequence; the client that wishes to establish a connection sends a packet with the SYN flag set, to which the server responds with a packet with the SYN and ACK flags set, to which the client responds with a packet with the ACK flag set, before useful data can start flowing through the connection.
(Whatever runs inside that connection may then have its own handshake process separate from that of TCP; for example, the TLS layer in HTTPS requires its own handshake to set up the encryption, before the actual HTTP request can be sent.)
Therefore, to allow (TCP) traffic in only one direction means that no traffic can flow, since no connection can ever be established; any attempt will be forever stuck early in the TCP handshake, only to eventually time out.
Some other protocols, such as UDP and ICMP, can in principle be used in one-way scenarios, because they don't have anything similar to TCP's two-way handshake. (UDP has the concept of ports, but for example ICMP doesn't even have that.) That being said, there's usually little point to doing that because most of the time, when a host legitimately sends data, it's either (a) some kind of request, to which a response is expected, or (b) in response to some kind of request that was received previously. Blocking traffic in the opposite direction would render the whole exercise largely moot.
What is often done is to set up different filtering policies for incoming and outgoing connections. For example, a client host's firewall may be set up to allow everything going out, but be very restrictive with regards to incoming connections, perhaps by only allowing traffic that relates to a connection that has already been established in the outgoing direction. Way back when, doing this securely was tricky, but with modern "stateful" firewalls, it's comparatively trivial. Many consumer firewalls don't even make it possible to turn that off, whereas professional firewalls can typically be deliberately configured in such a fashion in the unlikely case that this makes sense in the specific situation.
0 comment threads
1 comment thread