OpenSUSE Linux Rants

OpenSUSE Linux Tips, tricks, how-tos, opinions, and news

My Resume  -  My LinkedIn Profile - twitter: @scottmmorris

March 4, 2010

Researchers find way to zap RSA security scheme

by @ 2:19 pm. Filed under security

RSA security technology is not as secure as we thought. What?!

Check it:

“Three University of Michigan computer scientists say they have found a way to exploit a weakness in RSA security technology used to protect everything from media players to smartphones and e-commerce servers.

RSA authentication is susceptible, they say, to changes in the voltage supplied to a private key holder. The researchers – Andrea Pellegrini, Valeria Bertacco and Todd Austin — outline their findings in a paper titled ‘Fault-based attack of RSA authentication’ to be presented March 10 at the Design, Automation and Test in Europe conference.

‘The RSA algorithm gives security under the assumption that as long as the private key is private, you can’t break in unless you guess it. We’ve shown that that’s not true,’ said Valeria Bertacco, an associate professor in the Department of Electrical Engineering and Computer Science, in a statement.”

Read “Researchers find way to zap RSA security scheme”

Beginner’s Guide to Nmap

by @ 7:00 am. Filed under security, sweet tools

Linux has a number of incredible security tools. Joe Brockmeier introduces nmap, one of the better security tools out there.

Excerpt:

"Ever wondered how attackers know what ports are open on a system? Or how to find out what services a computer is running without just asking the site admin? You can do all this and more with a handy little tool called Nmap. What is Nmap? Short for "network mapper," nmap is a veritable toolshed of functionality to perform network scans. It can be used for security scans, simply to identify what services a host is running, to "fingerprint" the operating system and applications on a host, the type of firewall a host is using, or to do a quick inventory of a local network. It is, in short, a very good tool to know."

Read the article here

March 3, 2010

White House Declassifies Outline of Cybersecurity Plans

by @ 12:20 pm. Filed under Linux News, security

An anonymous reader writes "The Obama administration on Tuesday declassified part of the Comprehensive National Cybersecurity Initiative created during the Bush administration, outlining offensive and defensive strategies for protecting information networks. The initiative was originally intended to unify efforts of a number of government agencies into a comprehensive strategy to protect the nation's computer networks. 'One area in which the government did officially disclose new details was Einstein 3, a program to protect civilian government systems from intrusion by deploying sensors on the networks of private telecommunications companies. For the first time, the government disclosed officially that the program would use technology developed by the NSA, the nation's largest intelligence agency. It also said that the Department of Homeland Security, which would run the program, would share malicious code data with the NSA but not the content of communications, such as e-mails.'"

This one is from the Bush administration. Probably means he's dumping it for one of his own.

Read more of this story at Slashdot.

March 2, 2010

Microsoft Says, Don’t Press the F1 Key In XP

by @ 5:22 pm. Filed under M$ Exposed, humor, security

*FACEPALM* - 20 years and still not figuring it out:

Ian Lamont writes "Microsoft has issued a security advisory warning users not to press the F1 key in Windows XP, owing to an unpatched bug in VBScript discovered by Polish researcher Maurycy Prodeus. The security advisory says that the vulnerability relates to the way VBScript interacts with Windows Help files when using Internet Explorer, and could be triggered by a user pressing the F1 key after visiting a malicious Web site using a specially crafted dialog box."

Read more of this story at Slashdot.

February 19, 2010

Linux + Security = Happy Friday to Me

by @ 11:32 am. Filed under Linux migrations, Work-Related, security

At my place of employment, we are making some great progress at switching our end users to Linux. So far, we have made great progress. Everything has been successful up to this point. It is quite greatly satisfying for me to be able to save my employer money, while at the same time exposing people to the very capable operating system that is Linux. So far, so good!

We are also working towards tighter security and becoming more standards-compliant. This is incredibly exciting for me, as I am a security sucker. Don’t know everything there is to know, but really love the topic. My brother is a retired Colonel from the US Army. His specialty? Computer security, hacking, and all that sort of stuff. He currently has contracts with the Pentagon for security-related projects, etc. He helps a lot when I have questions. I’m actually pretty interested in the CISSP certification. But this exercise in PCI compliance is a shot in the arm for me. I love it.

If you have any recommendations for applications/appliances that are PCI-certified, let me know. I’m aware of OpenVPN, fail2ban, Nessus, OpenVAS, Snort, BASE, Squil, OSSEC, Kismet, PHPIDS, and mod_security, for example. What are some others that you have found useful?

November 30, 2009

