Block port 111 on centos 7

12,930

Solution 1

You are a little wrong with iptables command. Try this:

iptables -A INPUT -p udp -s 192.168.0.0/24 --dport 111 -j ACCEPT
iptables -A INPUT -p udp -s 127.0.0.1 --dport 111 -j ACCEPT
iptables -A INPUT -p udp --dport 111 -j DROP

This will allow connections to port 111 from localhost (127.0.0.1) and from network 192.168.0.0. All other connections will be dropped.
Note, your warning recommends to block UDP, not TCP. I replaced protocol in example.

Solution 2

If you don't need rpcbind then:

systemctl stop rpcbind.socket
systemctl disable rpcbind.socket

See https://unix.stackexchange.com/questions/369937/fedora-25-and-disabling-whatever-is-listening-on-port-111/

If you don't use something then it's stupid and less secure to leave it turned ON and then filter it with a firewall. Recommendation number 3 in the description should be number 1.

Share:
12,930

Related videos on Youtube

Mirage
Author by

Mirage

Nothing good...

Updated on September 18, 2022

Comments

  • Mirage
    Mirage over 1 year

    I am using a server with centos 7 running kvm/virtualization, I access using VNC server.

    Today I received an warning about my server being used to attack other server using port 111, I am completely lost. My password for the server is very very hard, I doubt someone could force it in years... the problem is, I need to protect, Is it possible to disable this port ? Do I need it ? I used

    netstat -l
    

    while on the machine and didn't see any 111 occurrence, so if I block, Can I still log into the machine and keep working ? If yes, how can I do this ? I tried this iptables -A INPUT -p tcp -s! 192.168.0.0/24 --dport 111 -j DROP iptables -A INPUT -p tcp -s 127.0.0.1 --dport 111 -j ACCEPT

    but didn't work, output:

    Bad argument `192.168.0.0/24'
    

    Is there a way to block it, or make it only usable to my local network/localhost (if block will block the server access)?

    The warning I received:

    A public-facing device on your network, running on IP address (IP ADDRESS), operates a RPC port mapping service responding on UDP port 111 and participated in a large-scale attack against a customer of ours, generating responses to spoofed requests that claimed to be from the attack target.

    Please consider reconfiguring this server in one or more of these ways:

    1. Adding a firewall rule to block all access to this host's UDP port 111 at your network edge (it would continue to be available on TCP port 111 in this case).
    2. Adding firewall rules to allow connections to this service (on UDP port 111) from authorized endpoints but block connections from all other hosts.
    3. Disabling the port mapping service entirely (if it is not needed).

    I am not using any firewall.

    • Jordi
      Jordi about 7 years
      I've just made up a Centos/7 machine and I'm realizing it's listening on 111 port. What's under that? Who is listening to?
  • Mirage
    Mirage almost 8 years
    Hey man, no errors on the output. Thank you very much for your help. You think this will solve the problem and prevent my server from being used for this attacks ?
  • Andrew
    Andrew almost 8 years
    This will prevent anyone from outside your network (192.168.0.0/24) from accessing port 111. If this udp port was using to attack server - now this type of attacks is blocked. But a) this can be not only vector of attack; b) system can be already compromised. As recommendation, it will be good to perform some virus/rootkit check.
  • user1914292
    user1914292 almost 8 years
    @Andrew thanks for the answer! From what I understood this type of attack doesn't require access to the actual server, but is merely a reflection attack that bounces of this UDP port 111 and attacks other systems - not the one that is used. Can you explain why the system itself could still be compromised and what kind of checks you would recommend? Thanks!
  • baelx
    baelx about 6 years
    This answer doesn't respond as directly to the OP's question, but more closely follows good Sys Admin practice of only running what is absolutely necessary on your system. Granted this user isn't implementing nor interfacing with an NFS, they should rightfully disable rpcbind. As a minor correction, they should be sure to disable the rpcbind.socket as well as the rpcbind.service using the above-mentioned systemd syntax.
  • MarcH
    MarcH almost 6 years