Napkin design...let's go LAN'less
-
@hobbit666 said:
What would you put in the firewall box? Would a Ubiquiti EdgeRouter be fine as you mentioned UTM devices are over rated and not really needed?
Ubiquiti EdgeRouter IS a firewall. What would you replace the firewall with?
-
@scottalanmiller said:
@hobbit666 said:
What would you put in the firewall box? Would a Ubiquiti EdgeRouter be fine as you mentioned UTM devices are over rated and not really needed?
Ubiquiti EdgeRouter IS a firewall. What would you replace the firewall with?
Sophos UTM?
-
@hobbit666 said:
@scottalanmiller said:
@hobbit666 said:
What would you put in the firewall box? Would a Ubiquiti EdgeRouter be fine as you mentioned UTM devices are over rated and not really needed?
Ubiquiti EdgeRouter IS a firewall. What would you replace the firewall with?
Sophos UTM?
Going the opposite direction there, I think.
-
I could choose older posts to resurrect... But recent topics have got me thinking about this again...
In the realm of a LANless design... What actually constitutes a LANless design?
- Everyone being able to work from anywhere?
- Treating all devices like they are untrusted (even your own servers)?
- Treating only client devices like they are untrusted?
- Allowing VPN / ZT / Pertino to access servers from off-site?
- Some combination of all of the above?
-
@dafyre said:
- Allowing VPN / ZT / Pertino to access servers from off-site?
This is actually LAN-centric thinking, not LANless. You can so LANless and keep those services, but they encourage LAN thinking.
-
@dafyre said:
- Everyone being able to work from anywhere?
Not required but would nearly always happen naturally.
-
@dafyre said:
- Treating all devices like they are untrusted (even your own servers)?
- Treating only client devices like they are untrusted?
These two are what matter. #2 is absolutely a requirement. #3 is a requirement to "go all the way." Think of it like database normalization. Getting the clients LANless is getting to first order normalization. Getting the servers LANless too would be second order.
-
@dafyre said:
I could choose older posts to resurrect... But recent topics have got me thinking about this again...
In the realm of a LANless design... What actually constitutes a LANless design?
- Everyone being able to work from anywhere?
My thinking is yes, this happens as a result of the initial design.
- Treating all devices like they are untrusted (even your own servers)?
I think servers would be hardened to not trust any client device unless authenticated or authorized.
- Treating only client devices like they are untrusted?
Yes.
- Allowing VPN / ZT / Pertino to access servers from off-site?
LAN-esque design you wouldn't really use them in this instance.
- Some combination of all of the above?
-
@scottalanmiller said:
@dafyre said:
- Allowing VPN / ZT / Pertino to access servers from off-site?
This is actually LAN-centric thinking, not LANless. You can so LANless and keep those services, but they encourage LAN thinking.
This is what I was thinking. Just throwing thoughts out there to see what everybody else is thinking.
Would you put things like Jump boxes into the LAN-centric category as well?
-
@dafyre said:
Would you put things like Jump boxes into the LAN-centric category as well?
No, that's a different kind of thing. A security aggregation point is not the same as a LAN. There is a relationship there for sure. And a LAN is a form of security aggregation, but one based on physical networking (bad) instead of logical security (better.)
-
@scottalanmiller said:
@dafyre said:
Would you put things like Jump boxes into the LAN-centric category as well?
No, that's a different kind of thing. A security aggregation point is not the same as a LAN. There is a relationship there for sure. And a LAN is a form of security aggregation, but one based on physical networking (bad) instead of logical security (better.)
What makes a VPN (ignoring ZT and Pertino for the moment) any different than a Jumpbox in that light?
-
@dafyre said:
What makes a VPN (ignoring ZT and Pertino for the moment) any different than a Jumpbox in that light?
A lot of things. One is that it is purely designed (all VPNs which means ZT and Pertino too) with the sole intent of replicating a LAN where a physical limitation would have prevented it before. The name VPN itself means that. The purpose of a VPN is to encrypt data in flight, nothing more. It "can" be leveraged to do more than that which is why using a VPN does not necessarily stop you from being LANless, but the fundamental goal of a VPN is LAN extension through data encryption. That's what makes it a VPN.
A Jump Box is a user centric authentication mechanism used as an aggregation and control system for security. It mimics many mechanisms in a VPN but is not a VPN. A VPN extends a LAN, a Jump Box proxies to it. Proxying with user authentication vs. network extension using many of the same tools and some not the same.
-
@scottalanmiller said:
@dafyre said:
What makes a VPN (ignoring ZT and Pertino for the moment) any different than a Jumpbox in that light?
A lot of things. One is that it is purely designed (all VPNs which means ZT and Pertino too) with the sole intent of replicating a LAN where a physical limitation would have prevented it before. The name VPN itself means that. The purpose of a VPN is to encrypt data in flight, nothing more. It "can" be leveraged to do more than that which is why using a VPN does not necessarily stop you from being LANless, but the fundamental goal of a VPN is LAN extension through data encryption. That's what makes it a VPN.
Okay, that above paragraph makes sense.
A Jump Box is a user centric authentication mechanism used as an aggregation and control system for security. It mimics many mechanisms in a VPN but is not a VPN. A VPN extends a LAN, a Jump Box proxies to it. Proxying with user authentication vs. network extension using many of the same tools and some not the same.
Wouldn't an RD Gateway function essentially the same as a JumpBox (differences in technology & OS choice aside)? It handles the user authentication, and then bounces the user to the specified host that they wanted to connect to -- the same as a JumpBox.
-
@dafyre said:
Wouldn't an RD Gateway function essentially the same as a JumpBox (differences in technology & OS choice aside)? It handles the user authentication, and then bounces the user to the specified host that they wanted to connect to -- the same as a JumpBox.
Yes, an RDG can be a form of jump box.
-
Time to suddenly reverse gears, ha ha ha. Why would you need a JumpBox or RDGateway in a LANless design (Legacy apps and lab setups aside)?
Your services are designed to be accessed via the internet...and those that can are cloud-hosted, right?
-
@dafyre said:
Your services are designed to be accessed via the internet...and those that can are cloud-hosted, right?
And one of the ways to access them is.... RDP
-
@dafyre said:
Time to suddenly reverse gears, ha ha ha. Why would you need a JumpBox or RDGateway in a LANless design (Legacy apps and lab setups aside)?
Your services are designed to be accessed via the internet...and those that can are cloud-hosted, right?
Centralized authorization/authentication and logging. You can easily know who logged into what system at what point in time. This is a bit harder, although not impossible, with disparate logs and systems. You also only have to lock people out of one location when/if they leave or are let go.
-
@scottalanmiller said:
@dafyre said:
Your services are designed to be accessed via the internet...and those that can are cloud-hosted, right?
And one of the ways to access them is.... RDP
Touche, lol.
-
@coliver said:
@dafyre said:
Time to suddenly reverse gears, ha ha ha. Why would you need a JumpBox or RDGateway in a LANless design (Legacy apps and lab setups aside)?
Your services are designed to be accessed via the internet...and those that can are cloud-hosted, right?
Centralized authorization/authentication and logging. You can easily know who logged into what system at what point in time. This is a bit harder, although not impossible, with disparate logs and systems. You also only have to lock people out of one location when/if they leave or are let go.
That is what tools like ELK are for. 8-) Centralized logging. But you do have a point about locking people out of multiple systems when they leave / are let go.
-
@scottalanmiller said:
ics many mechanisms in a VPN but is not a VPN. A VPN extends a LAN, a Jump Box proxies to it. Proxying with user
As for the Jump boxes, Why make administration something that can be done from anywhere? Sure, those managed boxes might provide other services to the internet at large, like web service, but why open port 22 to the internet at large? Instead you can put all those port 22's behind the jump box allowing logon only from the jump box. Hopefully this provides better security.
