Blocking admin logins from certain client machines

[shoenix]

Hi,

We want to use remote management to be able to have read-only access to say SmartDashboard. Those same users also know the 'admin' account and can therefor remotely login as 'admin'.

The problem is that we only want read-write (admin) access from a specific machine that is isolated in a specific room (so it had very limited access).

So to sumarize: We want users to connect from remote stations in read-only mode, but we want to block admin logins from those same machines.

Is there any possibility to do this ? I can only limit things on user level, but as soon as you allow a remote client it can logon with any defined user, including 'admin'.

Cheers,
Martijn Schoemaker/Shoenix

[mcnallym]

What I would suggest doing is as follows

1.) Create individual logins for EVERYONE, so that there is no common account. (this is also useful for auditing purposes)
2.) Change the admin account that is created in the cpconfig, put the password in a safe and do not use for anything other then an emergency where non of the other admins can access the Console.

This way administration users have there own personal account login and password unique to them that they should not share, and people who require read-only access will have there own login credentials.

The admin password has been changed so that the read-only people will not now it.

At the moment you cannot say only allow readwrite admin users to login from certain locations. As you have identified the gui client definition does not have an impact upon the user, so I believe that this is the nearest to what you want that you can do.

[shoenix]

Hi,

Thanks for the reply, and this is indeed the correct procedure. My biggest problem is that I do not want the possibility of people remotely hacking the admin account's password and gaining access. The current solution still allows remote admin logins. Ideally I would specifically appoint client stations to users, especially considering the security implications.

The people who have the admin password I can trust, other people attempting to break in via remote clients I cannot.

[northlandboy]

What if you used stronger authentication - certificates, or SecurID?

[shoenix]

Originally Posted by northlandboy

What if you used stronger authentication - certificates, or SecurID?

As fas as I can see, the admin user can always logon using password only. Anyway, certificates are stored on the same client machine, so the password hacking/exposure risk remains the same. And SecurID is a bit too expensive to roll out for this purpose, although it will indeed solve the problem.

What strikes me as odd is that a security product that is so well-though has such low configuration possibilities for allowing access to the heart of the system. Every OS has the possibility to deny remote logins for administrator/root users, exactly for this purpose.

To further specify the problem: Our department, which is responsible for FW-1 maintenance, used to be located next to the secured server room. In that server room we have a client station that is able to connect to the management server. You can only access the area via badge, and to enter the server room you also need a badge with different credentials.

Now we have moved away from the server room into another building. Our workstations are now in a office 'garden' which is accessible to many people. Also, a lot of people walk by while we work behind our machines. So the risk of someone peeking and via that way obtaining the password has increased significantly. Next to this, the workstations are now accessible to many different people. Access to the private directories is in the hands of multiple windows admins.

You can see that I do not trust any password or posession mechanism (other than physical tokens as suggested), therefor I want to limit the admin access to only the server room, and allow read-ony access to other stations within the office environment.

Regards,
Shoenix

[northlandboy]

Or use SmartPortal?

[rss8309]

As what others have said , I do not know about restricting GUI access with a combination of User and IP address. But to me , Allowing read-only access from the unprotected extended consoles is also dangerous as it provides c complete visibility to the policy list further inviting attacker to work on how to do a change in it. I would highly recommend you to use strong-two factor-authentication like secureID in case the consoles are extended to untrusted machines.

But due to cost contraints , You can also look at some ways like having a windows deskop behind your firewall and allowing GUI access only from it. All the users who has to gain access to the smart dashboard has to pass through two level of authentication - 1. RDP to the windows box with a strong password 2. From there , Authenticate to smart dashboard with a strong password. You may only allow limited desktops access the windows machine over RDP (in the firewalls). You may log this connection in this firewall and monitor it every morning if the previous day's connections (which will normally be very less in numbers) are legitimate.

Again , this is not completely secure but I feel it is a bit better than allowing GUI access directly from unprotected machines which are physically opened for everyone.

[shoenix]

That last solution was indeed also my idea as that is the only real safe option. I still think it's strange that a security product like this has such limited configuration possibilities with regard to accessing the core information.

Thanks all for thinking with me :)