Live data from Hacker News

Ubiquiti all but confirms breach response iniquity

krebsonsecurity.com

231–240 of 322 posts

Re: Ubiquiti all but confirms breach response iniquity

#231
post #137
post #48

Earlier quoted context omitted.

During this week I've been playing around with replacing my USG with my existing home server - it already has two NICs - my first thought was to run OPNSense in a VM but nftables on NixOS seems to work well enough - there are a few examples floating online [0,1]. OpenBSD even supports the USG [2] but I couldn't think of much reason to keep the extra hardware. The next thing I want to do is reflash my Unifi APs with O…

> The next thing I want to do is reflash my Unifi APs with OpenWRT My understanding is that this doesn't work anymore because Ubiquiti started signing firmware. Your link also goes to a blank page.

That’s odd, the link works for me but the wiki was very slow earlier. From what I’ve read Ubiquiti have made it harder to flash new hardware, but even the new ax APs are supported by OpenWRT. There is a commit with some info - it seems there is a way to disable signature verification [0].

[0] - https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=fb...

Re: Ubiquiti all but confirms breach response iniquity

#232

Mentioned it before, but since a few days ago my unifi devices (2 wifi APs, a small switch, plus one Debian VM with the controller, all on it's on VLAN) are not allowed to do outbound traffic anymore, with the exception of NTP, DNS and one trusted apt mirror. Looking at the firewall logs it seems the devices try to ping (ICMP type 8) a bunch of AWS IPs every few hours. The controller tries to connect 80/443 on differ…

The ping is probably the uptime and connectivity monitor, which can be disabled. It regularly sends a ping to ping.ubnt.com.

You're probably right, but blocking doesn't seem to be a problem. I'm going to leave it like that for now. Not sure I would need any more firmware updates for hardware which came out 3-4 years ago anyway, but I think enabling 13.224.195.59:443 for the devices only (not the controller) would trigger and download firmware updates.

Re: Ubiquiti all but confirms breach response iniquity

#233

Has anyone looked at Ubiquiti's firmware signing? Would it be possible to patch it to retain the drivers and kernel but replace the configuration layers? Being able to homebrew some config would make the equipment more valuable to us I think.

Ubiquiti does not lock their bootloaders like phone manufacturers do. It is very, very easy to run vanilla Linux (or even OpenBSD) on their hardware. I do exactly this: https://news.ycombinator.com/item?id=26645062 Octeons (not Octeon-TX) are amazing processors. Ubiquiti makes killer hardware. I hear their software is junk but wouldn't really know since I always erase it immediately after unboxing.

Do you run Debian on Ubiquiti's access points too?

Re: Ubiquiti all but confirms breach response iniquity

#235
post #64

Earlier quoted context omitted.

If you’re really asking, and not making a point; PF is created and primarily maintained by OpenBSD OpenBSD’s base system (without extra packages) includes PF and has a focus on security. PF in freebsd is several major versions old. nftables (like iptables before it) is rule based and not bucket based. So high numbers of rules will not affect pf’s performance like it does with nftables. But, for home users, probably n…

>nftables (like iptables before it) is rule based and not bucket based. What does this even mean? Do you have any documentation to explain? >So high numbers of rules will not affect pf’s performance like it does with nftables. This is wrong. From OpenBSD documentation: "More lines being evaluated for each packet will result in slower performance." [0] https://www.openbsd.org/faq/pf/perf.html It's not 2001 any more. N…

The key is “for each packet”, because it’s bucket based it will entirely skip evaluation for packets that do not match. This is due to how the rule set is compiled, but I can see how it could be confusing if you’re used to iptables and only think in those terms.

I posted the architectural diagrams of both in another comment on this thread yesterday, I think you missed that.

Re: Ubiquiti all but confirms breach response iniquity

#236
post #166

Earlier quoted context omitted.

Similar to the other responses, it's the fact that I can manage my network remotely from a simple app or UI. This helps me answer phone calls from my family asking why Netflix doesn't work on TV #2, when I'm not at home. Won't solve all problems, but at least I can narrow it down and troubleshoot. And I like the fact that I can an overview of the state of my network; one of my wired links to an AP would degrade to 10…

> it was a bad ethernet cable in the end Checking the cable is like checking if the power is on, it is NEVER the cable - except in networking for some reason. Half the time it's the cable.

Network cables (copper and fibre) have a limited bend radius. Most people don't think about this and will bend a cable beyond tolerance, which will eventually result in the cable not working correctly, and/or manifest as intermittent issues.

I suspect that's the most common cause of network cables 'going bad' in the home.

Re: Ubiquiti all but confirms breach response iniquity

#237

Earlier quoted context omitted.

> it was a bad ethernet cable in the end Checking the cable is like checking if the power is on, it is NEVER the cable - except in networking for some reason. Half the time it's the cable.

Network cables (copper and fibre) have a limited bend radius. Most people don't think about this and will bend a cable beyond tolerance, which will eventually result in the cable not working correctly, and/or manifest as intermittent issues. I suspect that's the most common cause of network cables 'going bad' in the home.

I learned this back in school, when the previous years students had laid new Ethernet cables from the classroom to the server room, but the machines would only get 10M and not 100M link as they should.

Didn't take us long to notice they had laid the cable like electricians, neatly following the contours of a few door frames with tight 90 degree bends.

Glad I learned that lesson early.

Re: Ubiquiti all but confirms breach response iniquity

#238
post #211

I can believe that they do not keep logs of the database access. As brain dead as it sounds. I have been in the position of implementing a client on a API I do not control. The owners of the servers (colleagues but in a different country) do not seem to know what logs are. We get random failures from the server. I can pin down to the second when they occur (not closer because of network lag). I suspect that the serve…

Logs are typically off by default in most Enterprise software, or goes nowhere by default which is basically the same thing.

Logs cost money to both collect and store. Not everyone is cheerfully burning through VC capital. Some people have budgets.

Speaking of log collection, simply dumping the logs into a central repository is the same as taking the garbage to the landfill. Collecting trash just results in a big collection of trash.

Extracting useful information from a huge pile of logs is non-trivial. You'd have to know at least one query language, probably several if you work on big enterprise systems. You'd have to know a bunch of esoteric things like how to convert the long decimal strings to a number so that you can interpret as any one of a dozen timestamp formats as an actual datetime in UTC, and then convert that to local timestamp so that you can tell when something actually happened. And so on.

All of this is merely a prerequisite for finding a specific instance of what you know is there.

You know what you'll never find in logs? Things you didn't know to look for! That's unfortunately about 90-99% of what you actually need to know, making logs typically about 1-10% as useful as you'd like.

Did I mention they cost money? Have you seen how many arms and legs Splunk charges these days? Why would you pay that much for something that is less than a tenth as useful as it could be?

The fundamental problem is that discipline doesn't scale. You can't expect a hundred thousand IT operations guys to all do everything all of the time, in spite of the non-technical finance guy holding on to the purse strings like he's gripping a life preserver after going overboard in a raging storm.

PS: I turned logging on extensively for a recent Azure project. Some logs cost more than the service they were monitoring. I mean sure, I could turn off the unnecessary logs, but how do I know ahead of time which ones will be necessary or not? I don't have a time machine! I can't go back and turn off the logs I won't need... later.

PPS: Have you noticed all logging companies charge by the gigabyte? What incentive do you imagine they have for improving the efficiency of the log transfer and storage formats?

Re: Ubiquiti all but confirms breach response iniquity

#239
post #205

Earlier quoted context omitted.

Most of the US leadership and many of the US employees quit in recent years. The CEO wanted to focus on international offices where employees were cheaper. It was backfiring while I was there and I heard it only got worse after I left. Sad situation. I knew a lot of good people there who cared about making good products during the UniFi glory days. Everything collapsed fast. I knew we were in trouble when the CEO's e…

Really sad to see. I still see no realistic alternative for the "distributed decent wifi at a reasonably SMB scale" wireless product though. Miraki I guess is as close as it gets, but then you are locked in 100% cloud and it's certainly not remotely the same price point. I am relegating Unify to manage my APs and (some) switches for ease of use - while I enjoy CLI fun, it gets old doing routine stuff the for the 100t…

Meraki go is their direct unifi competitor.

Re: Ubiquiti all but confirms breach response iniquity

#240
post #102

Earlier quoted context omitted.

If I can vent for a second, this company has no leadership . None. Things may have changed in 2 years, but I doubt it. I was messaged almost daily by random employees asking wtf was going on with the company. They were afraid for their jobs. Practically no one respected the CEO, and he was the only C-suite exec. There. Was. No. Leadership. There was no company wide communication, and all communication channels were m…

> There was no company wide communication, and all communication channels were made private I couldn't understand why the ex-Amazon cloud lead was also in charge of Slack. When he made all channels private and put a Slackbot in every channel to monitor conversations, I knew it was all over. I'm worried his Slackbot logs are part of the leak. Guy had his hands in everything :( Same guy who took over GitHub and forced…

> I couldn't understand why the ex-Amazon cloud lead was also in charge of Slack. When he made all channels private and put a Slackbot in every channel to monitor conversations, I knew it was all over. I'm worried his Slackbot logs are part of the leak. Guy had his hands in everything :(

He did.... what? That sounds like straight out of a Dilbert comic.

Post reply on HN