It wasn't until I'd posted the earlier item that I discovered that today is a work holiday too.
A few days ago I received a LiFePO4wered device for a Raspberry Pi 3. It seemed like a good idea, though the price tag is a bit high. To play with it, and also to follow up on something else I'd wanted to try, I installed the ARM image of Kali Linux on the Pi. This worked fine and was snappy, but the kali-linux-full package I would like to have had was too big for the 8 GB microSD card on the Pi. Additionally, the LiFePO4wered battery software is tested only for Raspbian Jessie, and didn't quite work for Kali ARM. So Kali was replaced with Raspbian Jessie with Pixel. In what can be considered slight overkill, I downloaded and installed this package of pentesting tools, leaving me with about 500 MB of spare space. A better idea might have been to add the Kali repository and install a kali metapackage such as kali-linux-wireless, which was the target goal.
The primary benefit of the LiFePO4wered battery so far is that it includes a touchpad on/off button, which is great for keeping the pi running while you switch from external battery pack to plug power. It also means that the pi won't accidentally turn off if you're performing a wireless audit and the cable to the external battery pack comes unplugged. In fact, with the setup above the Pi could probably run over 2 hours with a small adapter like this, albeit with reduced range. The time could be extended with a solar panel, which the LiFePO4wered battery is designed to work with.
Next, I plugged in an Alfa 052NH and walked around the apartment complex, got stopped by a neighbor, installed a spare cloud camera for him to monitor his car outside the window, all for about 1.5 hours, during which time kismet was running. It produced a 127 MB pcapdump file, plus some extra for the nettxt and netxml files. With that benchmark, it's probably safe to stick with the current tools list rather than start over with a Kali metapackage. (Interesting ESSIDs include a Thermostat with an open network, nepeta, and 2cups_1girl and 2cups_1girl_the_sequel for 2.4 and 5 GHz respectively).
Today, I spent too much time trying to connect the Pi to my PirateBox so it could communicate with my laptop on a local wireless LAN. Turns out the PirateBox is designed to be private, which means that cross-router communication is not possible. (Missing routes in the routing table? Maybe client isolation is enabled in OpenWRT?) Either way, it's a feature, so instead I did some research and decided to purchase a different model of TP Link travel router, one which hopefully doesn't have an app that needs to be connected to be used. This one I can eventually use to follow this great guide to make myself a private VPN for work travel.
Next I reflected on the lack of backup solutions in my network. It would be great to have a copy of the music on the Plex device USB to transfer around in case I'm travelling and want to have my latest downloaded music with me. It would be good for backups too. Or how about if I could use youtube-dl to download very large playlists of youtube videos? With enough storage that becomes feasible.
So here are my requirements (thinking out loud):
1. Ideally it should be accessible via SSH. Alternatively, as long as it's network attached and there's a web interface of some sorts, just make sure attaching it works fine.
It would be great to have a script on the backup device that uses SFTP or SCP to ssh into all my devices and backup data or generate traffic stat data to visualize on an internal monitoring page, separate from the munin installation. Alternatively, I could split the job, putting the scripts on a VM to pull the visualization data, and also have scripts to perform backups to the storage device.
2. I need to be convinced to bother with RAID 6. The easier the setup the better, as my primary homelab focus is learning basic network infrastructure in support, or pursuit, of primarily application security and also penetration testing. That is, the majority of my projects so far have involved setting up web servers or products that include web servers. Plug and play with minimum amount of fuss is my goal, not spending days getting a backup solution to work.
3. The faster the better. Network cabling is entirely Cat6, and most of the PCs have gigabit NICs. The raspberry PIs do not, and would be the primary bottlenecks.
4. The quieter the better. I sleep in the same room as the nascent home lab, meaning silence is golden.
5. Smaller form factor is preferable, but not mandatory.
6. Low power requirements would be nice.
I'm looking at Synology devices, but am open to other solutions, such as NUCs with FreeNAS.
Tomorrow I hope to practice two items:
1. Practising with iptables on the pentesting Pi.
2. Setting up a simple captive portal on the Ubiquiti AP AC Lite to try to get the EvilAuth modules for the Pineapple Wifi to work.
A few days ago I received a LiFePO4wered device for a Raspberry Pi 3. It seemed like a good idea, though the price tag is a bit high. To play with it, and also to follow up on something else I'd wanted to try, I installed the ARM image of Kali Linux on the Pi. This worked fine and was snappy, but the kali-linux-full package I would like to have had was too big for the 8 GB microSD card on the Pi. Additionally, the LiFePO4wered battery software is tested only for Raspbian Jessie, and didn't quite work for Kali ARM. So Kali was replaced with Raspbian Jessie with Pixel. In what can be considered slight overkill, I downloaded and installed this package of pentesting tools, leaving me with about 500 MB of spare space. A better idea might have been to add the Kali repository and install a kali metapackage such as kali-linux-wireless, which was the target goal.
 |