Linux Security with Fail2Ban

by @ 1:45 am. Filed under How-To, bash, command-line, security, sweet tools

Linux is built to be inherently secure, and has a great track record of having superior security to its proprietary counterpart.

However, in the world of server administration, paranoia is an asset. How else could someone get in? How can I prevent that? How can I be notified?

One magnificent contribution to the security of Linux servers the world over is called fail2ban. Why should you care?

From the Fail2ban main page:

Fail2ban scans log files like /var/log/pwdfail or /var/log/apache/error_log and bans IP that makes too many password failures. It updates firewall rules to reject the IP address.

So basically, it gives the finger to those mean people who are trying to brute-force your ssh server. And it blocks them at the packet level with iptables. No iptables knowledge necessary. (Though if you want a quickie, take a look at this short “Iptables for Linux” intro).

For openSUSE users, check to see if you have it available using zypper:

[1049][root@laptop:~]$ zypper search fail2ban

If you find it, use zypper install fail2ban to get it on your box.

If you have trouble getting it installed, follow the seriously excellent advice on the fail2ban download page.

When you get it installed, as root, edit your /etc/fail2ban/jail.conf file.

Put your ip addresses in the ignoreip list so you don’t lock yourself out.

bantime is in seconds. 1 hour is 3,600 seconds. 24 hours is 86400. I put in at least 24 hours. Do what works for you.

maxretry is how many tries a user gets before they’re blocked for bantime seconds. 3 to 5 chances seems more than generous.

Now to set up the notification.

In the same file, look for the section called [ssh-iptables]. Change this section so it looks like this:

[ssh-iptables]

enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
           sendmail-whois[name=SSH, dest=notrealemail@suseblog.com, sender=fail2ban@suseblog.com]
logpath  = /var/log/messages
maxretry = 3

If you don’t want the ‘whois’ info, take out the ‘-whois’ from the sendmail part. Change the dest email to your own, and set the sender to whatever you want. Maxretry will override the default that you set further up. In logpath, put in the system log, or wherever your sshd logs stuff. Mine happens to be what you see there.

When it’s set up as you like, save and quit.

Now, fire that bad fool up:

[1607][root@mail:/etc/fail2ban]$ fail2ban-client start
2009-11-27 16:07:46,554 fail2ban.server : INFO   Starting Fail2ban v0.8.4
2009-11-27 16:07:46,555 fail2ban.server : INFO   Starting in daemon mode
[1607][root@mail:/etc/fail2ban]$

To make it run when the machine restarts, use chkconfig:

[1607][root@mail:/etc/fail2ban]$ chkconfig -a fail2ban
fail2ban                  0:off  1:off  2:off  3:on   4:off  5:on   6:off
[1610][root@mail:/etc/fail2ban]$ 

Within at least a few hours, you should get notifications. Or, you can have someone try and brute force your box and see if their IP gets banned.

If you read through jail.conf, you’ll see that fail2ban can do loads more than I’ve covered here. But if you want a little more armor on ssh, your biggest target, slap fail2ban on your box.

November 9, 2009

Linux LiveCD Saves Windows Admin Jobs

by @ 1:53 am. Filed under Linux tips, security, sweet tools

Ophcrack Linux LiveCD

Ophcrack is the Linux LiveCD that you reach for when you forget your admin password on your Win32 (incl. XP and Vista) box.

From the Ophcrack Sourceforge page:

“Ophcrack is a Windows password cracker based on a time-memory trade-off using rainbow tables. This is a new variant of Hellman’s original trade-off, with better performance. It recovers 99.9% of alphanumeric passwords in seconds.”

For all admins who use said proprietary OS, if you ever forget your admin password, this is one great way to recover it, and help you keep your job.

Please do not ever, ever, ever use tools like this for malicious purposes, because that’s just plain not very nice.

July 14, 2009

Securing Linux – A Crash Course in iptables

by @ 6:27 pm. Filed under General Linux, How-To, command-line, security

Once in awhile, it’s nice to block hostile machines on the kernel level. Specifically, this is done with iptables or ipchains. Iptables if you are living in this millenium.

If a specific host is known to be hostile, execute the ‘whois’ command on the ip address. This will give you the IP range of the organization assigned the ip block to which the offending ip belongs. If it is outside of the country and you only service clients inside your country, it doesn’t hurt to block the whole ip range. So, we’re going to block a hostile block from China. As root, run the following command:

iptables -I INPUT -s 125.71.214.0/24 -j DROP

