Today's fun was dealing with a VPN client from Japan called
Softether PacketiX VPN. It's a free VPN package out of Japan that's won some awards and had someting like 3 million downloads in its first week of availability.
The client works fine and the VPN is fine, however while its not connected or in use I get alert emails from one of the firewalls telling me the internal IP of the VPN client is making http requests to some unknown server. Then I get a barrage of some 70 alert Emails from the firewall about the address 130.158.6.56 doing port scans on an internal firewall... What the?
So, I jumped onto Splunk to see what the different logs were saying. I do a search for 130.158.6.56 and find that my internal VPN client, which isn't connected to any session, is keeping a heartbeat with this IP.
Jan 3 15:09:00 (edge FW IP) id=firewall sn=xxxxxxxxxxx time="2012-01-03 15:08:34" fw=(Public IP) pri=6 c=1024 m=537 msg="Connection Opened" n=0 usr="admin" src=(internal FW IP):59474:X0 dst=130.158.6.56:80:X1 proto=tcp/http sent=144
Okay, I did some Googling to see what the IP was. Then I ran netstat on the client. You might have assumed it's the developers site and your right, keepalive.softether.com. This is an odd one. So, it's a keepalive for the VPN? Shouldn't that be handled by the VPN server?
At any rate, PacketiX is big in Japan and other East Asian countries, but interest is minimal in N. America. Thus, English documentation is close to nil. I added a firewall rule to drop all packets from the 130.158.6.56 IP and went back to digging through the PacketiX client.
First things first, kill the idle VPN application and disable the virtual Nic. Then run netstat after a few moments. Odd, it's stilll there. So, I ran netstat again with the -bn options to see the process that started the connection. It's listed the antivirus as the executable process. Okay.
Next step is to kill the tcp connection. I opened up
CurrPorts to kill off the TCP connection. No dice, Chicago. Doh, I closed all
incoming connections from 130.158.6.56. I effectivly killed off 1/2 of the TCP handshake making it so SYN packets would never get a responce from the server named keepalive.
Ok, pull up
Process Explorer and have a look - see for Softether or PacketiX. Sure enough, there was an active service in addition to the client software and the virtual Nic.
Ok, stop the service and make sure it's going to only be started manually from now on.
Check netstat again and the TCP connection is gone. Nice. Back over to the firewall and allow connections from 130.158.6.56 again. I watched the logs for a bit longer, but no further traffic came through with the volume of garbage that PacketiX was.
In my search, I did manage to find
this document by one James T. Yu, Ph.D. covering the basics of Softether and stating it is known to have "traffic difficult to detect and filter by the firewall [4]. As a result, SoftEther is considered a pest by many pest control tools." I'll agree. A good tool, but certianly a pest.