Automating LINUX Password Audit

As most of you might know, LINUX stores the user password information in the shadow file which can be accesses from /etc/Shadow. For those ofyou, who are experts in LINUX, reading the shadow file and obtaining password related information might be easy. However for those new/un-aware of the LINUX system but still have to audit them often, this tool might be of great help. This is a simple script which analyzes the shadow file and provides the output in a simple text file. The output file has the following information

1. User Name 2. Password Set to Expire (YES/NEVER) 3. Account Status (Disabled/Active) 4. Password Last Changed (in Days)

This is how a etc\shadow file looks like and has the following information

/etc/shadow file fields (Fig.01: /etc/shadow file fields) User name : It is your login name Password: It your encrypted password. The password should be minimum 6-8 characters long including special characters/digits Last password change (lastchanged): Days since Jan 1, 1970 that password was last changed Minimum: The minimum number of days required between password changes i.e. the number of days left before the user is allowed to change his/her password Maximum: The maximum number of days the password is valid (after that user is forced to change his/her password) Warn : The number of days before password is to expire that user is warned that his/her password must be changed Inactive : The number of days after password expires that account is disabled Expire : days since Jan 1, 1970 that account is disabled i.e. an absolute date specifying when the login may no longer be used.

The last 6 fields provides password aging and account lockout features (you need to use chage command to setup password aging). According to man page of shadow - the password field must be filled. The encrypted password consists of 13 to 24 characters from the 64 character alphabet a through z, A through Z, 0 through 9, \. and /. Optionally it can start with a "$" character. This means the encrypted password was generated using another (not DES) algorithm. For example if it starts with "$1$" it means the MD5-based algorithm was used.

I hope this small tool will make the lives of the auditor a little easier. Reach me at arvind.mehta16@gmail.com and I would send you this free tool.

Arvind

Technology Risk Advisor

CISCO PIX Firewall Audit Tool

Long time since I wrote something!!! BUt let me tell you I'm not out of touch as I was writing for some external websites and magazines and didnt get time to write for my own blog. Well this is for IT auditors having issues assessing CISCO PIX firewalls. I had a new team for one of my recent assignment where we had to assess the IT controls for our client. We had to evaluate the firewalls and generate a fancy report as always required by the management. Some of my team members were fairly new to firewalls and we had ton's to verify level 1 security for all of location around the globe. This is when I got an idea to create a script that goes through the firewall's running config and verifies the various security configurations.

This program, written in VBScript makes use of WMI routines while reading the configuration file in offline mode. (requires you to provide running config as input in txt format). This way you dont even have to touch you firewall and take the risk of some external program runing your current configuration.

This little script audits the running config which is provided as an input (when it asks for it) and prepares a fancy excel report which has information on two separate sheets. The first sheet has the following information and a comparision with industry leading recommended values for level 1 security settings like:

1. Password Encryption 2. Logging/mode of logging 3. SYSLOG 4. AAA 5. IDS status 6. Failover configuration 7. Timeouts 8. Login Banner 9. SSh configuration.

The second sheet give you little more details on the following critical areas which you can use for further planning and scoping your detailed audit analysis. It also verifies the following details:

1. Local users created on the firewall with their privilege levels

2. Allowed protocols

3. Interfaces in uses with the security level assigned.

Here's a sample of the report that is generated by this program.

The program really helped us reducing the overall effort and time in evaluating the multiple page running configs and preparing reports for management.

Feel free to write to me at arvind.mehta16@gmail.com if you think this program might help in performing you tasks in a more efficient and effective manner.

Keep visiting for more information.

Cheers

AM

Auditing RACF Security

During my span of 3 years with information security and auditing, I've came across very few checklists/leading practices to ensure the security of a RACF (OS390/Z-OS) environment. Although RACF and Mainframes are not used widely by the corporates nowadays because of the ease of use with MS Windows, but they Mainframes is still the most stable environment and used by most of the financial firms and banks.

I thought of creating a simple checklist which will give an individual basic idea about what to look for while performing an audit of a RACF system on OS390/Z-OS. This includes password parameters, user administration and security etc.

