Internet access in difficult administrative conditions
Greetings dear
I would like to share some solution that is still experimental in our company, but is brought to mind by small forces. It is about collective access to the Internet, in conditions when the Internet is better for users not to give (for various reasons - organizational, technical, administrative).
Until now, we have implemented a fairly common access scheme. Namely:
')
Integrating these three components received a good combination of convenience and reliability. Moreover, this method will still be suitable for many people until now, but for us the realities dictate other rules. As long as there is Internet in the workplace, there is a possibility of information leakage (a lot of ways, you want to argue - welcome to comments ..).
And it was decided to leave the Internet access, but remove it from the o_O work machines. In our work, we actively use Linux (usually CentOS 4-5-6) and remote access. These are completely different technologies, each has its own scope of application and we actively use each solution based on the task.
It was with the help of the latter that they decided to work wonders. Fortunately, clients (OpenNX, NoMachineNX, Remmina) are for different platforms. We must get a system that meets the following requirements.
In order not to depend on hardware and easily increase capacities, we created a virtual machine in the vmware factory (it is still not clear what exactly we need, perhaps in the future we will transfer to real hardware). For the base, we use the CentOS6 x86_64 distribution with the XFCE4.8 window manager - this will give us a good performance saving (unlike KDE and other weightlifters). By the way, for XFCE a keyboard layout was not found for Russian users. I had to rebuild it with alt linux and put it in the form of rpm for CentOS. After installing the OS, the maximum number of programs familiar to users, such as Opera, Firefox, Google Chrome, as well as Pidgin, LibreOffice, Acrobat Reader, etc., etc., etc. were delivered ...
Log in via ssh banned by all but the domain admins group. Firewall (iptables) closed all possible local services leaving only access to dns, cups. Everything else inside the network mercilessly falls under -j Reject.
A squid was installed locally (in /etc/profile.d/ scripts were set depending on the shell, setting variables * _proxy), which will be used exclusively for the cache. Home folders of users were carried out on a separate section, they included journal quotas on it.
For freenx server allowed 1 per user connection. Disable the clipboard in both directions.
As a result, we have the system itself. Access to it only with the help of the nx-client, entry only by key, with domain authentication. There is no connection with local machines. It is almost impossible to transfer anything to a remote nx machine, and therefore the extra data will not be available on the Internet.
Active simultaneous users of a dozen and a half (the work does not allow a large number of people to go). The parameters of the virtual machine at the moment - 2 cores, 8GB of RAM, hdd and so on are not so important. If necessary, you can add, in fact, the charm of virtualka.
Clarified some points regarding performance. Individual users can open the Opera with multiple tabs and thus bite off a lot of memory. Attempts were made to limit resources by means of limits.conf, but nothing sensible came out and experiments with cgroups started. This mechanism was limited to using memory only for browsers, limiting works, but users don’t like it :). We are looking for compromises.
I do not attach special configs. all from fairly simple components. NX put a lot of manuals, iptables is also nothing complicated to configure :) but if you have questions - write.
To make it easier for users to start, the NX client itself (binaries) is put on the network ball, and the shortcut to the batch file with the launch of a previously prepared customized NX session is put on the desktop to users. Works without installation on specific machines with a bang.
I would like to share some solution that is still experimental in our company, but is brought to mind by small forces. It is about collective access to the Internet, in conditions when the Internet is better for users not to give (for various reasons - organizational, technical, administrative).
Until now, we have implemented a fairly common access scheme. Namely:
')
- Dedicated proxy server (squid, no options), which actually connected, in general terms, the internal network with the Internet.
- SAMS2 - solutions for creating templates and policies for Internet access.
- Domain controller (samba + ldap)
Integrating these three components received a good combination of convenience and reliability. Moreover, this method will still be suitable for many people until now, but for us the realities dictate other rules. As long as there is Internet in the workplace, there is a possibility of information leakage (a lot of ways, you want to argue - welcome to comments ..).
And it was decided to leave the Internet access, but remove it from the o_O work machines. In our work, we actively use Linux (usually CentOS 4-5-6) and remote access. These are completely different technologies, each has its own scope of application and we actively use each solution based on the task.
- ssh with its tunnels allows you to do almost anything. If more is not required;
- RDP;
- HP Remote Graphic Software (HP RGS) is sometimes necessary;
- Freenx
It was with the help of the latter that they decided to work wonders. Fortunately, clients (OpenNX, NoMachineNX, Remmina) are for different platforms. We must get a system that meets the following requirements.
- Easy to deploy, good performance;
- Isolated from the main network (at the program-logical level);
- Internet access anywhere - www, mail, ftp, im. To save traffic, local cache proxy. Storage of your files in certain limits.
In order not to depend on hardware and easily increase capacities, we created a virtual machine in the vmware factory (it is still not clear what exactly we need, perhaps in the future we will transfer to real hardware). For the base, we use the CentOS6 x86_64 distribution with the XFCE4.8 window manager - this will give us a good performance saving (unlike KDE and other weightlifters). By the way, for XFCE a keyboard layout was not found for Russian users. I had to rebuild it with alt linux and put it in the form of rpm for CentOS. After installing the OS, the maximum number of programs familiar to users, such as Opera, Firefox, Google Chrome, as well as Pidgin, LibreOffice, Acrobat Reader, etc., etc., etc. were delivered ...
Log in via ssh banned by all but the domain admins group. Firewall (iptables) closed all possible local services leaving only access to dns, cups. Everything else inside the network mercilessly falls under -j Reject.
A squid was installed locally (in /etc/profile.d/ scripts were set depending on the shell, setting variables * _proxy), which will be used exclusively for the cache. Home folders of users were carried out on a separate section, they included journal quotas on it.
For freenx server allowed 1 per user connection. Disable the clipboard in both directions.
As a result, we have the system itself. Access to it only with the help of the nx-client, entry only by key, with domain authentication. There is no connection with local machines. It is almost impossible to transfer anything to a remote nx machine, and therefore the extra data will not be available on the Internet.
Active simultaneous users of a dozen and a half (the work does not allow a large number of people to go). The parameters of the virtual machine at the moment - 2 cores, 8GB of RAM, hdd and so on are not so important. If necessary, you can add, in fact, the charm of virtualka.
Clarified some points regarding performance. Individual users can open the Opera with multiple tabs and thus bite off a lot of memory. Attempts were made to limit resources by means of limits.conf, but nothing sensible came out and experiments with cgroups started. This mechanism was limited to using memory only for browsers, limiting works, but users don’t like it :). We are looking for compromises.
I do not attach special configs. all from fairly simple components. NX put a lot of manuals, iptables is also nothing complicated to configure :) but if you have questions - write.
To make it easier for users to start, the NX client itself (binaries) is put on the network ball, and the shortcut to the batch file with the launch of a previously prepared customized NX session is put on the desktop to users. Works without installation on specific machines with a bang.
Source: https://habr.com/ru/post/166197/
All Articles