Handout for Aix Security

Total Page:16

File Type:pdf, Size:1020Kb

Handout for Aix Security 10/16/2013 BASIC AIX S ECURITY Jaqui Lynch [email protected] Presentation can be found at: http://www.circle4.com/papers/aixsecurity- oct2013.pdf AGENDA Basics Security Intro Permissions Checklists Tools that can help OpenSSL, OpenSSH TCP Wrappers Snort, stunnel Logging, finding Rootkits Incident Handling and laws AIX v6 and v7 PowerSC Questions 2 1 10/16/2013 SECURITY TYPES Physical Local Keep system patched!!! Microcode/firmware BIOS on HMC and consoles Operating Systems Files and filesystems Passwords Kernel Network 3 LEVELS & T YPES OF ATTACKS Levels Types • Embarrassment (replace Root access break-in banners, home page, etc) Replacement of materials • Denial of service (syn-flood Damage done connections) • Ping of Death Just looking • Stealing proprietary code Theft of proprietary information • Pornography Denial of service • Harassment or threats - stalking Worms and Trojans • Email Spam or bulk subscribes • Hate mail • Buffer Overflow 4 2 10/16/2013 SANS T OP 10 V ULNERABILITIES FROM 2004 •U1 BIND Domain Name System •U2 Remote Procedure Calls (RPC) •U3 Apache Web Server •U4 General UNIX Authentication Accounts with No Passwords or Weak Passwords •U5 Clear Text Services •U6 Sendmail •U7 Simple Network Management Protocol (SNMP) •U8 Secure Shell (SSH) •U9 Misconfiguration of Enterprise Services NIS/NFS •U10 Open Secure Sockets Layer (SSL) •Sadly this has not changed much •Many of these are also turned on by default 5 SANS T OP 20 C RITICAL SECURITY CONTROLS HTTP :// WWW .SANS .ORG /CRITICAL -SECURITY -CONTROLS /# THREATINDEX Critical Control 1: Inventory of Authorized and Unauthorized Devices Critical Control 2: Inventory of Authorized and Unauthorized Software Critical Control 3: Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers Critical Control 4: Continuous Vulnerability Assessment and Remediation Critical Control 5: Malware Defenses Critical Control 6: Application Software Security Critical Control 7: Wireless Device Control Critical Control 8: Data Recovery Capability Critical Control 9: Security Skills Assessment and Appropriate Training to Fill Gaps Critical Control 10: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches Critical Control 11: Limitation and Control of Network Ports, Protocols, and Services Critical Control 12: Controlled Use of Administrative Privileges Critical Control 13: Boundary Defense Critical Control 14: Maintenance, Monitoring, and Analysis of Audit Logs Critical Control 15: Controlled Access Based on the Need to Know Critical Control 16: Account Monitoring and Control Critical Control 17: Data Loss Prevention Critical Control 18: Incident Response and Management Critical Control 19: Secure Network Engineering Critical Control 20: Penetration Tests and Red Team Exercises 6 3 10/16/2013 UNIX S ECURITY BASICS Permissions UID GID Dangerous Accounts Superuser SUID Sticky bit Umask Backups 7 PERMISSIONS r read w write x execute s SUID or SGID t sticky bit e Encrypted aaa bbb ccc aaa file's owner permissions bbb users who are in the file's group ccc everyone else on the system (except uid 0) Permissions apply to devices, named sockets, files, directories and FIFOs. 8 4 10/16/2013 OCTAL PERMISSIONS 4000 SUID on execution 0040 Read by group 2000 SGID on execution 0020 Write by group 1000 Sticky Bit 0010 Execute by group 0400 Read by owner 0004 Read by other 0200 Write by owner 0002 Write by other 0100 Execute by owner 0001 Execute by other 755 Anyone can copy or run the program - Only the owner can change it +r +w +x +s SUID if u+, SGID if g+ +t Add sticky bit 9 FILE SECURITY ls -l shows: -rwxr-xr-x 1 jaqui jgroup 4320 Feb 9 12:19 files - file's type (- for file, D for directory) rwxr-xr-x file's permissions if rwxr-xr-xe then file is encrypted 1 no. of hard links the file has jaqui name of the files owner (if a number then this is the Uid) Jgroup name of the group (if a number then this is the Gid) 4320 size of file in bytes Feb 9 12:19 file's modification time files the file's name ls -l Shows modification time for file ls -lu Shows last accessed time It is possible in AIX to code noatime on a filesystem The above two times can be changed with a command so you should check: ls -lc Shows last modification time of the inode 10 5 10/16/2013 FILE SECURITY # ls -l messages -rw-r--r-- 1 root system 1215 Oct 14 19:11 messages # ls -lu messages -rw-r--r-- 1 root system 1215 Oct 13 23:59 messages # ls -lc messages -rw-r--r-- 1 root system 1215 Oct 14 19:11 messages Then tail messages and: # ls -l messages -rw-r--r-- 1 root system 1215 Oct 14 19:11 messages # ls -lu messages -rw-r--r-- 1 root system 1215 Oct 14 19:23 messages # ls -lc messages -rw-r--r-- 1 root system 1215 Oct 14 19:11 messages 11 UMASK Specifies the permissions you do not want given by default to newly created files and directories. By default on most systems: New files are 666 (anyone can read/write) New programs are 777 (all rwx) root should be 022 and all others 077 Common Umask Values Umask User Group Other 0000 rwx rwx rwx 0002 rwx rwx r-x 0007 rwx rwx --- 0022 rwx r-x r-x 0037 rwx r-x --- 0077 rwx --- --- 12 6 10/16/2013 UMASK EXAMPLES Default umask of 022 $touch file1 $mkdir firj1 $ ls -al total 8 drwxr-xr-x 3 jaqui system 256 Oct 14 19:31 . drwxr-xr-x 18 root system 4096 Oct 14 19:30 .. drwxr-xr-x 2 jaqui staff 256 Oct 14 19:31 dirj1 -rw-r--r-- 1 jaqui staff 0 Oct 14 19:30 file1 $umask 007 $touch file2 $mkdir dirj2 $ ls -al total 8 drwxr-xr-x 4 jaqui system 256 Oct 14 19:31 . drwxr-xr-x 18 root system 4096 Oct 14 19:30 .. drwxr-xr-x 2 jaqui staff 256 Oct 14 19:31 dirj1 drwxrwx--- 2 jaqui staff 256 Oct 14 19:31 dirj2 -rw-r--r-- 1 jaqui staff 0 Oct 14 19:30 file1 -rw-rw---- 1 jaqui staff 0 Oct 14 19:31 file2 13 SUID, SGID, S TICKY BIT SUID Sets UID to program's owner at execution SGID Sets GID to program's group at execution Also used to share files in a directory All files and subdirectories will inherit the group Sticky If set on a dir then only root or owner can delete or rename (see /tmp drwxrwxrwt) Old usage was: Causes program to be left in swap space after termination. Used for programs that were executed frequently - outmoded. The su command is an SUID program. To find them: find / -perm -004000 -o -perm -002000 \) -type f -print or ncheck -s filesystem-name 14 7 10/16/2013 EXAMPLE OF STICKY BIT Use of sticky bit # ls -al /tmp drwxrwxrwt 19 bin bin 4096 Oct 14 19:10 . # pwd /usr/local # mkdir jaquidir # ls -al jaquidir total 8 drwxr-xr-x 2 root system 256 Oct 14 19:16 . drwxr-xr-x 18 root system 4096 Oct 14 19:16 .. # chmod 777 jaquidir # ls -al jaquidir total 8 drwxrwxrwx 2 root system 256 Oct 14 19:16 . # chown jaqui.sshd jaquidir # ls -al jaquidir total 8 drwxrwxrwx 2 jaqui sshd 256 Oct 14 19:16 . # chmod +t jaquidir # ls -al jaquidir total 8 drwxrwxrwt 2 jaqui sshd 256 Oct 14 19:16 . drwxr-xr-x 18 root system 4096 Oct 14 19:16 .. You can do this with one step – chmod 1777 jaquidir 15 ACLS –ACCESS CONTROL LISTS acledit /usr/local/jaquidir Extended permissions: aclget /usr/local/jaquidir extended permissions: enabled * permit rw- u:dhs * ACL_type AIXC deny r-- u:chas, g:system * attributes: specify r-- u:john, g:gateway, g:mail base permissions permit rw- g:account, g:finance owner(jaqui): rwx group(system): r-x others: r-x Other commandsL extended permissions disabled aclget aclput # ls -al /usr/local/jaquidir drwxr-xr-x 2 jaqui system 256 Oct 14 acledit 19:47 . drwxr-xr-x 18 root system 4096 Oct 14 aclconvert 19:30 .. aclgettypes http://publib.boulder.ibm.com/infocenter/pseries/v5r 3/index.jsp?topic=/com.ibm.aix.security/doc/security /access_control_list_aixc.htm 16 8 10/16/2013 FILES TO CLEAN OUT Backup file first – I use filename-JLdate /etc/services Password and group files Know who is in there and why /etc/inetd.conf Delete services – don’t just comment them out Check whenever you install maintenance /etc/inittab /etc/rc.tcpip Do you need sendmail, ATM, SNMP? /etc/rc.local and other rc files Don’t make changes to inittab to add things Instead kick off an rc.local from inittab and make your changes to rc.local 17 CHECKLIST 1/3 Individual accounts only including for applications All accounts must have GOOD passwords Disable tftp if possible Use /etc/tftpaccess.ctl to control access Remove .rhost and core files nightly Ensure /etc/passwd can't be read anonymously by UUCP or TFTP Check the SU log regularly Only allow root to login at the console (force su or sudo) if at all Set console as only trusted location for root Set umask to 033 or 077 (077 = rwx --- ---) Scan regularly for SUID/SGID files & for crack Change default password on all system default accounts Get rid of guest Disable dormant or temporarily inactive accounts or set them to /bin/false as a login shell Make regular backups & check restores regularly Export filesystems that have programs as read-only Check last login when you login 18 9 10/16/2013 CHECKLIST 2/3 System directories - not world or group writable /etc/hosts.equiv and hosts.lpd should be rwx r-- r– and preferably empty Remove the + and all comments from your /etc/hosts.equiv and lpd files Disable unused network services, especially finger, cmsd, ttdbserver Ensure sendmail or Postfix is at latest version Do not run sendmail unless you are a mailserver or relay Instead set it up in cron to run the queues hourly Make sure ftpd is current and disabled (try secure FTP or SFTP in SSH) Ensure anonymous FTP & tftp can't get the /etc/passwd file Make sure /etc/ftpusers contains root, uucp, bin, etc Scan periodically for hidden directories (".
Recommended publications
  • CIS Debian Linux 7 Benchmark V1.0.0 - 12-31-2015
    CIS Debian Linux 7 Benchmark v1.0.0 - 12-31-2015 http://benchmarks.cisecurity.org The CIS Security Benchmarks division provides consensus-oriented information security products, services, tools, metrics, suggestions, and recommendations (the “SB Products”) as a public service to Internet users worldwide. Downloading or using SB Products in any way signifies and confirms your acceptance of and your binding agreement to these CIS Security Benchmarks Terms of Use. CIS SECURITY BENCHMARKS TERMS OF USE BOTH CIS SECURITY BENCHMARKS DIVISION MEMBERS AND NON-MEMBERS MAY: Download, install, and use each of the SB Products on a single computer, and/or Print one or more copies of any SB Product that is in a .txt, .pdf, .doc, .mcw, or .rtf format, but only if each such copy is printed in its entirety and is kept intact, including without limitation the text of these CIS Security Benchmarks Terms of Use. UNDER THE FOLLOWING TERMS AND CONDITIONS: SB Products Provided As Is. CIS is providing the SB Products “as is” and “as available” without: (1) any representations, warranties, or covenants of any kind whatsoever (including the absence of any warranty regarding: (a) the effect or lack of effect of any SB Product on the operation or the security of any network, system, software, hardware, or any component of any of them, and (b) the accuracy, utility, reliability, timeliness, or completeness of any SB Product); or (2) the responsibility to make or notify you of any corrections, updates, upgrades, or fixes. Intellectual Property and Rights Reserved. You are not acquiring any title or ownership rights in or to any SB Product, and full title and all ownership rights to the SB Products remain the exclusive property of CIS.
    [Show full text]
  • 1 Introduction
    Technical report, IDE1202, February 2012 Enhancing Network Security in Linux Environment Master Thesis in Computer Network Engineering By Ali Mohammed, Sachin Sama and Majeed Mohammed School of Information Science, Computer and Electrical Engineering Halmstad University i Enhancing Network Security in Linux Environment Master Thesis in Computer Network Engineering School of Information Science, Computer and Electrical Engineering Halmstad University Box 823, S-301 18 Halmstad, Sweden February 2012 ii Preface First of all, we would like to express our sincere gratitude to our Supervisor Philip Heimer and Professor Tony Larsson for their supervision and assistance in the entire thesis work. We are also thankful to IDE department, Halmstad University for providing this opportunity to complete this thesis. Ali Mohammed Sachin Sama Majeed Mohammed iii iv Abstract Designing a secured network is the most important task in any enterprise or organization development. Securing a network mainly involves applying policies and procedures to protect different network devices from unauthorized access. Servers such as web servers, file servers, mail servers, etc., are the important devices in a network. Therefore, securing these servers is the first and foremost step followed in every security implementation mechanism. To implement this, it is very important to analyse and study the security mechanisms provided by the operating system. This makes it easier for security implementation in a network. This thesis work demonstrates the tasks needed to enhance the network security in Linux environment. The various security modules existing in Linux makes it different from other operating systems. The security measures which are mainly needed to enhance the system security are documented as a baseline for practical implementation.
    [Show full text]
  • Secure Telnet
    The following paper was originally published in the Proceedings of the Fifth USENIX UNIX Security Symposium Salt Lake City, Utah, June 1995. STEL: Secure TELnet David Vincenzetti, Stefano Taino, and Fabio Bolognesi Computer Emergency Resource Team Italy Department of Computer Science University of Milan, Italy For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: [email protected] 4. WWW URL: http://www.usenix.org STEL Secure TELnet David Vincenzetti Stefano Taino Fabio Bolognesi fvince k taino k b ologdsiunimiit CERTIT Computer Emergency Response Team ITaly Department of Computer Science University of Milan ITALY June Abstract Eavesdropping is b ecoming rampant on the Internet We as CERTIT have recorded a great numb er of sning attacks in the Italian community In fact sning is the most p opular hackers attack technique all over the Internet This pap er presents a secure telnet implementation whichhas b een designed by the Italian CERT to makeeavesdropping ineective to remote terminal sessions It is not to b e considered as a denitive solution but rather as a bandaid solution to deal with one of the most serious security threats of the moment Intro duction STEL stands for Secure TELnet We started developing STEL at the University of Milan when we realized that eavesdropping was a very serious problem and we did not like the freeware solutions that were available at that time It was ab out three years ago Still as far as we know e tapping problem and there are no really satisfying
    [Show full text]
  • Access Control Framework
    This material is based on work supported by the National Science Foundation under Grant No. 0802551 Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author (s) and do not necessarily reflect the views of the National Science Foundation C5L1S1 When working for an institution as a Linux Administrator, you may be required to protect certain information based on its sensitivity. For instance, most organizations will have an internal network in which data contained in certain directories or drives are made public—employees can access the contents. However, certain kinds of information such as employee salaries, classified research, secret prototypes, health information, military secrets, and private communications are considered highly sensitive and are usually restrictedU the from everyone except very few people authorized to access the data. In this lesson, we will explore processes, tools, and control lists that make it possible to limit access to sensitive data on a Linux-based system. Understanding this topic is important for any system administrator configuring systems in the workplace that require access control mechanisms. C5L1S2 You should know what will be expected of you when you complete this lesson. These expectations are presented as objectives. Objectives are short statements of expectations that tell you what you must be able to do, perform, learn, or adjust after reviewing the lesson. Lesson Objective: U the Given the need to secure a Linux server, the student will recommend a set of standard Linux tools such as PAM, Access Control Lists, and TCP Wrappers to effectively secure a Linux system and demonstrate the use of one set of tools for system lock-down.
    [Show full text]
  • My Name Is Robert Kudyba and I Am the System Administrator for The
    My name is Robert Kudyba and I am the System Administrator for the Department of Computer Science here at Fordham University and a recent graduate of the Master’s in Cybersecurity. The lab will require you to install VirtualBox with Ubuntu preferable from osboxes.org. The commands listed in the lab will assume you have installed this image. Any Ubuntu version will work but if you installed from ubuntu.com then you will have to substitute the username you created for every place I reference osboxes. If you use Kali, you will be using the root user and there may be other issues as I’ve only confirmed everything works on Ubuntu. 1 In this lab, I will be gong over Linux remote access protocols Telnet and SSH, providing a history, the various encryption methods used, the concept of security through obscurity, a program called Fail2ban, how to use a Certificate Authority in OpenSSH, TCPWrapper, and Port Knocking. 2 • Telnet is a simple, text-based network protocol that is used for accessing remote computers over TCP/IP networks like the Internet. Telnet was created and launched in 1969. • Prior to telnet, you had to physically walk to a server in order to access its data. This meant, among other things, that you had to spend some time arriving at the server's location and then you had to wait for your turn to work with the server. Even if the server had the hardware power to do multiple things at the same time, you were blocked from using if someone was before you so you had to wait for others to finish their work first.
    [Show full text]
  • Unix Security
    Unix Security Vulnerability Assessment Course All materials are licensed under a Creative Commons “Share Alike” license. ■ http://creativecommons.org/licenses/by-sa/3.0/ 2 Agenda ■ Why assess ■ Where are we in the process ■ What’s needed ■ Defining vulnerabilities ■ NIST 800-53A controls ■ Assessment Exercise ■ Security Exercise ■ Conclusion 3 Vulnerability Assessment ■ Provides the opportunity to address weaknesses before an enemy can exploit them ■ Implementation: Scanning tools that identify vulnerabilities in computer hardware, software, networks and operating systems ■ Common techniques – Multiple tools – one tool may not identify all vulnerabilities – Ability to identify backdoors security perimeter, e.g. modems, VPNs, etc. – all potential vulnerabilities need to be assessed – Correction verification mechanism – ability to check if vulnerability has been eliminated ■ Compliance with OMB, DOD, DHS policy – Utilize NIST 800-53 and 800-53A – DOD 8500 series 4 What’s Needed ■ Unix experience – Hands on experience: configuration, managing, building various Unix systems – Working knowledge of best practices ■ Security Experience – Intimate knowledge of how to secure a system – Prior experience with CIS Benchmark, DISA STIG/SRR ■ Data Collection – Network scans from NMAP and Nessus – Host output from any data collection tools ■ Other Skills – Need to work with administrators – Put vulnerability in their language – Be tedious while looking for vulnerabilities – Work well in a team 5 Defining Unix Vulnerability Assessment ■ Defining Unix Vulnerability Assessment – Unix Vulnerability Assessment – Unix Security Issues – Security Paradigm – System Hardening: The CIS Philosophy – Network Based Vulnerability Scanning – Host (Local) Vulnerability Scanning – Remote vs. Local Vulnerability Scanning – Common Problems and Issues – Mitigation 6 Unix Vulnerability Assessment ■ Definition – Examining the operating characteristics of a Unix environment remotely and locally in order to accurately assess its security posture (or profile).
    [Show full text]
  • Computer Network Security Protocols: a Review
    International Journal of Enhanced Research in Management & Computer Applications ISSN: 2319-7471, Vol. 5 Issue 1, January-2016 Computer Network Security Protocols: A Review Anil Kumar Programmer-Cum-Networking Engineer, Haryana Roadways, Transport Department, Govt of Haryana, India. ABSTRACT Network security is a complicated subject, historically only tackled by well-trained and experienced experts. However, as more and more people become ``wired'', an increasing number of people need to understand the basics of security in a networked world. This document was written with the basic computer user and information systems manager in mind, explaining the concepts needed to read through the hype in the marketplace and understand risks and how to deal with them. Keywords: Protocol, Security, Secure Socket Layer (SSL) and Transport Layer Security (TLS) Protocols; secure IP (IPSec); Secure HTTP (S-HTTP), secure E-mail (PGP and S/MIME), DNDSEC, SSH. 1. INTRODUCTION The rapid growth of the Internet as bothan individual and business communication channel has created a growing demand forsecurity and privacy in this electronic communication channel. Security and privacy are essential if individual communication is to continue ande-commerce is to thrivein cyberspace. The call for and desire for security and privacy has led to several security protocols and standards. Among these are: Secure Socket Layer (SSL) and Transport Layer Security (TLS) Protocols; secure IP (IPSec); Secure HTTP (S-HTTP), secure E-mail ( PGP and S/MIME), DNDSEC, SSH, and others. In this paper I discuss these protocols and standards within the framework of the network protocol stack as follow: Application Layer Transport Layer Network Layer Data Link Layer: PGP, SSL IPSec PPP S/MIME TLS VPN RADIUS S-HTTP TACACS+ HTTPS SET KERBEROS 2.
    [Show full text]
  • Nessus 8.11 User Guide
    Nessus 8.11.x User Guide Last Updated: October 29, 2020 Table of Contents Welcome to Nessus 8.11.x 13 Get Started with Nessus 16 Navigate Nessus 18 System Requirements 19 Hardware Requirements 20 Software Requirements 23 Licensing Requirements 26 Deployment Considerations 27 Host-Based Firewalls 28 IPv6 Support 29 Virtual Machines 30 Antivirus Software 31 Security Warnings 32 Manage SSL Certificates 33 Custom SSL Certificates 34 SSL Client Certificate Authentication 35 Create a New Custom CA and Server Certificate 36 Upload a Custom CA Certificate 38 Add a Root CA 39 Create Nessus SSL Certificates for Login 40 Enable Connections with Smart Card or CAC Card 43 Connect with Certificate or Card Enabled Browser 44 Copyright © 2020 Tenable, Inc. All rights reserved. Tenable, Tenable.io, Tenable Network Security, Nessus, SecurityCenter, SecurityCenter Continuous View and Log Correlation Engine are registered trade- marks of Tenable,Inc. Tenable.sc, Tenable.ot, Lumin, Indegy, Assure, and The Cyber Exposure Company are trademarks of Tenable, Inc. All other products or services are trademarks of their respective Install Nessus and Nessus Agents 46 Download Nessus 47 Install Nessus 49 Install Nessus on Linux 50 Install Nessus on Windows 52 Install Nessus on Mac OS X 54 Install Nessus Agents 56 Retrieve the Linking Key 57 Install a Nessus Agent on Linux 58 Install a Nessus Agent on Windows 62 Install a Nessus Agent on Mac OS X 66 Link an Agent to Nessus Manager 70 Upgrade Nessus and Nessus Agents 73 Upgrade Nessus 74 Upgrade from Evaluation 75 Update Nessus Software 76 Upgrade Nessus on Linux 79 Upgrade Nessus on Windows 80 Upgrade Nessus on Mac OS X 81 Upgrade a Nessus Agent 82 Downgrade Nessus Software 85 Configure Nessus 86 Install Nessus Essentials, Professional, or Manager 87 Link to Tenable.io 89 Copyright © 2020 Tenable, Inc.
    [Show full text]
  • Nessus 8.3 User Guide
    Nessus 8.3.x User Guide Last Updated: September 24, 2021 Table of Contents Welcome to Nessus 8.3.x 12 Get Started with Nessus 15 Navigate Nessus 16 System Requirements 17 Hardware Requirements 18 Software Requirements 22 Customize SELinux Enforcing Mode Policies 25 Licensing Requirements 26 Deployment Considerations 27 Host-Based Firewalls 28 IPv6 Support 29 Virtual Machines 30 Antivirus Software 31 Security Warnings 32 Certificates and Certificate Authorities 33 Custom SSL Server Certificates 35 Create a New Server Certificate and CA Certificate 37 Upload a Custom Server Certificate and CA Certificate 39 Trust a Custom CA 41 Create SSL Client Certificates for Login 43 Nessus Manager Certificates and Nessus Agent 46 Install Nessus 48 Copyright © 2021 Tenable, Inc. All rights reserved. Tenable, Tenable.io, Tenable Network Security, Nessus, SecurityCenter, SecurityCenter Continuous View and Log Correlation Engine are registered trade- marks of Tenable,Inc. Tenable.sc, Tenable.ot, Lumin, Indegy, Assure, and The Cyber Exposure Company are trademarks of Tenable, Inc. All other products or services are trademarks of their respective Download Nessus 49 Install Nessus 51 Install Nessus on Linux 52 Install Nessus on Windows 54 Install Nessus on Mac OS X 56 Install Nessus Agents 58 Retrieve the Linking Key 59 Install a Nessus Agent on Linux 60 Install a Nessus Agent on Windows 64 Install a Nessus Agent on Mac OS X 70 Upgrade Nessus and Nessus Agents 74 Upgrade Nessus 75 Upgrade from Evaluation 76 Upgrade Nessus on Linux 77 Upgrade Nessus on Windows 78 Upgrade Nessus on Mac OS X 79 Upgrade a Nessus Agent 80 Configure Nessus 86 Install Nessus Home, Professional, or Manager 87 Link to Tenable.io 88 Link to Industrial Security 89 Link to Nessus Manager 90 Managed by Tenable.sc 92 Manage Activation Code 93 Copyright © 2021 Tenable, Inc.
    [Show full text]
  • Unix Security Overview: 1
    CIS/CSE 643: Computer Security (Syracuse University) Unix Security Overview: 1 Unix Security Overview 1 User and Group • Users – root: super user (uid = 0) – daemon: handle networks. – nobody: owns no files, used as a default user for unprivileged operations. ∗ Web browser can run with this mode. – User needs to log in with a password. The encrypted password is stored in /etc/shadow. – User information is stored in /etc/passwd, the place that was used to store passwords (not anymore). The following is an example of an entry in this file. john:x:30000:40000:John Doe:/home/john:/usr/local/bin/tcsh • Groups – Sometimes, it is more convenient if we can assign permissions to a group of users, i.e. we would like to assign permission based on groups. – A user has a primary group (listed in /etc/passwd), and this is the one associated to the files the user created. – Any user can be a member of multiple groups. – Group member information is stored in /etc/group % groups uid (display the groups that uid belongs to) – For systems that use NIS (Network Information Service), originally called Yellow Page (YP), we can get the group information using the command ypcat. % ypcat group (can display all the groups and their members) 2 File Permissions • File Permissions – The meaning of the permission bits in Unix. ∗ Owner (u), Group (g), and Others (o). ∗ Readable (r), Writable (w), and Executable (x). ∗ Example: -rwxrwxrwx (777) • Permissions on Directories: – r: the directory can be listed. – w: can create/delete a file or a directory within the directory.
    [Show full text]
  • Evaluating UNIX Security Previous Screen Allen B
    84-01-15.1 Evaluating UNIX Security Previous screen Allen B. Lum Payoff The UNIX operating system's basic security features include password protection, access permission, user profiles, shell scripts, and file ownership. Because new and enhanced UNIX security features are continually being added to these features in response to the demands of an increasingly competitive user community, information security professionals must begin with an understanding of the basic UNIX security environment. This article covers the fundamental security features that can be found in most of the currently available versions of the UNIX operating system. Several checklists are included at the end of the article to assist administrators in ensuring the security of UNIX systems. Problems Addressed The UNIX operating system was originally developed for use by programmers within an open systems environment. The adoption of UNIX as a common operating system across several different platforms has increased the need for security beyond its original purpose. As a result, many UNIX installations have less than optimal security. In addition, there are several versions of UNIX on the market today with differing security features. This article discusses basic access controls (e.g., passwords) and directory and file permissions within the UNIX system. The concepts discussed are applicable to all versions of UNIX unless specifically noted otherwise. UNIX History As the majority of UNIX users know, UNIX was developed at AT Bell Laboratories in the late 1960s by Thompson and Ritchie; the name UNIXis a contraction of uni and multics. The original UNIX system software was written in the assembler language to run on the digital PDP-7 computer.
    [Show full text]
  • Absolute BSD—The Ultimate Guide to Freebsd Table of Contents Absolute BSD—The Ultimate Guide to Freebsd
    Absolute BSD—The Ultimate Guide to FreeBSD Table of Contents Absolute BSD—The Ultimate Guide to FreeBSD............................................................................1 Dedication..........................................................................................................................................3 Foreword............................................................................................................................................4 Introduction........................................................................................................................................5 What Is FreeBSD?...................................................................................................................5 How Did FreeBSD Get Here?..................................................................................................5 The BSD License: BSD Goes Public.......................................................................................6 The Birth of Modern FreeBSD.................................................................................................6 FreeBSD Development............................................................................................................7 Committers.........................................................................................................................7 Contributors........................................................................................................................8 Users..................................................................................................................................8
    [Show full text]