Ever had one of these?
Too many long nights and early mornings were partially to blame for the precipitation of a sense of panic that ensued when the following was seen in ISA's live query:
ISA: Unidentified IP Protocol: Source Port 1175, Destination Port 5571
So, a quick search for the destination port of 5571 turns up: Trojan "Lamer Variant".
The next step was to figure out what the program/service was and where it was.
The inital PortQry using the GUI version turned up (unknown service) for the sending port of 1175. That was not too encouraging.
SysInternals' Process Explorer was also turning up nothing out of the ordinary.
The next step was to run the
SysInternals Rootkit Revealer. After 45 minutes of scanning - this particular server has huge arrays - nothing out of the ordinary seemed to be there. The scan kept on going with nothing to show for it.
The Symantec A/V on the server was up to date and running with no indications of any interference.
By now, the panic has set in, and the thoughts swirling around were along the lines of, "Mr. Client, we need to perform a Swing Migration in the next 5 minutes." Not really a bad thing given they have a secondary AD server that also has the arrays mirrored. Or is it? With the possibility of rootkit infection, we may be pulling
just the data from backups.
Mr. Client's reaction would probably not be too happy. :(
So, as a final effort before having to consider the above meeting, a full port analysis was needed - just in case.
In the command line
PortQryV2 directory the following was done:
- portqry -local -l serverlog.txt [Enter]
This command runs a full query of absolutely everything on the local machine that is related to ports and services on those ports.
After the serverlog.txt file was created, we opened it in NotePad, and did a find for 1175 to see if anything came up and low and behold:
Process ID: 2476 (javaw.exe) on UDP Port 1175
Bingo. Open the Task Manager and shutdown the javaw.exe service, and the UDP errors in ISA disappeared.
Java is required for the Intel Management software that runs on the server. We had updated it during the last update run last week on that particular SBS box. So, something has changed in the program.
The
DNSStuff.com report for the IP:
Reverse DNS for 229.111.112.12
Details:
strul.stupi.se. (an authoritative nameserver for 229.in-addr.arpa., which is in charge of the reverse DNS for 229.111.112.12)
says that there are no PTR records for 229.111.112.12.
A Whois for the mentioned .se server turned up Switzerland with no details. Not sure what Java is up to there.
For now, we will leave Java running, but not allow the UDP communication to pass through ISA to that 229 IP. We may even place a full ISA application restriction against it just in case.
After all of that, a huge sigh of relief and a little Irish kick! We got to smile and say, "Good day" to Mr. Client on our way out. ;)
UPDATE 2007-10-12: One thing that wasn't considered was searching for the actual IP listed. It seems that the IP is drawing people to the blog via search.
A question on Experts Exchange: Possible Hacker 229.111.112.12 mentions that the IP address may be an internal "Multicast" IP for the 229/8 range.
It would possibly explain why the Destination Network in ISA was Internal and the Source was the Local Host. It would also explain why there were no rDNS PTR records for the IP.
From the Internet Assigned Numbers Authority we have the following document: Internet Protocol V4 Address Space that indicates:
229/8 Sep 81 IANA - Multicast
Personally, this is not one of my strong points. So, please feel free to comment on whether this is the right direction or are we barking up the wrong tree?
Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
*All
Mac on SBS posts are posted on our in-house iMac via the Safari Web browser.