Access.TXT Config file

Is there any chance of changing the way this operates?
With broadband and WiFi you can now get excellent control of Homegate if you are away from your house
I do it all the time from work
But this only works when you can Control your IP address
Something not possible when using the remote Homegate from a WiFi Hotspot
I fully understand the reason it is there is security but it would be really useful either to add an IP address without a reboot of cgate or just turn it off
Thanks
Mike

 

The access.txt file is actually more powerful than our current client applications make use of because only 0.000001% of users need the extra power. However, after saying that it is something I would like to add for completeness in the future.

To explain what I mean by that, restricting connections based on the clients IP address is only one of the ways that C-gate uses to authenticate connections. C-gate actually supports a Username/Password model as well, in which case the clients IP address is not important. Unfortunately as I mentioned before, we currently don't support it in our client applications.

You asked whether the access control could be modified without restarting c-gate. I'm happy to say it can be, although you have the problem that you need to connect to it to it to make the modification. This doesn't help your situation because if you could connect to make the change, you wouldn't need the change.

But there is a way.... If we combine the 2 features above. Use a username and password via a telnet session to modify the access permission to include the current client IP address and then connect using Homegate from the client. When you are done you could optionally revoke the permission.

It's late so I will have to post info on the relevant commands tomorrow when I'm in the office. (sending reminder).

Oh, one last thing, you could probably configure the access.txt to leave cgate open to anyone (effectively turning access permission off so to speak) but please don't try and do this .... the ramifications could be horrible.

 

I don't know anything about security in Homegate etc, but I do know a bit about access security in TCP/IP / Internet / FTP applications. I spent many years designing web-based security systems and scripts to deal with various aspects of access control to webpages and other online resources.

It is completely unreliable doing security based on incoming IP alone. Even the best broadband connections have a limited IP lease, and can change at any time especially after power failure / reboot of modem (not many of us pay the extra for a fixed IP). Dialup as you know changes the IP every time you connect!

So, IP-only authentification just causes end-users to get frustrated. And what happens if the "access IP" inadvertantly gets allocated to a "bad guy" (possible, even if unlikely) ?

Complicating matters is that many users connect via a "shared IP" (eg: operation behind a proxy or router, like what is done in many homes like mine, and most businesses). By using only incoming IP as a security measure, you open up the connection to everyone else who's sharing that same IP.

Finally, what happens if someone else gets access to the computer? Can they just click an icon and connect straight in because they are connecting via the already-defined IP?

I suggest U would be a much better model to include in future releases - think of online banking, etc where there's no way you could rely solely on IP as a security measure. Apart from being potentially more secure, it's far far easier for the average end-user to understand and cope with as well.

Cheers, JC

 

Hi John,

I agree with everything you say. But we don't have support in the client application for the username|password model so *temporarily* opening a port via IP address is the only way to do it.

 

Ok here is how to do it.

add the follow lines to your access.txt

Code:

interface 255.255.255.255 connect
user {username} {password} program

Where {username} is a user name you would like to use and {password} is a highly secure password that no one would ever guess.

example of a modified access control file

Code:

##C-Gate Server Access Control File
## This file was written automatically by a command issued to the server
## Created:Tue Oct 05 16:22:26 CST 2004
## File name: C:\clipsal\c-gate\config\access.txt
interface 0:0:0:0:0:0:0:1 Program
interface 127.0.0.1 Program
interface localhost Program
interface 255.255.255.255 connect
user admin mysecurepassword program
## End of access control file

Now start C-Gate or if C-gate is already running type ACCESS LOAD (in the cgate window) to have the new access.txt loaded without restarting cgate.

Now on some remote machine start a telnet session

Code:

telnet {ip address} 20023

obviously use the ip address of the cgate machine.

you will now have access to do nothing until you login, which is done by doing the following:

Code:

login {username} {password}

using the example above you would type:

Code:

login admin mysecurepassword

Now you have admin rights in cgate from a remote computer without cgate needing to know in advance what that remote computers IP address is.

However, homegate still won't be able to connect and run correctly. You need to give temporary access to the remote machines IP address to connect.

using the telnet session that is logged in type

Code:

access add remote {ipaddress} program

replacing IPaddress with the remote computers IP address

now Homegate should be able to connect no problems.

Once you have finshed with homegate you need to remove the remote IP address so the next person on the machine (or if the ip address is assigned to someone else by the isp) can't access cgate.

the simplest way is to issue ACCESS LOAD to cause the original permission to be reloaded remove the dynamically added permission.

NOTE: don't type ACCESS SAVE otherwise the new dynamically added permission will be written into the access.txt and available all the time.

hopefully that is enough to get it all working, let me know!

 

Richo,
Have had a go down the remote access and user name / password path - this looks like what we require on one of our larger sites. This leads to another two questions though: is there any way to issue the "access load" command (or something similar) to wipe the tempory access rights once the remote PC logs off automatically ?
The second one is: is there anyway to start Toolkit up looking for the remote repository without starting c-gate on the local machine ?
What we want to do is load Toolkit onto the server giving limited access to the Engineers and IT Guys, with the ability to lock people out if required.

Thanks....
Mark

 

No way of auto issuing the ACCESS LOAD that I can think of.

I'm pretty sure there is an undocumented commandline paramter to get Toolkit to connect to a remote repository (or at least not open the local one). Will need to check when I'm in the office tomorrow.

 

I was wrong. Just checked the source code and the code isn't there. Sorry. Have added it as a feature request.