ACL in AWS is a stateless firewall, that means it treats all the requests (inbound or outbound) as independent connections. Hence, if you are trying to allow the port 22 of the server reachable from the client, you need to enable both (inbound to port 22 of the server + outbound to the random [1024-65535] port of the client) sides' connections.
Whereas, if you are dealing with "Security Groups", you only need to allow the inbound to port 22. Its just because "Security Group" is a statefull firewall and it keeps track of the inbound connection, therefore you need not explicitly allow the outbound connection to the client's random [1024-65535] port.
I would not consider ESTABLISHED and RELATED traffic too open. You may be able to omit RELATED, but should definitely allow ESTABLISHED. Both of these traffic categories use conntrack states.
ESTABLISHED connections have already been validated by another rule. This makes it much simpler to implement unidirectional rules. This only allows you to continue transactions on the same port.
RELATED connects are also validated by another rule. They don't apply to a lot of protocols. Again they make it much simpler to configure rules. They also ensure proper sequencing of connections where they apply. This actually makes your rules more secure. While this may make it possible to connect on a different port, that port should only be part of a related process like an FTP data connection. Which ports are allow are controlled by protocol specific conntrack modules.
By allowing ESTABLISHED and RELATED connections, you can concentrate on which new connections you want the firewall to accept. It also avoids broken rules meant to allow return traffic, but which allow new connections.
Given you have classified the program on port 1337 as insecure, it should be started using a dedicated non-root user-id. This will limit the damage someone can do if they do manage to crack he application and gain enhanced access.
It is highly unlikely a connection on port 1337 could be used to access port 22 remotely, but it is possible that a connection to port 1337 could be used to proxy a connection to port 22.
You may want to ensure SSH is secured in depth:
- Use hosts.allow to limit access in addition to the firewall restrictions.
- Prevent root access, or at least require the use of keys and limit their access in the authorized_keys file.
- Audit login failures. A log scanner can send you periodic reports of unusual activity.
- Consider using a tool like fail2ban to automatically block access on repeated access failures.
Best Answer
Your understanding is wrong :-). The client will choose a 'tcp-high port' to initiate traffic to the server's target port 22. The server will respond to the clients initiated source port.
For example, the client chooses port 12345 as source port to connect to the servers destination port 22. The server will try to send traffic from it's port 22 to the client on port 12345.
The tcp-high port range is from > 1024 to 65535.
Therefore you should allow RELATED and ESTABLISHED traffic to your client. For example:
Ensure that the above rule comes before the 'block all the rest' rule.