In talking with Sybergen, some other potential problems have come to light. Jeff Alerta talked about the fact he was able to connect to the Sygate Management Console (port 7323) from outside of the internal network, something which was not supposed to be possible. The installation process for Sygate uses inverse DNS queries (gethostbyaddr) to determine which interface is the "trusted" network, and which is to the "internet". It sends out a lookup request and whichever NIC in the Sygate box returns the response is deemed to be the "internet". Ergo, the other NIC is the "trusted" network. If you don't host your own DNS server, this method probably returns the desired results. If you do host your own DNS server, then the response is quite possibly going to come from your internal NIC. The result will be that your internal network will be deemed the "internet", and the internet deemed your "trusted" network...;-[ Given that the product is targeted at home office users, they could probably argue that most of their customer's installations are done correctly. Infosec folks who might be evaluating the product are likely to find different results in a test environment where an existing network connection to the internet could fool the Sygate box as described above. Of course once its made this determination it is possible to change it (kinda scary in and of itself), although its not terribly easy to do so. Its also not obvious to a new user that you might have to do this, although once you start setting up restrictions/permissions you'll likely quickly notice that none of your internal users are able to get to much. I believe, however, that it would be possible for you to completely configure this thing to permit your internal users to do what you thought they should, despite leaving the internet as the "trusted" network. As far as I can tell, only this Remote Management service is exposed if Sygate is misconfigured as above (of course why would you need anything else...;-]). As Jeff noted, if the "Enhanced Security" option is enabled, then the Remote Management service relies on access from 127.0.0.1 to determine if you can do anything with the listening port. With this option disabled, access is still restricted to packets received over the "trusted" NIC (so if misconfigured, access is granted to anyone on the Internet and denied to your local network). As far as this one-time per reboot issue, apparently build 560 would allow a single connection to the Remote Management program and then, upon that client exiting, it would shut down the service (the management service, not the gateway). Build 562 apparently corrects this (presumably not shutting down after client termination). Cheers, Russ - NTBugtraq Editor
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:32:51 PDT