Local System Security Audit - Nethemba

Network and System Security

Local System Security Audit

01
Suitable for:
  • all servers with many local users
  • where local security is important (e.g. relatively untrusted people have local access to trusted servers)
Report size:
5-50 pages
Testing time:
3-4 days

The goal of the comprehensive local system security audit is to verify local system security of the given OS:

  • Check for unused services and packages – unused services and packages can increase a number of possible ways to compromise the given system
  • Analysis of system strange behaviour – check for strange processes and network connections (interface’s promiscous flag), rootkit hunting – looking for modified binaries, suspicious log files, kernel and hacker’s toolkit
  • Check for system suid/sgid binaries and their consequent elimination – suid/sgid binaries owned by root are security critical, i.e. exploiting these binaries can lead to a compromise of whole system
  • Check for the latest security patches of all system packages and a kernel – unmaintained system packages and the kernel contain a lot of public available security bugs that can be exploited
  • Proposal of suitable AC mechanism – Unix DAC (Discretionary Access Control) is insufficient in many cases. The more robust access control mechanisms based on DTE or RBAC model exist for many OS platforms (SELinux, Trusted Solaris). We suggest to verify used AC mechanism and propose a better one.
  • User review – review of existing users, their rights and their settings (e.g. validity of shell, home directory), separation to special groups, review of used password hash schema and proposal for better one (blowfish), possibility of remote root login, user cron checks
  • Service configuration assessment – wrong service configuration can lead to service security compromise. Analysis if all used TCP/UDP services that work with sensitive information (logins, passwords, ..) use appropriate encryption and authentication (SSL), check if all security-critical daemons run under unprivileged user in changed root directory. If service implementation is unsuitable from the security perspective (e.g. had a lot of security issues in the past), we suggest more secure implementation.
  • Privacy assessment – permission check for all sensitive data and devices, check for the safe system storage (e.g. encrypted file system), check if only selected applications can access to sensive data, check for boot manager password protection.
  • Check for host-based firewall – carefully configured host-based firewall can increase system security and complicate massive worm-based exploiting

Features:

  • all common OSes are supported
  • follows OSSTMM methodology, mainly Vulnerability Research and Verification (OSSTMM Section C/4) and Privacy Review (OSSTMM Section C/5)
  • technical report with executive summary, all revealed vulnerabilities, risk levels and recommendations