Protecting NFS mounts against Windows viruses

For the past two weeks, I've been seeing a new variation of the brute force password attack: instead of sending hundreds of inane attempts per second from the same IP, they now send an inane attempt every few minutes, each from a different IP address. Their software seems to be too stupid to know they're all blocked.

It has no more chance of success than the old way, but it's still annoying because it clogs up my logs. I still prefer the hosts.deny method over iptables for its simplicity, but in my enthusiasm for blocking I accidentally blocked the 127 network. So when I ran an NFS mount, I got the following bogus error message:

# mount 192.168.xxx.xxx:/volume1/backup /backup2
mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
mount.nfs: an incorrect mount option was specified


The real error showed up in the logs:

Jul 27 06:00:06 oxygen rpcbind: connect from 127.0.0.1 to getport/addr(status): request from unauthorized host

But it gave me an idea about an easy way to prevent a Windows ransomware from ruining your backups. Normally, of course, you'd keep your backup device unmounted for protection and mount it only when backing up. But what if you put sentinel files in your home directory and set your backup script to check their MD5 checksum before mounting the backup disk? Your system would be unable to mount the backup in the event your server gets ransomwared, and your backups would remain intact.

Of course, a better solution is to block Windows machines from having write access, but that's not always practical.

Another annoyance is the practice of blocking all outbound connections on every port except 80 and 443. The effect of this is to force everything onto those two ports. Result: when something's going out, you have no idea what it is. It makes life tougher for those of us who run sshd to log in from a remote system, and it makes life so much easier for attackers: they know in advance that you can only keep two ports open, so they no longer need to port scan.

Another example of the Law of Inexorable Screwing-Up of Communications Media.