Fingbox Helps You Monitor & Manage Devices on Your Network with Your iOS/Android Smartphone
Fing network scanner mobile app available for iOS and Android that allows you to discover which devices are connected to your Wi-Fi network, map devices, detect intruders, assess network security risks, troubleshoot network problems, and optimize wireless network performance.
But in order to go beyond network monitoring, the developers have designed Ubuntu Core based Fingbox hardware to add features such as access control (e.g. parental control), analyze the usage of bandwidth for each clients, find Wi-Fi sweet spots/ avoid black spots, verify your Internet speed, monitor devices in your network, and protects it with a digital fence that works against threats.
From a hardware perspective Fingbox is a round shaped Ethernet node with the following specifications:
Processor – ARMv7 processor
System Memory – 1GB RAM
Connectivity – Gigabit Ethernet
The Linux (Ubuntu Core) device just needs to be connected to your network via an Ethernet cable, and powered by its adapter. You’d then run Fing app on Android or iOS, which will automatically detect the Fingbox, and allow you to easily monitor and control devices on your home network. The best way to clearly understand what the device brings to the table is to watch the demo embedded below.
Fingbox was launched through an Indiegogo campaign, that ended up very successfully with 20,000 backers, and over @1.6 millions raised, but now you can purchased it directly from Amazon for $129 with shipping to US, UK, EU, and Canada, or Fing website for other countries.
When I think about it, I’m wondering why we don’t get such functionality from the router directly, as surely that’s something vendors could implement in the firmware, except possibly on the cheapest models due to storage and/or memory limitations, with no added hardware cost. Feel free to comment if you can already use your smartphone to monitor and manage other devices via your router, or is Fingbox the only workable solution right now?
Tweet Fing network scanner mobile app available for iOS and Android that allows you to discover which devices are connected to your Wi-Fi network, map devices, detect intruders, assess network…
GitHub’s new security scanner
GitHub just announced a new service called “security alerts for vulnerable dependencies.” It’s not the catchiest name ever, but it’s a new service from GitHub that is going to change how we build software. Again.
The very short description of the service is GitHub is launching a service for public repositories that will look at your software dependencies, then alert you if there is a security vulnerability in one of your dependent components. This is a huge deal as before now it was very difficult to figure this out. The only options were rather expensive services or manual inspection. Neither is an option for most open source projects.
From reading about the service they’re going to leverage existing CVE data to populate their scanner with security details. It’s a bit poetic that MITRE just moved the CVE data to GitHub.
As with most news, there are already some security people complaining about this new GitHub effort. Everything from it won’t catch all flaws, there will be false positives, the CVE data is incomplete, basically the fact that this won’t be a perfect solution. These complaints are technically correct, but they’re not helpful and will thankfully be ignored.
The thing GitHub seems to understand that much of the security universe doesn’t understand is that change doesn’t happen overnight, and it’s never perfect the first time. Real change takes time and many iterations. This lack of understanding is no doubt one of the reasons our current security track record isn’t very good. Perfect and nothing are functionally the same thing in the end.
The data GitHub is using will be out of date, it will contain mistakes, and it will be incomplete. It doesn’t matter though. They will march this project forward, it will get better, and it’s going to make a huge difference in how software is built. Someday we will wonder how we built software without this level of insight into our projects.
Now this topic of understanding your dependencies isn’t new. I’ve been talking about it for years. I generally start the conversation about this topic by saying “open source won”. That used to be a controversial statement. It’s not anymore. In fact, I’ve not had anyone question me in a few years about it. It’s pretty clear open source won.
However, just because open source won doesn’t mean it gets some sort of free pass. The reason it won is because it’s very easy to incorporate open source into your own projects and get a huge boost in productivity. But how you include open source into your projects can bring a certain level of risk with it.
If you include open source software in a project that contains security vulnerabilities, now your project contains security vulnerabilities. It’s not uncommon for one open source component to contain copies of other components, and those components contain other copies and its dependencies all the way down. These multiple layers of dependencies can get out of hand quickly. You might think you are adding one thing, but you’re really adding seven.
The missing piece in the open source dependency story has been finding a way to understand what’s in a product or project and if those components need updating. In a perfect world everyone would update components with every build, but this is far from a perfect world. Updating your open source dependencies generally takes time and effort so we can’t update things constantly.
If you’re not updating your dependencies constantly, do you know if one of those dependencies has an unfixed security vulnerability? This problem has been getting more and more attention over the past few years as the success of open source has been noticed. With the new attention some hard questions have also arrived. The single biggest revolves around understanding your third-party dependencies.
It will be very interesting to watch how this service evolves at GitHub. No doubt it will have some problems as all new things do. The CVE data will have to be expanded, there are many open source components that don’t even know what a CVE ID is today. These are all problems we can solve though. The future of security will always be unknown and turbulent, but in this one instance I have high hopes that things will get better.