[00:01.350 --> 00:04.950]  So, just a quick rundown of what I'm going to go through here.
[00:05.330 --> 00:07.990]  I'm going to introduce myself a little bit more.
[00:08.150 --> 00:12.290]  And then, if you're not too familiar with bastion hosts or jump hosts,
[00:12.290 --> 00:15.030]  don't worry about it. I'm going to go through a quick overview of those
[00:15.630 --> 00:18.470]  and talk about why people use them.
[00:18.470 --> 00:22.090]  Then I'll go through some problems with bastion hosts.
[00:22.190 --> 00:26.430]  In particular, I want to go through the SSH multiplexing attack.
[00:26.430 --> 00:32.430]  And then, we're going to go through some alternatives to bastion hosts
[00:32.430 --> 00:37.090]  in three major cloud providers, AWS, GCP, and Azure.
[00:38.350 --> 00:41.570]  So, like Jaron mentioned, my name is Colin Estep.
[00:41.910 --> 00:45.410]  I worked on the security team at Apple.
[00:45.590 --> 00:48.250]  I also worked in security at Netflix.
[00:48.250 --> 00:52.670]  So, I had kind of a baptism by fire at Netflix learning AWS.
[00:52.810 --> 00:55.310]  And I really loved it.
[00:55.310 --> 00:59.690]  So, I sort of continued that at a startup called SIF Security,
[00:59.690 --> 01:02.290]  where we built some cloud security software.
[01:02.530 --> 01:06.410]  And now, I do threat research at Netscope,
[01:06.410 --> 01:08.630]  the Netscope Threat Labs team.
[01:09.030 --> 01:14.010]  And when I'm not working, I'm probably hanging out with my four kids.
[01:14.010 --> 01:16.290]  And I included a couple pictures here.
[01:16.290 --> 01:19.490]  I like to snowboard. That's at Lake Tahoe.
[01:19.490 --> 01:22.530]  And I also like taking my 4Runner off-road.
[01:22.530 --> 01:26.550]  So, whenever I manage to do those things, that's a lot of fun.
[01:26.690 --> 01:30.870]  So, if anyone has some cool mods that they've done to their off-road vehicle,
[01:30.870 --> 01:32.290]  I would love to see that.
[01:33.250 --> 01:37.290]  So, let's go ahead and jump right in. So, what are bastion hosts?
[01:38.970 --> 01:42.290]  I grabbed this diagram from an old AWS post
[01:42.290 --> 01:44.830]  because it's really nice and simple.
[01:44.930 --> 01:48.650]  So, it shows an AWS environment where you have one VPC,
[01:49.090 --> 01:52.450]  and you have a private subnet and a public subnet.
[01:52.450 --> 01:57.690]  And basically, what's happening here is the only way that the bastion host users,
[01:57.690 --> 02:01.450]  meaning your corporate users that need to access these systems,
[02:01.450 --> 02:06.290]  the only way that they can get to those instances is through these bastion hosts.
[02:06.350 --> 02:11.550]  So, the Linux instances that are running sensitive workloads for you
[02:11.550 --> 02:16.310]  are actually in a private subnet that's not accessible from the Internet,
[02:16.310 --> 02:20.170]  at least for these management protocols like SSH.
[02:20.170 --> 02:25.170]  And so, the only way that you can get to them is through creating your own bastion hosts
[02:25.170 --> 02:30.330]  in a public subnet that does expose SSH to your users.
[02:30.810 --> 02:34.250]  And so, what's the benefit here?
[02:34.250 --> 02:40.570]  So, the idea is that you're limiting the exposure of servers to the Internet
[02:40.570 --> 02:43.910]  and hopefully reducing your footprint, your attack surface.
[02:43.910 --> 02:50.170]  So, it can prevent brute force attacks on SSH for most of your infrastructure.
[02:50.470 --> 02:57.130]  Usually, those bastion hosts, the best practice is to make them simply be bastion hosts.
[02:57.130 --> 03:02.450]  So, you're running EC2 instances in AWS that are not doing anything else.
[03:02.450 --> 03:06.550]  They should not be running a website, they should not be running a database or anything like that.
[03:06.550 --> 03:10.190]  They should just be there for SSH access.
[03:10.190 --> 03:17.030]  And they should be locked down, they should be hardened, and they should have good monitoring around them.
[03:17.090 --> 03:21.450]  And that's one of the things I like about this is that you have some centralized access
[03:21.450 --> 03:25.750]  where you can set up really verbose logging and monitoring.
[03:25.950 --> 03:30.850]  And it's useful, it's not going to just flood the sock with random events.
[03:30.870 --> 03:36.450]  There are probably events that you want to respond to if they're happening on your bastion, if there's something weird.
[03:37.790 --> 03:42.310]  So, you may be wondering, okay, it sounds like there's alternatives.
[03:42.310 --> 03:45.310]  Maybe bastion hosts are sort of an older thing.
[03:45.310 --> 03:46.970]  Why is this still relevant?
[03:46.970 --> 03:50.730]  Well, you know, out of the customer base at Netscope,
[03:50.730 --> 03:57.050]  we looked at a lot of the customers who expose instances to routable IP addresses at all.
[03:57.050 --> 04:03.530]  And we found that almost half of the exposed instances actually allow SSH ingress.
[04:03.530 --> 04:08.910]  So, to me, this kind of signals that people are still running bastion hosts,
[04:08.910 --> 04:14.030]  people may even be running SSH on sensitive workloads directly.
[04:14.150 --> 04:18.370]  And so this is definitely something that's still around and still relevant.
[04:18.370 --> 04:24.750]  And we should look at this a little bit more closely to find what's the best approach for each case.
[04:25.830 --> 04:29.330]  So with that, let's talk about some problems with bastions.
[04:29.330 --> 04:33.890]  Again, you're maintaining EC2 instances yourself.
[04:33.890 --> 04:36.770]  So you're responsible for the OS patching.
[04:36.830 --> 04:43.250]  You're responsible for the configuration of both the network ports and the OS.
[04:43.310 --> 04:49.990]  It could become expensive if you need to distribute bastions in different regions and support a large user base.
[04:49.990 --> 04:55.510]  You're running these compute instances that could, you know, rack up on your bill.
[04:56.690 --> 04:59.790]  And you still need to manage the access all by yourself.
[04:59.790 --> 05:03.510]  So that includes managing SSH certificates.
[05:03.510 --> 05:06.130]  Maybe you have an identity provider you want to connect to.
[05:06.130 --> 05:08.150]  You've got to connect all that plumbing.
[05:08.150 --> 05:10.690]  You've got to worry about the MFA being in place.
[05:10.690 --> 05:17.470]  If you enforce MFA when someone's using your bastion hosts in order to gain access to your infrastructure,
[05:17.470 --> 05:20.030]  you're still dealing with all of that.
[05:20.030 --> 05:26.270]  Plus, it is vulnerable to this SSH multiplexing attack that we're going to talk about next.
[05:26.270 --> 05:31.910]  So these are just a few of the problems that you could run into if you're running your own bastion hosts.
[05:33.070 --> 05:40.390]  So before I talk about attacks, let's just talk about SSH multiplexing itself and what this actually is.
[05:40.390 --> 05:49.350]  It's really a feature of OpenSSH that allows you to reuse a TCP connection for more than one SSH session.
[05:49.350 --> 05:57.470]  So if it's configured in your SSH client, that will essentially save a file to your file system.
[05:57.470 --> 06:03.450]  And you can just invoke the SSH session again by calling up that file.
[06:03.450 --> 06:08.390]  So I have a little example here. There's just a small config snippet on the left side.
[06:08.390 --> 06:12.830]  And that shows how easy it is to set this up for multiplexing.
[06:12.830 --> 06:16.930]  So at the bottom, you'll see control persists 240 minutes.
[06:16.930 --> 06:23.830]  So that's how long I can keep that connection active and then still call the SSH session back up.
[06:23.870 --> 06:27.490]  And then on the right hand side, I have the command that I could use to do it.
[06:27.490 --> 06:32.470]  So I'm basically just calling the file and then telling it what server to use.
[06:32.570 --> 06:39.190]  And I've re-established my SSH connection, and I don't need to enter a password for the key.
[06:39.190 --> 06:44.310]  I don't need to use MFA, even if MFA is being enforced. It's already established.
[06:44.310 --> 06:49.850]  So it's kind of a shortcut to just get straight into a shell.
[06:52.070 --> 06:56.590]  So now that we've talked about multiplexing, a little bit about how that works.
[06:56.590 --> 06:58.550]  Now let's talk about the attack.
[06:58.550 --> 07:03.970]  So basically, the attack is an attacker could compromise one of your users.
[07:05.050 --> 07:15.070]  So a phishing attack or some other thing gaining shell access on an endpoint that is being used by one of your users.
[07:15.970 --> 07:24.210]  Once they get that shell access, it's pretty easy for them, like I showed, to set up this config for the SSH client.
[07:24.330 --> 07:30.430]  And the end user may be completely unaware, because it's not really going to affect anything on their end.
[07:30.430 --> 07:37.370]  So the next time they establish SSH to the bastion, it's getting saved to that socket file.
[07:37.450 --> 07:45.070]  And now the attacker can call that back up and re-establish the connection to the bastion host and circumvent MFA.
[07:45.270 --> 07:50.270]  And from there, it's pretty trivial from the bastion host to get to the actual servers.
[07:50.270 --> 07:59.770]  So even if your end users have really, really great hygiene and are not saving PII onto their laptops or whatever,
[07:59.770 --> 08:07.730]  this is a pretty easy way to sort of gain access to where those good things live.
[08:08.410 --> 08:13.670]  And I just wanted to give credit to the NCC group for a blog post about this.
[08:13.670 --> 08:17.590]  So on the bottom right hand corner of my slide, you'll see a link to their blog post.
[08:17.590 --> 08:21.750]  It was a really useful blog post when I was discovering this.
[08:21.830 --> 08:24.690]  So this is not something I cooked up myself.
[08:26.410 --> 08:35.570]  So now that we've talked about bastion hosts, hopefully you guys were able to follow what those are and why there might be some problems with them.
[08:35.570 --> 08:38.150]  I wanted to present you with some solutions.
[08:39.310 --> 08:46.470]  Before I dive into the details of each solution, I wanted to just sort of cover some common attributes that I found.
[08:46.470 --> 08:51.750]  And these are not necessarily all requirements that I set out to satisfy.
[08:51.750 --> 08:56.850]  These were just things that I discovered as I was exploring these different solutions.
[08:57.150 --> 09:02.030]  And I think it's good to keep these in mind as we examine each one.
[09:02.030 --> 09:13.610]  So the first one is that your end users are not actually establishing SSH or RDP connections straight up from their endpoints.
[09:13.610 --> 09:17.930]  They're going over HTTPS to start these connections.
[09:20.190 --> 09:25.170]  The next two items are really sort of related to having bastion hosts as well.
[09:25.170 --> 09:33.530]  In an ideal world, you're not going to need to have public IP addresses assigned to your sensitive workloads in order to gain access to them.
[09:34.010 --> 09:38.710]  But, you know, again, if you're running your own bastion hosts, you have to take care of all that plumbing.
[09:38.710 --> 09:41.210]  You have to make sure that it can communicate.
[09:41.970 --> 09:47.630]  The third point is, again, having to do with network exposure.
[09:47.630 --> 09:52.610]  You're not exposing these network ports to external routable IP addresses.
[09:52.990 --> 09:57.710]  With these alternative solutions, in some cases, you don't have to expose it at all.
[09:58.450 --> 10:01.050]  And it removes the risk.
[10:01.050 --> 10:06.510]  These new solutions, well, they're relatively new compared to bastion hosts.
[10:06.510 --> 10:14.650]  These alternative solutions sort of remove the risk of the SSH multiplexing attack as I presented it.
[10:14.710 --> 10:27.190]  I will point out, if you have an attacker that got remote shell on the client endpoint and they're advanced enough, I'm sure they're going to find another way to peer into HTTPS traffic or something else.
[10:27.190 --> 10:34.170]  But the low-hanging fruit of this SSH multiplexing attack will essentially go away.
[10:34.170 --> 10:41.270]  And then lastly, the logging provided by these cloud services is pretty good.
[10:41.350 --> 10:44.390]  Right out of the box, you kind of get a lot for free.
[10:44.390 --> 10:46.950]  So I'll cover that.
[10:46.950 --> 10:51.230]  So with that, let's dive into the actual services themselves.
[10:51.230 --> 11:00.190]  So I'm going to cover Session Manager, which is part of a bigger service called AWS Systems Manager in AWS.
[11:00.190 --> 11:06.150]  And then GCP has OSLogin and the Identity-Aware Proxy or IAP.
[11:06.570 --> 11:09.410]  And then Azure has the Bastion service.
[11:09.410 --> 11:11.730]  So these are the three that I'm going to cover.
[11:13.690 --> 11:16.050]  So first, let's start with AWS.
[11:17.350 --> 11:23.310]  Like I mentioned, Session Manager is part of AWS Systems Manager or SSM.
[11:23.590 --> 11:29.010]  And this is the only service that I'm going to show you that actually relies on an agent.
[11:29.010 --> 11:39.370]  So in order for you to use the model that I'm going to go through, you actually have to deploy SSM agent to each EC2 instance that you want to be able to access.
[11:39.870 --> 11:48.990]  But if you're an AWS customer who's already using Systems Manager, this might be a non-issue because you're probably already going to have it on there.
[11:49.690 --> 11:54.290]  It does not actually use SSH at all or RDP by default.
[11:54.290 --> 12:00.690]  And it can provide you full session logs, which sort of stands out from the other services.
[12:01.910 --> 12:06.750]  So with that, let's just sort of get a high-level view of how this works once it's configured.
[12:06.770 --> 12:12.030]  There's a lot of steps to get this configured, and I'm not going to go through that because that would take a long time.
[12:13.110 --> 12:20.110]  I do have a blog post that came out a couple days ago about this specific setup.
[12:20.110 --> 12:23.590]  And so that takes you into more gritty detail of how you get this working.
[12:24.170 --> 12:29.950]  But for the sake of this presentation, I'm just going to walk through the scenario so you get a high-level view of it.
[12:30.310 --> 12:36.790]  So in this scenario, I've got a bunch of EC2 instances in a private subnet in a VPC.
[12:36.790 --> 12:43.470]  So that means these EC2 instances are not exposed to the internet, at least for any sort of workload purposes.
[12:44.330 --> 12:48.150]  And I want to keep it that way, you know, especially for this access.
[12:48.150 --> 12:55.590]  So basically, within the VPC, I can create VPC endpoints.
[12:55.610 --> 13:06.420]  And this is something called AWS Private Link, where you set up a virtual sort of endpoint for APIs that you want to interact with, AWS APIs.
[13:06.850 --> 13:14.130]  And they live in the VPC, so the traffic is not going over the internet.
[13:14.130 --> 13:21.670]  So the traffic between the EC2 instances and what says SSM endpoints in my diagram is actually staying within AWS.
[13:21.670 --> 13:23.590]  And it's over HTTPS.
[13:23.590 --> 13:33.250]  So in this case, I didn't even have to create an opening for SSH within the VPC or within the subnet.
[13:33.250 --> 13:36.420]  SSH is completely locked down in this example.
[13:36.890 --> 13:39.770]  And I don't have traffic going over the internet.
[13:39.770 --> 13:46.150]  The only place that I have traffic going over the internet is the client accessing the Session Manager.
[13:46.590 --> 13:52.210]  So the client side on the far right hand side, you'll see I have three methods listed out.
[13:52.210 --> 13:56.590]  These are the main methods to launch a session with Session Manager.
[13:56.590 --> 14:00.430]  The first two are both through the AWS Web UI.
[14:00.430 --> 14:02.930]  One is within the EC2 console.
[14:02.930 --> 14:05.890]  One is within the Session Manager console.
[14:05.890 --> 14:19.350]  The reason why I listed those out here is because you can actually put the permissions for each client at such a granular level that you can specify if you don't want them using the Session Manager console.
[14:19.350 --> 14:25.250]  You can say, hey, they can only launch sessions through the EC2 console, for example.
[14:25.870 --> 14:29.550]  Or just through the AWS command line interface.
[14:29.550 --> 14:34.030]  And so in the case of the AWS command line interface, you can do that.
[14:34.030 --> 14:39.570]  But for some reason, you need to install a plugin in order for that to work with Session Manager.
[14:41.450 --> 14:44.430]  But those are three ways of doing it.
[14:44.550 --> 14:50.170]  And it's communicated over HTTPS as well on that side of things.
[14:50.170 --> 14:52.910]  So Session Manager kind of sits in the middle.
[14:52.910 --> 14:58.330]  The service itself is sitting in the middle, providing that shell access to the end client.
[15:00.490 --> 15:08.730]  So once you're doing this, once you're actually using that for sessions, how do you sort of keep track of what's happening?
[15:08.730 --> 15:20.590]  So the great thing here is for anyone who's not familiar, AWS has a logging facility called CloudTrail, which keeps tabs on what's happening in your account if you enable it.
[15:21.310 --> 15:29.470]  And you save it off, you can look at these CloudTrail logs, and it provides a nice audit trail of everything your users are doing.
[15:29.530 --> 15:37.530]  And so by default, without you configuring anything else, SSM will log events around the beginning and ending of sessions.
[15:37.850 --> 15:49.330]  And these sessions contain some nice metadata about, I mean, these events contain some nice metadata about the sessions, such as the AWS user that's making these requests.
[15:50.130 --> 15:56.390]  In the cases where multi-factor is in the workflow, that will be logged as well.
[15:56.550 --> 16:11.550]  I'll just point out if your user has the AWS CLI, and they are using their API key, and MFA is not being enforced there, obviously, that's a way around using MFA.
[16:11.750 --> 16:13.770]  So that's something to be aware of.
[16:13.770 --> 16:19.750]  It also includes the EC2 instance ID that's being targeted for access.
[16:19.870 --> 16:30.850]  And then the other basics that you're usually going to see for these sort of audit events, like the IP address it's coming from, the timestamps, and whether it's allowed or denied.
[16:32.250 --> 16:38.290]  Now, another great thing about Session Manager is it goes beyond just that CloudTrail logging.
[16:38.290 --> 16:52.770]  If you want full session logs, and what I mean by that is if you want to see, once the users get on the system, what they've typed in and what the results were, you can actually obtain that pretty easily.
[16:52.770 --> 17:04.290]  So once you configure that logging in Session Manager, you're just going to want to elect where to save the logs.
[17:04.290 --> 17:18.250]  So if whether you do data lake from S3 buckets, or you use CloudWatch to ship logs off somewhere else, or whatever your case may be, you can use either one of those options to save off the SSM logs.
[17:18.250 --> 17:27.490]  And in my example here, I'm just showing again, in the case that I have EC2 instances that I want to stay private, and minimize internet traffic,
[17:27.490 --> 17:36.930]  I can set up endpoints and get those logs shipped off to where they need to go without it going through the internet. So it's a really great feature.
[17:37.870 --> 17:52.870]  And one thing I do want to point out is that, excuse me, if one thing that they do provide in Session Manager is the ability to say tunnel SSH over those HTTPS connections.
[17:52.870 --> 18:03.190]  And if that happens, if you elect to do that, the only shortfall here is you won't have these full session logs because it's encrypted traffic with SSH.
[18:05.530 --> 18:12.510]  Okay, so next, we're going to go over the GCP solutions. That's using OS login and IAP.
[18:15.830 --> 18:24.850]  So in GCP, you don't need any agents to be deployed to your virtual machines. I will point out it's very easy to set up.
[18:24.850 --> 18:35.730]  So if your organization is a G Suite organization that uses GCP, it's very easy to set this up. It's like a matter of minutes.
[18:35.730 --> 18:45.550]  And it's great because you can pair your local OS level users that are SSHing in with the Google IAM user.
[18:45.570 --> 18:55.870]  It also provides LDAP and AD support if you need to do that. And again, it logs metadata of the sessions for free, very similar to AWS.
[18:55.870 --> 19:07.070]  And it's super easy. If you use two-factor authentication for G Suite, you can basically do like a checkbox and enable it for SSH as well.
[19:09.310 --> 19:17.770]  So we'll go through how this works a little bit. So again, you have servers in a VPC that are private.
[19:17.770 --> 19:25.190]  And I don't want these exposed to the internet. So there's no public IP addresses associated with them, or any of that.
[19:25.310 --> 19:35.850]  And what I have to do is create an... well, I have to enable Identity-Aware Proxy or IAP in the project itself.
[19:35.850 --> 19:42.870]  So you'll notice here in the diagram, I have the Google Cloud Platform box. And then I have a project box within that.
[19:42.870 --> 19:50.090]  And so I put IAP in there on purpose, because you have to create that in each project you want to use it.
[19:51.050 --> 20:01.030]  And so once you've enabled it, essentially, for anyone who's not aware, in GCP, you have to enable the APIs you want to use, with a few exceptions.
[20:01.030 --> 20:07.510]  But for the most part, you have to enable everything you want to use. And so IAP is one of those that you have to enable it first.
[20:07.510 --> 20:15.270]  So the admin or whoever will enable that. And now you can say that you want to use it with TCP forwarding.
[20:15.290 --> 20:24.810]  And that's where it gives you pretty good access to SSH into your servers directly.
[20:24.910 --> 20:34.490]  So you hit IAP with HTTPS coming from your user, and then it creates the tunnel for you to your server.
[20:34.490 --> 20:40.050]  And then OS login is a second service that you can be using for logging into the servers.
[20:40.050 --> 20:43.450]  So IAP is basically just sort of the networking piece.
[20:43.450 --> 20:56.230]  So the servers that you have in your VPC have to allow the IAP endpoint range, the IP address range, to access port 22 on the servers.
[20:56.290 --> 21:00.910]  But other than that, you can have SSH locked down and blocked for everything else.
[21:00.910 --> 21:06.410]  And then OS login is sort of the SSH off portion of it.
[21:06.890 --> 21:16.830]  So once you hit the servers, it goes and checks. If OS login is enabled for those machines, you can do it on the individual machine level or in the project.
[21:16.950 --> 21:25.590]  And if the user who's making the Google IAM user who's making the request is authorized by OS login, they'll be able to establish a connection.
[21:25.590 --> 21:36.890]  Now, one of the great things that I like about this is even though it's still using SSH, if the OS login is all set up, and the user hasn't even set up SSH keys on these machines,
[21:36.890 --> 21:42.350]  it'll set up an ephemeral pair of keys for you and establish the connection.
[21:42.950 --> 21:48.270]  And so you still don't have to manage SSH keys, even though it is using SSH.
[21:49.030 --> 22:02.170]  And on the bottom of the diagram, I'm just showing basically for your overview here that SSH traffic is not being allowed from the internet at all.
[22:04.630 --> 22:11.370]  So what do you get from this? You're getting, again, in the default audit logs.
[22:11.710 --> 22:17.730]  Within Google, there's two different types. There's administrative action, I think is what it's called, and then data access.
[22:17.730 --> 22:24.770]  And when IAP is authorizing a session for a user, we'll see entries in the data access logs.
[22:24.770 --> 22:34.730]  So the audit logs that you get for free in GCP will contain events where you're establishing and removing connections.
[22:34.750 --> 22:47.430]  And so that'll contain the same kind of info we had with AWS, where it's got the primary email of the Google identity, the destination IP import, instance ID, and all the rest.
[22:49.270 --> 22:54.710]  Now, if you want additional logs, I borrowed this diagram from the GCP documentation.
[22:55.270 --> 23:04.810]  It's kind of a complicated looking diagram just to show, basically, you can install a logging agent on your virtual machines.
[23:04.870 --> 23:12.630]  And you can set it up to take things like syslog and process that and send it off to Stackdriver Logging.
[23:12.630 --> 23:17.070]  Stackdriver Logging is where you have those audit logs that I was just talking about.
[23:17.070 --> 23:21.670]  So Stackdriver is sort of the centralized place that you go in GCP to look at logs.
[23:21.830 --> 23:25.550]  And so it's just showing here that it's fairly straightforward.
[23:25.550 --> 23:36.530]  If your virtual machines don't have internet access, you need to enable private access, Google private access, and that'll allow it to hit the logging API endpoints.
[23:36.910 --> 23:40.510]  And the logging agent will ship these logs off for you.
[23:40.530 --> 23:46.650]  And, you know, you can do, if you want debug level logs on things, you can get that off of your endpoints.
[23:46.650 --> 23:53.870]  But that's basically your option here if you wanted to get additional things from the virtual machines.
[23:54.730 --> 23:58.630]  So that's it for Google. It's really sort of quick and easy.
[23:58.710 --> 24:03.470]  The next one we'll go through is in Azure, the Azure bastion hosts.
[24:03.910 --> 24:11.190]  So basically, in Azure, you're again connecting over HTTPS to the bastion.
[24:11.190 --> 24:14.910]  And then that connects to the servers via SSH or RDP.
[24:15.470 --> 24:20.030]  You still need to maintain your SSH certificates with this particular one.
[24:20.290 --> 24:26.150]  And you expose the SSH port to internal traffic so that the bastion can get to it.
[24:26.790 --> 24:30.490]  A great feature here is that it works with just-in-time access.
[24:30.590 --> 24:39.650]  So in case you're not aware of that, even though you need to enable the SSH port from internal traffic, you can use it with just-in-time.
[24:39.650 --> 24:44.470]  So just-in-time is where you block SSH in your firewall rules.
[24:44.470 --> 24:53.310]  But anytime you want to establish an SSH connection, you request access, and then it gets granted through the just-in-time service.
[24:53.490 --> 24:58.930]  And that enables SSH for, say, an hour or three hours, whatever it is.
[24:58.950 --> 25:03.130]  And then it goes back to being blocked automatically after the time expires.
[25:04.550 --> 25:11.610]  And I borrowed this diagram from Azure. I thought it was pretty good, so I didn't bother reinventing the wheel here.
[25:13.130 --> 25:20.710]  This shows the user hitting the Azure portal, and it establishes a connection on the Azure bastion.
[25:20.710 --> 25:28.750]  So in your virtual network where you want to have this level of access, you have to create an Azure bastion instance.
[25:28.750 --> 25:34.650]  Now, that's not an instance of a virtual machine. It's an abstracted sort of instance.
[25:34.650 --> 25:38.450]  So you're not maintaining the OS-level patching or any of that.
[25:38.450 --> 25:46.310]  It's just sitting there for your use. And it has to sit in its own subnet called Azure bastion subnet.
[25:46.690 --> 25:56.570]  And so you access that through HTTPS, and then the bastion allows you to access SSH on your virtual machine.
[25:58.850 --> 26:04.370]  And so what does this look like? I mentioned you have to kind of still manage the SSH certs.
[26:04.370 --> 26:11.030]  So what this looks like here is this is a screenshot from me going through the virtual machine.
[26:11.450 --> 26:16.410]  I'm looking at the virtual machine in my Azure portal, and I say I want to connect to it.
[26:16.410 --> 26:20.270]  And it gives me three options. It says RDP, SSH, and bastion.
[26:20.390 --> 26:30.830]  So connecting via bastion, I put in the local username for my SSH user, and then I can put in my private key here.
[26:30.830 --> 26:34.330]  But the public key needs to be sitting on that virtual machine.
[26:35.570 --> 26:41.330]  And you may be asking, does this support AD? And it does not currently.
[26:41.770 --> 26:45.730]  I saw that Microsoft says that they're working on that.
[26:45.730 --> 26:53.610]  So you can set up AD shell access, but you can't do it through a bastion.
[26:56.030 --> 26:59.290]  So what do you get when you're using the bastion host?
[26:59.290 --> 27:07.870]  So one unique thing that you have here that stands out from the other two cloud providers is you can see active sessions as they are happening.
[27:08.050 --> 27:12.770]  And if you are an admin, you can actually delete sessions.
[27:12.770 --> 27:22.270]  So if a user contacts you and says, hey, I'm noticing something weird and you think there's a compromise, you can come in here and you can knock sessions off.
[27:22.590 --> 27:27.070]  So that was kind of interesting to see that. And this is what the screen looks like.
[27:27.070 --> 27:34.290]  So you can see here I have one active connection to call in server and I can see the target IP address.
[27:34.290 --> 27:40.690]  And that IP address is obviously not routable because I wanted it to stay in a private VNet.
[27:41.110 --> 27:47.810]  And it's using the SSH protocol. So you can see some of the good details there.
[27:49.290 --> 27:53.550]  And again, with this provider, you get similar support.
[27:53.550 --> 28:01.470]  So Azure makes it really easy. You don't get it quite for free, but it's so easy to set up and send it off that it's pretty much for free.
[28:01.570 --> 28:06.910]  So you just have to tell Azure where you want to send the audit logs from the bastion.
[28:07.350 --> 28:12.490]  And so these are the three choices, log analytics, a storage account or an event hub.
[28:12.670 --> 28:17.430]  And I did not see any facility for setting up full session logs at this time.
[28:18.010 --> 28:21.510]  Because again, it's using SSH, so it's going to be encrypted.
[28:22.350 --> 28:26.470]  So if you sent it off to log analytics, this is kind of what it would look like.
[28:26.470 --> 28:35.830]  Again, you get some useful metadata around the connections themselves and when they're ended and the protocols they're using.
[28:37.770 --> 28:41.330]  So that's it for the deep dive.
[28:41.930 --> 28:48.610]  So just to kind of wrap things up here, running your own bastion hosts may not be necessary.
[28:48.610 --> 28:57.950]  If you're looking at rolling something out, if your organization is migrating to the cloud and you're thinking about rolling out bastion hosts,
[28:57.950 --> 29:01.490]  you should really look at these alternatives. You may not need to.
[29:03.050 --> 29:10.050]  If you need to, for some reason, just at least be aware that these SSH multiplexing attacks exist.
[29:10.050 --> 29:13.530]  And so there's ways of dealing with it.
[29:13.530 --> 29:21.270]  But I think personally, the best way of dealing with it is just not to have to manage your own bastion hosts.
[29:22.090 --> 29:28.530]  Cloud providers and even third party vendors provide some great alternatives for managing this level of access.
[29:28.550 --> 29:31.390]  So it's definitely worth looking at.
[29:32.370 --> 29:40.690]  These solutions that are out there, they can help with basically all aspects of the bastion host issue.
[29:41.270 --> 29:46.690]  If you're running your own bastions, you're running more compute instances that you have to manage.
[29:46.690 --> 29:51.390]  You have to manage the patching schedule, you have to deal with the costs, all of that.
[29:51.450 --> 29:56.930]  And then there's identity management that comes into play and the logging and monitoring.
[29:56.930 --> 30:02.230]  I was surprised at the level of logging and monitoring you can get from these cloud providers right out of the box.
[30:02.390 --> 30:05.410]  So it's definitely something worth considering there.
[30:06.670 --> 30:09.330]  So with that, I'll take any questions.
[30:09.570 --> 30:16.090]  One thing I wanted to plug here is if this sort of content is useful to you,
[30:16.090 --> 30:21.090]  I highly encourage you to follow our blog, the Netscope Threat Labs blog.
[30:21.090 --> 30:29.110]  We post things about threats that we find, but we also post stuff that we just find interesting, things that we dream up.
[30:29.310 --> 30:32.850]  It could be some useful content.
[30:32.850 --> 30:38.310]  So I highly encourage anybody who's interested to check that out and follow us on Twitter.
[30:38.310 --> 30:42.670]  You can reach out to me on Twitter or LinkedIn if you have any more questions.
[30:42.670 --> 30:51.750]  Or even if you're like, hey, I've been looking at these things and what do you think of some other issue I didn't bring up here?
[30:51.750 --> 30:56.650]  I love to nerd out about cloud stuff, cloud security.