Home / server / Questions / 302248
Accepted
Brad Mace
Asked: 2011-08-18 12:04:26 +0800 CST

Firewall rules for outgoing RSH connections

  • 772

I have a CentOS 6 server that needs rsh access to one of our old legacy servers which does not support ssh.

RSH connects to port 514 on the remote servers, which then creates another connection back to the client on a port between 512-1023. My current firewall skill level is "port open/port closed" and opening up all of them wouldn't leave much of a firewall. What's the most restrictive way to allow outgoing RSH connections?

firewall centos remote-access

3 Answers

  1. Best Answer

    I'd restrict the incoming from the range of servers using iptables -A INPUT --src {IP address or range}/{netmask} -m state --state NEW -m tcp -p tcp --dport 514:1023 -j ACCEPT.

    You can then restrict the incoming port ranges to the right servers

    Unless you need to restrict outgoing data from a specific server I would not worry about setting up outbound rules.

    I use webmin to set up my basic rules then I copy them manually (its faster and it saves me from looking up all the information I don't use regularly). Webmin supports all sorts of rules--inbound, outbound and mangle. You can set webmin up on a test box then edit then write the rules and copy them to the proper server.

    • 2

  2. On Ubuntu 18.04 with rsh-redone-client/server packages installed, rsh/rlogin to another host in LAN (running CentOS 6) was blocking for a long time (ca. 30 secs) until I opened port 113 (auth) in the local firewall for incoming connections from LAN. I am not sure how it was eventually (after those ~30 sec) working event w/o port 113 opened. Probably the server allowed the connection after some timeout anyway.

    • 1

  3. Some old services include a feature that will send a username query back to the client host on each incoming connection. Services that I've seen to include this feature:

    • FTP on old proprietary Unix servers
    • rsh/rlogin/rexec
    • IRC

    The username query has a destination TCP port 113, originally known as auth port, later renamed to ident as it was recognized that it had nothing to do with any real authentication. In the early days of Internet, when most of the TCP/IP-connected systems were multi-user Unix systems, this service took as input the IP address and source + destination port numbers of another TCP connection, and looked up the client-side username associated with the connection.

    Today, such a blindly trusting, easily spoofable disclosure of usernames is obviously not a good thing.

    In most cases, the service that is making the ident/auth query will accept that the information is not available - but you must either accept or reject the query: if you just drop it, the user will see connection delays of up to 30 seconds, until the server-side gives up. The optimal rejection would be similar to what would happen if a host has no firewall in place, but has no service listening in TCP port 113, i.e. a TCP Reset packet.

    For iptables rules, this means you should use a REJECT rule rather than DROP for TCP port 113, if you are using any legacy services that still send out ident queries.

    Something like this should reject the ident queries in a way that will minimize the delays:

    iptables -I INPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset

    If you are afraid that someone might abuse this to generate a denial-of-service attack, you can add a rate-limiting rule for TCP port 113 before this rule. But I understand the most modern network drivers will already handle the sending of TCP Reset responses as a very low priority task by default anyway, so it might not be a very significant risk.

    • 0