Why not REJECT instead of drop? This adds a rule to the firewall that simply drops the packets. This is more annoying to the other end because they never get a response. If you explicitly reject the packets, they get a message to the effect instantaneously. You want them to have to wait. It slows them down, which is bad for them.

To list the rules in the INPUT chain:

iptables –line-numbers -L INPUT

To delete a rule from the INPUT chain:

iptables -D INPUT [line number]

ex. iptables -D INPUT 1

Would delete the first rule in the INPUT chain.

Cool subnet calculator at : http://www.subnet-calculator.com/

Helpful comments with more useful or better commands welcome.

May 21, 2009

OpenSUSE Linux: Creating Self-Signed SSL Certificates

by @ 2:54 pm. Filed under Linux tips, SUSE Tips & Tricks, security

Originally written Jun 2, 2008, and updated on May 21, 2009

Overview

At some point or another, you’ll likely end up needing an SSL certificate for a Web site somewhere along the line. For a commercial site, your hosting provider can or will help you get this all squared away. This article is not for people in that situation.

What we’re doing here will be to create our own Certificate Authority. Then, we’ll create our own server key and a signing request. Then, we’ll sign our own certificate using the key and certificate from our own Certificate Authority. In other words, we’re not just going to create an SSL certificate, but we’re going to sign that bad boy, too.

This is useful for personal websites that need a little security, or when you’re waiting for your real cert from a real Certificate Authority. Perhaps you need it for transmitting data from an external server to your Intranet. Or perhaps you need it in any of the three hundred thousand seven hundred forty-two other situations that may arise.

Certificate Authority

The first thing that you’ll need is root access to the server. SSH in and head somewhere secure like /root.

Next, we’ll go ahead and generate our own Certificate Authority key. In this step, we are impersonating someone like Verisign or Thawte. Well, not impersonating, but we are going to do the same thing for ourselves that they would normally do.

To create our key, we’ll run this command:

openssl genrsa -des3 -out ca.key 4096

When we do that, it looks something like this:

[1257][root@mail:~/cert]$ openssl genrsa -des3 -out ca.key 4096
Generating RSA private key, 4096 bit long modulus
...............................................................................................................................++
.................................................++
e is 65537 (0x10001)
Enter pass phrase for ca.key: [enter a pass phrase here for the CA key]
Verifying - Enter pass phrase for ca.key: [verify the same pass phrase here]
[1258][root@mail:~/cert]$ 

Note that those pass phrases are something you make up right then. You are not authenticating anything, but rather setting up a pass phrase for authenticating later.

Next, we’ll need to use that key to create a certificate. Before we do this, the information that you will enter here is NOT the information you will enter later for your own server. Remember, we are emulating a Certificate Authority here. When we generate our server certificate, we will put in the real information which must differ from what is here. With that, let’s whip out the certificate. Notice that we are making it good for 3650 days, or 10 years. Adjust to your taste. So let’s make the cert, now. This is done with the following command:

openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

And doing this may resemble something like this:

[1306][root@mail:~/cert]$ openssl req -new -x509 -days 3650 -key ca.key -out ca.crt
Enter pass phrase for ca.key: [enter the CA pass phrase from above here]
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:WA
Locality Name (eg, city) []:Redmond
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Microsoft Corporation
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:www.microsoft.com
Email Address []:bill.gates@microsoft.com
[1307][root@mail:~/cert]$ 
Our Server Key and CSR

Next up on the list is to create a key that corresponds to our server. The first one we made was for the Certificate Authority. This one will be generated by and for our own server. We will do that with this command:

openssl genrsa -des3 -out server.key 4096

The output should look familiar:

[1310][root@mail:~/cert]$ openssl genrsa -des3 -out server.key 4096
Generating RSA private key, 4096 bit long modulus
................................++
....++
e is 65537 (0x10001)
Enter pass phrase for server.key: [enter a pass phrase here for our server key]
Verifying - Enter pass phrase for server.key: [verify the same pass phrase here]
[1313][root@mail:~/cert]$ 

Again, those pass phrases are something you make up right then. You are not authenticating anything, but rather setting up a pass phrase for authenticating later.

Now… let’s see… oh yeah. Now, we have to create a signing request, or CSR, from the server key we just made. This signing request will usually make a trip to a genuine Certificate Authority to have the key signed and a real, verified, bonafide signed certificate returned back to us. So, to generate our signed certificate, we’ll need to first have a signing request so we can make the signed cert. See how that works?

To create the CSR, we do this:

openssl req -new -key server.key -out server.csr

