Showing posts with label Security. Show all posts
Showing posts with label Security. Show all posts

2015/04/07

Syslog on NetApp

Data Ontap has the ability to send system log messages to an industry standard syslog server (see https://library.netapp.com/ecmdocs/ECMP1196979/html/man5/na_syslog.conf.5.html)

To cause your Netapp to start logging to a syslog server named "logs.mycompany.com", you would use the wrfile to (over)write the syslog configuration file, directly from the console; leave a blank line at the end, and use ctrl-c to conclude the edit:

mynetapp> wrfile /vol/vol0/etc/syslog.conf
*.info    /dev/console
*.info    /etc/messages
*.info    @logs.mycompany.com
auth.*    @logs.mycompany.com
cmdsaudit.auditlog    @logs.mycompany.com



mynetapp>


(You should then see "syslogd restarted" shortly, when the NetApp detects the config file change.)

The "cmdsaudit.auditlog" line causes all console commands that are entered to also be logged to syslog -- thus, you have a record of who did what, when.

2015/01/21

View package changelog prior to updating

On Redhat/CentOS systems, have a look at the Yum "Changelog" plugin, "yum-plugin-changelog" or "yum-changelog" package

See “man yum-changelog”.


This lets you see what has change on a package between the version that is already installed and the latest available version.

Go to a system, and run “yum  update --changelog”

Or, for a narrower view, try: “yum update kernel --changelog”

We should use this when we patch, to understand what is changing and to scope potential impact, rather than to simply “patch and pray”.  Alone it is not enough (release notes should also be reviewed where available), but it is a good start and may help in flagging potential problems.


In particular, we should look at this on critical infrastructure servers, especially for those that get their software from external repositories where the software changes may be more impactful than standard RedHat/CentOS packages (which generally remain on the same version, with only back-ported bug and security fixes).

2014/08/28

Authentification is not a word

Whether one is referring to...

authentication - the validation of credentials (i.e., "Yes, you are who you claim to be")
authorization - the validation of whether access should be granted based on that identity (based on role, group membership, policy, ACL, etc.) (i.e., "Yes, that user is allowed to access that resource")

...the word "authentiFIcation" never comes into play... nor authentify, authentificated, etc.

Identification / identify is a valid word, mind you.

Just saying...

2014/04/11

Create Postgres read-only user (pre 9.x)

Here’s how I created the user; due to limitations in postgres 8.1, this user will not have access to any new tables (such as may be created during an upgrade of the application); the process is much easier than this for postgres 9.1+.


(Credit to this helpful user http://stackoverflow.com/a/762649 ; I just want to show it in action and spread the love. )

First, connect to postgres, then list databases, then connect to the correct one, then create the DB user.
[root@mycomputer ~]# su - postgres
-bash-3.2$ rpm -qa | grep postgres
postgresql-libs-8.1.23-10.el5_10
postgresql-8.1.23-10.el5_10
postgresql-server-8.1.23-10.el5_10
-bash-3.2$ psql
Welcome to psql 8.1.23, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
       \h for help with SQL commands
       \? for help with psql commands
       \g or terminate with semicolon to execute query
       \q to quit

postgres=# \list
         List of databases
    Name    |   Owner    | Encoding
------------+------------+----------
testdb | testdb | UTF8
postgres   | postgres   | UTF8
template0  | postgres   | UTF8
template1  | postgres   | UTF8
(4 rows)

postgres=# \c testdb
You are now connected to database "testdb".
testdb=# CREATE USER testdbread WITH password 'supersecretpassword';
testdb=# GRANT USAGE ON SCHEMA public TO testdbread;
GRANT

# This command creates a list of GRANT commands that you can copy and paste to grant access to existing tables:
testdb=# select 'GRANT SELECT ON ' || relname || ' TO testdbread;' FROM pg_class JOIN pg_namespace ON pg_namespace.oid = pg_class.relnamespace WHERE nspname = 'public' AND relkind IN ('r', 'v', 'S');
                         ?column?
----------------------------------------------------------
GRANT SELECT ON usermigration TO testdbread;
GRANT SELECT ON plugindata TO testdbread;
GRANT SELECT ON os_propertyentry TO testdbread;
GRANT SELECT ON os_user TO testdbread;
GRANT SELECT ON attachments TO
testdbread;
(5 rows)
# Now, copy and paste those lines, then exit:



testdb=# GRANT SELECT ON usermigration TO testdbread;
GRANT
testdb=# GRANT SELECT ON plugindata TO testdbread;
GRANT

testdb=# GRANT SELECT ON os_propertyentry TO testdbread;
GRANT

testdb=# GRANT SELECT ON os_user TO testdbread;
GRANT
testdb=# GRANT SELECT ON attachments TO testdbread;
GRANT
testdb=# exit
testdb-# \q
-bash-3.2$ logout
[root@mycomputer ~]#

2014/04/09

Protect and access your passwords anywhere

Web sites are regularly compromised and your data may be compromised.  Server applications have as-yet-undiscovered weaknesses, as do even security appliances and encryption protocols.  The Heartbleed vulnerability with the very widely used OpenSSL was recently made public.  The details on how and even whether it may have been used to compromise data are not as clear to me.  However, we know that the vulnerability can allow sensitive data to be stolen from devices that use it for encryption.

In any case, if you haven't rolled your passwords in a while, this could be a good time to do so.  If you're doing so, it should also be a good time to finally start protecting your online and financial identities in this well-connected world the same way you lock the door on your home and perhaps have an alarm on your car.

Others may/will disagree, but here's what I recommend, as a way to (1) always have strong passwords, (2) reduce risk of a compromise of one account meaning other things get compromised, and (3) ensure that you can always get to your passwords in a pinch, any time, from nearly any device.

  1. Use a local storage password keeper program, one that never uses unencrypted temporary files and has sensible semantics for automatically backing itself up and locking itself.  I like Password Safe, for example. Download the latest here: http://sourceforge.net/projects/passwordsafe/files/passwordsafe/  (supports Windows, Linux, Android, MacOS X, iOS) 
  2. Use a free backup program and service from a reputable (publicly traded, with a lot to lose if they abuse your data,) to sync your encrypted password safe and ensure it survives local hard drive failures.  I use DropBox.  Dropbox lets you have a "dropbox" folder on your local computer (Windows, Linux, Android, MacOS X, iOS) that is automatically backed up to a cloud, and makes the files accessible from other computers (e.g., between yours, mom's laptop, and home PC; even via the web, and from Android and iOS phones).  Once you have run password safe and "saved" your password safe to your "Dropbox" folder, it is backed up automatically.
  3. With two exceptions, all of your passwords will be completely random; only your password keeper program and your password safe will have phrases that you can remember, that nobody else could guess, and that are different from each other.
    1. I suggest picking a sentence that only you would know for your password, something from your childhood like: "Oh, how I loved camp chatta-wookie as a child." (If you thought to use that exact phrase, repent and sit in the corner for 5.)
    2. Better yet, let your spouse choose a phrase that you can both remember. Like a sentence about a great memory -- you get the idea.  Then you can share the same password safe.  If something happens to one of you, the other can still log in to your sites to take care of business.
    3. You could use a favorite line from a book, but you need to change it in a way that someone else would not use or guess the exact same phrase; e.g., don't use "For God so loved the world" or "Et tu, Brute?", because those are very common phrases.
  4. Create an account with your online backup/sync provider using the pass phrase advice in the last step.  You will need to be able to recall this if you ever want to access it from a computer other than your regular PC/laptop, or if your local hard drive fails.  This is the one password that you may write down somewhere and keep in your safe. Compromise of this phrase will allow someone to get at your synced files, but they won't be able to get your passwords -- those will be encrypted using a different password.
  5. Start up the password safe program and assign a different passphrase than the one you used for your online backup/sync provider.  If you forget this pass phrase, you're out of luck.  Save your new password safe data file to the location that your backup provider uses. For drop box, that would be a "Dropbox" folder under your home directory or documents folder.
  6. Now, go to each site where you have an account and change the password, recording it in the password safe program and following this method:
    1. For Title, use a name of the service so that you can find it quickly in the list. When your list grows large, you'll want something that is meaningful
    2. For Username, use the exact username as you use it to log in.
    3. For password, click "Generate".  For details on how to configure Password Safe to be naturally stronger, see below.  If you're not going to use strong, unique (if not random) passwords, then nothing else you do will matter too terribly much, and you have left your windows unlocked and inviting.
    4. Copy and paste the generated password into your web site in the change password / new password field.
    5. URL: specify the web site URL, if it's a web site. This will help you to remember how to get to the exact site, or to search your list of passwords more easily.
    6. Use "Notes" to record stuff you'd need to remember. You might record the date you opened the account, or answers to security questions (see below on security question).
    7. Click "OK" to apply.  I like to go into password safe and configure it to automatically save every time I change a password. I also like to configure it to *not* use the system tray, so it actually exits and closes when I click the close button.
  7. Thoughts on passwords
    1. Always let let your password safe program randomly generate passwords for every site where you register.   Perhaps the only exceptions would be your main email account, your password safe "combination", and your data sync/backup site.  Set those to other sentences that you will always remember. 
    2. Never, ever use the same password twice.
    3. Using random and unique passwords ensures that if a person gets a password or access to one site, they'll have a harder time getting access to another site. Consider that some IT staff and related functions may be able to actually see your passwords that you used to register for sites at companies you deal with; if you use the same passwords, an unscrupulous IT staffer could then simply guess what sites you might use in order to gain access to other accounts and steal your data or impersonate you.
    4. Ensure that the passwords are long and complex (10+ characters, including alpha, num, and punctuation where the site permits it).  In Password Safe, you configure the "password policy" using the Manage menu --> Options --> Password Policy.
    5. Never write down your passwords elsewhere for any site.  Even silly sites.  Compromising silly sites is one way for someone to socially engineer their way into assuming parts of your identity or learning more about you to compromise the rest.  An exception would be to put the password in your strong home safe (not in a locking drawer that can easily be broken into).
    6. Never access services like these from a public or shared computer. Never.
  8. Thoughts on security questions:
    1. Generally speaking, security questions are a bad idea: they provide in some circumstances a backdoor to bypass the best passwords; and it is too easy for other people to socially engineer in order to take advantage of security questions.
    2. How many people know the name of your pet, your first school, the street on which you grew up, your teachers, mother's maiden name?  Too many. Much of it is public knowledge; much can be gleaned by casual strangers from social networking sites.
    3. My recommendation for security questions?  Give bogus, random-ish answers, and store those questions and answers in the "Notes" section for that account in your password safe.  If the answer is false and unrelated to real life, it will be much harder for a ne'er do well (old boyfriend, identity thief, etc.) to provide those answers to gain access to an account.
  9. Thoughts on the complexity, and the rule of KISS:
    1. While I understand that this is not as easy as using a password sync service, I still prefer this methodology, in part because I do not necessarily trust any vendor with a single point of access.
    2. Because password safe encrypts the file locally, and that encrypted file is synced to a private dropbox account, there is not a single person that could potentially have access to my data: even if password safe's encryption is compromised (and it will be, like everything), then someone would still have to gain access to the encrypted datafile on my personal dropbox account or on my personal computer. 
Now, if you've done all of this, then you are more protected than otherwise against password guessing and other attacks, and you can get to your passwords from any computer, even an android phone, as long as you remember your password safe account (and your dropbox password, if you don't have any other computer).  

You'll never keep the NSA away from your passwords, data, and accounts, but this should keep organized crime and casual miscreants away.

Using this method, I even have secure access to my passwords from my smart phone when I need them.  And I don't have to actually remember but a couple of passwords.

I welcome your thoughts and critiques. Everybody has blinders, perhaps you've found a problem with this method?

2013/07/02

Manipulate windows firewall from CLI

The windows firewall UI is a bit cumbersome.  This method will let you set up a host reliably to be secure, and to allow only inbound traffic that you want.

Enable firewall in all profiles (home / domain / public)
netsh advfirewall set allprofiles state on

By default, deny all inbound and allow all outbound traffic
netsh advfirewall set allprofiles firewallpolicy blockinbound,allowoutbound

Add rule to allow SMTP traffic inbound to a specific port from a specific network range
netsh advfirewall firewall add rule name="Allow Inbound TCP/25 from SMTP relay hosts" protocol=TCP dir=in localport=25 action=allow remoteip=10.20.30.0/24


Add rule to allow all HTTP and HTTPS traffic inbound
netsh advfirewall firewall add rule name="Allow Inbound TCP/80 from everywhere" protocol=TCP dir=in localport=80 action=allow

2010/08/20

Import an SSL cert from a URL

This info is from Capital City Consultants, plus some insight from this great page (http://gagravarr.org/writing/openssl-certs/others.shtml#selfsigned-openssl ), and it works:

You'll need the openssl program, from www.openssl.org

To save a cert from a web server:
openssl s_client -connect www.example.com:443

or, to save a cert from an LDAP server:
openssl s_client -host DC01.AD.example.com -port 636

..in either case, ctrl-C out of the openssl program, and copy and paste the certificate text
-----BEGIN CERTIFICATE-----
MIIBzTCCATasadfsd803tdsasdtadsa/XuDQwDQYJKoZIhvcNAQEFBQAwFDESMBAGA1UE
(snip)
zjl2l707W5pffEhKVvuG2W3ipuAtXrMgmfeWsrkQtg0e
-----END CERTIFICATE-----

into a file, e.g., www.example.com.cert .

To do that programmatically, try:
openssl s_client -host DC01.AD.example.com -port 636 | awk '/BEGIN/{s=x}{s=s$0"\n"}/END CERTIFICATE-----/{print s}'








You will find that the openssl s_client command hangs -- it is awaiting data on the established ssl connection.  You can address this programmatically by sending it the "quit" command, e.g.:

echo quit | openssl s_client -host DC01.AD.example.com -port 636 | awk '/BEGIN/{s=x}{s=s$0"\n"}/END CERTIFICATE-----/{print s}'

Now, use your tool/application to import that certificate.

For Linux system openssl store:

First, get the hash of the cert:
echo quit | openssl s_client -host DC01.AD.example.com -port 636 | awk '/BEGIN/{s=x}{s=s$0"\n"}/END CERTIFICATE-----/{print s}' | openssl x509 -noout -hash

That will output a number like "a837f31d".

Next, save the real cert into a file by that name, plus ".0"
echo quit | openssl s_client -host DC01.AD.example.com -port 636 | awk '/BEGIN/{s=x}{s=s$0"\n"}/END CERTIFICATE-----/{print s}' > /etc/pki/tls/certs/a837f31d.0

And last, create a sym-link to the hashed cert, so that you remember which is which, and so that you can update it more easily:
cd /etc/pki/tls/certs
ln -s a837f31d.0 DC01.AD.example.com.crt

For a java keystore:

keytool -importcert -keystore jssecacerts -alias www.example.com -file www.example.com.cert

2007/02/16

sudo: sudoers examples

Sudo can be used allow users to execute certain commands as other users (including root) on certain machines, with logging.

Edit the sudoers file with visudo. Note that to execute many system commands, your PATH will need to include /sbin:/usr/sbin

See what access is allowed with "sudo -l".

The best example file I found was at http://www.gratisoft.us/sudo/sample.sudoers , except that is uses "!", which is pointless (commands can be copied).

## Sample sudoers file ##
# *** Host_Alias specifications ***
# Host_Alias seems not to be useful, unless you have a
# global sudoers file that is replicated across multiple hosts.

# make LOCAL mean localhost (probably a bad idea, as this will allow it to run on any machine that has the sudoers file)
Host_Alias LOCAL = 127.0.0.1
# Anywhere that "LAN" is specified, these hosts apply:
Host_Alias LAN = ahost.mycompany.com, anotherhost.mycompany.com

# *** User_Alias specifications ***
# User_Alias allows you to group users. (better to use AD/NIS groups, for global/central management?)
# MAILADMINS user alias refers to users dick and jane
User_Alias MAILADMINS = dick, jane

# *** Runas_Alias specifications ***
# This specifies an alias or grouping of whom a command can be run as.
Runas_Alias SOMEONE = larry, tom

# *** Cmd_Alias specifications ***
# alias or group commands with full paths, to make things easier to read later.
Cmnd_Alias SU = /bin/su

Cmnd_Alias SMTP = /sbin/service postfix stop, /sbin/service postfix start, /sbin/service postfix status
Cmnd_Alias REBOOT = /usr/bin/reboot, /sbin/shutdown -r now

# *** Defaults specification ***
# make user john.doe not have to enter a password to run commands as another user
Default:john.doe nopasswd
# make user kate have no timeout, and add env variable "GOO" to the sudo environment, and run as linda by default, but always require the root password
Defaults:kate timestamp_timeout=-1, env_delete+="GOO", runas_default=linda, rootpw
# make user jim have to enter the password of whoever he's running a command as, every time, with 1 attempt allowed
Defaults:jim timestamp_timeout=0, runaspw, passwd_tries=1
# global defaults - log to a specific file.
Defaults logfile=/var/log/sudo.log, log_year

# *** User Privilege specification ***
# This is where we actually say who and where (as whom) can do what
#
user/%group hostname = (user) command
# by default, root can do all commands as all users

root ALL=(ALL) ALL

# users jake and jim, on localhost, can execute crond without entering a password. (probably a bad idea)

jake,jim LOCAL = NOPASSWD: /sbin/service crond restart

# allow MAILADMINS on hosts LAN to run as root the commands SMTP and REBOOT.

MAILADMINS LAN = (root) SMTP, (SOMEONE) REBOOT

# members of the group "wheel" can run, on all hosts, all commands as all users

%wheel ALL=(ALL) ALL

2007/02/14

Selinux tips

Here are some really good SElinux resources:

http://www.linuxsecurity.com/content/view/120567/49/
http://www.linuxsecurity.com/content/view/120622/49/
http://www.linuxsecurity.com/content/view/120700/49/
http://www.linuxsecurity.com/content/view/120837/169/
http://www.it-observer.com/articles.php?id=1013

Touch up a folder for apache to access (change file context labels recursively):
chcon -R -t httpd_sys_content_t

Touch up a folder for samba to access (change file context labels recursively):
chcon -R -t samba_share_t /backups


To reset the labels on all mounted filesystems:
restorecon -Rv /

If you need the filesystems to be relabeled on bootup, do this and then reboot:
touch /.autorelabel

To boot once with SELinux enforcement disabled, add the enforcing=0 flag to the kernel boot line.

To get the kernel's enforcement status:
getenforce

To change the kernel's enforcement status to "permissive" (aka log-only):
setenforce 0
To change the kernel's enforcement status to "Enforcing" (aka block access):
setenforce 1
(edit /etc/selinux/config to make the changes persistent across reboots)

2006/11/17

Quickly create or request ssl certificate for Apache

#Create different directories for the different data (this is the path for RedHat derivatives)
cd /etc/httpd/conf
mkdir ssl.csr ssl.key ssl.crt
chmod 700 ssl.*

Self-Signed Certificate

# Create the cert request. Common Name (CN) should be the FQDN, e.g., myhost.foo.com
# 2048 bits is probably adequate these days. Expiration more than 5 years makes little sense.
# PEM passphrase is what the server process (or user) will have to type to use the cert; it
# can be bypassed if you want with the key file in the next step.  EDIT: current versions
# of openssl that ship with CentOS/RHEL do not let you bypass the PEM
# passphrase. Give it one, then create the key file if you want to eliminate the need for it.
openssl req -newkey rsa:2048 > ssl.csr/myhost.foo.com.csr

# create the key file, myhost.foo.com.key (careful! this makes it so that e.g. httpd will
# not prompt for the key on startup, but so that the cert is easily
# read if the host is compromised.)
openssl rsa -in privkey.pem -out ssl.key/myhost.foo.com.key

# self-sign/create the cert, myhost.foo.com.crt
openssl x509 -in ssl.csr/myhost.foo.com.csr -out ssl.crt/myhost.foo.com.crt -req -signkey ssl.key/myhost.foo.com.key

Externally signed certificate request
openssl req -newkey rsa:1024 -keyout ssl.key/myhost.foo.com.key -out ssl.csr/myhost.foo.com.csr

mail the myhost.foo.com.csr file to your ssl provider.
Make the key unencrypted if you want:
openssl rsa -in ssl.key/myhost.foo.com.key -out ssl.key/myhost.foo.com.key.unenc
...and reference the unenc file in your ssl host config file. This will prevent having to enter the encryption key passphrase every time the httpd is restarted, but it will mean your key could be compromised if the box is compromised.