How we (Information security guys) get the information about user activities within information system? Sure thing – from the logs, produced by this system. But what could we do if some business critical system do not produce such logs or we cannot trust them? It could be in cases below:
1. Legacy system with no logging at all.
In the any big enterprise you can find old legacy system that have been designed a lot of years ago and do not fit any information security requirements at all. Very often you even haven’t possibility to install any additional software on such system (restricted by vendor or lack of performance). Sure thing you could protect this system from the network side by firewall but it not helps to get more logs from the system inside.
2. Business/ Mission critical systems supported on site or remotely by vendor.
It’s very popular now to give IT system operation support to the vendor or special outsourcing company. It’s very useful and helps to reduce you costs. But what about security? In such case you should fully trust to this company and couldn’t trust to the system logs (they could be changed easily with admin privileges on system and vendor knowledge of the system internals).
3. Protect your Business/ Mission critical systems from the evil systems administrators’ activities.
These guys have full knowledge and enough permission to do whatever they want. Sure thing well designed system must send logs to the central log’s storage and you could do investigation based on these logs. But what happened if it’s not enough or some subsystem of the system does not produce logs at all?
In all this case you must have a special designed infrastructure with terminals servers with advanced logging capabilities and give users access to the protected systems only through this terminal servers.
So , below samples of such infrastructures for each case.
1. Legacy system with no logging at all.
Except terminal server in this case sometimes you will need install network sniffer for control data flow within legacy information system (because old switches do not support acl or installing acl on network equipment prohibited by vendor )
2. Business/ Mission critical systems supported on site or remotely by vendor.
3. Protect your Business/ Mission critical systems from the evil systems administrators’ activities.
There are a lot of very expensive commercial terminal server solutions that could record all activities and produce a lot of logs or even be a man of the middle for ssh session. From my point of view one of the best solutions is Shell Control Box from Balabit. But it cost a lot and you should by license per each user ho access to the system and per each server access to whom this device protect.
In this article I gonna propose you alternative solution that will be much much cheaper but have almost the same functionality.
As a terminal server core I use Windows Terminal Server (Windows Server 2003). I chose licensing type – per user, but you could choose whatever you want.
1. Installing Windows Server 2003 and Terminal Server Service
Here there are two options:
2. Hardening terminal server.
First of all install Microsoft Windows Server 2003 Security Guide Tools and Templates (download it from Microsoft site) and configure your server as a Specialized Security - Limited Functionality server.
Then turn off or uninstall all unused services and windows components.
Modify the group policy and the registry to prohibit users to mount disk, copy clipboard, redirect ports and etc through RDP.
Do not forget do disable windows admin shares!
3. Set up a file share for users file transfer.
Very often users should have possibility to copy files to or from protected servers. We cannot allow users to use for this purpose RDP drive mounting for a lot of security reasons. The best way is to setup dedicated file share for such purpose. So, how user will transfer file to the protected area?
First of all user copy file to the terminal server file share. After that, he logon to the protected area through terminal server and copy file from terminal server to the protected server. So, he uses the terminal server as temporary transfer storage.
For you , as a security guy, it give possibility to copy this files for further analysis, scan it by anti-virus, log file transfer event, etc.
So, what should you do for this:
5. Install a Screen Anytime software.
It cost about 1K$ per terminal server without session limitation. This really amazing soft could capture the user’s terminal session and store it as a high compressed video file. More over this software provide you session player and records management tools.
Configure Screen Anytime software for recording all session in shadow mode (hide it from users). If you have centralized log storage you can configure this software to send captured session video files to this log storage from all your terminals servers.
6. Change default shell to mstsc.exe instead of explorer.
Changing shell you prevent users from access data and software stored on terminal server. So, users can only go through this terminal server without possibilities to do something on the terminals server.
So, using mstsc ( RDP client) you can easily manage only windows servers.
But what happens if you would like to control access to the unix based systems? No problem! Create custom shell based on ssh client like Putty or even write small shall and include in it RDP, ssh, sql or other clients that you need. I strongly recommend you to check and modify these clients for preventing user access to terminal server file system. For example in my terminal server I using modified Putty with record session option and without any possibility to change it. So, I get two logs in one time: video from Screen Anytime and commands log in text from Putty.
7. Create a custom startup script to start Screen Anytime video capture on user log on.
Normally Screen Anytime does it for you. But, when you change this default shell you must take care of starting screen capturing.
8. Configure and startup a firewall.
Transit terminal server infrastructure
Sometimes you would like to allow users to install some software on terminal server or you cannot modify some client software to securely install it on terminal server. I recommend you to create a chain of terminal servers. First terminal server will have mstsc ( RDP client) as a shell and work as a transit terminal server with one purpose – record users activity. First server will only allow user to get to second terminal server. On this terminal server users will have all their software installed or even be administrators!
This scheme works amazing especially in case number 2 - giving ability to vendor easily remotely support your business critical systems.
Last tip: Use virtual infrastructure for these terminal servers! It really simplify your life.
That’s all folks!
1. Legacy system with no logging at all.
In the any big enterprise you can find old legacy system that have been designed a lot of years ago and do not fit any information security requirements at all. Very often you even haven’t possibility to install any additional software on such system (restricted by vendor or lack of performance). Sure thing you could protect this system from the network side by firewall but it not helps to get more logs from the system inside.
2. Business/ Mission critical systems supported on site or remotely by vendor.
It’s very popular now to give IT system operation support to the vendor or special outsourcing company. It’s very useful and helps to reduce you costs. But what about security? In such case you should fully trust to this company and couldn’t trust to the system logs (they could be changed easily with admin privileges on system and vendor knowledge of the system internals).
3. Protect your Business/ Mission critical systems from the evil systems administrators’ activities.
These guys have full knowledge and enough permission to do whatever they want. Sure thing well designed system must send logs to the central log’s storage and you could do investigation based on these logs. But what happened if it’s not enough or some subsystem of the system does not produce logs at all?
In all this case you must have a special designed infrastructure with terminals servers with advanced logging capabilities and give users access to the protected systems only through this terminal servers.
So , below samples of such infrastructures for each case.
1. Legacy system with no logging at all.
Except terminal server in this case sometimes you will need install network sniffer for control data flow within legacy information system (because old switches do not support acl or installing acl on network equipment prohibited by vendor )
2. Business/ Mission critical systems supported on site or remotely by vendor.
3. Protect your Business/ Mission critical systems from the evil systems administrators’ activities.
There are a lot of very expensive commercial terminal server solutions that could record all activities and produce a lot of logs or even be a man of the middle for ssh session. From my point of view one of the best solutions is Shell Control Box from Balabit. But it cost a lot and you should by license per each user ho access to the system and per each server access to whom this device protect.
In this article I gonna propose you alternative solution that will be much much cheaper but have almost the same functionality.
As a terminal server core I use Windows Terminal Server (Windows Server 2003). I chose licensing type – per user, but you could choose whatever you want.
1. Installing Windows Server 2003 and Terminal Server Service
Here there are two options:
- use local authentication for terminal users (for small amount of users )
- join the AD domain and use domain authentication for terminal users (for big amount users). If your company do not use AD, but you need to manage a lot users, especially on a multiply terminals servers you could install special AD Domain controller for this purpose.
2. Hardening terminal server.
First of all install Microsoft Windows Server 2003 Security Guide Tools and Templates (download it from Microsoft site) and configure your server as a Specialized Security - Limited Functionality server.
Then turn off or uninstall all unused services and windows components.
Modify the group policy and the registry to prohibit users to mount disk, copy clipboard, redirect ports and etc through RDP.
Do not forget do disable windows admin shares!
3. Set up a file share for users file transfer.
Very often users should have possibility to copy files to or from protected servers. We cannot allow users to use for this purpose RDP drive mounting for a lot of security reasons. The best way is to setup dedicated file share for such purpose. So, how user will transfer file to the protected area?
First of all user copy file to the terminal server file share. After that, he logon to the protected area through terminal server and copy file from terminal server to the protected server. So, he uses the terminal server as temporary transfer storage.
For you , as a security guy, it give possibility to copy this files for further analysis, scan it by anti-virus, log file transfer event, etc.
So, what should you do for this:
- Create a file share on separate disk.
- Turn on disk quotas.
- Modify folder and subfolder permissions for allowing only to file owner view o modify own files and folders. (It will protect information of one user from others during file transfer through terminal server)
5. Install a Screen Anytime software.
It cost about 1K$ per terminal server without session limitation. This really amazing soft could capture the user’s terminal session and store it as a high compressed video file. More over this software provide you session player and records management tools.
Configure Screen Anytime software for recording all session in shadow mode (hide it from users). If you have centralized log storage you can configure this software to send captured session video files to this log storage from all your terminals servers.
6. Change default shell to mstsc.exe instead of explorer.
Changing shell you prevent users from access data and software stored on terminal server. So, users can only go through this terminal server without possibilities to do something on the terminals server.
So, using mstsc ( RDP client) you can easily manage only windows servers.
But what happens if you would like to control access to the unix based systems? No problem! Create custom shell based on ssh client like Putty or even write small shall and include in it RDP, ssh, sql or other clients that you need. I strongly recommend you to check and modify these clients for preventing user access to terminal server file system. For example in my terminal server I using modified Putty with record session option and without any possibility to change it. So, I get two logs in one time: video from Screen Anytime and commands log in text from Putty.
7. Create a custom startup script to start Screen Anytime video capture on user log on.
Normally Screen Anytime does it for you. But, when you change this default shell you must take care of starting screen capturing.
8. Configure and startup a firewall.
Transit terminal server infrastructure
Sometimes you would like to allow users to install some software on terminal server or you cannot modify some client software to securely install it on terminal server. I recommend you to create a chain of terminal servers. First terminal server will have mstsc ( RDP client) as a shell and work as a transit terminal server with one purpose – record users activity. First server will only allow user to get to second terminal server. On this terminal server users will have all their software installed or even be administrators!
This scheme works amazing especially in case number 2 - giving ability to vendor easily remotely support your business critical systems.
Last tip: Use virtual infrastructure for these terminal servers! It really simplify your life.
That’s all folks!
No comments:
Post a Comment