• Create key: openssl genrsa -des3 -out vpn-cert2.key 1024
• Create CSR (make sure that the CN is a simple name, no spaces or special characters): openssl req -new -key vpn-cert2.key -out vpn-cert2.csr
• Request certificate with your CA
• Create a p12 file from the key and the certificate: openssl pkcs12 -export -inkey vpn-cert2.key -in certnew-3.cer -out vpn.p12
• Import the p12 file (containing the key and certificate) in the system keychain (not the login keychain, that doesn’t work): sudo security import vpn.p12 -k /Library/Keychains/System.keychain
• If needed you can import the CA in your keychain and trust the imported certificate: sudo security add-trusted-cert -k /Library/Keychains/System.keychain root.ca.pem
  Note:Make sure that if you import your own CA, that you do it this way. Otherwise the VPN server certificate will not be verified correctly.

To use the certificate for VPN authentication do the following:

• Open System Preferences
• Go to Network
• Click + to add network interface, Select Interface: VPN, VPN Type: Cisco IPSec
• Click Create
• In the Server Address type the hostname of the firewall. This is really important. The firewall has a certificate configured on the FQDN. Make sure the server address is the name of the certificate in the firewall. This FQDN can be found in the trustpoint configuration (see below)
• Enter the username
• Click Authentication Settings
• Select Certificate and Click Select
• Select the correct certificate that you just imported
• Click OK
• Click Apply

When you are not able to select the certificate you created the problem is that the CN is not supported. Make sure the CN that you used to create the CSR does not contain spaces or special characters.

Firewall trustpoint config:

crypto ca trustpoint CA1
enrollment terminal
fqdn fw.xxxx.com
subject-name CN=fw.xxxx.com,OU=IT,O=XXX Limited,C=NL,St=NH,L=Amsterdam


Now I found the problem, I thought it was easy to fix it. I just had to make MySQL case-insensitive. This sounds easier than it actually was Lots of articles talked about the character set and the collation, but these only affect the data in the tables, not the actual table name itself. Some googling let met to the lower_case_table_names setting in MySQL. It appears that Windows, Unix and MacOSX all have different default settings, and therefor behave differently.

Setting the following line in the my.cnf in the [mysqld] section solved my case problem with SplashID. MySQL now changes all table names to lower case.

lower_case_table_names=1


Update: I have not tested SplashID Enterprise yet, so I don’t know if it is any good

Your-Face-Will-Soon-Be-In-Facebook-Ads
facebook-apps-kunnen-meer-privedata-gaan-opvragen
rogue-facebook-apps-access-your-home-address-mobile-phone-number
Facebook-Opens-Up-Home-Addresses-and-Phone-Numbers
facebook-app-permissions.html
Private photo’s public?
Afgeschermde facebook foto’s zichtbaar
facebook exploit macht alben nicht freunden einsehbar

Of course, there are also positive sides on facebook and what its use and users can achieve with it:
The-Inside-Story-of-How-Facebook-Responded-to-Tuni

I know facebook is a free service (as in beer), but that should not mean that they can use your data whichever way they want…

Some investigation showed that this was caused by a default maximum MSS setting in the ASA. It appears that the ASA has a default max MSS of 1380. This is set by the command:

sysopt connection tcp-mss MSS_size_in_bytes

The default is 1380 to prevent fragmentation on possible IPSec connections in the path.

To get to MTU 1500 the ASA needs to support an MSS of 1460. This is configured with the following command:

sysopt connection tcp-mss 1460

More information can be found here:

• http://cisco.com/en/US/products/ps6120/products_configuration_example09186a008081e621.shtml
• http://fixunix.com/firewalls/347579-cisco-asa-5510-mss-issue.html

Step 1: Enable network access for libvirtd
First enable network access for libvirtd on the KVM server(s). On CentOS/RHEL this is done by uncommenting or adding the following line in /etc/sysconfig/libvirtd:

LIBVIRTD_ARGS="--listen"


Step 2: Install a CA on the management server
Install the Perl certificate tools:

yum install openssl-perl

Create Certificate authority:

cd /etc/pki/tls/misc/
./CA.pl -newca

Example output:

./CA.pl -newca
CA certificate filename (or enter to create)

Write out database with 1 new entries
Data Base Updated


Step 3: Create CSR’s

