After being awakened much earlier than I had desired this morning, I decided to make the best of the situation and sit down to install VirtualBox in Ubuntu Netbook Edition on my Eee PC 1000H. My main reason for wanting to install VirtualBox on my netbook was simply so I could install BackTrack 4 in a virtual machine running on my netbook for the ultimate portable pentest/security monitoring setup. Of course, running VirtualBox will allow me to create VMs for anything I need going forward. The process I followed to install VirtualBox on my Eee PC is outlined in detail below.
In order to be able to install VirtualBox via my preferred method of using aptitude at the command line, I had to first add the proper repository to my /etc/apt/sources.list. For my particular installation (Ubuntu Maverick), the repository to be added is:
deb http://download.virtualbox.org/virtualbox/debian maverick non-free
Once the repository has been added, the next step is to download and add the Oracle public key via the following command:
ken@hostname:~$ wget -q http://download.virtualbox.org/virtualbox/debian/oracle_vbox.asc - O- | sudo apt-key add -
The above command will simply return OK if it has completed successfully.
The next step is to update the software repositories, since we added the virtualbox download repository to our sources.list file earlier:
ken@hostname:~$ sudo aptitude update
The final step is to install VirtualBox via aptitude. One note here: I first installed virtualbox-3.2, as directed on the VirtualBox website. It installed successfully, however, when I looked for the VirtualBox application in my applications list, it was nowhere to be found. Curious, I typed 'virtualbox' at the command line and it advised that VirtualBox was not installed, but, I could install virtualbox-ose-qt if I desired. So, I followed the prompt and did just that:
ken@hostname:~$ sudo aptitude install virtualbox-ose-qt
This successfully installed VirtualBox and there was now an application icon for VirtualBox in my applications list. Plus, I could now start VirtualBox from the command line via the 'virtualbox' command.
That's all there is to it! In my next post I'll discuss the process of creating a virtual machine in VirtualBox and installing BackTrack 4 on it for the ultimate in portable pentesting and security auditing.
Monday, December 20, 2010
Tuesday, December 7, 2010
Geeking Out with PortSentry
I have been super busy over the past few months! Thankfully, life seems to be slowing down a bit, but not much. Yesterday, I interviewed for a position as a Support Engineer with FireHost in Plano, TX. The interview went well and the opportunity is a ground-floor opportunity, which is absolutely awesome.
Aside from that, I have been dusting off some of my rusty old Linux sysadmin skills and rebuilding my knowledge and skills in that arena. In addition, I am also dipping my toe into the IT security realm a bit. For now, I am familiarizing myself with some of the more common tools for Intrusion Detection and Forensics. Once I'm comfortable with those tools I'll explore exploitation and cracking.
The first tool I got my hands dirty with is PortSentry. I installed it from the Official Ubuntu Repositories yesterday evening and settled in for what I expected to be a long process of learning how to configure and optimize the portsentry.conf file. As usual, I installed via command line, using the following command:
ken@hostname:~$ sudo aptitude install portsentry
I backed up the default configuration file by running the following commands:
ken@hostname:~$ cd /etc/portsentry/
ken@hostname:~$ sudo cp portsentry.conf portsentry.conf.bak
*Note: I always leave the .bak files I create in place in the event that my custom configuration file ever becomes corrupted, deleted, or otherwise tampered with, thus providing a simple file to restore from.
Then, using an archived article from Linux.com, found at this link: http://linux.omnipotent.net/article.php?article_id=12540&page=-1 I began going through the configuration file one section at a time. To my pleasant surprise, I noticed that during the install, the configuration file was configured automatically. I only had to change two sections, one of which was optional. The first change was as follows.
In the IGNORE OPTIONS section, I changed the default:
BLOCK_TCP="0"
BLOCK_UDP="0"
to the more preferred setting of:
BLOCK_TCP="1"
BLOCK_UDP="1"
The final change I made to the configuration file was to uncomment the message in the PORT BANNER section. It's advised to leave it commented, but I felt better having a warning message display to anyone trying to gain unauthorized access to my home network.
Overall, the installation and configuration for PortSentry was completely painless, and I highly recommend that anyone interested in running a secure Linux system install PortSentry and utilize it as part of their security scheme.
Aside from that, I have been dusting off some of my rusty old Linux sysadmin skills and rebuilding my knowledge and skills in that arena. In addition, I am also dipping my toe into the IT security realm a bit. For now, I am familiarizing myself with some of the more common tools for Intrusion Detection and Forensics. Once I'm comfortable with those tools I'll explore exploitation and cracking.
The first tool I got my hands dirty with is PortSentry. I installed it from the Official Ubuntu Repositories yesterday evening and settled in for what I expected to be a long process of learning how to configure and optimize the portsentry.conf file. As usual, I installed via command line, using the following command:
ken@hostname:~$ sudo aptitude install portsentry
I backed up the default configuration file by running the following commands:
ken@hostname:~$ cd /etc/portsentry/
ken@hostname:~$ sudo cp portsentry.conf portsentry.conf.bak
*Note: I always leave the .bak files I create in place in the event that my custom configuration file ever becomes corrupted, deleted, or otherwise tampered with, thus providing a simple file to restore from.
Then, using an archived article from Linux.com, found at this link: http://linux.omnipotent.net/article.php?article_id=12540&page=-1 I began going through the configuration file one section at a time. To my pleasant surprise, I noticed that during the install, the configuration file was configured automatically. I only had to change two sections, one of which was optional. The first change was as follows.
In the IGNORE OPTIONS section, I changed the default:
BLOCK_TCP="0"
BLOCK_UDP="0"
to the more preferred setting of:
BLOCK_TCP="1"
BLOCK_UDP="1"
The final change I made to the configuration file was to uncomment the message in the PORT BANNER section. It's advised to leave it commented, but I felt better having a warning message display to anyone trying to gain unauthorized access to my home network.
Overall, the installation and configuration for PortSentry was completely painless, and I highly recommend that anyone interested in running a secure Linux system install PortSentry and utilize it as part of their security scheme.
Friday, August 20, 2010
Yikes!
I've really let this blog slip into obscurity! Not to worry, though. I've actually been brainstorming ideas for a series of post topics, and should be getting those typed and ready to publish over the next week or so. Aside from that, I've also been working on getting some infrastructure in place for SEO and really just streamlining this blog as much as possible for the best possible user experience.
In the meantime, I do promise to have a regular posting schedule in place very soon!
In the meantime, I do promise to have a regular posting schedule in place very soon!
Friday, July 23, 2010
Configuring GRUB2 in Ubuntu
Currently, my main Linux machine is my ASUS EeePC 1000H netbook, running version 10.04 of Ubuntu Netbook Edition. I love it, mainly because it is uber-upgradeable and super-portable. I can stuff it into my small Eagle Creek urban man bag with a day's worth of essentials to cover any computing needs that may arise when my iPhone just isn't enough.
Now, call me crazy, but I like to have my computers display the GRUB boot menu at boot time, even though I generally do not run a dual-OS setup anymore now that I no longer use Windows. My reason for wanting to see the boot menu mainly has to do with the fact that I like to compile and test different kernels every so often, plus I have easy, instant access to memtest86+, should I ever need it.
In the days of old (in this case, as recently as a year or two ago), you would edit the menu.lst file in Ubuntu in order to change the GRUB boot menu settings. Beginning with the previous version of Ubuntu, version 9.10, this changed due to the fact that Ubuntu was updated to run GRUB2. As a result, the configuration file is much different. Outlined below is the very easy process for configuring GRUB2 to show the boot menu upon system startup.
First you need to know which file to edit. In Ubuntu 10.04, for GRUB2, the config file is located at /etc/default/grub. To edit the file simply issue the following command:
ken@hostname:~$ sudo vi /etc/default/grub
The lines we are concerned with in the grub config file are GRUB_HIDDEN_TIMEOUT and GRUB_TIMEOUT, shown below. Note that your grub config file may look a little different.
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
In order to show the boot menu, add a '#' character at the beginning of the GRUB_HIDDEN_TIMEOUT line.
#GRUB_HIDDEN_TIMEOUT=0
This inactivates the line by changing it to a comment. Next, delete any values that are located after the '=' character, so that the line now looks the same as I have it below:
#GRUB_HIDDEN_TIMEOUT=
The above process is the key element to ensuring that the boot menu displays during startup, but we aren't finished yet. The final step in editing the grub config file is to set the amount of time that the boot menu will stay on screen. To do this, change GRUB_TIMEOUT=0 to GRUB_TIMEOUT=10, replacing 10 with whichever value you want the menu to display for in seconds. In my case, I have it set to 10 seconds.
Finally, to apply the changes that have been made to the grub config file, you'll need to save and close the file, then issue the following command:
ken@hostname:~$ sudo update-grub
That's it! You can restart your machine and the boot menu will now display at startup. For more information about configuring GRUB2 in Ubuntu 9.10 or later, visit https://help.ubuntu.com/community/Grub2
Now, call me crazy, but I like to have my computers display the GRUB boot menu at boot time, even though I generally do not run a dual-OS setup anymore now that I no longer use Windows. My reason for wanting to see the boot menu mainly has to do with the fact that I like to compile and test different kernels every so often, plus I have easy, instant access to memtest86+, should I ever need it.
In the days of old (in this case, as recently as a year or two ago), you would edit the menu.lst file in Ubuntu in order to change the GRUB boot menu settings. Beginning with the previous version of Ubuntu, version 9.10, this changed due to the fact that Ubuntu was updated to run GRUB2. As a result, the configuration file is much different. Outlined below is the very easy process for configuring GRUB2 to show the boot menu upon system startup.
First you need to know which file to edit. In Ubuntu 10.04, for GRUB2, the config file is located at /etc/default/grub. To edit the file simply issue the following command:
ken@hostname:~$ sudo vi /etc/default/grub
The lines we are concerned with in the grub config file are GRUB_HIDDEN_TIMEOUT and GRUB_TIMEOUT, shown below. Note that your grub config file may look a little different.
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
In order to show the boot menu, add a '#' character at the beginning of the GRUB_HIDDEN_TIMEOUT line.
#GRUB_HIDDEN_TIMEOUT=0
This inactivates the line by changing it to a comment. Next, delete any values that are located after the '=' character, so that the line now looks the same as I have it below:
#GRUB_HIDDEN_TIMEOUT=
The above process is the key element to ensuring that the boot menu displays during startup, but we aren't finished yet. The final step in editing the grub config file is to set the amount of time that the boot menu will stay on screen. To do this, change GRUB_TIMEOUT=0 to GRUB_TIMEOUT=10, replacing 10 with whichever value you want the menu to display for in seconds. In my case, I have it set to 10 seconds.
Finally, to apply the changes that have been made to the grub config file, you'll need to save and close the file, then issue the following command:
ken@hostname:~$ sudo update-grub
That's it! You can restart your machine and the boot menu will now display at startup. For more information about configuring GRUB2 in Ubuntu 9.10 or later, visit https://help.ubuntu.com/community/Grub2
Tuesday, June 29, 2010
Portal 2? Yes Please!
It would be an understatement if I said that I love Portal. It would be an even larger understatement to say that I believe Valve is the greatest game development studio of our time. Yeah, that's right! You listening over there in Mesquite, you id freaks? Doom, what? Quake, huh? Anyway, that's a post for another day. Today, just revel in the awesomeness of this Portal 2 preview from E3.
Sunday, June 13, 2010
iGoogle Custom Theme Woes
Update: Unfortunately, I never could get Google Gadget Editor to play nice with my custom XML file, so I have set this endeavor to the side for the time being, mainly in the interest of building my skills in IT Security, as well as refreshing my knowledge of system administration.
I've been working on creating my first, very own custom iGoogle Theme. Unfortunately, the Google Gadget Editor does not seem to want to open the XML theme file I've created. I will continue to work the problem and will update here with either a resolution and information about the theme, or a short obituary entry advising of my attempt's complete and total demise.
Stay tuned!
Sunday, April 18, 2010
Socketbrain has been reinitialized.
Please excuse my dearth of posts, lately. I switched to 10-hour shifts at work, which has taken some adjustment, and have also been enjoying some extra time with my family. Socketbrain has been reinitialized, however, and is back on track.
Not much has happened since my last post, other than the fact that I discovered my ASUS Eee PC's AC adapter does in fact still work. This was a pleasant, accidental surprise and, suffice it to say, I'm simply glad. Now I don't have to rely on my iPhone only for all of my mobile computing needs! This is good, considering the latest news from Apple detailing that owners of the original iPhone, such as myself, will not be able to update to the new iPhone OS 4. I'm highly irritated by this and think it is very short-sighted of Apple. Alas, it has sparked my desire to simply trade-up for an open-source-driven smartphone. Maybe I'll buy a Nexus One!
The only other thing of importance has been my decision to migrate away from CentOS - and Red Hat-based distros in general - to Ubuntu - and Debian-based distros - on my personal home server. Why, you may ask? Simple. I feel that Debian/Ubuntu is far more stable than Red Hat distros. This is in my own experience only and is not derived from any sort of testing. At any rate, I've come to prefer Debian/Ubuntu over Red Hat/Fedora.
That's it for the catch-up. More useful posts to come soon!
Not much has happened since my last post, other than the fact that I discovered my ASUS Eee PC's AC adapter does in fact still work. This was a pleasant, accidental surprise and, suffice it to say, I'm simply glad. Now I don't have to rely on my iPhone only for all of my mobile computing needs! This is good, considering the latest news from Apple detailing that owners of the original iPhone, such as myself, will not be able to update to the new iPhone OS 4. I'm highly irritated by this and think it is very short-sighted of Apple. Alas, it has sparked my desire to simply trade-up for an open-source-driven smartphone. Maybe I'll buy a Nexus One!
The only other thing of importance has been my decision to migrate away from CentOS - and Red Hat-based distros in general - to Ubuntu - and Debian-based distros - on my personal home server. Why, you may ask? Simple. I feel that Debian/Ubuntu is far more stable than Red Hat distros. This is in my own experience only and is not derived from any sort of testing. At any rate, I've come to prefer Debian/Ubuntu over Red Hat/Fedora.
That's it for the catch-up. More useful posts to come soon!
Subscribe to:
Posts (Atom)