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