Results 1 to 6 of 6

Thread: neoiface, akamai, and svchost trying to act as service at 192.168.0.1:1900

  1. #1
    psyncho Guest

    Default neoiface, akamai, and svchost trying to act as service at 192.168.0.1:1900

    Hi,

    I recently got a window popup saying svchost was trying to act as a service at 192.168.0.1:1900

    The first thing I thought odd was that my subnet is actually 192.168.0.X

    I did a netstat to try and find more detail and got:

    Active Connections

    Proto Local Address Foreign Address State PID
    TCP golem:1285 a96-17-168-33.deploy.akamaitechnologies.com:http TIME_WAIT 0


    These two items, I think, are unrelated. No process information was listed for the akamai connection.

    Does anyone have any ideas of what's going on or what step to do next to look further? I'm incredibly curious as to what service my machine may be running that's connecting to akamai. By default I try to run nothing that makes outgoing connections really, except ZA (and its updating).

    O.k., I just did another netstat real quick and it's gone.

    Regards,
    John

    Operating System:Windows XP Pro
    Software Version:8.0
    Product Name:ZoneAlarm Internet Security Suite

  2. #2
    Join Date
    Dec 2005
    Posts
    9,056

    Default Re: neoiface, akamai, and svchost trying to act as service at 192.168.0.1:1900

    <blockquote><hr>psyncho wrote:
    Hi,

    I recently got a window popup saying svchost was trying to act as a service at 192.168.0.1:1900

    The first thing I thought odd was that my subnet is actually 192.168.0.X

    I did a netstat to try and find more detail and got:

    Active Connections

    Proto Local Address Foreign Address State PID
    TCP golem:1285 a96-17-168-33.deploy.akamaitechnologies.com:http TIME_WAIT 0


    These two items, I think, are unrelated. No process information was listed for the akamai connection.

    Does anyone have any ideas of what's going on or what step to do next to look further? I'm incredibly curious as to what service my machine may be running that's connecting to akamai. By default I try to run nothing that makes outgoing connections really, except ZA (and its updating).

    O.k., I just did another netstat real quick and it's gone.

    Regards,
    John

    Operating System:
    Windows XP Pro
    Software Version:
    8.0
    Product Name:
    ZoneAlarm Internet Security Suite

    <hr></blockquote>


    Ok there are two seperate and unrelated incidents.

    192.168.0.1:1900 is you own lan and not the internet, and the port 1900 is used for UPnP.
    More than likely the router has UPnP enabled and the computer is responding the UPnP connection attempts.

    1285 a96-17-168-33.deploy.akamaitechnologies.com is akamai and is internet.

    See http://www.ip-db.com/96.17.168.33

    Akamai technologies is a cached virtual server for many vendors and companies - Microsoft, ZA/ZL, checkpoint, symantec, mcafee, etc use akamai for extending their own servers for online information and as update servers.Probably something was checking for an update or doing an update and connected to the akamai server.

    The two events are unrelated.
    Kind of wondering how the neoiface fits into the post from the title.

    Netstat -anob shows the program/files not just the PIDs.

    Your ZA logs have recorded the previous connection attempts - ln the Log viewer, the information is there to be seen and perused. Details are there to be studied.

    Oldsod.

    EDIT:

    'Time wait' specified the connection had been established or attempted (and not succesful) and the connection is simply waiting to 'time out' and then it will stop or cease completely.
    '0' indicates the PID which is usually 'system' but your results in the task manager may vary.
    'System' is a generic term to cover the actual windows and usually is related to various .dlls used/owned by windows - even the windows update .dll's could be involved.

    Oldsod.

    Message Edited by Oldsod on 05-13-2009 12:19 PM
    Best regards.
    oldsod

  3. #3
    psyncho Guest

    Default Re: neoiface, akamai, and svchost trying to act as service at 192.168.0.1:1900

    This all makes sense.

    I actually mistyped - my subnet is 192.168.1.X - but I have cascading routers, a hack to do subnetting. I knew it looked like it was from the other lan but I'm used to apps spoofing IPs. It makes sense though that it's probably just the other router UPnP and I hadn't noticed it before.

    I'm familiar with Akamai - but couldn't figure out what was making the connection. I used netstat -bv to print process names and be verbose but what I posted is all I got, so I couldn't figure out exactly what was making the connection. Could zonealarm updating itself trigger such a connection? The only other thing I noticed was microsoft updates - which I assume could also be the culprit.

    I've gone over the ZA logs - the akamai connection didn't show up at all and I wasn't alerted, just something that showed up on netstat. I used netstat to try and figure out why svchost
    kept tryhing to act as a service - it did with a number of IPs and ports. One of the combinations I looked up said it was for neoiface. I tried to find more information but web searches only turn up port listings - no additional info that I could find. I'm just curious at this point as to what it is.

    I think the other svchost I've seen is for default dcom services, which I have to figure out what I'm going to do about.

    Regards,
    John

  4. #4
    Join Date
    Dec 2005
    Posts
    9,056

    Default Re: neoiface, akamai, and svchost trying to act as service at 192.168.0.1:1900


    <blockquote><hr>psyncho wrote:
    This all makes sense.

    I actually mistyped - my subnet is 192.168.1.X - but I have cascading routers, a hack to do subnetting. I knew it looked like it was from the other lan but I'm used to apps spoofing IPs. It makes sense though that it's probably just the other router UPnP and I hadn't noticed it before.

    I'm familiar with Akamai - but couldn't figure out what was making the connection. I used netstat -bv to print process names and be verbose but what I posted is all I got, so I couldn't figure out exactly what was making the connection. Could zonealarm updating itself trigger such a connection? The only other thing I noticed was microsoft updates - which I assume could also be the culprit.

    I've gone over the ZA logs - the akamai connection didn't show up at all and I wasn't alerted, just something that showed up on netstat. I used netstat to try and figure out why svchost
    kept tryhing to act as a service - it did with a number of IPs and ports. One of the combinations I looked up said it was for neoiface. I tried to find more information but web searches only turn up port listings - no additional info that I could find. I'm just curious at this point as to what it is.

    I think the other svchost I've seen is for default dcom services, which I have to figure out what I'm going to do about.

    Regards,
    John
    <hr></blockquote>


    More than likely a program already allowed access has made this connection, thus maybe this is why there was no alert by the ZA.
    To ensure all possible alerts are projected by the ZA, the ZA Alerts must be properly set to High for the Alert Events Shown section of the Main of the Alerts and Logs.

    To ensure all logging is performed, set the Log Events to On and then customize the logging and events in the 'Advanced' of the 'Main' of the Alerts and Logs section of the ZA.

    The ZA Help has a good description of this customizing feature - open the ZA and press the [F1] key and look under the 'Alerts and Logs' in the Content lisiting.

    The actual akamai connection may not appear as the connection could have been to the correct update server which then referred it immediately instead to the akamia server. But strictly speaking the akamai connection should have been seen by the ZA and logged as such.

    "kept tryhing to act as a service - it did with a number of IPs and ports. One of the combinations I looked up said it was for neoiface. I tried to find more information but web searches only turn up port listings - no additional info that I could find. I'm just curious at this point as to what it is."

    Act as a service or server?
    There is a big difference.
    Please say which one.
    'neoiface' is a local port and not the remote port (where previously it was stated it was http or port 80 that was involved for the remote port) - checking the local ports for the outgoing is futile as the entire port range of 1020-5000 will be used for all outgoing TCP connections to the remote ports of the internet.
    I seriously doubt there were many server ports but probably it was just local ports being used for the outgoing connection to the remote port 80.
    Also in the list of the seen IPs, it would not be unusual to see 'server' used for the loopback address (127.0.0.1) and the zero octet address (0.0.0.0) - both are considered safe as these are just internal addresses of window itself and are not related to any internet addresses or IPs.

    Oldsod.
    Best regards.
    oldsod

  5. #5
    psyncho Guest

    Default Re: neoiface, akamai, and svchost trying to act as service at 192.168.0.1:1900

    Thanks for the pointers.

    Logging was enabled. I have Alert Events Shown on medium, but all alerts are still logged, correct?

    ZA would only log the Akamai connection if it triggered an alert, correct? So if ZA itself was making the connection, or a program that had been &quot;allowed&quot; was making the connection, then it wouldn't generate an alert and this it would not be logged, correct?

    Would ZA have access to any more information than netstat? Most of my ZA logs don't provide info on the applications making connections or most are typically masked as svchost.

    I do get the alerts for svchost operating as a server on 0.0.0.0 and figure it's just the dcom stuff.

    However, I also get the same alert on other ports. I don't have the exact text, but the alert specifically said svchost was trying to listen for incoming connections on port 1285, which I looked up and is associated with neoiface. My guess is some application was trying to act as a server and picked any random port - but I was trying to get more info on neoiface, and I can't seem to find any. Do you have any idea what it is?

    I'll try and catch more info on my next restart.

    Regards,
    John

  6. #6
    Join Date
    Dec 2005
    Posts
    9,056

    Default Re: neoiface, akamai, and svchost trying to act as service at 192.168.0.1:1900


    <blockquote><hr>psyncho wrote:
    Thanks for the pointers.

    Logging was enabled. I have Alert Events Shown on medium, but all alerts are still logged, correct?

    ZA would only log the Akamai connection if it triggered an alert, correct? So if ZA itself was making the connection, or a program that had been "allowed" was making the connection, then it wouldn't generate an alert and this it would not be logged, correct?

    Would ZA have access to any more information than netstat? Most of my ZA logs don't provide info on the applications making connections or most are typically masked as svchost.

    I do get the alerts for svchost operating as a server on 0.0.0.0 and figure it's just the dcom stuff.

    However, I also get the same alert on other ports. I don't have the exact text, but the alert specifically said svchost was trying to listen for incoming connections on port 1285, which I looked up and is associated with neoiface. My guess is some application was trying to act as a server and picked any random port - but I was trying to get more info on neoiface, and I can't seem to find any. Do you have any idea what it is?

    I'll try and catch more info on my next restart.

    Regards,
    John
    <hr></blockquote>


    Alerts Events Shown at medium only shows the high rated alerts and yes should be logged.

    Both the networking event logging and the alerts logging can be further customized in the 'Advanced' button of the 'Main' of the 'Alerts and Logs' section of the ZA.


    The ZA should be logging all networking connections regardless if there was an alert or no alert.

    The involved programs) should be seen in the Log viewer - check both Firewall and Program logs in the Log viewer and set the number for the events higher than the default setting (select something like 500) and even increasing the number of days before archiving the firewall logs will help to read the past connections with the involved program in the Log viewer.

    If most of the program listed are just svchost, then usually the port, protocol and IP listed in the log is the better way to determine the actual events.

    Unfortunately there is no netstat viewer built in the ZA, and many get by with just the netstat command.
    There is a special GUI for the netstat to show real time and save as a log (or easier as the netstat.exe in the command can be saved too as a log).....see TCPView.....free from microsoft.
    Also Process Explorer which does include details of the then active connections (buried in the details of the Properties of the file(s) in question).

    Often the Tasklist command can be helpful to look at the involved svchost services in the Windows XP Pro editions.

    0.0.0.0 is another internal address for windows.
    0.0.0.0 is similar to the 127.0.0.1 but no internet connections are possible from the 0.0.0.0 address whereas the 127.0.0.1 can connect directly to the correct assigned IP of the windows and then obtain internet access- only windows's internal connections and initial dhcp broadcast, initial arp connections and dhcp gateway connections are possible with the 0.0.0.0 address.
    Often the epmap (135) and the netbios (137-139) and the microsoft-ds (445) ports will be used with the 0.0.0.0 address by the svchost.exe, depending on how the windows services and daemons are arranged or enabled in your windows.
    But so will many other uninportant ports be involved along with the usual bootpc(68) and bootps(67) ports and of course the dns (53) port.


    "but the alert specifically said svchost was trying to listen for incoming connections on port 1285, which I looked up and is associated with neoiface"

    Listening is normal and very acceptable and this in no way implies there is an open port involved.
    It simply means the svchost.exe is acrive and most likely the port was selected randomly - I doubt you have the neoiface software installed and in use and besides, the svchost.exe would not be involved with the neoiface software program or it's external port use (which would either be the receiving port from another server to the neoiface or outgoing from the port 1285 to another neoiface server).
    Just another normal svchost connection and the listening is normal when the svchost is active for that particular service the svchost is managing at that time.
    By no means is this a server attempt to the internet - especially true if the listening port was to the 127.0.0.1 or 0.0.0.0 addresses.

    Listening does not equate into a server.

    Plus if the svchost did make any external or internet tcp connections, it would have used any random port starting from 1020 to 5000 and any connections made or failed would have the svchost still in a 'listening' state as it would have to be still there to wait for the return tcp/ip connections from the internet web site. Often the connection is waiting to be next set to be timed out (and then it is 'closed' or properly understood as 'dropped') and it will close all by itself is there is no returned responces.
    Plus this would still not constitute a 'server' or an open port, but just a listening state which is a 'closed' port or just simple 'access' (by za terms).

    Oldsod.


    Oldsod.
    Best regards.
    oldsod

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •