Greetings -
In my logwatch report this morning I noticed reference to an attempt to connect to rsync from an external IP address. It doesn't appear that the connection was successful based on correlating information between /var/log/secure and /var/log/messages. But I am looking for some suggestions for implementing more preventative measures, if necessary. The log information from the last few attempts are shown below.
/var/log/secure Oct 13 00:14:08 Bison xinetd[2232]: START: rsync pid=15306 from=180.97.106.36 Oct 13 01:55:51 Bison xinetd[2232]: START: rsync pid=15343 from=85.25.43.94 Oct 13 23:25:35 Bison xinetd[2232]: START: rsync pid=16548 from=114.119.37.86
/var/log/messages Oct 13 00:14:08 Bison rsyncd[15306]: rsync: unable to open configuration file "/etc/rsyncd.conf": No such file or directory (2) Oct 13 00:14:08 Bison rsyncd[15306]: rsync error: syntax or usage error (code 1) at clientserver.c(923) [receiver=3.0.5] Oct 13 01:55:51 Bison rsyncd[15343]: rsync: unable to open configuration file "/etc/rsyncd.conf": No such file or directory (2) Oct 13 01:55:51 Bison rsyncd[15343]: rsync error: syntax or usage error (code 1) at clientserver.c(923) [receiver=3.0.5] Oct 13 23:25:35 Bison rsyncd[16548]: rsync: unable to open configuration file "/etc/rsyncd.conf": No such file or directory (2) Oct 13 23:25:35 Bison rsyncd[16548]: rsync error: syntax or usage error (code 1) at clientserver.c(923) [receiver=3.0.5]
There is no /etc/rsyncd.conf file present on the system, so I can see why the connection wasn't successful. Our backups get pushed to this one from other servers using rsync.
This is on a RHEL 3.9 box (Dell PE2600, year 2004) that is primarily used as backup storage within our LAN. I will retire it when it dies, until then it runs fairly maintenance free. I do have a public IP address assigned to the WAN because we have a vsftp server running on it for transferring files back and forth to a few clients, and I occasionally access the server remotely. I am wondering if there is anything relatively simple that I can do to address these attempted connections, until I have time to move our vsftp server from it and remove the public IP address from the WAN? Thanks.
Jeff
Jeff Boyce писал 2015-10-14 21:13:
Greetings -
In my logwatch report this morning I noticed reference to an attempt to connect to rsync from an external IP address. It doesn't appear that the connection was successful based on correlating information between /var/log/secure and /var/log/messages. But I am looking for some suggestions for implementing more preventative measures, if necessary. The log information from the last few attempts are shown below.
/var/log/secure Oct 13 00:14:08 Bison xinetd[2232]: START: rsync pid=15306 from=180.97.106.36 Oct 13 01:55:51 Bison xinetd[2232]: START: rsync pid=15343 from=85.25.43.94 Oct 13 23:25:35 Bison xinetd[2232]: START: rsync pid=16548 from=114.119.37.86
/var/log/messages Oct 13 00:14:08 Bison rsyncd[15306]: rsync: unable to open configuration file "/etc/rsyncd.conf": No such file or directory (2) Oct 13 00:14:08 Bison rsyncd[15306]: rsync error: syntax or usage error (code 1) at clientserver.c(923) [receiver=3.0.5] Oct 13 01:55:51 Bison rsyncd[15343]: rsync: unable to open configuration file "/etc/rsyncd.conf": No such file or directory (2) Oct 13 01:55:51 Bison rsyncd[15343]: rsync error: syntax or usage error (code 1) at clientserver.c(923) [receiver=3.0.5] Oct 13 23:25:35 Bison rsyncd[16548]: rsync: unable to open configuration file "/etc/rsyncd.conf": No such file or directory (2) Oct 13 23:25:35 Bison rsyncd[16548]: rsync error: syntax or usage error (code 1) at clientserver.c(923) [receiver=3.0.5]
There is no /etc/rsyncd.conf file present on the system, so I can see why the connection wasn't successful. Our backups get pushed to this one from other servers using rsync.
You can block access to tcp/udp port 873 from external addresses. You probably don't need rsync server either and can just disable it.
2015-10-14 20:13 GMT+02:00 Jeff Boyce jboyce@meridianenv.com:
There is no /etc/rsyncd.conf file present on the system, so I can see why the connection wasn't successful. Our backups get pushed to this one from other servers using rsync.
Why do you have rsyncd enabled if you don't have rsyncd.conf ? If your pusing backups using rsync over ssh, you don't need rsynd.
-- Laurent.
On 10/14/2015 01:13 PM, Jeff Boyce wrote:
This is on a RHEL 3.9 box (Dell PE2600, year 2004) that is primarily used as backup storage within our LAN.
You have a RHEL 3.9 box exposed to the Internet?
<shudder/>
On 10/14/2015 11:13 AM, Jeff Boyce wrote:
This is on a RHEL 3.9 box (Dell PE2600, year 2004) that is primarily used as backup storage within our LAN. I will retire it when it dies, until then it runs fairly maintenance free. I do have a public IP address assigned to the WAN because we have a vsftp server running on it for transferring files back and forth to a few clients, and I occasionally access the server remotely. I am wondering if there is anything relatively simple that I can do to address these attempted connections, until I have time to move our vsftp server from it and remove the public IP address from the WAN? Thanks.
block all ports except what you need at your firewall.
suggestion, retire FTP, and use something like OwnCloud for customer file transfers, this is a dropbox style web based file service.
-
Ian Pilcher -
Jeff Boyce -
John R Pierce -
Laurent CREPET -
Александр Кириллов