![]() Or, is it something different in Mountain Lion? I thought it only looked at outgoing stuff. I don't recall this sort of behavior in Little Snitch before. Note that it is saying that screensharing is being "poked" to allow incoming, not outgoing. Shortly thereafter little snitch puts "terminated" over the pop-up and it goes away. ![]() I too get little snitch pop-ups saying that screensharingd.bundle wants to accept incoming connections from (insert random IP#).on port #. I also recently upgraded to Mountain Lion. Same Problem and I have the exact same issue after installing the newest Little Snitch. Most likely it will also involve changing all password on the AD or LDAP as well. Other option would be to use a socks proxy or vpn to gain access to the network and bypass the ACLs on the router, this would show up on the logs though as coming from that IP address that is compromised and not the external address.Įither case, the best option is to say, take all relevant log files for forensics and a legal team, and start with a fresh slate. I'm not saying it's impossible since they could of had root access before the upgrade, but it would take either a dedicated person, or an inside job to rewrite the binaries to accomplish the task. Thus in order to do this, they would have to have complete root access since you've upgraded to ML, since looking at my files all have been modified since upgrading to ML. There are some exceptions, such as an echoserver, but it would require a total rewrite of the binaries involved. Screensharingd is a service, ie it can't normally initiate a connection. This could be from an upgrade from Lion that you just didn't notice, so you might have to do some forensics on the logs. If it's closed, then test every port open to find out how they are getting to the screensharingd service, and put in some blocks while you reinstall ML. If vnc is open on a known blacklisted IP, then you've found an issue. My first suggestion would be simply run nmap right now on a off-network computer, and find the available ports open on the router. The odds of someone random doing this is pretty slim, and would break other things like Apache so you would probably notice. I'm not super familiar with Untangle, but know it's a linux distro with a GUI that pretty well used. IE they would have to guess your ACLs that allowed public access to the server, so for example modify screensharingd to use both. Unless they replaced the screensharingd service, plist, etc, it shouldn't get through the untangle box unless specified by the ACLs listed on the router. System/Library/CoreServices/RemoteManagement/screensharingd.bundle/Contents/MacOS/screensharingd Looking at the plist, it might just be changing the port listed. ![]() System/Library/CoreServices/Screen Sharing.app/Contents/MacOS/Screen Sharing Since the daemon is calling the connection, I would think this would be inbound traffic, instead of the client: Either case, this should be blocked by the firewall since you've limited down to certain IPs? I'm not sure if it's Active or Passive sockets, in that both connections send/recieve on that single port 5900 or the return port varies on screensharingd selecting an upper level port. You know the program causing the traffic: screensharingd.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |