portsentry possibly causing false-positives in rkhunter

S

sidetone

I installed security/rkhunter with security/nmap support, and it kept showing TCP ports 1524, 6667, and 31337 as possible ports where a rootkit could have interacted. Running sockstat showed security/portsentry interacting with those ports on a freshly installed system. No known rootkits were detected, but It seems like portsentry triggered a false positive on those tcp ports interactions. Any opinions about dismissing what seems to be likely false-positives. I realize that hidden malware would like someone to dismiss it or be undetected.
 
You can't tell apart a legitimate service listening on a TCP port from a malware just by looking if there is something listening on a port, there have to be more specific tests done on the listening process to figure out if it is indeed malware.
 
This is funny. I checked the logs, and it showed 3 potential ports where there could be backdoor interaction. I later checked it, and these warnings were gone from the logs. Ran portsentry again, and sockstat -4 showed the interaction with portsentry. It could be crontab replacing the logfile, but all the logs should be there and not be replaced. I'm suspicious about rkhunter compiled with security/nmap.

I also firewalled the ports on a state setting (so it can receive the those 3 connections only if my computer started the interaction), and the logs showed warnings that later disappeared. Of course portsentry started the interaction. This is if I set up my computer the way I think I did.
 
Last edited:
sockstat -4 shows many ports activated by security/portsentry, but these do not trigger security/rkhunter. The strange warnings show up when security/nmap is compiled in.

I need to look at this again with the firewall loaded before the network in rc.conf, and see if the three strange ports still interact. Which if they did, they did it is the small amount of time in the initialization scripts.

rkhunter also showed other problems like /usr/.sujournal possibly being malicious. I used chflags 0 .sujournal in order to remove it with the rm command. I can't remember if I had this file installed by some configuring. The computer wouldn't mount the filesystem without it. By looking it up, it says it's for soft updates.

I'll also test these settings again.

Another odd problem is about ssh, and rkhunter. rkhunter shows Protocol 1 as a problem and to be enabled. I have ssh_config and sshd_config Protocol 2 enabled but Protocol 1 disabled according to:

Code: 
Protocol 2
# Protocol 1 #commented out
I'll start a new thread about ssh questions.
 
Last edited:
I might have installed Kerberos, and forgot about it, that might explain why it had /usr/.sujournal. I didn't get back to testing another installation of it. It is still highly suspect that even if my firewall was loaded after the network in rc.conf, it still should have blocked connections to these three odd ports, considering it loads in the small amount of time of the boot process. That suggests to my understanding, that something is happening that's not supposed to.

It's odd, because security/portsentry is showing on connections, but it's not triggering positives. It is as if security/rkhunter is warning me of a problem that is caused by it's dependency (security/nmap). It causes me problems, but it's too far fetched to be nmap.

SirDice said:
It won't hurt but there's no need for it, sshd(8) uses protocol version 2 (and only version 2) by default.
Click to expand...

SSH continued here... Thread questions-about-ssh.54536
 
Last edited:
I forgot to update this. It didn't matter if the firewall settings were loaded before the network settings in /etc/rc.conf (which shouldn't matter anyway). Still, these network ports would show, the firewall rules completely blocking these three ports were ignored, and the logs would soon disappear. I don't know why I haven't heard of anyone else finding suspicion in security/rkhunter warning about a potential problem with it's dependency security/nmap. It's either doing something it's supposed to do and creating a false positive without documentation of why it's doing it, or the problem is in a zero day bug.
 
It doesn't appear to be nmap. I've tried rkhunter, and found no potential security risks and backdoors. After installing portsentry, rkhunter shows possible backdoor rootkit interactions on TCP ports 1524, 6667, and 31337. Possibly a false positive, and portsentry rotates logs? But that wouldn't explain how these showed after my firewall completely blocked the three tcp ports. sockstat -46 shows them all to be portsentry. This time, ssh is not in my base system, so there are no warnings about that. I think nmap caused the warning about ssh, but I don't plan on investigating nmap at the moment.

From /usr/local/etc/portsentry.conf, I removed 1524, 6667, and 31337, and these network ports stopped showing up in rkhunter, and sockstat -46. Still not sure why other uncommented network ports from portsentry.conf don't show up, like these do, and why these network ports get past the firewall unless it's only working on the bypassed lo0 interface.
 
I'm not sure but it's possible rkhunter simply looks for listening ports. Even if they're firewalled they'd still be listening. These ports are well known backdoor ports.
 
You must log in or register to reply here.
Back
Top