| CPUG | |
| The Check Point User Group | |
| A Resource For The Check Point Community. Fast. Useful. Independent. | |
|
| |||||||
![]() |
| | LinkBack | Thread Tools | Display Modes |
| |||
| OK here is the setup We have an internet facing Nokia with CP NGX R62 on it. Its being managed by a Smartcentre server (running Windows server 2003) through a dedicated connection. I want to be able to connect to the Smartcentre server via RDP from the corp network. The Smartconsole tools are on the Smartcenter server. Are there any particular steps I should take to secure this setup? Should I put another firewall between the Nokia and the Smartcentre Server ? I'd interested in your feedback. Richso =o= |
| |||
| What does "dedicated connection" mean? That the SmartCenter is connected directly to a different NIC on the firewall solely for management and there is nothing else on that NIC? It's generally a bad idea. Anyone with RDP access can make themselves a firewall administrator or copy off the entire configuration. You should have a static IP address or a DHCP reservation on your computer along with a copy of the SmartConsole tools. Ray |
| |||
| ^ +1.... As well you should secure that Windows server, which means disabling not only things like RDP for terminal services, but also the server service, workstation service, file sharing, etc... Google Windows 2003 Bastion Host, for information on properly securing your Windows platform. |
| |||
| What does "dedicated connection" mean? That the SmartCenter is connected directly to a different NIC on the firewall solely for management and there is nothing else on that NIC? Yup Anyone with RDP access can make themselves a firewall administrator I was'nt planning on opening up RDP access to everyone You should have a static IP address or a DHCP reservation on your computer along with a copy of the SmartConsole tools. Thats my preferred solution but it going to be difficult getting the tools installed on desktops as they are locked down. Bastion Host The server is not in the DMZ but I am interested in possible risks via the connection to the Nokia. I know that SIC deals with authentication and encrypts the communication, I just wonder whether its enough. The internal threat I guess also needs to be addressed, I'm going to have to think of good solution for remote access to the Smartcentre server. Thanks Richso =o= |
| |||
| Quote:
Quote:
|
| |||
| Quote:
The fact that you can't get the SmartConsole programs installed does raise the question as to whether your company only wants it managed from the SmartCenter itself and you're trying to beat the system. That's usually a career-ending move. I'll assume I am reading in between the lines too much. :-) Quote:
Ray |
| |||
| I'm surprised by the number of people that are attacking the use of an RDP session to connect to a SmartConsole Client. I know of a number of environments that do not allow remote GUI clients and enfirce that a user must RDP (and authenticate!) to a console server before running SmartDashboard (again, requiring another layer of authentication to connect). If RDP access to the console is restricted by firewall rules (which, again, could require authentication via SecuRemote/SNX or Client Auth) you've got a pretty secure setup IMHO. You are bypasasing the GUI-Clients ACL on the SmartCenter Server, but with all the other caveats in a design like this, I struggle to see the issue. Admittedly, I don't think that using the Management Station as your SmartConsole station is the wisest move, but I don't think it's anywhere near as bad as is being suggested. In favour of this design is the fact that there is a risk of information leakage if a machine running SmartConsole is physically stolen or compromised. Running everything remotely minimises that risk. |
| |||
| Actually you lose another layer of security besides the GUI IP client list, a very important layer... If someone has access to that server, via rdp or whatever, then they have access to bypass the GUI login authentication... Also, in many environments, any user can sign on to anyone's machine... Whether it be a user or an admin... If that machines IP is cleared for RDP, then another user or admin could just as easily sign on to it, then RDP in... We actually had someone try that years ago, before I worked at this place... He got caught though... Fired as well.. lol... Last edited by rokudan; 2008-01-22 at 18:45. |
| |||
| There are some places where it's needed, such as when you have a lot of latency between the computer and the SmartCenter. I try to follow the rule of never giving users a logon to a server wherever possible and certainly never for convenience. Ray |
| |||
| If the system is designed such that someone can get authenticated adminstrator-level access to your SmartCenter Server, then yes, it's game over irrespective of where your GUI clients are. But at this point, you're arguing about the level of Windows Security, not Check Point security. I would hope that the W2k3 Server that is the SmartCenter is a standalone system, or if it's part of the domain (eek!) then Group Policies and the like are in place. If not then a separate console system which is used to RDP into and runs the GUI is a better solution. (and then move the SmartCenter to SPLAT... :P) |
| |||
| That right there is the answer.. In our environment we have one group that manages Windows boxes, another does *nix... The only way to keep both of them out, is to use SPLAT... Neither group would support that outside of my group... Just the same with the IPSO OS... That is ours to deal with, no one elses... So no Windows admins poking around, no *nix admins.. No one else except us... In part, security through obscurity... In short, I dont think I could ever argue for using Windows over SPLAT for a SmartCenter box... Even if you are a Windows only guy, SPLAT is a cakewalk to use... |
![]() |
| Thread Tools | |
| Display Modes | |
| |