January 31, 2013 3:08 PM
Posted by: Eric Hansen
Back in late 2009, an article was published by CyberCiti detailing 20+ tips on how to secure your Linux machine. How have things changes since and now (especially since we’re nearing Linux kernel 4.0)?
Then: #1: Encrypt Data Communication
Especially with the advent of more sophisticated tools at everyone’s disposal, ensuring data communication is encrypted should be a top priority. This includes using SSH instead of Telnet, SFTP over FTP, HTTPS over HTTP, etc…
These steps have also been made easier, however. Instead of purchasing a new SSL cert for every Intranet site, just create your own. It saves $30+/year per certificate and is more manageable.
Then: #2: Minimize Software to Minimize Vulnerability
#3: One Network Service Per System or VM Instance
It’s no secret having 100 different programs listening on different ports makes you 100x more at risk than 1 program listening on 1 port (or even 1 program listening on multiple ports). This will also help with the “go green” initiatives as well, though, as it will require less power to constantly maintain those applications.
Virtualization is a hot subject right now, and it has gained a lot of steam since around 2006 from my experience. Now, everywhere you look online there’ more talk about new virtualization, cloud solutions, etc..
Then: #4: Keep Linux Kernel and Software Up to Date
Similar to the above, this one is no secret as well. However, one thing I feel is lacking in every package manager I’ve seen is the ability to update just a single package. There’s not always a reason to update the entire system when you just need PHP updated, for example. It also causes sysadmins to be put between a brick and a hard place, because if they don’t update it could be catastrophic to their network, but if they update everything the entire server could get corrupted.
Then: #5: Use Linux Security Extensions
I’m a firm believer of not using “security extensions” such as SELinux. They tend to cause more of a headache than they’re worth and just add extra load on the server.
While they’re good for a catch-all approach, proper sysadmin and monitoring solutions should be a better approach.
I’ll continue with the next batch of 5 in another part.
January 31, 2013 2:34 PM
Posted by: Eric Hansen
While running python setup.py install is simple and easy, it doesn’t always work when you want to install some things (such as pip in my case). Especially when you have multiple versions of Python and you’re not using virtualenv.
To install pip on Python 2.7, this is what will make your life a lot easier:
1. Install setuptools:
wget http://pypi.python.org/packages/2.7/s/setuptools/setuptools-0.6c11-py2.7.egg -O setuptools.egg
2. Install pip via easyinstall:
This will install pip as pip-2.7 for you and make the rest of your adventures easier.
Typically a binary of /usr/bin/pip might exist as well. To see what Python version it’s currently linked to, do this:
# pip –version
The output is pretty self-explanatory:
pip 0.3.1 from /usr/lib/python2.6/dist-packages (python 2.6)
To change this to 2.7, do this:
rm -rf /usr/bin/pip
ln -s /usr/local/bin/pip-2.7 /usr/bin/pip
This will now link pip to your 2.7 installation.
January 31, 2013 2:25 PM
Posted by: Eric Hansen
So, I ran into the issue of msfupdate not updating Metasploit on my BackTrack installation. It worked fine on my laptop, but wouldn’t on my home server. I didn’t even get the typical SSL library issues that occur on initial install. Heck, even the usual svn update didn’t work for me.
What I found, however, is a relatively easy way to upgrade Metasploit without issues.
First, we need to remove our current installation:
rm -rf /pentest/exploits/framework2/
This will completely remove Metasploit from the system. Next, we need to download the newest data from Metasploit’s servers:
svn co https://www.metasploit.com/svn/framework3/trunk/ /pentest/exploits/framework2
This will download the most recent snapshot of the Metasploit base into our new folder. Then you should be able to run svn update or msfupdate just fine!
January 30, 2013 4:48 PM
Posted by: Eric Hansen
I installed Back Track recently, which is based on Ubuntu 10.04 (Lucid Lynx). As such, it’s not got the most up to date software, even with it operating on it’s own repos. So, when I migrated a site over that was used to PostgreSQL 9.1, to the new server running PostgreSQL 8.4, the database wouldn’t play nice. Some of the queries would work, but when it came to performing CONCAT() and similar operations, the server croaked.
After looking high and low on Google for how to solve this, I decided to just see what my options were on my system. This is where I discovered pg_upgradecluster. From what it seems like it’s the older version of pg_upgrade, but for the life of me I can’t figure out why Postgre would make this more difficult in pg_upgrade. Anyways…
The first thing you should (and I highly suggest) do is stop any instances of both the old and new PgSQL server. For me it was simply running these:
service postgresql-8.4 stop
service postgresql stop
Easy enough. Then I had to figure out where my 8.4 data was stored. Typically (as was the case here), it was stored in /var/lib/postgresql/8.4/main. It’s important to make note of the last two parts of that directory structure, too. You’ll see why in a bit.
To keep things organized and nice, I decided to use the same structure for 9.1. What I ran was this:
pg_upgradecluster 8.4 main /var/lib/postgresql/9.1
This took me about 3 minutes on a small-scale database (49 MB according to du -h .). What happens is pg_upgradecluster will migrate all of the data from /var/lib/postgresql// (in this case version = 8.4 and cluster = main) to the new data directory, keeping the same cluster (main). It will also migrate over the configuration files and any user accounts in the PgSQL system.
After that, just start up the PostgreSQL server instance and you should be running on 9.1 now.
January 28, 2013 3:03 PM
Posted by: Eric Hansen
Earlier this month I started a series about breaking into the Linux security field (part 1: http://itknowledgeexchange.techtarget.com/security-admin/getting-into-linux-security-part-1/). I’m going to continue this with more tools of the trade to start learning.
I wrote an article about some of the pro’s and con’s of Shorewall, a supplement of iptables. But why am I listing it here? Because once you know how people can get into a network, you need to be able to prevent them.
Installing a firewall is one thing, but being able to manage it is another. While sometimes you won’t have to mess with the grittiness of firewalls, it’s definitely a good asset to have, knowing how to configure various firewalls. As such, learning how to use Shorewall can be easily translated into iptables or some other solution. Kind of like how learning the Linux CLI can help you navigate around a Unix CLI, even though they aren’t the same.
There’s a few different solutions besides Shorewall you can dab into, but I’ve found that for those that don’t use the native iptables, Shorewall is there. The effectiveness and ease of configuration will basically give you a ‘set it and forget it’ feel, and will definitely make life easier.
Venturing away from the network aspect of things, Metasploit is another one of those de-facto standard applications that you should have in your Swiss army knife. Used by many IT professionals and highly recognized in the application vulnerability assessment field, Metasploit will be a great asset during audits.
Similar to other tools that’ll be listed, this isn’t one that is a hacker’s delight, and it’s not meant to be. It’s very easy to be detected using this when it comes do to being automated. Instead, this is supposed to give you an realistic look at how hackers view your network.
Metasploit is basically a huge database of known vulnerabilities in various services and systems themselves. For example, if a hacker detects you’re running Apache CloudStack 4.0, they could attempt to exploit CVE-2012-5616. Metasploit has a vast community of developers and authors who write plugins for Metasploit that will allow penetration testers the ability to see if their Apache server(s) are vulnerable to this CVE.
Unless you have permission from the server owner, I would advise running this against anything outside of your LAN. Even as a professional, when I’m performing audits I contact the data center and inform them of the audit, what it will involve and the time frame. This is a very powerful tool, but as the saying goes, “with great power comes great responsibility”.
The last tool in our second part is going to be Nessus. This tool has been around about as long as Metasploit, if not longer, and has another strong background in the audit world. However, this is more of a network auditing tool than application.
Nessus itself is very powerful. It will also create a lot of noise, similar to Metasploit, on the network. So again, I advise unless you have permission to only do this on the LAN.
What this software does is probe any hosts you provide it, and throw a bunch of attacks at it. You can, however, also create different profiles to fit different attacks. So if you want to only test Apache, you can create an Apache profile and add specific tests. This makes the tool very versatile and flexible.
I’ll admit I haven’t used Nessus in a few years, but that last time I remember, the paid version only allowed PDF reports, and those had references to Tenable Security (Nessus’ developers) in it. However, if you’re looking for a strong competitor and a very flexible engine that offers in-depth information about your network’s security, this is definitely a great tool to have and understand.
There’s so many other tools that I’ll be touching on, more so free ones that offer the same functionality but with a better price tag. However, this is a good start into looking into the deeper security aspects.
January 28, 2013 12:55 PM
Posted by: Eric Hansen
Linux is well known for it’s networking capabilities. This includes turning an old dusty machine in your house into a home grown firewall or even PBX (a fun weekend project, by the way). But with just about everything else involving Linux, there’s a million ways to solve one problem. Such is true with firewalls.
When you install your OS, you’re most likely going to have iptables pre-installed (you should, anyways). This is mostly due to the fact that iptables is the de-facto standard application for Linux when managing a firewall. It allows direct access via netfilter to inspect packets to great depths and even interface with IDSes like Snort when configured properly. But, the problem with having such power is that it can become very troublesome to maintain and configure.
For example, to set up a simple logging rule, you have to do this: iptables -A INPUT -p tcp –dport 22 -s !192.168.1.0/24 -j LOG –log-level 4 –log-prefix “[ssh daemon access attempt]: ”
This is not very well written, and the fact I know this by heart kind of speaks for itself too. Mind you, this is a pretty simplistic rule, but it goes to show that it takes a bit to configure a firewall properly with the default tools. But, what if there was an easier tool? A better tool? A safer tool?
Over the weekend I spent a few hours working with Shorewall, a front-end of sorts for iptables. Now, while the documentation for Shorewall says to disable iptables from running, it still requires iptables to be installed. This threw me off at first until I realized why, when I started up Shorewall.
Shorewall does a lot of work by making firewall management easier without taking away the power of iptables, it just simplifies it. For a one-NIC firewall configuration, you’re looking at about 4 or 5 files you have to edit, with 2 of them being ones you have to edit more than once (policies and rules files). This, compared to the troublesome iptables rules and switches, remembering which rule does what, etc… can make for a headache fast.
I’ll be writing a tutorial on this soon, but as a starting point, Shorewall separates the power from the user. This allows you to easily know what you’re configuring, and how it’s configured, and when it’ll work. Shorewall even allows for macros, which are even further simplified rulesets that you can use for known services (i.e.: to deny ping attempts, just call the ping macro like this: Ping(DROP)). This makes for quick and easy mangement and also makes rules that much simpler to follow.
Now that I’ve talked Shorewall up like it’s a godsend and unbeatable, lets raise the playing requirements a bit. While a great solution, Shorewall also has it’s downfalls. The biggest of which is poor documentation.
The documentation on the website makes Shorewall sound like it takes at least a master’s degree to get up and running. However, even if I had an associate’s I could get it going without issues, but I had to follow a different guide. There is a lot of technical jargon that, to me, is nothing more than fluff. It adds nothing to assisting users in getting a firewall set up, and if it wasn’t for I was bored and wanted to configure it, I would’ve just stuck with direct iptables rules.
There is also a severe lack of tutorials on Shorewall, and most of what is out there is lacking in substance. A lot of the guides I looked through were either for older versions, or for configuring ‘the perfect firewall’. I just wanted a simple how-to and that was that.
January 16, 2013 11:14 AM
Posted by: Eric Hansen
There’s a big increase lately in terms of Linux security and how to get into the field. Some can get by only knowing basic command line arguments, others require a CISSP to even be considered. But, experience in the field itself shows more than anything, even if you’re sitting at your desk working through a virtual machine. But what can really help someone, who’s passionate about security and Linux become even better? Help them get a job, and even start their own Linux security business?
You’re not going to know the tricks and ropes of every situation. Even if you were to simulate your own DoS and see how it affects your home network, there’s many ways to construct such an attack.
What you can do, however, is set up a virtual environment, or even a small virtual server farm. Get them to talk to each other, throw DoS attacks at them and see how they react. Having the knowledge of virtualization will get you further ahead than you may think, especially if you work for a “go green” company.
Scenario: I had a job interview late last year for a company. I did pretty well up until troubleshooting came into play. Safe to say I didn’t get the job, but knowing what they were looking for me to do on a day-to-day basis really opened my eyes. It made me realize what I need to focus more on, and how to do so. I ended up taking that knowledge, installing a small Linux distro on a server and trying to simulate various issues. With virtualization I can kill the network adapter without interrupting anything important. I’m able to run through various scenarios in practice that I was tested with in the interview, and try to solve them there.
It’s not a permanent solution, but it helps a lot. Heck, I have another scenario for you.
Scenario: Working for a web hosting company, I was placed in the position of rebuilding a RAID array. I had very minimal experience with such technology and only knew a little bit of the basics. But, I was forced to dive in blindfolded and do it what I needed to do. I don’t remember the details, but I can definitely tell you it didn’t go well (I told them before hand I wasn’t sure what I was doing, but I sure learned what not to do hah). Anyways, after I got off work, I went back to my place, and again installed a server via virtual machine. I spent a good week toying with RAID and how to work with it. Even to this day I’ve done it, and have also written various scripts to make the process smoother.
Virtualization is probably going to be your biggest friend going into security. There’s so many things that can break and go wrong that it’s easier being to reformat a virtual machine than it is reformatting your PC.
Knowing the Software (Part 1)
This here is going to be at least a two-part coverage, because in security there is just too much to cover. However, the biggest tool I see in the arsenal everywhere is nmap. Especially if you’re looking to set up or test a firewall, nmap should always be the first tool you go to. It will help you test against malformed packets, scan the network for devices and a whole lot more. The documentation on this tool will pretty much speak more volume than I can about it, but you should definitely learn your way around this piece of software.
Scenario: You notice a lot of traffic being sent to a server but no requests being fullfilled. this can either be an attempted DoS attack or someone just sending bad packets. The best way to find out if you don’t have network monitoring software set up is to test. While nmap won’t be a viable solution to test for a DoS attack, it does provide a vast array of methods to test for bad packets. You can run the host against each known test in nmap, and compare the results until you find a match.
December 31, 2012 3:51 PM
Posted by: Eric Hansen
Recently there’s been a lot of hysteria about privacy and the controls to it. A good instance of this is Facebook, which has essentially been under the gun ever since (or even before) it’s IPO failure earlier this year.
The idea behind privacy policies are nice, but short of being something to sue a company over, they hold very little information. They don’t tell you how the data stored or distributed, just that they are. It doesn’t say what happens on a privacy breach, or how to protect your data. It also doesn’t provide information on how to protect your privacy, just that it’s possible.
A lot of businesses, especially social media-based ones, are primarily focused on bringing in users, but they tend to give the assumption all of their users are computer-conscious. In fact, the safest way to present this to the user should be to assume that their users are not savvy and to spell out the information instead.
December 31, 2012 3:28 PM
Posted by: Eric Hansen
Typical Snort installs have you installing BASE for a graphical front-end to view packet information. While the UI is fluid, it’s also very outdated. It has the coding standards of 1995-2000, with limited functionality in it (just enough to get what you want and get out).
As such, there’s been advances in making viewing Snort logs easier. Of those is Snorby (www.snorby.org). It’s based on Ruby on Rails and has a pretty slick interface that brings Web 2.0 to Snort. But how good is it, really?
Personally I can’t stand any RoR projects. They’re about as resource intensive as Java programs and have about the same performance. It’s great if you have a 32-CPU and 192GB RAM server, but if you’re trying to operate it on a VPS, you’ll need a pretty high-end VPS just to give it enough RAM (Xen VPS might be better suited).
The UI is nice but it feels a bit clunky in that it tries to present too much to you at once. Otherwise, the color scheme is nice, but the navigation feels like everything is just clumped up together.