openssl genrsa -des3 -out kvm-server1.tmp
openssl rsa -in kvm-server1.tmp -out kvm-server1.key
openssl genrsa -des3 -out mgmt-host.tmp
openssl rsa -in mgmt-host.tmp -out mgmt-host.key
openssl req -new -key kvm-server1.key -out kvm-server1.csr
openssl req -new -key mgmt-host.key -out mgmt-host.csr


Step 4: Sign the certificates

openssl ca -config /etc/pki/tls/openssl.cnf -policy policy_anything -out /root/mgmt-host.crt -infiles /root/mgmt-host.csr
openssl ca -config /etc/pki/tls/openssl.cnf -policy policy_anything -out /root/kvm-server1.crt -infiles /root/kvm-server1.csr

Example output:

Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for /etc/pki/CA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number:
d8:95:24:4b:4e:b1:13:9c
Validity
Not Before: Feb 25 23:31:40 2010 GMT
Not After : Feb 25 23:31:40 2011 GMT
Subject:
countryName = XX
stateOrProvinceName = XX
localityName = XX
organizationName = XX
organizationalUnitName = XX
commonName = mgmt-host.xxx.nl
emailAddress = xxxxx
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
6C:EA:8B:C1:D6:XX:B6:6B:5B:18:02
X509v3 Authority Key Identifier:
keyid:C9:36:4A:XXXX:6F:FD:2E:86

Step 5: Copy over the certificates to the correct location
On the management host (mgmt-host):

mkdir /etc/pki/libvirt
mkdir /etc/pki/libvirt/private
mkdir /etc/pki/libvirt-vnc

cp /root/mgmt-host.key /etc/pki/libvirt/private/clientkey.pem
cp /root/mgmt-host.key /etc/pki/libvirt-vnc/clientkey.pem
cp /root/mgmt-host.crt /etc/pki/libvirt/clientcert.pem
cp /root/mgmt-host.crt /etc/pki/libvirt-vnc/clientcert.pem


Transfer the key and certificate files to the KVM server (kvm-server1). Ideally, you create the key and CSR on the host itself, so you only have to transfer the certificate. Then, copy the certificates and CA to the correct location on the KVM (libvirtd) server:


mkdir /etc/pki/libvirt
mkdir /etc/pki/libvirt/private
mkdir /etc/pki/libvirt-vnc

cp kvm-server1.crt /etc/pki//libvirt/servercert.pem
cp kvm-server1.crt /etc/pki/libvirt-vnc/server-cert.pem


Make sure the CA generated on the management server is available on the KVM server in the following file:
/etc/pki/CA/cacert.pem

Step 6: Reload libvirtd

/etc/init.d/libvirtd reload


Step 7: Test
With these certificates setup, you should be able to access libvirtd on kvm-server1 from mgmt-host. Use the following command to test:

virsh -c qemu://kvm-server1.xxxx.nl/system
Welcome to virsh, the virtualization interactive terminal.

virsh #

Use the list command to see a list of running guests on the server. This only works if these guests have also been created via libvirtd. Manually started KVM guests will not show up in this list.

NOTE: Always be careful when changing authentication and authorization configuration, as this might lock you out of the device. The savest way is to do this on the console of the machine.


aaa new-model
aaa authentication login default group tacacs+ enable
aaa authentication enable default enable
aaa authorization exec default group tacacs+ if-authenticated
aaa authorization commands 15 default group tacacs+ if-authenticated
aaa authorization network default group tacacs+ if-authenticated
aaa accounting exec default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+
aaa accounting system default start-stop group tacacs+
aaa session-id common
tacacs-server host 1.1.1.1 single-connection
tacacs-server host 2.2.2.2 single-connection
tacacs-server key TACACSKEY
tacacs-server directed-request

To restrict access to specific devices, you can configure an ACL in the tacacs configuration on the server (tac_plus.conf). See the example below.


user = username {
login = des "XXXX"
member = admin
acl = mgmt_devices
service = shell {
priv-lvl = 15
}
}
group = admin {
default service = permit
service = exec {
priv-lvl = 15
}
}
# acl's

acl = mgmt_devices {
permit = 12.12.12.12
permit = 13.13.13.13
}


I find it very strange that hackers were able to retrieve creditcard numbers from computer files. Specifically since PCI puts great restrictions on storing this stuff:

