Recommendations for securing devices on the MUNI network
Do you have multiple services running on your device for different user groups? A report from our team warns of a vulnerability in an application under your management that cannot be updated or disabled for specific reasons? These are not the only cases that pose a serious security risk that need to be addressed proactively.
Do you have multiple services running on your device for different user groups? A report from our team warns of a vulnerability in an application under your management that cannot be updated or disabled for specific reasons? These are not the only cases that pose a serious security risk that need to be addressed proactively.
The two main mechanisms for mitigating this risk are the firewall on the endpoint device and network segmentation. You set the firewall directly on the device. Segmentation is handled by working with your network administrator - this may be IT centre or the networking department of the ICS (networks@ics.muni.cz) if the solution exceeds the competence of the CIT.
To implement the mechanisms, it is necessary to answer the questions: What services or applications are running on the device? Which users should have access?
Step 1: Service Identification
A firewall on the network and endpoint device blocks or filters unwanted traffic for specific applications and ports. Therefore, the ideal configuration should be based on a "deny all" policy, which means to allow only ports necessary for applications/services and implicitly disallow the rest. To be able to implement such a setup, you need to know what is running on the machine.
To help you identify the key issues, we have prepared the following checklist:
-
a) User access to the server
- Do users need remote access to the device (RDP, VNC)?
- Does the administrator need remote access to the device (RDP, SSH, VNC)?
- Do users access any web interface running on the device?
- Do users access any special application on the device?
- Does the vendor need access to the device?
-
(b) Data management and access to data
- Does the server store data that users access?
- Does the server store data on its own or network storage?
- Do users have a mapped network drive on this server? If so, how do they access the data (e.g. Samba, NFS, SSHFS)?
-
c) Controlled devices
- Are there devices connected to the machine that can only be controlled by this server?
- Are they on the local network or remote?
- What protocols are needed?
-
d) Access Control
- Does the machine use access control services? (e.g. Perun, Single Sign-On, Kerberos, LDAP, Shibboleth, AD)?
-
e) Data backup, monitoring
- To which server and by which protocol is the data backed up?
Is service monitoring (e.g. Nagios or Icinga) implemented on the server?
- To which server and by which protocol is the data backed up?
-
f) Other services
- Does the server need to actively connect (initiate) with external services (e.g. license servers, certificate renewal, update downloads)?
- Does the server need any other services (e.g. NTP, DNS, printing, sending mail)?
Step 2: User Identification
In the previous step, you created a list of services running on your device. Now you need to assign a user to each of these services. This can be done by answering the following series of questions:
Do you need only MUNI users to have access to the device/service?
So you should be able to specify at least one of the following criteria:
- Specific IP addresses/range;
- the entire network segment/VLAN.
Do you need external users (outside the MUNI network) to access the device/service?
One of the following solutions should be applicable:
- VPN for staff and students outside the MUNI network;
- jump host, e.g. for remote management by a vendor.
Step 3: Local Firewall and Segmentation Configuration
Based on the answers to the above questions, you can now start setting up firewalls on your managed devices yourself. However, setting up a firewall on a device is only the beginning. Don't forget to double its protection afterwards with network segmentation, which limits the attack surface. This not only limits potential attacks on your segment, but also strengthens the overall security of your MUNI network.
Case in point: situations handled with our administrators - vulnerable service exposed to the world
a) Ideal solution: the ideal solution is to update the service. Vulnerable services are always an unnecessary risk.
b) Alternative solution - implement adequate measures: if a service cannot be updated, it is advisable to isolate it. This means moving it to a separate server (ideally a virtual one) and running it with minimal user permissions, for example only "write to specific directories".
In the case of the alternative solution, the goal is to ensure that if the vulnerability is exploited, the attacker cannot penetrate further, into other parts of the MUNI network. In this way, you can run the service provisionally until you find a suitable replacement or until you can fix the vulnerability, e.g. update the service.
Is your situation more complex, and can't easily answer the above questions? Or does the article not apply to your situation at all? Feel free to contact us at csirt@muni.cz to arrange a consultation for more complex issues.
Is your situation more complex, and can't easily answer the above questions? Or does the article not apply to your situation at all? We are happy to consult with you on more complex problems. Contact us at csirt@muni.cz.