Recent trends in IT Security, as well as actual security incidents and "close calls" at UCI, have highlighted the need to get more proactively aggressive about finding vulnerabilities on our network before the real hackers do. Because of the enormity of our network and limited set of resources, the OIT Security Team will begin to do periodic scans of all hosts connected to the UCI network looking for the lowest of the low hanging fruit: the most exploited and easiest to fix vulnerabilities hackers attempt to attack us with every day. In a way we can be seen as "white hat" or "good" hackers, looking for obvious problems and alerting the owners of those systems so that they can be fixed before a "black hat" or "evil" hacker finds the problem and causes real damage to our University. These scans will emulate some of the same tools and methods hackers use to find vulnerabilities to exploit. An analogy is that of a fire department performing a "controlled burn" of a forest or field in a controlled and safe environment, reducing the risk and damage of an out-of-control wildfire in the future.
What we will periodically look for initially:
- Open systems with empty or weak passwords, including Windows (RDP/SMB), SSH, FTP, VNC and various database types (including MSSQL and MySQL).
- Public web sites and web applications that allow anonymous (no login required) access to pages with SQL Injection or Cross-Site Scripting, and other common high impact web vulnerabilities.
What you may notice:
- Your log files (hopefully you are adequately keeping audit logging turned on) may show attempts to login from strange addresses or multiple failures in a row that you don't expect. Web access logs may show many requests from the same IP including strange URLs.
- If you allow anonymous updates to your websites (i.e. no login required), junk data or what looks like spam may be inserted into your application's database or email forms.
- If web application uses a database and vulnerable to input injection, regular database queries with altered SQL could take longer to run, connection pools may fill up and requests hang waiting for new connections.
What you should do:
- If notified by OIT Security about a potential vulnerability, act quickly to respond and correct the problem or work with them to think of possible mitigating controls until a fix can be produced.
- Configure audit logging and retention at an appropriate level such that a scan will not completely wipe out prior recent log data, not just for these scans but also for the inevitable time when a real hacker will attempt to attack your system. Audit logging retention settings will vary depending on system.
- Be aware of any account lockout policies or other denial of service controls you have configured on your systems.
- Don't specifically block IPs of scans in a blacklist manner, because the real hackers will use different IPs and methods each attack. Instead if you can limit access, do it in a comprehensive way only allowing a whitelist of IPs and users that should have legitimate access. We will intentionally not publish the times and sources of these scans.
As time goes on, we will add more types of scans as we will continue to grow the service in future phases.
If you have any questions or concerns, please email security@uci.edu