OpenBSD 5.6 was released to the world today. The first things I noticed was a hint of better laptop support via an extra prompt from the installer, and the fact that they have finally ditched a functioning version of the apache fork in the base distribution, requiring users to rely on either nginx or the all-new relayd-based httpd, both of which are provided in OpenBSD 5.6. I've already updated the walk-through for OpenBSD/nginx/MySQL/PHP-FPM (ONMP Stack). As Apache is now out of the base distribution, I will transition the OAMP Stack page to cover Apache2 from the package repository. I plan on working out the details of getting MySQL/PHP working with the new httpd as well, but that could take a while.
I haven't written here much lately. I've been swamped with work and real life.
Recently, my wife wanted me to clone one of my VMs so she could play around with running a MUD for some friends. Yes, my wife's a nerd like me. As anyone who's ever run a game server can guess, it didn't take long for the griefers to show up. She asked me to log everything going to her VM. I could have probably compiled DaemonLogger or something similar, but I decided tcpdump was more than capable enough for us.
sudo tcpdump -i eth0 -wPacketLog -W10 -C100M
Throw that in the background (or in a tmux/screen session) and enjoy a 1GB looped recording of everything you can see on the network, broken into 100MB chunks (named PacketLog0 - PacketLog9), overwriting old files as it goes. You can also add typical tcpdump filters (e.g. "tcp port 80") to the end if you want. Adjust -W to increase/decrease the number of files it saves and -C to adjust the number of MB of data kept in each file. File prefixes, as you guessed, are controlled by the -w option.
If you want to monitor your whole network, this works best if you have a span/mirror port set up, or you can make a passive network tap.
To review the contents of the saved file, use tcpdump -nvXs0 -r PacketLogN (displays the contents in Hex/Ascii side-by-side format) on the file you want. You can also use tcpdump filters here to watch specific connections, protocols and/or hosts.
At any rate, belhold, the updated guides:
Several mirrors are live with OpenBSD 5.5 available for download. ftp5 is my go-to.
I think the most interesting changes are crypto-signed release and package files (see signify(1) for details) and the addition of an automated unattended install (see autoinstall(8)). As always, more hardware support, some bug fixes, and interesting new features. This weekend, I'll probably make sure that our OAMP and nginx walk-throughs still work, with minor tweaks.
My first real ham radios were a pair of outdated Yaesu handhelds -- The VX-7R, and the VX-2. Both of them entered production more than a decade ago, and while I believe Yaesu still makes the VX-7R, the VX-8 series de-throned it as Yaesu's Flagship Handheld radio in 2008. The VX-2 was replaced by the VX-3 in 2007.
When I got my license a few years ago, inexpensive handheld radios were just starting to become popular. I've had more than a year to put two polar-opposites head-to-head against each other.
I won't dwell much on my VX-2 or the newer VX-3. These diminutive Yaesu handhelds pack a lot of features into a small package, but with a maximum of 1.5 watts when running on battery power, they aren't very practical for most hams. It's a good, compact radio if you only want to monitor or scan ham and business band channels. Much of what I write below will hold true for the VX-2 and VX-3 compared to the similarly-sized, low-power Baofeng UV-3R radios.
To provide some context, I've been using the Baofeng almost daily since early March of 2013. The stock battery in my Yaesu had become almost unusable, and the cheap ($20) replacement battery failed within 9 months. A new "official" Yaesu battery for the VX-7R costs between 70 and 100 dollars depending where you look. I opted to spend half of that on a new, cheap Baofeng UV-5R. After more than a year of using it, I figure I'm qualified to make a comparison.
On with the show.
|Left: Baofeng UV-5RA (Circa 2012) |
Right: Yaesu VX-7R (Circa 2007)
Let's start with the Baofeng, because this radio, and ones like it available under brand names such as Wouxun and TYT, have become quite popular among new ham radio operators mostly due to their low prices, ranging anywhere from $30 to $160. Many of these radios were designed to be programmed for Business Band (FCC Part 90) use, and some even bear type certification for this use. They are clearly competing with Motorola and Kenwood in the business radio arena. Others, like my UV-5RA, bear no type certification and can only be legally used for ham radio frequencies.
- These radios will get you on the air for 2m and 70cm repeaters, which is many peoples' first step to becoming an active ham radio operator.
- On simplex freqencies, they make excellent walkie-talkies (assuming everyone's licensed, of course) and will provide much better range than a pair of FRS or hand-held CB radios. Highly recommended for camping, bike trips, road convoys, the bug-out-bag, etc.
- This radio can receive broadcast FM, and can receive and transmit in the 136-174 MHz and 400-480MHz bands including weather radio.
- Relatively inexpensive
- Long battery life, even for long-winded ragchews or an active day helping with a public service event (marathons, bike races, storm spotting)
- The backlight is very bright and the display is fairly easy to read in all lighting conditions.
- Although it displays two frequencies at once, it cannot actually use both at the same time. "Dual Watch" tries to emulate simultaneous use of both tuners.
- Dual Watch functionality can be problematic and lead to you inadvertently transmitting on the "wrong" tuner if you're not careful.
- Scanning is very slow: in 5kHz steps, it takes exactly one minute to scan 1MHz.
- Poor interference rejection either due to or causing RF squelch to be over-sensitive
- When using CTCSS tone for squelch, the speaker still un-mutes when no CTCSS carrier is present on occasion
- The backlight is very bright and cannot be turned down, only off. You can change the color between a reddish-orange, purple and blue. At night, the display seems far too bright to me.
- The construction is cheap.
- Ambiguous menu abbreviations are difficult to navigate without a manual.
- Complaints of parts failures are common.
The Yaesu, by comparison, has quite a bit more going for it, at the expense of... well... money.
- VERY fast scanning: 1MHz at 5hKz increments in 10 seconds.
- Dual VFO functionality can receive from two channels at the same time.
- Can receive almost every frequency between 500kHz and 1GHz, with a few gaps in coverage for legacy mobile phone frequencies that the FCC forbids reception of. This includes weather radio, AM/FM broadcast radio, CB, shortwave and most analog two-way radio transmissions.
- Quad-band transmitter that's capable of operating at full power on 2m and 70cm as well as limited power on 1.25m (220 MHz) and 6m (50MHz).
- Alloy case is an excellent heatsink and construction is very solid
- Water-resistant to 10 feet, which makes it my go-to radio for storm spotting if I need to be outside my home or my car.
- "Smart scan" loads in-use ham frequencies into memory for you automatically (requires a few hours of scanning)
- "Frequency counter" mode, which isn't really a frequency counter, but is good for finding the frequency being used by almost any nearby RF transmitter
- "Spectrum analyzer" mode that I've found comes in handy for rough calibration of transmitters, identifying spurious emissions and visualizing how wideband certain transmissions are (hint: my 900 MHz wireless headphones use almost 100KHz of bandwidth!)
- Severe weather alert mode
- Superior interference rejection
- Can be hacked in interesting ways with software. Don't get yourself into trouble.
- Menu options are pretty self-explanatory.
- Cost! The radio, brand new, retails for $350 or more, making it literally 7 times more expensive than the average Baofeng on Amazon. Used, expect to pay $250 for one in good condition.
- Most official parts and accessories from Yaesu are also expensive, especially batteries.
- Overwhelming number of menu options might daunt some users.
- The alloy case is prone to superficial cracks and blemishes.
- The display has very flexible options for large numbers, but seems difficult to read with default settings.
- The backlight is adjustable, but its highest setting isn't very bright.
Programming either of these radios is a task best left to the software, which may cost money, and requires a programming cable, which definitely costs money. Programming either of them from the keypad can be a chore, but that's how I opted to set mine up. Overall, the Yaesu's menus make programming channels in with meaningful labels a lot easier than the Baofeng.
There are quite a few websites dedicated to hacking and using the cheaper radios. The one I stumbled across most often was http://www.miklor.com. Without the programming guide there, I would have never figured out how to get the local repeaters plugged into my Baofeng.
This week, the Baofeng experiment ended, as I finally caved in and bought a new battery for the VX-7R. The moral of the story is that you really do get what you pay for a lot of the time, and the more expensive handheld radios can pay off in the long run. The Baofeng will still be my backup radio. It's proven to be reliable, and when you just need to get on the air, that's what counts.
The infamous Baofeng. Specifically, I have the UV-5RA model. This is a lot of new hams' first handheld radio, and perhaps first radio period. I picked this one up because it was half the price of paying for a new battery to get my Yaesu VX-7R back on the air, and I had to get a reliable handheld radio quickly. I've had this one for about a year. I'm not sure I'd recommend it as a first radio unless you're really on a budget, but for what it is, I've been pretty happy with it. Lack of features compared to my Yaesu radios aside, my only complaints are that it poor intermod rejection, and the receive CTCSS squelch frequently fails to keep RF noise from coming through the speaker when there's not a real carrier there.
I have a lot of antennae with male SMA connectors for my Yaesu handheld radios. A lot of these inexpensive Chinese radios (Baofeng included) use a female SMA antenna for whatever reason. Instead of coughing up $20-$40 at the local candy store for a new antenna that works with my Baofeng, I picked up an SMA coupler similar to one you can find at Radio Shack. It has flats on the sides, so I used a pair of needle nose pliers to screw it tightly into the Baofeng. You don't want to strip the coupler or the radio's connector, but it should be pretty snug there, so that it'll stay in the radio when you unscrew antennae from it. I had this Comet SMA-24 laying around, and chose to use it on the Baofeng. It comes with a rubber spacer, which comes in handy for this install. The new antenna fits on nicely with the addition of the spacer. Without it, a little section of the coupler shows through. The end result is that all my other HT antennae now work perfectly on this radio.
Years ago Mattel released an educational toy microscope called the Intel Play QX3, and later the QX5. This particular microscope has a CMOS imaging chip with a lower lamp for transmitted light to come through a specimen and an upper lamp for light to be reflected off of it, each of which is independently toggled on and off by software. The resolution and speed of the CMOS chip in the QX3 is quite poor by modern standards but it does function adequately for a basic educational model. Some samples of image quality attainable can be found. I happen to own a QX3 and in the past was able to use the old guides for the old driver to turn the illuminator lamps on and off in older releases of various Linux distros. As time moved on driver rewrites began and things got shuffled around. Instead of using the old CPiA driver modern distros use the gspca driver framework which still operates under Video4Linux. V4L has a control command that allows regular users to send commands to the driver via their API, available in the v4l-utils package. The old method involved sending commands directly to the device driver module as a user with root privileges.
Plugging the microscope in shows the following:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 002: ID 0813:0001 Mattel, Inc. Intel Play QX3 Microscope
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 003: ID 046d:c063 Logitech, Inc. DELL Laser Mouse
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
[101645.604019] usb 5-1: new full-speed USB device number 2 using uhci_hcd
[101645.811040] usb 5-1: New USB device found, idVendor=0813, idProduct=0001
[101645.811045] usb 5-1: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[101645.811048] usb 5-1: Product: Intel Play QX3 Microscope
[101645.811050] usb 5-1: Manufacturer: Mattel Inc.
[101645.830281] Linux video capture interface: v2.00
[101645.833059] gspca_main: v2.14.0 registered
[101645.835930] gspca_main: cpia1-2.14.0 probing 0813:0001
[101646.140126] input: cpia1 as /devices/pci0000:00/0000:00:1d.3/usb5/5-1/input/input11
[101646.140262] usbcore: registered new interface driver cpia1
To talk to the camera driver module use v4l2-ctl to list and change the various settings it has available.
jon@leon:~$ v4l2-ctl -l
brightness (int) : min=0 max=100 step=1 default=50 value=50 flags=slider
contrast (int) : min=0 max=96 step=8 default=48 value=48 flags=slider
saturation (int) : min=0 max=100 step=1 default=50 value=50 flags=slider
power_line_frequency (menu) : min=0 max=2 default=1 value=1
illuminator_1 (bool) : default=0 value=0
illuminator_2 (bool) : default=0 value=1
compression_target (menu) : min=0 max=1 default=0 value=0
Flipping the lights on/off involves setting the illuminator_n controls with bool values. illuminator_1 is the lower, transmissive, light source. illuminator_2 is the upper, reflective, light source.
It is easy to turn them on/off at will from a command line.
v4l2-ctl -c illuminator_1=0
v4l2-ctl -c illuminator_2=1
v4l2-ctl -c illuminator_2=0
v4l2-ctl -c illuminator_2=1
HiR is hosting a TW2002 contest. Fire up your telnet clients, pick a throwaway password you'll never use for anything else, and join us.
The contest game (Game B) is a TW2002 Gold game with very few modifications, a 5,000 sector universe and 1,000 turns per day. 5 deaths eliminates you. The contest opens on February 1st, with a 14 day entry window. No admittance after that. No prizes other than bragging rights, but it should be fun.
In the meantime, a sandbox (Game A) is in session for your amusement and a bit of practice. It offers 5,000 turns per day to really give you a lot of time to explore and get your bearings straight with how the game works. I'm sure some of you are kind of rusty. I'll probably reset it in about two weeks when the entry period for the contest game closes.
You can get to the games via telnet on tw2002.h-i-r.net port 2002/tcp
All of the "Forgotten Ages" verbiage is a hold-over from the telnet MUD/BBS my wife ran back in the early 2000s. We've had licenses for Trade Wars and TWGS for a long time, and decided to finally put them to use.
Play clean, or play dirty. There are a lot of glitches and loopholes in this relic of a game. They're yours to use if you can find them.
OpenVAS can be tricky to set up. Once OpenVAS packages are installed, there's a bunch of steps you need to perform, and in a pretty specific order, to turn it into a working vulnerability scanner. There are four parts to OpenVAS: The Scanner service, the Manager service, the Administrator service, and then some front-end client. In this case, I'm demonstrating Greenbone Security Assistant, which is yet another service, an SSL web UI that you can access locally, or from another computer, for managing OpenVAS.
I recommend using sudo instead of doing everything as root, but you're obviously not obliged to do it that way. These instructions presume you are using sudo, though. Sudo isn't in the Arch base distribution, but you can add it with:
[root@spx ~]# pacman -S sudo
First, install all the packages. gsa is the web UI, while gsd is a graphical client that runs under X11. You don't need to install both of them, but I usually do. A bunch of dependencies will be added with these packages. Stuff in bold is what I typed. Everything else is terminal output. Most of the really verbose output is truncated and noted with my own commentary in ellipses.
[axon@spx ~]$ sudo pacman -S openvas-administrator openvas-manager openvas-scanner gsa gsd
Packages (75): alsa-lib-126.96.36.199-1 cmake-188.8.131.52-3 damageproto-1.2.1-2
Total Download Size: 73.21 MiB
Total Installed Size: 338.56 MiB
:: Proceed with installation? [Y/n] y
:: Retrieving packages ...
Next, download all the OpenVAS NVT scripts. These are updated frequently. By default, OpenVAS doesn't ship with any scripts, so you need to download them. If there are no NVTs, OpenVAS scanner service doesn't like to start.
[axon@spx ~]$ sudo openvas-nvt-sync
... lots of text while the NVT scripts download ...
[i] Download complete
[i] Checking dir: ok
[i] Checking MD5 checksum: ok
Next, make the SSL Cert for OpenVAS with this handy script:
[axon@spx ~]$ sudo openvas-mkcert
Answer each prompt if you want, but as this is a private-use certificate, I usually just hit enter at all the prompts to accept the defaults. We also need to make a Client Cert for OpenVAS-Manager (om) like this:
[axon@spx ~]$ sudo openvas-mkcert-client -n om -i
Write out database with 1 new entries
Data Base Updated
User om added to OpenVAS.
Start the OpenVAS Scanner service. This can take a really long time, and consumes a lot of RAM.
[axon@spx ~]$ sudo openvassd
Loading the OpenVAS plugins...base gpgme-Message: Setting GnuPG homedir to '/etc/openvas/gnupg'
base gpgme-Message: Using OpenPGP engine version '2.0.22'
Loading the plugins... 1887 (out of 33836)
The OpenVAS Manager service requires an SQLite database, but none is created during package installation. Use the following command to create the database. It will sit there for a few minutes and return to the command line without saying anything. This is normal.
[axon@spx ~]$ sudo openvasmd --rebuild
Start the OpenVAS Manager service. This runs quickly.
[axon@spx ~]$ sudo openvasmd
Add a user to OpenVAS. You'll log into OpenVAS with these credentials. Pick a strong password, not the one I use here.
[axon@spx ~]$ sudo openvasad -c 'add_user' -n adminusername -w adminpassword
ad main:MESSAGE:4484:2014-01-28 14h31.41 CST: No rules file provided, the new user will have no restrictions.
ad main:MESSAGE:4484:2014-01-28 14h31.41 CST: User adminusername has been successfully created.
Start the OpenVAS Administrator service.
[axon@spx ~]$ sudo openvasad
I'm usually paranoid, and at this step, I check the process list for "openvas" services. You should see openvassd, openvasad and openvasmd all running. If not, look at the logs in /var/log/openvas to give you some hints, or check to make sure you performed each step necessay. If that all checks out, start a client, such as Greenbone Security Assistant.
[axon@spx ~]$ sudo gsad
Now just browse to https://localhost (or your BlackArch's network IP). You'll need to accept the self-signed certificate. Generating a new SSL cert for GSA is beyond the scope of this article.
I've always admired Arch Linux, the spartan and light-weight Linux distro with its rolling release and clever package management system. At the same time, a lot of the security tools I know and love are difficult to compile, and found in few package repositories outside of Kali Linux, the Debian-derived distro that comes packed with pretty much every open-source security and penetration-testing tool that's relevant to today's researchers... and that's part of the problem. It's fun to play with new tools on occasion, but I rarely want or need all that stuff installed at once. Also, while I've spent more than enough time on Debian-family Linux distros thanks to a job managing Ubuntu LTS servers and hand-holding various friends and family through Ubuntu on desktops, it never quite felt like home as much as Arch does.
I prefer to start with a basic Arch Linux installation. For the command-line adept and those familiar with Arch, the Arch Installation Guide is a no-nonsense checklist of things you need to do, while the Beginners' Guide offers a bit more hand-holding. I used both when getting back into Arch Linux a while ago. You'll need to partition your drive, format the filesystems, pacstrap it, set up the network, add a user, and some other basic things that are outlined in the guides. Installation difficulty is on par with OpenBSD, but with a little less guidance from a dedicated install script. Don't forget to set up a boot loader!
You'll probably want to customize your Arch Linux install, which may include setting up X11, a Display Manager and a Window Manager or Desktop Environment (handy for using a graphical web browser or GUI-driven tools such as BurpSuite). That's all covered in the Beginners' guide as well. I'm pretty fond of OpenBox with Conky, so I ended up with a pretty minimalist desktop, shown here.
Once you have Arch installed and a comfortable userland configured, you'll want to make sure it's up to date by running "pacman -Syu" and then you should install wget before moving on to installing BlackArch, if you haven't already:
pacman -S wget
From there, you can simply follow the instructions on the BlackArch Download page. This will just add the repositories to your Arch Linux installation, and doesn't actually install the packages. You can opt to install all the packages at once with:
pacman -S blackarch
But in my opinion, the fact that you can pick and choose which tools to install makes it quite nice for devices like netbooks or other machines that you really don't want bogged down with hundreds of tools you don't need. The BlackArch download page outlines how to peruse their repository for the stuff you want, or installing groups of similar packages, such as "blackarch-scanner" and "blackarch-networking"
In my next post, I'll explain how to configure OpenVAS, and get it up and running on BlackArch. I frequently set this up in my security lab when introducing interns to vulnerability scanning, and it's usually a bit tricky to get running for the first time.
A few years ago, I bought a new gas can. I noticed it doesn't have a ventilation hole, but I figured there was some magic in the bizarre spout design that made ventilation unnecessary. I figured wrong. It takes several minutes to empty two gallons into a vehicle. I got tired of it today.
Step 1: Acquire useless gas can.
Step 2: Drill a small pilot hole in the handle, somewhere that won't leak when the can is full or in use.
Step 3: Plug said hole with a thumscrew, wing bolt or other suitable, secure device.
Loosely illustrated in attached photos. This works much better, but 1) might not be as safe for transporting gasoline, 2) might get you in trouble with some all-seeing government agency. As always: We're not responsible for problems caused by people who try this at home.