rpcbind got installed.
So I go to check my e-mail today and I see a lot of updates were pulled in by yum last night. This is the first time in a while since I've gotten an e-mail like that. Anyway, it shows rpcbind was installed. Some of the various updates (there were a lot) show the words updates after them, but this shows base after it.
I've never had rpcbind installed, or if I did, it wasn't configured to startup. I recently switched to a new hosting provider and had to tighten the security on the server. rpcbind was not showing as running before when I ran netstat -tulnp, but now, it shows.
I'm thinking perhaps a package had a dependency and required rpcbind maybe? Is there a way to see what installed packages depend on rpcbind?
I don't really want it there. Even if it isn't a security risk, I don't like having unneeded services running. To me, that just increases the chance of my server getting hacked. Maybe there aren't any exploits available for rpcbind yet, but maybe they'll come in the future?
I just don't want to remove it without understanding if it's going to break anything and without understanding why it got installed in the first place.
I just was reading the rest of my e-mails and see the cron log from last night.
Maybe this is the reason yum did so much with all the packages and everything last night? Do you guys think it's related? It seems something weird was going on last night. I'd love to get to the bottom of this. Any suggestions? Thanks!
/etc/cron.daily/0yum-daily.cron:
/usr/lib/systemd/system/named.service: read error
(tried to read 773 bytes from offset 0)
cannot reconstruct rpm from disk files
Some delta RPMs failed to download or rebuild. Retrying..
warning: /etc/bashrc created as /etc/bashrc.rpmnew
warning: /etc/profile created as /etc/profile.rpmnew
warning: /etc/shadow created as /etc/shadow.rpmnew
warning: /etc/nsswitch.conf created as /etc/nsswitch.conf.rpmnew
warning: /etc/sysctl.conf created as /etc/sysctl.conf.rpmnew
warning: /etc/cron.daily/logrotate created as /etc/cron.daily/logrotate.rpmnew
grubby fatal error: unable to find a suitable template
warning: /etc/yum/yum-cron.conf created as /etc/yum/yum-cron.conf.rpmnew
warning: /etc/named.conf created as /etc/named.conf.rpmnew
warning: /var/lib/logrotate.status saved as /var/lib/logrotate.status.rpmsave
2671 blocks
Maybe this is the reason yum did so much with all the packages and everything last night? Do you guys think it's related? It seems something weird was going on last night. I'd love to get to the bottom of this. Any suggestions? Thanks!
-
Was there any recent nfs related changes done in your server ? 0 -
Was there any recent nfs related changes done in your server ?
If there was, it wasn't done by me. BuycPanel.com had to log into my server to check some things, but I highly doubt they would have messed with anything not-related to the issue I was having (I had problems with Apache and error documents). I haven't installed any packages recently or anything. A few days ago, my server was done because of physical problems. The hosting provider contacted me. The physical problem was three days ago and they've resolved that. I couldn't see them installing anything or playing around with NFS. It's a real mystery. I'd like to add, when I went to look at the ticket from Linode (my hosting provider) about the physical hardware problem, I saw a date of 12-08-2016. When I went to migrate some of those rpmnew files in the /etc/ directory to the normal config files, I had to restart MariaDB. I ran systemctl status mysql. I noticed this in the output:Dec 08 18:09:28 franklin.mydomain.com mysqld[3930]: 2016-12-08 18:09:28 140288809585408 [ERROR] mysqld: Table './cphulkd/known_netblocks' is marked as crashed and should be repaired Dec 08 18:09:28 franklin.mydomain.com mysqld[3930]: 2016-12-08 18:09:28 140288809585408 [Warning] Checking table: './cphulkd/known_netblocks' Dec 08 18:09:40 franklin.mydomain.com mysqld[3930]: 2016-12-08 18:09:40 140288809282304 [ERROR] mysqld: Table './eximstats/smtp' is marked as crashed and should be repaired Dec 08 18:09:40 franklin.mydomain.com mysqld[3930]: 2016-12-08 18:09:40 140288809282304 [Warning] Checking table: './eximstats/smtp' Dec 08 18:09:40 franklin.mydomain.com mysqld[3930]: 2016-12-08 18:09:40 140288809282304 [ERROR] mysqld: Table './eximstats/sends' is marked as crashed and should be repaired Dec 08 18:09:40 franklin.mydomain.com mysqld[3930]: 2016-12-08 18:09:40 140288809282304 [Warning] Checking table: './eximstats/sends' Dec 08 18:09:40 franklin.mydomain.com mysqld[3930]: 2016-12-08 18:09:40 140288809282304 [ERROR] mysqld: Table './eximstats/failures' is marked as crashed and should be repaired Dec 08 18:09:40 franklin.mydomain.com mysqld[3930]: 2016-12-08 18:09:40 140288809282304 [Warning] Checking table: './eximstats/failures' Dec 08 18:27:13 franklin.mydomain.com mysqld[3930]: 2016-12-08 18:27:13 140288809282304 [ERROR] mysqld: Table './modsec/hits' is marked as crashed and should be repaired Dec 08 18:27:13 franklin.mydomain.com mysqld[3930]: 2016-12-08 18:27:13 140288809282304 [Warning] Checking table: './modsec/hits'
I than ran myisamchk -e on all of the MYI files, including the cphulkd, eximstats, and modsec ones. There were no errors. I'm wondering if that had something to do with the physical problems they had with my server. When I restarted MySQL, there were no errors.0 -
Also, I'd like to add something that might be of interest. I don't know a lot about RPC or rpcbind. I know a little though. Could this have something to do with the kernel? With Linode, I'm given the choice to use the kernel version that is provided with CentOS or a more recent kernel. I'm not certain how they boot the more recent kernel. It's not in the /boot directory. That contains the kernel version that's provided by CentOS. I'm using the Linode provided kernel. uname -a shows: Linux franklin.mydomain.com 4.8.6-x86_64-linode78 #1 SMP Tue Nov 1 14:51:21 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux
I don't think yum is smart enough to detect this (nor should it be). But I noticed one of the updates it tried installing:kernel x86_64 3.10.0-514.2.2.el7 updates 37 M
I believe that update failed to install. Personally, I don't think yum, on my system, should be trying to update the kernel at all, because I'm using Linode's kernel. Is there a chance though, that 3.10.0-514.2.2.el7 kernel might have something to do with rpcbind? Maybe the default configuration for the 3.10.0-514.2.2.el7 kernel has some NFS support enabled by default, whereas the Linode one might not? And maybe when yum knew the 3.10.0-512.2.2 kernel had NFS support, it knew I needed rpcbind? Do you think that's a possibility or no? Do you also think there's a current security risk, having rpcbind listen on all interfaces? Should I block that using iptables? Thanks for the help! This worries me a bit and I appreciate you taking the time to answer my questions.0 -
I guess at this point, I think I'd like to try removing rpcbind. Is there anything special I have to do or can I just use yum to install it? 0 -
Looking through /var/logs/yum.log, I see rpcbind was installed way before today. It just must not have been running. I know this because I specifically remember looking at the Linode server hardening document and they were talking about blocking unnecessary ports. They used rpc as an example and I thought it was odd that rpcbind wasn't showing under netstat. I ran: root@franklin:[/etc/cron.daily]# rpm -q --whatrequires rpcbind quota-4.01-14.el7.x86_64
So I see quota depends on rpcbind. I don't use quota though. Also, I see:root@franklin:[/etc/cron.daily]# rpm -q --whatrequires quota cpanel-perl-522-Quota-1.7.2-2.cp1156.x86_64 quota-devel-4.01-14.el7.x86_64
So, cPanel-perl-522-Quota depends on quota. How could I disable rpcbind without breaking anything? If I uninstall rpcbind, quota will break and so will cpanel-perl-522-Quota. I don't want to be breaking packages. I just find it odd that up until this time, rpcbind wasn't running. ConfigServer Firewall is going nuts with all the rpcbind stuff. That's another way I know it wasn't installed. I never got any emails before about rpcbind or the user rpc. Now I'm getting them non-stop. Any suggestions on the proper way to fix this? Ultimately, if I need rpcbind on my server, I'd rather have it not running at all, unless it's absolutely needed (ie, don't uninstall it, just disable it from starting as a deamon and let cpanel-perl-522-Quota start it if it ever needs to). Can I do that and if so, how? Just something like:systemctl disable rpcbind
Or maybe:chkconfig rpcbind off chkconfig rpcbind --del
?0 -
Hrmm, I disabled rpcbind, doesn't seem to have caused any issues. But I get a security advisor saying compilers are currently enabled for all users. How did that get reset I wonder? Hrmm. 0 -
Hello, The 'rpcbind' package is provided as part of the OS. The recent update from CentOS is normal, and I can confirm it also happened on a test system (CentOS 7): grep rpcbind /var/log/yum.log Sep 21 18:03:24 Installed: rpcbind-0.2.0-33.el7_2.1.x86_64 Dec 12 08:17:37 Updated: rpcbind-0.2.0-38.el7.x86_64
It's used for RPC services, so you can safely disable it if you prefer, as long as you don't plan to use NFS mounts. However, I don't see any harm in leaving it installed, especially with the quota dependency. Thank you.0 -
I was thinking maybe with CentOS 7, it's enabled with a default install, but perhaps the Linode CentOS 7 image has it disabled for one reason or another. Perhaps when it got updated, it reenabled itself?
This is possible, but you'd want to check with Linode or your provider to verify if that's the case. I'm moving your question about compiler access into a separate thread, and will send a response to it shortly. Thanks!0 -
Sorry to bring a dead thread back to life, but rpcbind got reenabled again. I seem to remember using Metasploit a long time ago and something with RPC and Windows. I was able to do stuff with RPC and gain access to the Windows machine, remotely. I believe RPC is Remote Procedure Call. I think I was able to use RPC to view running services on the Windows machine or something. It was so long ago (back in 2005). There's no known ways for someone to exploit rpcbind to gain information about my system that could be used in an attack? I am going to need quota's enabled soon. I'm wondering if there's away to have rpcbind listen to local interface only, and not provide access to the public. I don't (and won't) be using NFS anytime soon (if ever). 0 -
Hello @Spork Schivago, You likely noticed this due to the recent update to the package published by CentOS: Sep 13 13:35:45 Updated: rpcbind-0.2.0-42.el7.x86_64
The following third-party URL provides some information about the purpose of this package: Exactly what does rpcbind do? You could disable rpcbind and configure it not to start when the system boots. EX:systemctl stop rpcbind systemctl disable rpcbind
Thank you.0 -
Right, but are there any security implications for leaving it enabled? Does it increase the risk for someone getting into my system? For example, if I have some services running on my server that I don't want people to know about, if they're not particularly written to use RPC, rpcbind shouldn't provide any information on them, right? I remember seeing some recent news about rpcbind and an exploit called Rpcbomb. It crashes the host system running rpcbind, essentially. I see rpcbind is listening on the public interface. Should my firewall be blocking access to the port (111 udp I think)? Should it be listening on the local loopback address or something? I believe quota requires rpcbind, and because I want to implement quota's, I think I would need to keep it enabled. 0 -
Here's a third-party URL where this topic is discussed: Security risk of opening port 111 (rpcbind)? You'd want to block public access to port 111 at a minimum, however note this is more of a question that's better aimed towards a security-focused system administrator or directly on the CentOS forums. Thank you. 0 -
Thank you cPanelMichael. You're correct, I should have asked this question on some other type of forum. Not really related to the cPanel, except for the dependency part. cPanel's quota system still depends on RPCBind, right? And blocking public access to that port will not break quotas, right? 0 -
Hello, Blocking access to that port or disabling the rpcbind RPM will not break quotas (unless you plan to use a NFS mount). Note that it's your operating system's quota RPM that has rpcbind as a dependency. EX: ---> Package rpcbind.x86_64 0:0.2.0-38.el7_3.1 will be erased --> Processing Dependency: rpcbind for package: 1:quota-4.01-14.el7.x86_64
Thus, if you removed rpcbind through YUM, it would also remove the "quota" RPM which is required for existing cPanel RPMs. Thank you.0 -
Doh! I forgot Linux distros usually support some sort of quota system. For some reason, I was thinking the quota RPM was a cPanel package. Sorry for the misunderstanding! I'll make sure that port 111 is definitely blocked to the outside world (but I'll keep it enabled for the private interface) and I'll configure CSF to stop sending me reports about rpcbind. Thanks for all the help again. 0
Please sign in to leave a comment.
Comments
15 comments