WEBVTT 0:00:02.200000 --> 0:00:07.380000 In this video, I'd like to talk about the two most common ESA deployment 0:00:07.380000 --> 0:00:12.280000 options. So I'm going to be discussing in a particular topology that utilizes 0:00:12.280000 --> 0:00:16.420000 email where the ESA fits into that topology. 0:00:16.420000 --> 0:00:20.480000 And specifically, we're going to be covering two terms you might hear, 0:00:20.480000 --> 0:00:25.480000 something called single interface or single arm deployment or dual interface 0:00:25.480000 --> 0:00:29.240000 or dual arm deployment. 0:00:29.240000 --> 0:00:34.540000 Now, as far as the Cisco email security appliance is concerned, the only 0:00:34.540000 --> 0:00:38.280000 protocol that it actually listens to and monitors as far as emails concerned 0:00:38.280000 --> 0:00:44.540000 is a simple mail transfer protocol, which is on TCP port 25. 0:00:44.540000 --> 0:00:49.840000 So the ESA does not listen to POP3 or IMAP protocols, which are sometimes 0:00:49.840000 --> 0:00:55.800000 used by email clients like laptops and PCs to download their emails from 0:00:55.800000 --> 0:01:03.360000 a server. So the ESA is not meant to sit between the client or laptop 0:01:03.360000 --> 0:01:07.660000 and the email server, because those transactions are typically as emails 0:01:07.660000 --> 0:01:10.740000 downloaded IMAP or POP3. 0:01:10.740000 --> 0:01:13.040000 So it's your choice. 0:01:13.040000 --> 0:01:16.320000 The ESA can be deployed as either a physical or a virtual appliance. 0:01:16.320000 --> 0:01:20.120000 You can buy a physical ESA, which is a physical box, which you would rack 0:01:20.120000 --> 0:01:23.740000 mount somewhere, or it can be a virtual appliance, which is simply you 0:01:23.740000 --> 0:01:30.040000 would have a server and you would install it as software within the server. 0:01:30.040000 --> 0:01:33.800000 And the ESA is deployed as an MTA in the email pipeline. 0:01:33.800000 --> 0:01:35.140000 Now what is an MTA? 0:01:35.140000 --> 0:01:36.460000 You may have never heard that before. 0:01:36.460000 --> 0:01:38.860000 Well, let's take a look at this next picture right here. 0:01:38.860000 --> 0:01:43.380000 And this sort of shows you where the ESA fits into everything. 0:01:43.380000 --> 0:01:48.360000 So when you are sending your email outbound, let's just take a look at 0:01:48.360000 --> 0:01:49.740000 that right here. 0:01:49.740000 --> 0:01:54.120000 So here's you, John at INE.com, and you are pushing out an email. 0:01:54.120000 --> 0:01:57.660000 Now this is assuming, of course, that you're running some sort of email 0:01:57.660000 --> 0:02:03.760000 client software right here on your laptop, like Eudora or Microsoft Outlook 0:02:03.760000 --> 0:02:06.200000 or Apple email or something like that. 0:02:06.200000 --> 0:02:11.660000 So you've created the email locally on your client, which means that if 0:02:11.660000 --> 0:02:14.940000 you shut off that laptop, that email would be destroyed. 0:02:14.940000 --> 0:02:19.820000 And now you need to upload that email to an MSA. 0:02:19.820000 --> 0:02:22.160000 So what is an MSA? 0:02:22.160000 --> 0:02:24.900000 An MSA stands for a mail submission agent. 0:02:24.900000 --> 0:02:27.660000 So you are uploading the email to the MSA. 0:02:27.660000 --> 0:02:30.980000 Now this does utilize SMTP. 0:02:30.980000 --> 0:02:36.940000 Like I mentioned, the ESA does listen to SMTP, but the ESA was not designed 0:02:36.940000 --> 0:02:41.980000 to fulfill the role of a mail submission agent. 0:02:41.980000 --> 0:02:43.380000 It doesn't have the bells and whistles. 0:02:43.380000 --> 0:02:47.920000 It doesn't have the software to directly interact with the client like 0:02:47.920000 --> 0:02:50.560000 that. So that's not its purpose. 0:02:50.560000 --> 0:02:59.620000 Now once the MSA gets the email, then the next server that is email related 0:02:59.620000 --> 0:03:03.280000 that it's going to send it to is the MTA. 0:03:03.280000 --> 0:03:06.560000 And this is where the Cisco ESA fits. 0:03:06.560000 --> 0:03:10.380000 The MTA is the mail transfer agent. 0:03:10.380000 --> 0:03:14.420000 In most scenarios, this would be like a Linux box or a Windows box or 0:03:14.420000 --> 0:03:15.760000 a Windows server or something like that. 0:03:15.760000 --> 0:03:19.860000 In this case, we're substituting all that for our Cisco ESA and that's 0:03:19.860000 --> 0:03:27.140000 where it goes. And so one MTA will then transfer email via SMTP to another 0:03:27.140000 --> 0:03:31.580000 MTA. And you can see in both these scenarios here, this is where your 0:03:31.580000 --> 0:03:38.780000 ESA sits. And then we've got Sally over here. 0:03:38.780000 --> 0:03:42.740000 Sally decides that she wants to check her email. 0:03:42.740000 --> 0:03:47.620000 So if like John, if she's running some sort of local email client in her 0:03:47.620000 --> 0:03:51.600000 laptop like Eudora or Microsoft Outlook or something like that, she's 0:03:51.600000 --> 0:03:56.740000 going to invoke pop three or IMAP and she's going to send a message upstream 0:03:56.740000 --> 0:04:02.380000 to her mail delivery agent and say, hey, do you have any email for me? 0:04:02.380000 --> 0:04:07.800000 And just like the ESA is not designed to sit as an MSA, it's also not 0:04:07.800000 --> 0:04:10.660000 designed to act as an MDA. 0:04:10.660000 --> 0:04:17.460000 So the three components of email are an MSA and MTA and an MDA. 0:04:17.460000 --> 0:04:28.040000 And of those three, the ESA fits right here as a mail transfer agent. 0:04:28.040000 --> 0:04:32.700000 So sort of at a real high level here, two key points to remember. 0:04:32.700000 --> 0:04:38.840000 The ESA is deployed as the first email server for mail coming from the 0:04:38.840000 --> 0:04:44.080000 internet. So as email is coming in, most likely the very first box that 0:04:44.080000 --> 0:04:46.800000 email is going to hit is going to be a firewall at the very edge of your 0:04:46.800000 --> 0:04:51.520000 network. And then right behind that firewall should sit your ESA as the 0:04:51.520000 --> 0:04:55.460000 very first device that's getting that email is coming in. 0:04:55.460000 --> 0:04:59.920000 What about email is going out leaving your company going to the internet? 0:04:59.920000 --> 0:05:02.460000 Well, the ESA should be the last server. 0:05:02.460000 --> 0:05:05.560000 The last thing just before it hits the firewall, just before it leaves 0:05:05.560000 --> 0:05:10.240000 your company. So that leads us to the two deployment scenarios that you 0:05:10.240000 --> 0:05:12.080000 should be familiar with. 0:05:12.080000 --> 0:05:14.520000 So this one right here is the most common. 0:05:14.520000 --> 0:05:18.220000 By far, the most common is what's called a single arm or a single interface 0:05:18.220000 --> 0:05:23.920000 deployment. The main thing here to remember is why we call it that is 0:05:23.920000 --> 0:05:27.820000 because ESA is just like you can see here just using one physical interface, 0:05:27.820000 --> 0:05:32.540000 which is connecting to in this particular scenario a firewall. 0:05:32.540000 --> 0:05:37.900000 So in a single arm or single interface deployment, the outside interface 0:05:37.900000 --> 0:05:45.200000 of the firewall would be facing the internet. 0:05:45.200000 --> 0:05:48.040000 You'd have a third interface, a second interface, which is called a DMZ 0:05:48.040000 --> 0:05:51.480000 interface. That's what would connect to your ESA. 0:05:51.480000 --> 0:05:55.280000 And then you'd have a third interface, which is an inside interface, which 0:05:55.280000 --> 0:05:58.480000 would connect to your rest of your inside network. 0:05:58.480000 --> 0:06:04.520000 So as far as email that's coming in from the internet's concerned, as 0:06:04.520000 --> 0:06:05.300000 it comes in this way. 0:06:05.300000 --> 0:06:09.880000 And remember, it's coming in as SMTP because there's some other sort of 0:06:09.880000 --> 0:06:17.420000 mail delivery agent or mail, yeah, mail delivery agent or mail transfer 0:06:17.420000 --> 0:06:23.740000 agent up here that's doing SMTP hits the DMZ on the outside interface. 0:06:23.740000 --> 0:06:30.280000 Now the way most firewalls are configured is that interfaces have different 0:06:30.280000 --> 0:06:31.120000 security levels. 0:06:31.120000 --> 0:06:35.400000 And a lot of firewalls is based on like a numeric number, like zero would 0:06:35.400000 --> 0:06:37.620000 be the absolute lowest security. 0:06:37.620000 --> 0:06:41.560000 That would be, well, it depends on how you define low and high, but that 0:06:41.560000 --> 0:06:45.580000 would be like your outside interface. 0:06:45.580000 --> 0:07:01.020000 And then you might have something like 50 being the DMZ and then 100 being 0:07:01.020000 --> 0:07:03.800000 your inside. On your typical firewall. 0:07:03.800000 --> 0:07:07.400000 And your typical firewall once it understands which interfaces are assigned 0:07:07.400000 --> 0:07:12.120000 security levels at a high level, the way rules work is that, hey, if data 0:07:12.120000 --> 0:07:18.180000 is coming in on a really high number, like if data is being received on 0:07:18.180000 --> 0:07:22.440000 an inside interface, like here, whoop, okay, just got in, well, actually, 0:07:22.440000 --> 0:07:23.700000 let's do it like this. 0:07:23.700000 --> 0:07:25.480000 Right here, it just came in. 0:07:25.480000 --> 0:07:27.380000 So this interface here is an inside interface. 0:07:27.380000 --> 0:07:31.340000 That means without any restriction, without any rules, that data can leave 0:07:31.340000 --> 0:07:35.660000 the firewall if it's going out and interface with a lower number. 0:07:35.660000 --> 0:07:39.980000 So if it came in here with 100, and let's say this one here is zero, no 0:07:39.980000 --> 0:07:42.560000 problem. It can go out that way. 0:07:42.560000 --> 0:07:44.860000 But the reverse is not true. 0:07:44.860000 --> 0:07:47.540000 And this is how firewalls really implement their functionality. 0:07:47.540000 --> 0:07:52.220000 Whereas if data is coming in, like in this case, SMTP, and it's coming 0:07:52.220000 --> 0:07:55.880000 in and interface has got a really low number as far as the security level, 0:07:55.880000 --> 0:08:00.840000 by default, that will not be allowed to leave the firewall on an interface 0:08:00.840000 --> 0:08:03.220000 that has a higher number. 0:08:03.220000 --> 0:08:06.180000 It won't be allowed to go out this interface here with 50 or 100, the 0:08:06.180000 --> 0:08:07.720000 DMZ or the inside. 0:08:07.720000 --> 0:08:11.140000 So we would have to configure some sort of access rules on the firewall 0:08:11.140000 --> 0:08:17.120000 to allow this SMTP as it's coming in from the outside interface to actually 0:08:17.120000 --> 0:08:21.180000 pass through the DMZ to get to the ESA. 0:08:21.180000 --> 0:08:24.880000 Similarly, once the ESA has inspected that email and says, this is fine. 0:08:24.880000 --> 0:08:25.980000 There's no malware here. 0:08:25.980000 --> 0:08:27.320000 There's no virus here. 0:08:27.320000 --> 0:08:32.780000 At that point, the ESA now needs to take that email, send it back to the 0:08:32.780000 --> 0:08:37.920000 DMZ interface, and needs to leave an inside interface and get to the exchange 0:08:37.920000 --> 0:08:41.540000 server. This would require some more rules because remember, as far as 0:08:41.540000 --> 0:08:45.540000 the security levels are concerned, most likely the DMZ is going to have 0:08:45.540000 --> 0:08:53.200000 a lower number than the inside interface, and low going to high is blocked 0:08:53.200000 --> 0:08:59.100000 by default. So we would have to allow this SMTP transaction to happen 0:08:59.100000 --> 0:09:03.200000 from the ESA to our exchange server. 0:09:03.200000 --> 0:09:07.820000 So this would be considered our MDA, in this case, our mail delivery agent. 0:09:07.820000 --> 0:09:10.900000 So that will be a single arm deployment, and that is by far the most common 0:09:10.900000 --> 0:09:12.160000 of what you'll see. 0:09:12.160000 --> 0:09:16.040000 One other type of deployment that you could have, which is less common, 0:09:16.040000 --> 0:09:21.580000 is a dual arm or a dual interface, and just like it sounds, this means 0:09:21.580000 --> 0:09:25.960000 that your ESA is connected to your network via two interfaces. 0:09:25.960000 --> 0:09:30.620000 In this scenario, one of those would be connected to the DMZ of the firewall, 0:09:30.620000 --> 0:09:34.000000 just like we saw before, and then we'd have another physical interface 0:09:34.000000 --> 0:09:38.860000 connected to the inside interface of your firewall. 0:09:38.860000 --> 0:09:41.540000 Now, there's pros and cons to this approach. 0:09:41.540000 --> 0:09:44.580000 There's actually more cons than there are pros. 0:09:44.580000 --> 0:09:48.460000 So in this particular case, if we're looking at email is coming in from 0:09:48.460000 --> 0:09:53.040000 the internet, so it's coming this way, once again, on this firewall right 0:09:53.040000 --> 0:09:55.980000 here, we still need some sort of an access rule. 0:09:55.980000 --> 0:10:01.520000 We still need some sort of a rule that says, hey, when SMTP is being received 0:10:01.520000 --> 0:10:07.420000 on the firewall from the outside interface, it's okay to pass through 0:10:07.420000 --> 0:10:09.860000 the firewall and go out the DMZ. 0:10:09.860000 --> 0:10:11.860000 That way we can hit the ESA. 0:10:11.860000 --> 0:10:14.460000 So that rule would still need to be enforced. 0:10:14.460000 --> 0:10:17.220000 But with a dual arm, we don't need the second rule. 0:10:17.220000 --> 0:10:21.060000 The second rule, when we just had a single arm, let's get rid of this 0:10:21.060000 --> 0:10:24.740000 right here, when we just had one arm, that meant once the ESA said, oh, 0:10:24.740000 --> 0:10:28.100000 this email is fine, there's no problem with it, and sent the SMTP message 0:10:28.100000 --> 0:10:33.220000 this way back with the intent to get it over here to the mail delivery 0:10:33.220000 --> 0:10:35.600000 agent. Well, we needed another rule. 0:10:35.600000 --> 0:10:38.540000 We needed a rule in the firewall that said, hey, SMTP coming in on the 0:10:38.540000 --> 0:10:44.520000 DMZ is okay to be forwarded to the exchange server. 0:10:44.520000 --> 0:10:48.980000 We don't need that rule here because the ESA actually has an interface 0:10:48.980000 --> 0:10:51.480000 connected to the inside. 0:10:51.480000 --> 0:10:56.660000 Just like this interface right here is an inside interface. 0:10:56.660000 --> 0:10:59.360000 And by default, inside to inside, that's okay. 0:10:59.360000 --> 0:11:03.160000 That's allowed. But here's the downside. 0:11:03.160000 --> 0:11:06.620000 Here's a real big potential downside. 0:11:06.620000 --> 0:11:10.760000 In a dual arm or dual interface deployment, if somebody was able to hack 0:11:10.760000 --> 0:11:14.100000 into that ESA from the outside rule, if they were actually able to get 0:11:14.100000 --> 0:11:18.420000 access to that ESA, so they're living here in the internet and somehow 0:11:18.420000 --> 0:11:21.860000 they cracked it and they managed to get into it, once they're in this 0:11:21.860000 --> 0:11:26.400000 box, now they have access to this inside interface. 0:11:26.400000 --> 0:11:30.460000 So, it would provide them a way to circumvent the firewall and actually 0:11:30.460000 --> 0:11:35.640000 get into the inside of our network and that's a pretty big security risk. 0:11:35.640000 --> 0:11:39.500000 So for that reason, that's probably why most people prefer not to use 0:11:39.500000 --> 0:11:44.980000 a dual interface deployment but to go with a single arm deployment instead. 0:11:44.980000 --> 0:11:48.100000 So that concludes this video. 0:11:48.100000 --> 0:11:48.780000 Thank you for watching.