1. PCI 3.1 – Keep cardholder data storage to a minimum
2. PCI 3.2 – Do not store sensitive authentication data after authorization
3. PCI 3.4 – Render PAN (PAN == cc-number), at minimum unreadable anywhere it is stored by using one of the following: one-way hash, truncation, strong cryptography with associated key-management processes and procedures
4. PCI 3.4.1 – If dis encryption is used rather then file or database encryption, logical access must be managed independently of native OS access control

There are other requirements but the above give a good idea of the caution you must take when deciding to store this data. The full list of requirements can be downloaded from https://www.pcisecuritystandards.org/security_standards/pci_dss_download.html

Personally, I think these news items should contain more information, or should be evaluated somewhere so people can learn from the mistakes made by others. By being open on the causes of these problems people can easily prevent the holes that others left open. I know, this will probably not happen any time soon…

Link to original story: http://www.elsevier.nl/web/Nieuws/Internet-Gadgets/248802/Duizenden-creditcards-geblokkeerd-na-aanval-hackers.htm#

When implementing an iSCSI network you should be aware of the security risks that this imposes on the environment. To estimate the risk, awareness of the methods that can be used to secure iSCSI is paramount. The iSCSI protocol allows for the following security measures to prevent unintended or unauthorized access to storage resources:

• Authorization
• Authentication
• Encryption

Because iSCSI setups are generally shared environments access to the storage elements (LUNs) by unauthorized initiators should be blocked. Authorization is implemented by means of the iQN. The iQN is the initiator node name (iSCSI Qualified Name), this can be seen as a mac-address. During an audit, storage systems must demonstrate controls to ensure that a server under one regime cannot access the storage assets of a server under another.
Typically, iSCSI storage arrays explicitly map initiators to specific target LUNs; an initiator authenticates not to the storage array, but to the specific storage asset it intends to use.

As an added security method, the iSCSI protocol allows initiators and targets to use CHAP to authenticate each other. This prevents simple access by spoofing the iQN. And last, because iSCSI runs on IP, IPSec can be used to secure and encrypt the data flowing between the client (initiator) and the storage server (target).

Now that we know there are multiple ways to secure access to the storage resouces, you might conclude that iSCSI must be safe and secure to use. Unfortunately this is not evident. There are several flaws in the iSCSI security design:

• iQN’s are trusted, but are easy to spoof, sniff and guessed
• iSCSI authorization is the only required security method, and this uses only the iQN
• Authentication is disabled by default
• Authentication is (mostly) only implemented as CHAP
• IPSec is difficult to implement

Because iQN’s are manually configured in the iSCSI driver on the client, it is easy to change them. To get access to a LUN that is only protected by a iQN restriction, you can sniff the communication to get the iQN, or guess the iQN as it is often a default string (eg.: iqn.1991-05.com.microsoft.hostname), configure the iscsi driver to use this name and get access to the LUN.

The CHAP protocol is basically the only authentication mechanism that is supported by iSCSI vendors. The protocol allows for other mechanisms like Kerberos. The CHAP protocol is not a protocol know for its strong security on shared networks. The CHAP protocol is vulnerable to dictionary attacks, spoofing, or reflection attacks. Because the security issues with CHAP are well known, the RFC even mentions ways to deal with the limitations of CHAP (http://tools.ietf.org/html/rfc3720#section-8.2.1).

While IPSec could stop or reduce most of the security issues outlined above, it is hard to implement and manage. Therefor not many administrators will feel the need to use it. It should not only be possible to make a secure network, it should also be made easy.

To reduce the risk, and make your iSCSI network as safe as possible, you should do the following:

• Enable mutual (incoming/outgoing) authentication
• Follow advice to secure CHAP
• Enable CRC checksums
• Do not only rely on iQN for authorization
• Enable IPSec (if performance allows it)

Also vendors/distributors should enable authentication by default, and add other authentication mechanisms to the iSCSI target and initiator software.

References:
http://www.blackhat.com/presentations/bh-usa-05/bh-us-05-Dwivedi-update.pdf
http://en.wikipedia.org/wiki/ISCSI#Authentication
http://weird-hobbes.nl/reports/iSCSI%20security/

As a note, please only disable password aging when there is no other way to fix the problem.