Most security isn't the end-all-be-all.
I say this all the time - I'd rather be a user on a well secured Windows server than a poorly configured Linux one. The knowledge of the people running the equipment is more important generally than what the equipment is.
Fri Feb 26 2021 08:43:39 EST from Nurb432i agree that NAT isn't the end all to be all and just one piece of the puzzle, but i think its a bit more than just obscurity.
There was no such thing as "hiding" your network topology. If you had
a firewall it performed access control, and *only* access control.
That's the proper way, and IPv6 will bring us back there.
That's correct. There is no protection that can be achieved with NAT that cannot also be achieved with an SPI firewall that defaults to "outbound flows only." You could get into paranoid arguments about leaking information about the size and shape of your internal network, but none of that sounds like a high-priority concern to me.
Not only that, but the NAT model has a habit of lulling people into a false sense of security. Simply believing it can't be penetrated because the addresses don't work from the outside ... all of that goes away the moment someone establishes a malicious agent inside the network.
And the bad actor is just as likely to be a program or device you brought home.
Right, its not the solution, juts one piece of the puzzle. But ti does help with *basic* external threats.
Of course back during the time period i was talking, it wasn't nearly as 'inadequate' on its own, as it would be now. Times have changed.
Sat Feb 27 2021 17:23:57 EST from IGnatius T FoobarNot only that, but the NAT model has a habit of lulling people into a false sense of security. Simply believing it can't be penetrated because the addresses don't work from the outside ... all of that goes away the moment someone establishes a malicious agent inside the network.
And the bad actor is just as likely to be a program or device you brought home.
Right, its not the solution, juts one piece of the puzzle. But ti
does help with *basic* external threats.
Well then, if security by obscurity is an asset, it's actually a win for IPv6, because the address space is WAY too large for our non-friends on the other side of the world to scan the whole range.
2021-03-21 18:31 from IGnatius T Foobar
So would you do NAT66?
I would do NAT66 in order to have logical segmentations within a LAN and the ISP didn't deign to set propper prefix delegation. Because they would be giving you not much choice.
The bad side is that no one's going to fix it because there's an assumption that IPv6 means no NAT.
The good side is that it probably won't be a big deal for as long as developers continue to assume that they have to deal with both IPv4+NAT44, IPv6, IPv6+NAT64, and IPv6+NAT46 connections.
2021-03-27 12:32 from IGnatius T Foobar
Weird. I'm guessing you'll start to see a lot of the problems that
developed with protocols like FTP when NAT44 first came into existence,
where each end assumes that the IP address it sees at the other end is
the real one, and may attempt to establish a multi-port handshake on
that basis.
I am already finding those issues with some services. Which is the reason why I can offer certain services as ipv4 only
Also, I think the problem with FTP is not NAT as much as the fact there is a firewall in the middle of the connection that does not know which ports to open for data transfers. That issue does not go away just because you remove NAT (which is another reason why I don't think ipv6 is going to bring true end-to-end connectivity, since everything is going to be firewalled anyway).
Actually the issue with FTP is that when the client and server exchange messages over the control channel, those messages actually contain the IPv4 addresses on which they are expected to communicate. The authors of the protocol thought they were being clever and would able to multiplex two or more endpoints over a single control channel. SIP does the same thing, but it actually has a good reason to do so.
A firewall that implements ALG (Application Level Gateway) for such protocols will insert itself into the data stream of the control channel, strip out those addresses, and replace them with the actual visible address after NAT is applied. It will also open the correct dynamic ports to allow the connection to complete.
Modern software that needs to build a mesh does not take chances with ALG. It will establish a UDP connection to a central command-and-control server on the public Internet, which identifies the IP address and UDP port number visible *outside* the client's firewall. At this point, it knows that anyone can use that address/port to reach the originating application, so it distributes that information to all of the other clients on the mesh. Now they all know how to reach each other and they can communicate directly without hairpinning through the command and control server.
Usually. :) Once in a while you get some network nazi who configures the firewall to only permit return traffic from the remote address to which you originally opened the connection. You know this has happened because Mario Kart doesn't work and you have to ground-pound your firewall administrator for doing that.
Hello.
I have been wondering how private can dedicated servers, the sort offered by hosting & housing companies, be. By dedicated server, I mean a server offered in rental as part of a hosting & housing plan by a data center.
My concern is as follows: let's say I am hosting an important industrial secret in a dedicated server. For example, the formula for turning lentils into viagra). How likely is that a data center tech will compromise that information, either by negligence of by directly looking at what is in the server? Specially when comparing to a server that is yours but you placed in a datacenter under a colocation plan.
As far as I understand, dedicated servers get to run monitoring tools planted by the datacenter techs. I have heard some of them missmanage the access credentials very badly.
I know there are datacenter pros here. Any ideas or horror tales you'd like to share in this regard?
Myself, i wouldn't trust a hosted server. They have access to your hardware. And all the time in the world to screw with it, if they are so inclined.
Tue Apr 13 2021 14:00:16 EDT from darknetuserSubject: Privacy of dedicated servers
Hello.
I have been wondering how private can dedicated servers, the sort offered by hosting & housing companies, be. By dedicated server, I mean a server offered in rental as part of a hosting & housing plan by a data center.
My concern is as follows: let's say I am hosting an important industrial secret in a dedicated server. For example, the formula for turning lentils into viagra). How likely is that a data center tech will compromise that information, either by negligence of by directly looking at what is in the server? Specially when comparing to a server that is yours but you placed in a datacenter under a colocation plan.
As far as I understand, dedicated servers get to run monitoring tools planted by the datacenter techs. I have heard some of them missmanage the access credentials very badly.
I know there are datacenter pros here. Any ideas or horror tales you'd like to share in this regard?
I was the manager of an IT Hosted solution in Ohio.
I mean - yeah... when the company sold, the COO saved the document about the sale on her shared drive, with an obvious name - and one of my engineers saw the file - and we all knew what was coming down before anyone else in the company.
That is how IT works. We *do* own Bartertown. I always assume that anything with corporate assets on it has no secrets from the IT staff. I tell companies if they want me to connect remotely, they're not coming through my private residential network - they need to set me up with a corporate line and notebook that will be completely isolated from my personal network.
Tue Apr 13 2021 14:46:13 EDT from Nurb432Myself, i wouldn't trust a hosted server. They have access to your hardware. And all the time in the world to screw with it, if they are so inclined.
2021-04-13 23:54 from ParanoidDelusions
I was the manager of an IT Hosted solution in Ohio.
I mean - yeah... when the company sold, the COO saved the document
about the sale on her shared drive, with an obvious name - and one of
my engineers saw the file - and we all knew what was coming down
before anyone else in the company.
That is how IT works. We *do* own Bartertown. I always assume that
anything with corporate assets on it has no secrets from the IT
staff. I tell companies if they want me to connect remotely, they're
not coming through my private residential network - they need to set
me up with a corporate line and notebook that will be completely
isolated from my personal network.
That matches my experience, for things that are managed by an IT team.
I was wondering if it would be any different for a dedicated (rented) server the staff is only supposed to look into if something breaks, or a hostedserver that is not the property of the hoster and the staff is not even supposed to look at.
I guess it is one of those situations in which going with an external host is fine if you just need the appearance of security ("The data center has signed the data confidentiality papers, so if they mess up and our customers get screwed, we are covered"). However, not great if you need actual security (The server is a key piece in your world domination plan).
It sucks, because colocation/hosting is the only affordable way to have some sorts of benefits nowadays.
It does not mean they WILL, but they CAN. Always assume the worst with security, its safer. Depending on the use case, you might be able to mitigate somewhat with encrypted files and such, where you keep the keys, but they still need a certain level of OS access to support the stuff. ( and i dont blame them for that, if its in my network i need some visibility or you are a risk to everyone else )
We have that problem ourselves, so we get the stuff signed off on by all parties so if it does go south and we end up on the evening news, we can at least blame them.
Wed Apr 14 2021 06:02:18 EDT from darknetuserThat matches my experience, for things that are managed by an IT team.
I was wondering if it would be any different for a dedicated (rented) server the staff is only supposed to look into if something breaks, or a hostedserver that is not the property of the hoster and the staff is not even supposed to look at.
I guess it is one of those situations in which going with an external host is fine if you just need the appearance of security ("The data center has signed the data confidentiality papers, so if they mess up and our customers get screwed, we are covered"). However, not great if you need actual security (The server is a key piece in your world domination plan).
It sucks, because colocation/hosting is the only affordable way to have some sorts of benefits nowadays.
This is true regardless of whether your server is "managed" or simply colocated.
As to whether the employees of the data center would snoop on customer servers just for fun -- that is a matter of whether you are using a reputable hosting company. At my data centers it is grounds for termination, and we *will* find out; all access is logged and the cameras are always rolling. But if you're using a mom-and-pop hosting company with a 1000sqft data center, then yes, you can expect them to poke around when they're bored.
"i got the secret to the universe, go ahead and fire me"
Sometimes threat of being terminated is not enough to stop people. Especially if that is why they are there in the first place. Its better to assume zero trust.
Wed Apr 14 2021 09:20:19 EDT from IGnatius T FoobarThere is such a thing as "lawful intercept". If the data center operator receives a warrant for something on your server, they are typically not permitted to tell the server owner that data or network traffic is being extracted.
This is true regardless of whether your server is "managed" or simply colocated.
As to whether the employees of the data center would snoop on customer servers just for fun -- that is a matter of whether you are using a reputable hosting company. At my data centers it is grounds for termination, and we *will* find out; all access is logged and the cameras are always rolling. But if you're using a mom-and-pop hosting company with a 1000sqft data center, then yes, you can expect them to poke around when they're bored.
Agreed. Between ineptitude, curiosity, and the potential for the payoff being larger than the penalty...
There is also just stumbling across something in your regular work duties. Also... regardless of if everything is logged and cameras are everywhere - assuming your security is bulletproof is always a bad idea. I feel like the highest security places are always the shops with the highest profile leaks.
Wed Apr 14 2021 09:49:27 EDT from Nurb432"i got the secret to the universe, go ahead and fire me"
Sometimes threat of being terminated is not enough to stop people. Especially if that is why they are there in the first place. Its better to assume zero trust.
Wed Apr 14 2021 09:20:19 EDT from IGnatius T FoobarThere is such a thing as "lawful intercept". If the data center operator receives a warrant for something on your server, they are typically not permitted to tell the server owner that data or network traffic is being extracted.
This is true regardless of whether your server is "managed" or simply colocated.
As to whether the employees of the data center would snoop on customer servers just for fun -- that is a matter of whether you are using a reputable hosting company. At my data centers it is grounds for termination, and we *will* find out; all access is logged and the cameras are always rolling. But if you're using a mom-and-pop hosting company with a 1000sqft data center, then yes, you can expect them to poke around when they're bored.
Ok...
So, here is the concept I don't understand about a Vlan.
Let's say I configure my Cisco switch with a Vlan, so that it is on my public network. 7.5.0.0 and my internal LAN 192.168.0.0
How does the traffic get through the Cisco back to the actual 192.168.0.0 subnet?
I mean - I understand... I think - that on the system, you create two virtual NICs going through one physical NIC, right? That has to be true - and then you assign outgoing traffic to either one or both of those NICs - which must be exposed to software somehow... But then the Cisco has to have a route back to the actual physical subnet. Are you physically connecting the Cisco, in that example then - to the WAN, and also bridging it back to the internal network, with a static route defined on the Cisco to the internal network?