Page 1 of 1

Logging outgoing connections on a port?

Posted: 01 May 2015, 17:47
by droona
Hello,

We have CSF and Cpanel and have been using it with good results for years now.

We have a new issue our datacenter is giving us a hard time about (and we understand it). We have a CMS installation that is attempting to exploit remote wordpress installs by brute forcing. The offended servers are complaining to our datacenter (understandably so) and of course our datacenter wants this to stop.

We have CXS Exploit Scanner, and we delete basically PHP files and other exploits through uploads. We also delete ClamAv hits and fingerprint hits through FTP. Additional to that, we have nightly /home scans that detect and delete additional stuff.

But for some reason we are not able to find the script that is causing this. And because it is an outgoing connection, there are no apache logs or anything else that can point us through the right direction.

We have blocked port 80 outgoing temporarily to look for TCP_OUT Blocked messages in /var/log/messages and attempt to find the culprit. But it would be much easier if the port could be open and just the connections logged. So when we get the complaint from our datacenter, we just scan the logs for the offended IP, and through the UID we found the offending user and at least narrow this down.

Is this possible at all? To "simulate" a block but the port be really open?

Re: Logging outgoing connections on a port?

Posted: 01 May 2015, 18:19
by droona
I just want to post the solution I found myself after some digging on google.

So basically CSF Firewall offers the chance for custom IPTABLES command pre or post a restart.

So I added a file called csfpost.sh in /etc/csf with the following:

iptables -I OUTPUT -p tcp --dport 80 -j LOG --log-uid --log-prefix "Firewall OUT80: "

and it worked! So now the outbound port 80 is open, but every request is being logged. I just need to wait for the hacker to try to exploit another wordpress, my datacenter will complain, and as we keep 30 days of logs we should be able to find the culprit UID.

Additionaly, once you do so, you can block individual UID in csf.deny by adding:

tcp|out|d=80||u=X

Where X is the UID of the user is sending the attacks