Now remember, kids. This is the part where we do put in our actual real information because the server does in fact belong to us. Put in the real domain where it says “Common Name (eg, YOUR name) []:”. Fill out everything correctly. And so we do:

[1313][root@mail:~/cert]$ openssl req -new -key server.key -out server.csr
Enter pass phrase for server.key: [enter the pass phrase here for our server key from above]
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:UT
Locality Name (eg, city) []:Eagle Mountain
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Suse Blog
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:www.suseblog.com
Email Address []:my-address@suseblog.com [put in your real email address here]

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
[1323][root@mail:~/cert]$ 
Sign the Certificate

Now, we are going to take all these files and make them do some voodoo. We are going to sign the signing request using the Certificate Authority certificate and key that we made at the beginning. What we will get is our perfectly forged signed certificate. OK, not perfectly, because we are not a real CA. But we’ll get a pretty darn good signed cert that will work for us rather nicely.

The command we’re going to run looks like this:

openssl x509 -req -days 3650 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt

And when we run it, we see something hopefully resembling this:

[1326][root@mail:~/cert]$ openssl x509 -req -days 3650 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
Signature ok
subject=/C=US/ST=UT/L=Eagle Mountain/O=Suse Blog/CN=www.suseblog.com/emailAddress=my-address@suseblog.com
Getting CA Private Key
Enter pass phrase for ca.key: [enter the CA pass phrase from above here]
[1332][root@mail:~/cert]$ 
Generate server.key That Won’t Prompt for Password

Now, we have a little problem. Our server.key file will cause apache2 to prompt us for a password every time it starts. We need to fix it so that doesn’t happen. We’ll do that with these three commands:

openssl rsa -in server.key -out server.key.insecure
mv server.key server.key.secure
mv server.key.insecure server.key

When we run these commands, here’s our output:

[1354][root@mail:~/cert]$ openssl rsa -in server.key -out server.key.insecure
Enter pass phrase for server.key: [enter the pass phrase here for our server key from above]
writing RSA key
[1354][root@mail:~/cert]$ mv server.key server.key.secure
[1354][root@mail:~/cert]$ mv server.key.insecure server.key
[1354][root@mail:~/cert]$
Placing the Files

At this stage, you should now have a bunch of files. These, in fact:

[1354][root@mail:~/cert]$ ll
total 32
drwxr-xr-x  2 root root 4096 2008-06-02 13:54 .
drwx------ 10 root root 4096 2008-06-02 13:35 ..
-rw-r--r--  1 root root 2529 2008-06-02 13:07 ca.crt [CA certificate]
-rw-r--r--  1 root root 3311 2008-06-02 12:58 ca.key [CA key]
-rw-r--r--  1 root root 2049 2008-06-02 13:32 server.crt [our server certificate]
-rw-r--r--  1 root root 1748 2008-06-02 13:23 server.csr [our server signing request]
-rw-r--r--  1 root root 3243 2008-06-02 13:54 server.key [our password-less server key]
-rw-r--r--  1 root root 3311 2008-06-02 13:13 server.key.secure [our passworded server key]
[1355][root@mail:~/cert]$

Just having them doesn’t get us anywhere, so let’s get them installed. First, we are going to change some permissions, because we don’t want just anyone having access to these files. To apply the appropriate permissions, run this:

chmod 0600 server.key.secure server.key server.csr server.crt

Now, here’s where things depend on the distribution that you are using. I will describe what I am doing so that if you are not on OpenSUSE, you will still be able to get this working.

In OpenSUSE, the apache2 config directory is located at /etc/apache2. Underneath that, there are a handful of directories. The three we care about are /etc/apache2/ssl.crt, /etc/apache2/ssl.csr, and /etc/apache2/ssl.key. The server.crt needs to be moved to /etc/apache2/ssl.crt. The server.csr file needs to be moved to /etc/apache2/ssl.csr. And the server.key file needs to be moved to /etc/apache2/ssl.key:

[1348][root@mail:~/cert]$ mv server.key /etc/apache2/ssl.key/server.key
[1349][root@mail:~/cert]$ mv server.crt /etc/apache2/ssl.crt/server.crt
[1349][root@mail:~/cert]$ mv server.csr /etc/apache2/ssl.csr/server.csr
[1349][root@mail:~/cert]$

Yep, pretty complex stuff, moving files.

Now, we need to make a handful more edits to some files, and we’re just about there.

System Configuration

