1 It's impossible to secure against DoS, at the very least, without relying on your switching/routing gear.
2 Security-in-depth means hardening the network not just the servers, and that requires you to rely on your network gear to provide a security layer.
3 There are certain behaviors that properly chosen network gear perform very securely and reliably, and are good choices for first-line defenses, with server-side safeguards playing only a back-up role.
4 Network gear provides a third point from which behavior of the trusted servers can be monitored for signs of compromise, rather than trusting the servers to police themselves.
Network is part of the security picture. You can throw all the crypto you want at a problem, but if an attacker can wedge up the communications and cause services to fail before crypto is even a factor under consideration, I'd hardly call that "secure".
From the way the article words it they hadn't even segmented the broadcast domains -- the sensitive servers were in the same VLAN as everything else -- nothing to do with logging capabilities, really -- they were apparently using a dumb switch with no dot1q capabilities whatsoever.
Yeah pretty much. What you can do, if you are integrating these things with real gear, is connect multiple ports from the same switch which send bpdus, to L3-configured (when operating) ports on the crap gear. Then set up a bpduguard on the real gear with a recovery timer, so when this happens the real gear shuts down the ports for a few minutes while the device reboots, and it'll only come up in sub-second blips Not perfect, but better than spanning tree loops and opportunities for hackery.
ISTR there was some level of control via some firmware registers, but there was no utility to write those registers, or there was still a window of bridging, or something. That was a long long time ago.
The problem isn't that what's required is impossible, it's just that nobody has yet found a way to do it.
No, the problem is equivalent to preventing people from having knives despite the ready availability of pieces of metal and stones to sharpen them with.
That, and despite the fact that unbreakable crypto has been available to everyone for decades now, through a comedy of errors, actually getting people to care enough to know which systems are secure and use them, or even provide secure services by default for the ignorant, has eluded us, and our deployment models for secure communications are fraught with unnecessary busy-work and perverse incentives. So, If we cannot manage that there is no way in hell the extra complexity added by a third-party key is going to make it to universal deployment.
As a result, only a few small segments of the population actually get secure crypto: those who luck into using a platform where it has been implemented correctly, and those who care enough to figure out how to roll their own... either just because they are smart and it is easy, or because they really, really need it for purposes either illegitimate or bona-fide.
...or less-than-tech-savvy criminals, which many are.
But it is beside the point. This bill is obviously designed without any regard to the damaging impacts it will actually have and with no hope of producing any real quantity of useful intel. Pure posturing.
Why on earth would you think you need AC-AC conversion for a connector?
Standard NEMA connections will do 600V
I think you answered your own question there. Neither house current nor the battery pack's DC voltage will match the higher voltages needed to push power at reasonable currents.
1% is a bit optimistic... not for coupling loss but for the loss of AC-AC voltage conversion to get across the wire without cooking it or generating insane magnetic fields.
10% is undoubtably worse than the state of the art for plug-in systems, but already better than plug-in systems used to be some decade or so back,
Well, not entirely, you do get to use inflexible low gauge wire to attach it to the grid, since nothing needs to flex or bend, and there are no contacts so you can weld everything in place. Those two things may make for a much lower resistance which would mean less need to step the voltage up. Whether the electronics on the vehicle side are heavier or lighter is important, too. If the 90% figure is accurate it is quite impressive. It should probably be asked of them whether that figure is realistic in an average dingy garage on a gritty wet car without the car being aligned with the pad with laser accuracy.
the state can turn your car into useless junk by simply denying you a registration
But I can still make a mad dash for the border in it. And get all my stuff out of the glove compartment. Or sell it to someone who can register it.
What's really the issue here is that the average consumer has no clue as to the risk being taken on by a cloud product scheme, and thus has no way to compare competing products, so normal market pressures that would force companies to limbo at least under the "complete asshole" bar are rather absent.
Even the dumbass tech-fetishist modern consumer will eventually get sick of being repeatedly smacked in the forehead, but it seems to be taking a very long time these days and that market maturity gets harder to reach with the increasingly novel nature of modern products.
unless of course, the program itself was a browser, or something else that used the internet to perform its basic task
And this is the crux of the matter. Under the new model, you connect and are forced into an upgrade that renders some other part of the system obsolete, and without connecting, the product is of limited use. Why the heck a fitbit needs to store data in a cloud is the question that should have killed the product dead in a reasonable marketplace, but our consumers are not reasonable.
It's kinda hard for open source to do worse than bricking the entire device fleet intentionally, actually. You might have to isolate the device from threats to unpatched security holes, but you'd still be able to run it.
Good to see Google by any other name can still be relied on to continue yanking rugs out from underneath users. I was worried I wouldn't get my monthly schadenfreude fix anymore.
I'd disagree on that last point. The vendors did write (crummy) drivers and (balefully inadequate) documentation, but the OS/firmware vendors had to rewrite everything to actually work reliably, and then continue to rewrite everything when moving to new driver models as OSes evolve, and to new bus architectures/timings.
Personally I don't feel right unless I get a couple times the RDA of sodium. But then, if I want I can add it myself -- it's somewhat harder to remove it, so I'd say we're probably best off with the minimum amount of salt needed to act as a preservative/offset scarier preservatives.
The trouble with PIO/polling drivers was already very well known when USB hit the market, but the chipset manufacturers went for that anyway, and in part it was the fault of the standard for promoting excessive levels of penny pinching in device design, thus externalizing costs onto the software/firmware industry which had to waste time putting humpty dumpty back together again.
I never really had a problem with the friction fit aspect. Sure beat the heck out of PCMCIA. The plugs were fine just there were too many varieties of them. The cabling, though, really went overboard on sacrificing performance for the sake of a few pennies.
They worked out 1 and 2. With horrible extensions that make driver code utterly crummy compared to firewire where the features were designed in from the start.
USB follows the popular market model of "undercut", "embrace", "imitate" that gradually made ugly old IDE into ATA tunneling SCSI protocols after undercutting SCSI. There's just so many technologies like this, and we've accumulated a lot of junk DNA in the codebase as a result. Rarely do we see a benefit from that, it's all just technical debt.
(PoE seems to have no trouble responsibly negotiating power and dealing with wiring faults. They'll eventually imitate it as well, but messier, of course.)
Seriously what the hell is wrong with USB that they can't reliably push 10Gbps a few feet over a custom-built cable where 10G-BaseT can go hundreds of feet over commonly available standardized CAT-6A UTP cable?
When 802.3bt starts shipping can we please just get rid of USB entirely?
Thanks for the chuckle. I'm a professional in the industry. Public IPs get used all the time, where the institution is not address-poor. The proper way to administer a default-closed network is to put in a firewall that is default-closed and then only put in rules for allowed traffic, whether or not you are NATting some of your clients. NAT adds zero security over a proper firewall. Less so now than it used to, but it actually hurts visibility into security investigations by adding an unnecessary layer of indirection. Fortunately there is better reporting these days. In my particular sector, however, some of our users are tech veterans used to being allowed to run services themselves, rather than go to a third party for servers, so that just does not fly. Instead we have to wage a campaign of attrition where we slowly remove inbound access from small segments during office moves and see who complains.
I don't know where you learned "non-private IP" == firewalled IP, maybe in a class, or is Cisco trying to control the vocabulary again with their silly certifications? In the general vernacular, Public == non-Private.
Usually when you see martian sources on packets coming in from an ISP it's just that ISP's internal private addresses on their own equipment leaking out. However some ISPs do not correctly filter so you can get 3rd-party martian sources. You'll rarely ever see a martian destination since the ISP has no reason to install a route to a private network pointing towards you in their table. When that happens there has probably been some major screwups on the BGP level on both ends, assuming you peer. Also a lot of DPI firewalls will log the source and destination backwards if the packet matches a filter for a return packet and they do not bother checking whether a session actually exists before doing so, so what you're actually seeing is a privately addressed destination trying to leave the network (which, if you don't handle in the routing tables, should really be kiled at the edge firewall or failing that, by a competent ISP.)
These printers were on public IPs. In the typical case there was a firewall in place but the job of getting the IP of that printer installed in the firewall, or getting the host firewall on the printer configured, got bungled on a small handful of them. I know here every once in a while when the contractor that provides the printer shows up they do a firmware upgrade and accidentally wipe the device configuration, then realize they screwed up and ham-fist it back together again, whether host firewall policies survive that ordeal is a crap shoot.
Ridiculous. If discrete firewalls are follow-up measures to anything, it is a poor host firewall/OS/application security. There is absolutely nothing wrong with running a public IP.
Post-IPv6 the only place you'll find any NAT is in complicated cloud NOCs that were leveraging some of its more esoteric properties.
As to the sysadmins, well, we could chase every stupid printer an independent department orders and plugs into the wall, but we'd get fired for falling behind on other initiatives if we wasted our time on that.
At least in their BETA program, I believe you get a block. In fact the IPv6 address space is so large, core ISP routers do not generally carry routes below block level, and although the autoconf features in IPv6 are a complete farce which should never be actually used, they do serve an unwitting purpose in preventing subnetting below a certain mask on a technical level.
The world (the access layer at least) is eventually moving to fiver -- G-PON fiber with accompanying DC power leads, terminating in a wallplate that provides a copper power-over-ethernet jack. So, for the purposes of this discussion, nope.
Slashdot Mirror
Really? Personally, I've found the more advanced tech gets, the less reason there is to leave my chair.
Network is part of the security picture. You can throw all the crypto you want at a problem, but if an attacker can wedge up the communications and cause services to fail before crypto is even a factor under consideration, I'd hardly call that "secure".
From the way the article words it they hadn't even segmented the broadcast domains -- the sensitive servers were in the same VLAN as everything else -- nothing to do with logging capabilities, really -- they were apparently using a dumb switch with no dot1q capabilities whatsoever.
Yeah pretty much. What you can do, if you are integrating these things with real gear, is connect multiple ports from the same switch which send bpdus, to L3-configured (when operating) ports on the crap gear. Then set up a bpduguard on the real gear with a recovery timer, so when this happens the real gear shuts down the ports for a few minutes while the device reboots, and it'll only come up in sub-second blips Not perfect, but better than spanning tree loops and opportunities for hackery.
ISTR there was some level of control via some firmware registers, but there was no utility to write those registers, or there was still a window of bridging, or something. That was a long long time ago.
The problem isn't that what's required is impossible, it's just that nobody has yet found a way to do it.
No, the problem is equivalent to preventing people from having knives despite the ready availability of pieces of metal and stones to sharpen them with.
That, and despite the fact that unbreakable crypto has been available to everyone for decades now, through a comedy of errors, actually getting people to care enough to know which systems are secure and use them, or even provide secure services by default for the ignorant, has eluded us, and our deployment models for secure communications are fraught with unnecessary busy-work and perverse incentives. So, If we cannot manage that there is no way in hell the extra complexity added by a third-party key is going to make it to universal deployment.
As a result, only a few small segments of the population actually get secure crypto: those who luck into using a platform where it has been implemented correctly, and those who care enough to figure out how to roll their own... either just because they are smart and it is easy, or because they really, really need it for purposes either illegitimate or bona-fide.
backdoors to govt to spy on law-abiding people
...or less-than-tech-savvy criminals, which many are.
But it is beside the point. This bill is obviously designed without any regard to the damaging impacts it will actually have and with no hope of producing any real quantity of useful intel. Pure posturing.
Yeah, "how's it feel to want?" is the answer to that one.
Why on earth would you think you need AC-AC conversion for a connector?
Standard NEMA connections will do 600V
I think you answered your own question there. Neither house current nor the battery pack's DC voltage will match the higher voltages needed to push power at reasonable currents.
1% is a bit optimistic... not for coupling loss but for the loss of AC-AC voltage conversion to get across the wire without cooking it or generating insane magnetic fields.
10% is undoubtably worse than the state of the art for plug-in systems, but already better than plug-in systems used to be some decade or so back,
Well, not entirely, you do get to use inflexible low gauge wire to attach it to the grid, since nothing needs to flex or bend, and there are no contacts so you can weld everything in place. Those two things may make for a much lower resistance which would mean less need to step the voltage up. Whether the electronics on the vehicle side are heavier or lighter is important, too. If the 90% figure is accurate it is quite impressive. It should probably be asked of them whether that figure is realistic in an average dingy garage on a gritty wet car without the car being aligned with the pad with laser accuracy.
the state can turn your car into useless junk by simply denying you a registration
But I can still make a mad dash for the border in it. And get all my stuff out of the glove compartment. Or sell it to someone who can register it.
What's really the issue here is that the average consumer has no clue as to the risk being taken on by a cloud product scheme, and thus has no way to compare competing products, so normal market pressures that would force companies to limbo at least under the "complete asshole" bar are rather absent.
Even the dumbass tech-fetishist modern consumer will eventually get sick of being repeatedly smacked in the forehead, but it seems to be taking a very long time these days and that market maturity gets harder to reach with the increasingly novel nature of modern products.
unless of course, the program itself was a browser, or something else that used the internet to perform its basic task
And this is the crux of the matter. Under the new model, you connect and are forced into an upgrade that renders some other part of the system obsolete, and without connecting, the product is of limited use. Why the heck a fitbit needs to store data in a cloud is the question that should have killed the product dead in a reasonable marketplace, but our consumers are not reasonable.
It's kinda hard for open source to do worse than bricking the entire device fleet intentionally, actually. You might have to isolate the device from threats to unpatched security holes, but you'd still be able to run it.
Good to see Google by any other name can still be relied on to continue yanking rugs out from underneath users. I was worried I wouldn't get my monthly schadenfreude fix anymore.
Ahem, 10Gbe adaptors are available for less than that, and that's in the server market where vendors are still milking corporate purchase orders.
I'd disagree on that last point. The vendors did write (crummy) drivers and (balefully inadequate) documentation, but the OS/firmware vendors had to rewrite everything to actually work reliably, and then continue to rewrite everything when moving to new driver models as OSes evolve, and to new bus architectures/timings.
Personally I don't feel right unless I get a couple times the RDA of sodium. But then, if I want I can add it myself -- it's somewhat harder to remove it, so I'd say we're probably best off with the minimum amount of salt needed to act as a preservative/offset scarier preservatives.
The trouble with PIO/polling drivers was already very well known when USB hit the market, but the chipset manufacturers went for that anyway, and in part it was the fault of the standard for promoting excessive levels of penny pinching in device design, thus externalizing costs onto the software/firmware industry which had to waste time putting humpty dumpty back together again.
I never really had a problem with the friction fit aspect. Sure beat the heck out of PCMCIA. The plugs were fine just there were too many varieties of them. The cabling, though, really went overboard on sacrificing performance for the sake of a few pennies.
They worked out 1 and 2. With horrible extensions that make driver code utterly crummy compared to firewire where the features were designed in from the start.
USB follows the popular market model of "undercut", "embrace", "imitate" that gradually made ugly old IDE into ATA tunneling SCSI protocols after undercutting SCSI. There's just so many technologies like this, and we've accumulated a lot of junk DNA in the codebase as a result. Rarely do we see a benefit from that, it's all just technical debt.
(PoE seems to have no trouble responsibly negotiating power and dealing with wiring faults. They'll eventually imitate it as well, but messier, of course.)
Seriously what the hell is wrong with USB that they can't reliably push 10Gbps a few feet over a custom-built cable where 10G-BaseT can go hundreds of feet over commonly available standardized CAT-6A UTP cable?
When 802.3bt starts shipping can we please just get rid of USB entirely?
RFC1925 rule 11: "Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works."
Thanks for the chuckle. I'm a professional in the industry. Public IPs get used all the time, where the institution is not address-poor. The proper way to administer a default-closed network is to put in a firewall that is default-closed and then only put in rules for allowed traffic, whether or not you are NATting some of your clients. NAT adds zero security over a proper firewall. Less so now than it used to, but it actually hurts visibility into security investigations by adding an unnecessary layer of indirection. Fortunately there is better reporting these days. In my particular sector, however, some of our users are tech veterans used to being allowed to run services themselves, rather than go to a third party for servers, so that just does not fly. Instead we have to wage a campaign of attrition where we slowly remove inbound access from small segments during office moves and see who complains.
I don't know where you learned "non-private IP" == firewalled IP, maybe in a class, or is Cisco trying to control the vocabulary again with their silly certifications? In the general vernacular, Public == non-Private.
Usually when you see martian sources on packets coming in from an ISP it's just that ISP's internal private addresses on their own equipment leaking out. However some ISPs do not correctly filter so you can get 3rd-party martian sources. You'll rarely ever see a martian destination since the ISP has no reason to install a route to a private network pointing towards you in their table. When that happens there has probably been some major screwups on the BGP level on both ends, assuming you peer. Also a lot of DPI firewalls will log the source and destination backwards if the packet matches a filter for a return packet and they do not bother checking whether a session actually exists before doing so, so what you're actually seeing is a privately addressed destination trying to leave the network (which, if you don't handle in the routing tables, should really be kiled at the edge firewall or failing that, by a competent ISP.)
These printers were on public IPs. In the typical case there was a firewall in place but the job of getting the IP of that printer installed in the firewall, or getting the host firewall on the printer configured, got bungled on a small handful of them. I know here every once in a while when the contractor that provides the printer shows up they do a firmware upgrade and accidentally wipe the device configuration, then realize they screwed up and ham-fist it back together again, whether host firewall policies survive that ordeal is a crap shoot.
the problem _is_ the public IP
Ridiculous. If discrete firewalls are follow-up measures to anything, it is a poor host firewall/OS/application security. There is absolutely nothing wrong with running a public IP.
Post-IPv6 the only place you'll find any NAT is in complicated cloud NOCs that were leveraging some of its more esoteric properties.
As to the sysadmins, well, we could chase every stupid printer an independent department orders and plugs into the wall, but we'd get fired for falling behind on other initiatives if we wasted our time on that.
At least in their BETA program, I believe you get a block. In fact the IPv6 address space is so large, core ISP routers do not generally carry routes below block level, and although the autoconf features in IPv6 are a complete farce which should never be actually used, they do serve an unwitting purpose in preventing subnetting below a certain mask on a technical level.
The world is moving to fiber.
The world (the access layer at least) is eventually moving to fiver -- G-PON fiber with accompanying DC power leads, terminating in a wallplate that provides a copper power-over-ethernet jack. So, for the purposes of this discussion, nope.