Upgrade for home non-traditional ISP

I do have the good fortune of receiving a lot of mobile devices to test and muck around with at work. Around November 2015 I ditched paying the $60/month for Comcast and went with an unlimited plan from my mobile ISP. I now have 17GB of tethering per month (before throttling) and I push it through a Raspberry PI with some nice forwarding rules setup in iptables so it really just acts as the DMZ router.

This has been OK, except when I want to get a lot of work done, I can blow through that quickly. Additionally I do occasionally like having remote access to my stuff, and when I take my phone, then my network goes offline.

So…. now I get to test a Samsung SM-V100T. An Android hotspot from T-Mobile that has a tethering limit > 50GB/month. The unit comes with a battery, some nice additional features if this was someone’s primary mode of Internet connectivity such as a MicroSD card slot and DLNA support. I’m excited that the unit comes with Android and I’m curious about sideloading apps and getting a better UI setup for it. Linux detects it as if it was a Gear S2, so there’s hope for what I can do with it.

I have had a small problem with tethering some of the other test devices previously, and when I tested a Samsung S6 Edge, I found that certain models respond poorly to the amount of power that the Raspberry PI(a) can output from the USB ports.The symptoms specific to tethering is that the device continually knocks itself offline and behaves as if it has been connected to a new device again, and thus prompts for a connection method.

I’ve found previously that using a 2.1 amp charger for a tablet produces sufficient power to work through most of these devices, but the SM-V100T was responding the same way as the previous devices did. I didn’t have a powered USB hub on hand, and I can’t remember the last time I’ve seen a USB charger capable of greater than 2.1A output.

And then I had a great idea… I remembered back in the day external slim CD/DVD drives often connected via two USB cords. One for data and power, and an additional cable for just a bit more juice. Voila! Power supply to the hotspot fixed.

To do:

  • set hotspot to tether by default when plugging into a Pi.
    • Currently the device will default back to MTP, requiring a UI login to change this back to tethering
  • Side load apps
    • I must find out how to sideload the Android agent for MDM control. The SM-V100T represent a threat to the integrity of network behind it since it’s based of out-of-date Android
  • Disable Wi-Fi hotspot
    • If this is used for tethering 100%, no need to have another Wi-Fi signal saturating the channels
      • Maybe the WPS button could be changed for Wi-Fi hotspot on/off?
I may not test often, but when I do it's in production

The thrill of testing in production

if ($testing_in_production == true) {
RTFM();
}
else {
$Move=fast;
$Break=Shit;
}

 

I’ve been spending a lot of time hopefully making something better for a customer. They recently had an au

ditor c

ome in and tell them they were doing the most basic layers of security (i.e. Antivirus) all wrong and it needed to be redone. And the organization was given a deadline about a month away for 40 PCs and a dozen servers.

This is not a significant issue except the 13-hour timezone difference makes anything that gets messed up a little more precarious to go fix. My first

real sysadmin job allowed me the luxury of driving across town if I broke something.

In all cases I’m lucky that I have experience deploying the tools in a much larger environment. That environment was also under pressure. They had just been pwn’d and didn’t really know it until I stumbled across that. Really didn’t know what I was dealing with… at that time in 2008 I really had no clue what real information security was about. I learned quickly.

What I have also learned through many years of work, is that if you’re going to have to test in production, I recommend that you take a deep breath, slow down, and read the manual first. Knowing what the heck you are doing is only the first step. You really have to know *why* you are doing a thing. There’s no shortage of opportunity to move fast and break stuff, but with each instance there’s also an opportunity for learning and growth.

I may not test often, but when I do it's in production

With the amount of chaos in the world, inability for many OPSEC teams to focus on actually securing all the things, and the continual drive to still give customers what they want, there’s also no shortage of opportunities to learn-on-the-fly, be creative, and solve problems. Even in production.