| The LiFePO4wered battery on the left, with an Alfa card attached. |
The primary benefit of the LiFePO4wered battery so far is that it includes a touchpad on/off button, which is great for keeping the pi running while you switch from external battery pack to plug power. It also means that the pi won't accidentally turn off if you're performing a wireless audit and the cable to the external battery pack comes unplugged. In fact, with the setup above the Pi could probably run over 2 hours with a small adapter like this, albeit with reduced range. The time could be extended with a solar panel, which the LiFePO4wered battery is designed to work with.
Next, I plugged in an Alfa 052NH and walked around the apartment complex, got stopped by a neighbor, installed a spare cloud camera for him to monitor his car outside the window, all for about 1.5 hours, during which time kismet was running. It produced a 127 MB pcapdump file, plus some extra for the nettxt and netxml files. With that benchmark, it's probably safe to stick with the current tools list rather than start over with a Kali metapackage. (Interesting ESSIDs include a Thermostat with an open network, nepeta, and 2cups_1girl and 2cups_1girl_the_sequel for 2.4 and 5 GHz respectively).
Today, I spent too much time trying to connect the Pi to my PirateBox so it could communicate with my laptop on a local wireless LAN. Turns out the PirateBox is designed to be private, which means that cross-router communication is not possible. (Missing routes in the routing table? Maybe client isolation is enabled in OpenWRT?) Either way, it's a feature, so instead I did some research and decided to purchase a different model of TP Link travel router, one which hopefully doesn't have an app that needs to be connected to be used. This one I can eventually use to follow this great guide to make myself a private VPN for work travel.
Next I reflected on the lack of backup solutions in my network. It would be great to have a copy of the music on the Plex device USB to transfer around in case I'm travelling and want to have my latest downloaded music with me. It would be good for backups too. Or how about if I could use youtube-dl to download very large playlists of youtube videos? With enough storage that becomes feasible.
So here are my requirements (thinking out loud):
1. Ideally it should be accessible via SSH. Alternatively, as long as it's network attached and there's a web interface of some sorts, just make sure attaching it works fine.
It would be great to have a script on the backup device that uses SFTP or SCP to ssh into all my devices and backup data or generate traffic stat data to visualize on an internal monitoring page, separate from the munin installation. Alternatively, I could split the job, putting the scripts on a VM to pull the visualization data, and also have scripts to perform backups to the storage device.
2. I need to be convinced to bother with RAID 6. The easier the setup the better, as my primary homelab focus is learning basic network infrastructure in support, or pursuit, of primarily application security and also penetration testing. That is, the majority of my projects so far have involved setting up web servers or products that include web servers. Plug and play with minimum amount of fuss is my goal, not spending days getting a backup solution to work.
3. The faster the better. Network cabling is entirely Cat6, and most of the PCs have gigabit NICs. The raspberry PIs do not, and would be the primary bottlenecks.
4. The quieter the better. I sleep in the same room as the nascent home lab, meaning silence is golden.
5. Smaller form factor is preferable, but not mandatory.
6. Low power requirements would be nice.
I'm looking at Synology devices, but am open to other solutions, such as NUCs with FreeNAS.
Tomorrow I hope to practice two items:
1. Practising with iptables on the pentesting Pi.
2. Setting up a simple captive portal on the Ubiquiti AP AC Lite to try to get the EvilAuth modules for the Pineapple Wifi to work.
No comments:
Post a Comment