First thing is to edit /etc/sysconfig/apache2. Search through that file for the directive called APACHE_MODULES. Make sure you see ’ssl’ in there. If not, add it. Then, search through the file and find APACHE_SERVER_FLAGS. Make sure it has ‘SSL’ in it. If not, add it. Save and close the file.

You can also manage apache’s modules with the ‘a2enmod’ command. To view the list of loaded modules, run ‘a2enmod -l’.

Next, open up the config file that tells apache2 which ports to listen on. In OpenSUSE, this file is /etc/apache2/listen.conf. Rip that bad boy open. You will see the following line:

Listen 80

Add a new line for port 443, our HTTPS port, so that it looks like this:

Listen 80
Listen 443

Then, look for the following line:

NameVirtualHost *:80

Add a new line for port 443, our HTTPS port, so that it looks like this:

NameVirtualHost *:80
NameVirtualHost *:443

Save and quit.

Virtual Host Configuration

In OpenSUSE, it’s really easy to have virtual hosts on a machine. I have like 10 on mine. One of them is my blog, www.suseblog.com. Well, to make this easy, in OpenSUSE, the virtual domain configuration files are located in /etc/apache2/vhosts.d, each with their own name. My www.suseblog.com configuration file is called suseblog.conf. To set up SSL for this virtual host, just duplicate the file and give it another name. In my case, I named it ssl-suseblog.conf.

Now, we’re going to open up that file and add like 4 lines to it. No sweat.

At the top of the file, there is a line that looks like this:

<VirtualHost *:80>

Change the port from 80 to 443, so it looks like this:

<VirtualHost *:443>

Then, go down a ways and add these lines:

SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/apache2/ssl.crt/server.crt
SSLCertificateKeyFile /etc/apache2/ssl.key/server.key

Save and quit on that one, too.

Configure Firewall

We can configure this thing perfectly, but if the firewall doesn’t know to let traffic through, we will not have HTTPS access to the server. Let’s check the firewall really quick to make sure.

Fire up YAST. Go to the Security & Users option on the right, and select FIREWALL from the left. If you do not have a firewall running on the machine, you can just exit now. If you do, you will need to go to ALLOWED SERVICES. In the SERVICES TO ALLOW drop-down on the right, select HTTPS Server. Then click ADD. Then click NEXT, and finally FINISH. You should now have port 443 opened for HTTPS business.

Now, let’s go ahead and restart apache and enjoy our new self-signed self-generated SSL cert on our HTTPS service:

[1426][root@mail:/etc/apache2]$ /etc/init.d/apache2 restart
Syntax OK
Shutting down httpd2 (waiting for all children to terminate)          done
Starting httpd2 (prefork)                                             done
[1427][root@mail:/etc/apache2]$ 
Conclusion

Well, we’ve concluded. Enjoy.

More info on the mod_ssl page

April 15, 2008

ARP Poisoning – I Read Your Email

by @ 7:24 am. Filed under General Linux, freebies, security

Alrighty, folks. I gave a presentation at Utah Valley State College last night about a network security issue called ARP poisoning. It is the ability to hijack any computer’s connection on a local area network. The concept is that you force all traffic going to and from that machine through your own computer. You are then able to filter through that traffic and determine what the user is doing. It is possible to view passwords, and even change traffic as it goes through your computer. Even if they are on a secure website. It’s a fairly common method of attack, and is something to watch out for. I have compiled my notes into an article in the form of a 4-page PDF. If you want to take a look at how ARP Poisoning works, view the PDF here.

OpenSUSE Linux Rants
Official OpenSUSE Linux Site

internal links:

categories:

SUSE Resources

search blog:

rss feeds

news & syndication

archives:

March 2010
S M T W T F S
« Feb    
 123456
78910111213
14151617181920
21222324252627
28293031  

latest tweets:

  • Anyone have a 350Z/370Z that I can drive around for a few hours? 2 days ago
  • The skunk thunk the sunk sump pump in the stump stunk. 2 days ago
  • Five Tools for Measuring and Improving Linux System Performance | Linux.com http://tinyurl.com/yd8wglz 1 week ago
  • Beginner's Guide to Nmap | Linux.com http://ow.ly/1pEKDr 1 week ago
  • The Church History Symposium on Fri was spectacular. Vaughn J. Featherstone and Pres. Kimball's son were highlights for me. Fully loved it! 1 week ago
  • A magician was driving down the road... then he turned into a drive way. 2 weeks ago
  • No cavities for me. Yay! :) 2 weeks ago
  • Just finishing getting our proprietary Windows software humming along on wine. At 1:00 AM. 2 weeks ago
  • More updates...

136 queries. 0.727 seconds