• Enquire about the state of IBMUSER account (default). What is the current attributes for the account.
• Obtain the list of RACF users with SPECIAL/AUDITOR/OPERATIONS attributes assigned.2. Also enquire about users having CLAUTH(USER), CONNECT, JOIN, or GROUP-SPECIAL attributes.
• Obtain the SETROPTS report from the system administrator.
• Validate the PASSWORD PROCESSING OPTIONS to confirm that parameters like COMPLEXITY, HISTORY, LENGTH and ACCOUNT LOCKOUTS are configured.Recommended Password Configurations for MVS systemsLENGTH: 6:8 (Min 6 and Max 8)HISTORY: 10 Passwors remembered.CHANGE INTERVAL: 45 days LOCKOUT: After 4-5 unsuccessful logonsCOMPLEXITY: ALPHANUM
• Validate that none of the users have non-expiring passwords without a valid business justification.
• Determine RACF RVARY SWITCH and STATUS passwords have been changed?
• Obtain the list of datasets with the selection criteria as APF along with the UACC.
• Review the list to validate that none of the APF assigned datasets have UACC=ALTER/UPDATE.
• All APF Datasets should have UACC=READ or NONE.
• Obtain the SETROPTS report from the system administrator.
• Look under the SETROPTS LIST category to validate that JES-ATTRIBUTES configuration is set to SAUDIT, CMDVIOL and OPERAUDIT. SAUDIT: Specifies whether RACF commands issued using SPECIAL authority are logged CMDVIOL: Specifies whether RACF command violations are logged. OPERAUDIT: Specifies whether RACF commands issued & resources accessedusing OPERATIONS authority are logged
• Obtain the DSMON Program Properties Table report
• Validate that none of the program entries are defined to bypass the password protection by looking at the NOPASS option.
• Determine if SMF files are adequately RACF protected.
• Identify the active SMF parameter definitions.
• Identify the SYS1.MANx files defined by DSNAME() parameter and validate that nonoe has ALTER\UPDATE access by reviewing the dataset ACL.
• Validate that the following SMF record types are being collected by looking at REC, MAN and DSV parameters. RECORD TYPES 0 , 90 System IPL 7 SMF lost data 5,35 Job record 4,34 Program record 80,81 RACF 60-69 VSAM information 30 Combined record (replacing types (4,5,34,35) 14,15,17,18 Dataset information
• Validate that JOB WAIT TIME (JWT) parameter is configured to an appropriate time.
• Review the list of installation defined Supervisory Calls (SVC's).
• Determine that none of the SVC's is defined as APF=NO
• If any of the SVC's are defined as APF=NO, confirm that TESTAUTH macro is used to control the use of the SVC(s), by reviewing the source code of the SVC.

Client Security

We always think to secure our servers but security on the client machines is always overlooked simply because there are so many of teaming it is difficult to completely secure them. Whereas client machines are the one which are more prone to security risk. There is no physical security for the client machines. Client machines are used to connect to internet from a Cafe, on Airports, using public wireless etc which makes it more easier for aan attacker to break into it. Some of the following loop holes which are overlooked are: 1. Removable Storage on the client machines. Organizations have always planned to lock down removable media, a key means of introducingunwanted software into the environment and for removing confidential information from theenvironment.Because most removable media support only the FAT, FAT32, or CDFS file systems, none of which support security permissions. Thus,removable media not only represents an opportunity to introduce unwanted software and to removeconfidential data but also ensures that any data removed from the environment will be completelyunsecured. Although some removable media offers security options such as encryption, there is nocentralized means of enforcing the use of such features, making it less likely that users will do so. 2. Maintaining the Local Administrator accountClient machines often contain sensitive data, but their adenine accounts are so rarely maintained that the computer becomes a more likely target for an attacker Local Administrator password on the client machines should be changed more frequently. You can use a VBScript to change the password on multiple machines. Set objFSO = CreateObject("Scripting.FileSystemObject")Set objComp = objFSO.OpenTextFile("C:\ClientMachines.txt")Do Until objComp.AtEndOfStreamsComputer = objComp.ReadLineSet objUser = GetObject("WinNT://" & sComputer & "/Administrator, user") objUser.SetPassword "password"objUser.SetInfoLoopobjComp.Close3. NTFS permissions on the client machines.Consistent file permissions are crucial to enterprise security.Windows security templates can be used to create a consistent NTFS permissions structure on client machines.4. Services running on client machines. By disabling services that you are not utilizing, you will help prevent these services from becoming an attack vector in the future. The services which are not used in your organization should be disabled. 5. Local System PermissionsLocal system permissions is another area which nobody bothers about. Consider Cmd.exe, a file thatis usually located in C:\Windows\System32. The Figure shows the file permissions on Cmd.exe on a Windows XP Professional computer that has been upgraded to SP2. Notice that the SYSTEM account has Full Control. Why would the system itself need to open anew command-line window? I typically remove the SYSTEM account from this and many otherfiles in the file system.Also notice that the Internet Guest Account has permissions to run Cmd.exe. Anonymous usershave the ability to open a command-line window and execute commands. Spend some timeinvestigating the default permissions on the many files and folders lurking around in Windowsand to apply more sensible defaults. Some other files you might want to investigate include:Command.com Tftp.exe Telnet.exe WScript.exe CScript.exe Net.exe ftp://ftp.exe/ All these powerful utilities can create significant havoc if an attackergains access to them. Reduce the likelihood of that happening by removing access from any account that doesn't absolutely need to have it.