AIX Down Under
You know when you go to the ATM or enter a PIN, you're told to cover up your hands so no one can look on. I wonder whether the same rule ought to apply for people on the bus who are on the phone. I've overheard passwords for what seem to be very important institutions, and I have enough non-AIX knowledge to know the root password (for Linux) or Administrator (Windows) is probably something precious.
For that matter, if IBM developerWorks - let's shorten it to ibmdw, had a root password that went something like 1bmdw123, I'd be a little worried. So why does ACME Corporation's support guy tell me - and everyone on the bus - that the root password is @cme123? Or if Fred Nurks' software runs NurksApp, would it be too much for all of their customers not to have a password such as nurk5@pp?
I have no idea if IBM developerWorks even has a root password, and I certainly hope there is no such software as NurksApp, or else my next post may be from a law court, but I think and hope that password policy has come along a little from the days when we can log in as root and have a pretty good wild guess at the password. Still, if I were a hacker, sitting and listening on the bus or train or metro is probably more helpful than doing a course on Cybercrime for Dummies.
I once heard of an Australian company with the password pajamas. (Incidentally, this was many years ago and many systems ago and so don't try to crack them). That was actually a pretty hard one to guess because in Australia, at least, we spell that word pyjamas (starting with py, not pa). The "Modern" US spelling comes from 1845:
1800, pai jamahs "loose trousers tied at the waist," worn by Muslims in India and adopted by Europeans there, especially for nightwear, from Hindi pajama, probably from Persian paejamah, literally "leg clothing," from pae "leg" (from PIE *ped- "foot," see foot (n.)) + jamah "clothing." Modern spelling (U.S.) is from 1845. British spelling tends toward pyjamas.
Yesterday you discovered that Australia's emergency number is 000, not 911.
See what you learn from following @1X D0wn Und3r?
Written by @nth0ny123
AnthonyEnglish 270000RKFN Tags:  read_write permissions security chmod umask unix_permissions chown 6,842 Views
I just read this comment about Unix permissions in a whitepaper to do with securing databases. The comment is about Progress databases, which may not exist in your environment, but the comment is worth noting anyway:
One of the solutions suggested is this:
That came from this whitepaper:
AnthonyEnglish 270000RKFN Tags:  security aix_security_expert sox auditor fpm xml sox_corbit aixpert sarbanes_oxley system_hardening aix 8,332 Views
CAREFUL, THEY MIGHT HEAR YOU
word “auditor”, of course, comes from the Latin audire
'to hear', since audits were originally presented orally. Hearing is
the auditors' profession, so there's no need to shout at them. If you say your system is secure, they're listening.
Security is your business
Many administrators see security as a burden, an obstruction to their work ... until there's a real violation. Your company, and your job depend on keeping the bad guys out (and I don't mean the auditors). It isn't just malicious attacks which can compromise your systems and even wreck your business. Security is also about stopping innocent parties from doing something dangerous without meaning to do damage. By the way, those "innocent" parties might just include you, pal.
Call in the aixpert
There are so many components to system security that it's hard to keep up with them. So the nice people at IBM did us a favour and wrapped it all up into a single command that at the same time makes you feel important: aixpert (not to be confused with the excellent AIXpert Blog). Having over 300 security settings in a single command should make your job easier. Still, you need to be careful. As I explained to a manager recently: "I can secure your operating system and break your business in a single command."
Don't do it yourself
Unless you're only managing a single LPAR, it's simply mad to script or configure all the settings one by one. Use the aixpert command. That's what it was written for. There is some very helpful documentation explaining why and how to run aixpert, including:
Interface to the expert
You can configure aixpert security settings for an LPAR
If you want to see each rule in detail and are not keen on editing XML files, WebSM provides a more granular view than the other interfaces. WebSM allows you to select or deselect a rule in a menu with common rules grouped together (e.g. Password Policy, Login Policy, Tuning Network Settings). To use WebSM you will need to set up an X-Session. The recommended way, though, is by running aixpert on the command line. You can do this in conjunction with XML files provided for the AIX Security Expert.
XML for aixpert
ALL available aixpert settings which you can choose from are in the file /etc/security/aixpert/core/aixpertall.xml This file includes the level of security you have selected, a description of each of the rules and the actual commands which are run for each rule.
All the settings you last applied via aixpert are saved into an XML file called /etc/security/aixpert/core/appliedaixpert.xml
If you choose a security level (high / medium / low or default, which is lower than low), then only those rules for that level will be applied. (Each rule name starts with a three-character prefix i.e. hls= high level security, mls = medium, lls = low, dls = default). You could then create a set of these rules (e.g. high level), save it to an XML file and then strip out or tailor that list of rules for your system. You can also run a check on your appliedaixpert.xml file (if it exists) to see which security rules fail to comply. These would be the rules you either want to fix or explain to the auditors why they are not applicable for your environment.
XML for smarties
Having all your settings in a single XML file allows you to edit the file, view it in a spreadsheet or XML editor, and distribute the same rules to other LPARs and apply them using aixpert -f filename.xml. This also enables you to retain a history of XML files, provided you save them off to some other file name or back them up. It's a smart way of doing it.
Although the aixpert tool is undoubtedly helpful, here are some initial findings which I have yet to confirm, but which are worth being aware of as potential problems.
With all those difficulties, is it still worth using aixpert? Yes, I would say so. Each of the warnings has a simple enough workaround , and saving XML files as you go is usually it. The question is not whether aixpert is worth the trouble. It's whether not using it is worth the risk. Don't tell me your system is secure; tell the auditors. They're paid to listen.