(My issue is that I understand that most users are clueless, heck I started in support for Win3.1 for an ISP, but the stuff in the debug clearly was a statement that I understood what I was say, and even as a Jr. engineer 30 years ago, I would have read it and said "hum, this dude knows his stuff, maybe I should ask at the next level").
Ubiquiti sells some devices that are 24V passive PoE. These devices include their UISP products (such as devices like the AirMax). Passive injectors are dangerous because they always supply 24V to the port; this could damage a non-24V PoE device.
There's also the 802.3a* standards family, such as the 802.3at (what Ubiquiti calls PoE+). Each of the standards (e.g. 802.3at, 802.3af, etc.) support different amounts of current, but they're all 48V active adapters. Active PoE is safer because the device "requests" the power it wants; the switch does not always supply 48V power over the port, so devices that don't require PoE won't be receiving power.
Ubiquiti sells a few switches that support both 24V passive PoE and 48V active PoE. You can change this in the switch's web interface, through the port settings. You may also want to consider just using a 24V passive injector, especially if your switch cannot be configured to supply 24V power.
The rest of Ubiquiti's gear does use IEEE 802.x.
Edit: also their stock. Believed in them so much I bought their stock
Now... submit a ticket. Frustrating/pointless UI changes. Breaking system upgrades. Backed up your configuration? Doesn't matter, you're going to need to reset this update... disappointing. I still have hope they'll turn it around because they have the best UI of any network gear I've used for getting small/mid size networks up and done.
Regarding support wise: I've had one malfunctioning switch (POE just stopped working) and it was replaced within 24 hours, so that's nice.
I love Meraki stuff, so I looked into Meraki Go, and they handicapped Meraki Go by only allowing VLAN for devices with wired connections to the switch. I want the ability to setup a wireless SSID, apply a VLAN to it, and have any wireless devices connected to that SSID be on that VLAN.
Wish they would reevaluate that decision, as I've heard good things about their access points.
Personally, I would argue that Ubiquiti handled the pandemic much better than other companies. Take the Cloud Key firmware: Back when it was first released, the thing was so unstable it had to be reset every few weeks. Every firmware update required a factory reset. Nowadays, it's solid. Even flashing beta builds is a smooth, issue-free process. Features like person and vehicle detection in their Protect lineup are a much welcome addition, as is the revamp of the Protect app. All of this happened during the pandemic.
I know people whine about how Ubiquiti unified everything under a global login, but come on.. if it works, it works. It's hardly a reason to bash Ubiquiti because you're upset you temporarily have to sign into ui.com.
Now, maybe they are putting more effort into Protect than they are into the network side of things. I don't know, because I primarily use them for Protect. With that being said, I'm fairly satisfied.
But IMO the truly depressing event here is management refusing to do anything until it was too late. What are they even paid for?
Also, extortion. I'm always amazed at what people will say over Slack DMs, seemingly not realizing that it all is accessible by the company.
Is that (creds) considered safe/secure these days? Is it common place? I kinda figured slack might get to be a 1password on top of everything else, so it's interesting to hear it's happening.
No, definitely not. It's just super convenient and happens all the time at every organization.
The most recent Twitter breach involved a credential shared in a Slack channel. Security teams have a hard time monitoring Slack and the default settings are pretty bad (infinite session length, infinite message retention).
Unless slack hard deletes messages, but my guess would be soft deletion. Even then it's not really designed for sending sensitive credentials
Even if slack would delete the message, clients like bitlbee and wee-slack exist, and save the messages as soon as they came in, and slack will not be able to delete them. Bots get those messages as well.
Just because the chat service deletes messages from their backend does not mean the message is deleted at the clients.
So yes, you'll want to: 1. Delete the message 2. Revoke the token 3. Notify the user/ security operations team
Do you mean he got promotions cause he found a non existent vuln? Surely whoever handed out those promotions is to blame here?
Actually not unusual.
Lots of the Highest Ranked Sys Admins in larger companies are quite "invulnerable" due to the implication, that they might know everyones mail & the companies dirt.
Nick had his hands in everything from GitHub to Slack and we could never understand why or how. He rose to power in the company by claiming to find a vulnerability that let him access the CEO's personal system, but nobody I spoke to ever knew what the vulnerability was. I discussed this with another ex-Ubiquiti person in an old thread [1] Now I'm positive he faked the security issue as a power move, just as he faked this attack for extortion purposes.
He would also harass people and use his control over Slack and GitHub against the people he didn't like. Many people left around this time partially because Nick made everything so difficult at the company. What a terribly depressing series of events.
[1] https://news.ycombinator.com/item?id=26694945