Hello everyone, I'm Kevin Sparenberg.
I'm Destiny Bertucci.
And I'm Patrick Hubbard, and welcome back to another episode of SolarWinds Lab. Today, we're going to be talking about firewalls, and specifically, how to use the new Network Insight detail views for Cisco ASAs.
Yeah, so we're really excited about this new upgrade to NPM. You've been asking SolarWinds to add it for a while now.
That's right. Now, anytime you monitor an ASA, you automatically see a breakdown of its access policies and statuses of the VPN tunnels.
Wait, wait, wait. No extra polling, no MIB-browser, no UnDP pollers? It's just all...
Nope, all built in, and you can also track site-to-site VPNs, remote people VPNs, failovers, and get alerts on all of that.
So, we've also added a little bit extra in NCM to allow for smoother ASA upgrades.
Right, and ASAs both have multi- and single-context modes, and that made pushing upgrades a little tricky. We're going to show you how that works now in the new version of the Network Configuration Manager. It's...
Well, nice to see you once again.
Okay, ha, ha, ha. I'm pretty sure that you guys are sick and tired of me after THWACKcamp, but we did have a ton of great questions this year, and so we've done something a little bit different. Which is, we've gone ahead and made the whole 2017 archive freely available, and that's even for people who are not part of our THWACK family. So definitely swing by thwackcamp.com and check it out. So no, I'm not just here for color commentary. I really do care about firewalls, if only for the cloud.
Well, cool. And you know they've been waiting for Cisco ASA Network Insight for like— and then you carry the one...
No, no, no, no, no, no.
And then you cross--
Shhh. We got it now. Let's just go on.
Okay, well then, let's start with the access list management, and let's pull up an ASA view and start from there.
Okay, so this is the node details view for an ASA. And what it is, is you'll get this for any device that actually matches the ASA's OIDs. So, it's actually based around a technology we already have in Orion, which is the device type details view. So, it detects the device and then displays a view for that.
So, if you've got a bunch of ASAs already when you do the upgrade, this is just going to appear, just like it did with stack switches or anything else?
Exactly, it just kind of gets inherited. So, I want to point out one thing that anyone who has recently upgraded may run into, and that's that you will not actually have this bandwidth area. So, what you're looking at here is bandwidth for your favorite interfaces. Because there's a lot of interfaces that actually go in an ASA, and some of them you just don't care about. Maybe you only care about your DMZ traffic because they happen to be your firewalls. Maybe you only care about your inside to outside because they happen to be firewalls for a specific type of tunnel. So, you get to flag which are your favorite ones, and they're the ones that appear in here. And you can see for this one, we've selected port channel one and two. And just like all of our new charts, all you have to do is zoom in, and you can see detail level on it.
No, not like all of our new charts. This, to me, looks like a PerfStack resource.
Well, PerfStack uses new charts.
Well, I know, but this is actually inside of a resource, right? Where you've got multiple values for those favorites all automatically overlaid, and then if you hover over it with the mouse, you'll get the real-time views, right?
Yeah, plus you get to change your time span, so you're not locked into a certain time span for this view and then have to go out to another page just to shift forward or shift back in time. It's all here. So then, one of the other things that I really like is this other details. Now, I find this important because this is part of a failover cluster. Now, I've had this. I've spoken about it a lot of times when I talk about switch stacks, is that if you have one of them go out, you don't necessarily know which one went bad, so when you try to call Cisco's tech, you give them the serial number. Are you giving them the right serial number? Is it actually the one that went down? Here, you can actually set up an alert saying, "Hey, a failover went down," or "You've lost this node." Just include the serial number in that email alert, and if it's actually down hard, then you've got the serial number, and you can call right away.
So then, all of these values are going to be available as variables that you can actually place into that alert?
Which makes the visualization key, and that's something that we're always trying to focus on, is the alert needs to be able to tell us everything that we need and not search.
So, one of the things you'll want to do for your— Again, after you do the upgrade, that'll be something you might want to do, is go in and then add these fields to your alerts.
And you may want to have specific alerts for your ASAs and all those kinds of things because there are some things that are kind of ASA specific. The site-to-site VPNs, the remote user VPNs, and we've got out-of-the-box alerts that actually contain that stuff, but maybe you need to change it for your situation. Everyone uses these security appliances slightly differently.
Are you suggesting that you could actually use some of those variables to then have a different alert action for your firewalls?
Why couldn't you? The engine can handle it, so.
So, most of the other stuff you see here is kind of what you're used to seeing. We've got the hardware health, we've got the high availability status, we've got the load and the status. Thankfully, it's been up the whole time, no down issues. And this is all well and good. But this gives you that high-level view. What I actually like is on the next page, we have our platform details. Platform details is the one kind of the meat and potatoes, as far as I'm concerned. This is the one that gives you— the important thing is, for me, is what's the deal with my HA? So, what is my HA status? How are things working out? And this node is currently showing as a secondary. And here's another ASA, which I happen to be monitoring. You can see the green, and we actually have the name in there. If you actually weren't already monitoring the second half of this HA pair, it'll show up gray just like we do for a lot of the other ones. Say, click the button to add the node.
So you can alert again if you're in an availability issue? If you're not actually ready for failover?
And then because it's actually figuring out what all three of those different service components are, you can alert specifically on which one is absent?
Yeah, and the other part is, if you actually have this, and let's say the active one goes down, then you'll see the secondary come online, become the active one, and the other one will go into a passive mode, assuming it comes up clean.
And then on that view that we saw before with the tunnel traffic, you would expect to see it flip over.
Yep, you should see a pretty good shift on that.
Now, something that I like about the high availability is that it also tells you your last failover and things that are coming across. I use these in audits for security as well...
So that we can actually show that we have performed an actual failover. So, you should be able to perform your failovers to make sure that everything works correctly before it happens, like, in a critical moment. We use these, and I've helped people set these up as a change request and for their risk mitigations as well to actually show, look, we've done our failover. We've actually practiced our security features. I'm showing you that it was done. Everything went successfully, and then they can move on. But they use that as part of their documentation now, and they really are starting to latch onto that high availability just for the documentation side and reporting.
That was something that we talked about a lot at THWACKcamp this year, was that if you aren't doing failover tests, you aren't ready for failover.
You do not have backup, and you can't say, "Yes, we're highly available." And one of the things that, you know, talking to a lot of you online this year, one of the things that you had said was, you were way less likely to actually do the failover test. Especially for something like, let's say the security appliance that connects your headquarters out to the internet to failover if you're not sure that it's already ready. So, it's a way of mitigating some of that concern.
And to mitigate your concern is for things like this. You visually can see that it's recognizing that it's in secondary mode or primary mode. You know that the functionality behind the platform is correctly designed and set up. So, this should give you the confidence to want to do your failovers because it's already doing the checkboxes of we're green to go.
So, do you recommend— This is a question for you, and this is something that talking to you guys at both really Cisco Live is where we heard the most of it, but there was a couple times we got into— Well, we witnessed debates among visitors to the booth talking about whether they used exact, similar parroted gear for failover. Or they would do different or maybe older hardware, and they do degraded performance failover. So, is that a part? Is there an opportunity here to do regular inventory reporting also, as well, just to make sure that you have the gear that you expect, especially if you're doing HA any large number, like with a bunch of branch offices? Sometimes it's easy to have non-identical hardware.
So, that would be part of the NCM inventory as well, right? So, that's going to be able to pull you out and say, these are my ASAs, and the great thing is, you can use all those variables to actually use in the reporting for the inventory so that you can showcase areas, floors, however, you're trying to do that. The best thing that I like is that it also give you the reporting functionality for the configs and things of that nature too, so that you can actually check those off of your list to say, yes, this is the upgraded, this is "we are ready." Everything's on the same firmware version. This is what we're doing here.
That's the one for me. Not to mention you can also do the NCM vulnerability scans, so you can say, oh, there was— Now, I actually don't recall seeing one for an ASA probably in the last two years, but I'm sure they have existed at times. So it shows up in the CVEs, we'll actually say, "Hey, this is affecting these five devices." And maybe you just need to bump up to 916 or something like that from 843 or whatever.
But you can also index that within this data so that you can actually look at all three layers: your configuration, the IOS image, and the hardware itself.
Which is great, because that's where the vulnerability is, because that is your first line to-- Well, it's kind of like, you know, did I do my due diligence? Right?
Because this is the firewall?
Right, but what I love is that people, a lot of the times now, especially this year with all the security concerns and the breaches and things that have happened, and they're going, "Well, if I would have known..." And they may have even had Network Configuration Manager currently and didn't know that we actually have the vulnerability features within there. And that's telling you immediately, "Hey, this is something to look at." At least verify and look into it, and then you can have that checkbox and the information, the full information of the vulnerability, so that you can copy, paste that into your report and say, "This is why we need to do this firmware upgrade."
And we'll even take that one step further. Let's say you've actually run into something where you're worried about malware, or if one person in your environment got malware, and you put in a firewall rule to say, "Hey, block all traffic outbound to this IP or to this range of IPs." Wouldn't it be nice to know that in the event of a failover that that configuration had synced to the other firewall?
Yeah. So, that's the little things that we used to run into whenever we had a failover. It was, did everything failover clean? Now I can actually see that the configs are synced in here.
Okay, and I'm not trying to rush, but...
No, no, no.
I do want to get to where we can actually look at those access lists.
Yeah, we will, we will. But the one thing you actually also get to pull in here is all of the general hardware health. So, the hardware health we're used to seeing for your routers and your switches is now pulling in all that information for your ASAs. So in the event that you do have a failover, maybe you know the source reason for that. Like, we got a bad temperature sensor that maybe we've got a fan that's about to go up.
It's 32 degrees. It's fine.
Yeah, yeah, that... No. Just no.
And again, these values actually come directly from the native device. We're not overlaying our own interpretation of what the value is of that or fan speed or something else. That's just coming directly from the device.
Correct, yeah. All that information actually gets pulled through the custom MIBs that Cisco is providing that we know now how to interpret top to bottom on pretty much every ASA platform model they have available.
But again, Network Insight for ASA knows what those MIBs are. You didn't set those up as UnDP.
Correct, yeah. I don't know where these particular icons are stored in the database, so I did not write this by hand. So, another one you get from here is obviously your RAM, your CPU. This is something we see pretty much on every node, but the number of connections is nice, especially ones that are maybe not necessarily so much for your outbound firewall but for your inbound.
Definitely. Especially when you're going to look at it, if you see a spike of these that are coming across, then that definitely tells you that something may be going on. And the historical data that this can represent can actually show you, is that out of character? Is that a certain time? Is there certain, you know, things that are going on that could be causing this?
Yeah, and you can keep the data, obviously, as long as you want to, as long as your hardware can keep up for a certain polling interval, so.
Sure, but also if you're facing attack or basically just DDoS, one of the first things that you're going to see is a whole bunch of connection attempts or a lot of failed connections.
Yeah, probably in tandem, one with the other.
So, great alert object.
If this one-- Yeah, you hope it comes with failed, but if one jumps and the other one doesn't or the other one jumps and this one doesn't, that's a nice alert logic you can put in place to actually really work with it.
And visually, it shows you immediately where you need to look. That's what I like about it. When you see the spikes and you're going across here, if it's inbound or if it's out-of-bound failures, things that are coming on there, you instantly, from this page—I know where I need to check onto, and I know what I need to do quickly to resolve this and then figure out what's going on. You've got to prevent it from happening anymore and then assess the situation.
Yeah, yeah, circle the wagons first.
So, we mentioned in the first one that we've got that bandwidth resource. This is where that comes into play. So, you actually have to go in and basically check. In this case, it's a little favorite icon. We've been adding this all over the platform recently.
Okay, so that's what drives the favorites in the previous chart that we saw?
Correct, this is for the interfaces. And you'll notice that we actually get the names in here. Not the physical name, the logical name of the interfaces, because this is the way that all your ACLs are actually built. No one actually goes through and says, "Ethernet 00 in out," all that kind of stuff. I mean, maybe they did years ago. I know I did for PIX, but ASAs, it's a lot of--it's GUI-driven now.
ADSM is actually a really powerful tool, and it saves you from making some silly mistakes. So, we'll actually pull in that information. You've got all of the interfaces, the actual names, the IP addresses assigned to them, security levels, errors, ins and outs. So, what you're used to seeing, any of these will go to an interface detail chart, which is just like the ones we have for the rest of the suite. But like I said, these two are checked, so they actually bubble up.
Not what you're used to seeing. It's extended of what you're used to seeing.
And it's not like there's a drop-down here where you have to go to the interface first and then say this is a favorite. You're just checking them on and off.
Correct, yeah. If you want to see the details on one of these specifically, though, that'll go to the native chart that everyone's used to seeing, that you've had in the product for years and years and years now. But yeah, being able to actually take this information and bubble it up to an area where it's actionable. That's the important part because maybe this particular ASA is only used for routing into your DMZ. So, maybe you only care about the DMZ interface. So that's the only one you check. So, when you go to that node details page for this particular device, that's all you see.
And something that we need to focus in on is that SolarWinds is really trying to help you guys create your own situations that you need. And so by being able to put the control to you, these are my favorites, this is what I'm concerned about, that helps your business use case. And that's something that I like to focus in on is that, you know, we hear you guys talking, and not everybody is alike on their monitoring situation. But you need to quickly be able to set it up to what you're wanting to do. So these favorites that you're going to see throughout that are coming through, that's because we're listening to you to help you guys zone in on what's important to you.
Well, and if you've been going to SWUGs, and you guys go even more than I do.
Just a few.
Yeah, so you know, one of the things that we talk about— and actually, we talk about it on this show a lot too, is, if you're getting a million alerts, it is not useful. If you're getting so many alerts that they just go in a folder, you might as well not get any. You might as well not be getting any. So, we talk about getting useful alerts. And I think a big part of this, too, in being able to star favorites that then maybe coalesce the number of elements that would otherwise be in a multi-chart, a multi-value chart, is that you're just telling us, "Hey, we know what we want to see." We want you to continue to collect all the rest of the data in the background, but just make it easy to show us less, to just show the things that are important.
And that's the key. You're still monitoring the ones in the background.
All right, so if we just continue down...
I like that.
I like that pipe icon.
Yeah. [Chuckles] It works.
And it also flows up, which is kind of interesting.
Yeah, well, I mean, it's a VPN, that's what it does.
So this takes you to site-to-site VPN, so these are your routers that talk to your ASAs, or your ASAs and your remote location talk to your other ASAs. More than likely, it's some piece of hardware talking to another piece of hardware.
Or the big puffy thing that holds all the data?
Yeah, yes, my cloud. Actually, they tunnel through that, so it actually doesn't keep your data in the cloud. This goes through the cloud, hence the piping.
Yeah, it's like a cake. Different piping. [Chuckles] So, similar to what we did before, is we've got the stars where we can flag these as favorites. That means these also show up on the summary reports.
And the details levels.
You would want to have your physical interface data along with your tunnels in the same chart?
Or at least in the same place. I know, it's crazy talk.
It's crazy talk.
Yeah, so what I like is we actually have how long they've been up, how long they've been established because some VPN tunnels do go up and down. Some change. Some should be lockstep permanent all the time, so these numbers will grow very, very big, very, very quickly. We'll also let you know what type of encryption they're using, how they're doing on hash checks and all the traffic in and out.
I also like the fact, though, that you're surfacing if they're down if there was a failure where that actually happened.
Because I mean, the handshake process, especially depending on how that VPN is configured, can sometimes have a bunch of steps, and being able to immediately say, "Oh, this is on the remote side," or, "This is actually local to this device," makes it pretty quick.
It cuts your troubleshooting time, and that's what we're all trying to do here.
It's binary troubleshooting. Is it that side or this side? It's that side. I've cut it all in half. Now I can follow that logic and go that way. So this, just like a lot of our other resources, will actually allow you to go through. The favorites obviously get bubbled to the top. You can do whatever filtering you want if you're looking for specific ones, searching. These are by IP address because that's how they're identified.
And these are probably— And I know I'm not saying anything to you guys that you don't already know. This is probably the number one thing that you asked for, for ASAs, because it was the number one use for UnDP polling for that, right? Because was to check on the status of tunnels, whether they were passing traffic or collapsed or not. So, that is the main. If there's one thing here that I think you will find useful, it's this, so learning how to use this screen is really important.
Yeah, and I've actually used that feature years and years ago, and it worked great, but it was hard to figure out which tunnel was which and getting the list in.
The index not helpful?
Yeah, not super helpful. But we've taken all that guesswork out. We're bringing all of that here in as plain language as we can give you to explain what's happening. So, full searching is available. So of course, we've talked to site-to-site VPNs, so the other side of that is the remote user VPN. So, if you use the Cisco AnyConnect software or the Mobile AnyConnect software or any of those...
I may or may not use that a lot.
May or may not? [Destiny giggles]
She does. So, I like this one, because we had a lot of remote people. We actually had, I mean, an ungodly amount sometimes. It was just a lot of remote users.
Okay, I call this the, "My VPN's not working on the phone answer" screen.
I would love to give this to the help desk that I came from.
Because, exactly. And so you can actually sort it by date, status, but you can also do it by username. Which is nice, because what's your username? That's the first thing you're going to ask for, and normally you'd have to scroll through all those. So, being able to say, "Yeah, you're connected." "Oh no, I'm not connected." "No, I can see that you are, and I can actually see how much traffic you're passing." "Oh, it just updated again."
So you can use this on different levels, too. I've had people say that they actually use this to make sure their remote employees are actually online.
Make sure they're doing their job?
That is correct.
You could do a query.
That's evil in a good way.
You could query in a report.
Yes, and see actual time of which they are online.
Not that I would ever be that meticulous in trying to find everything or everybody, but I am.
When did you turn into the HR person? [All laugh] So yeah, there's a lot of detail in here, and we get a lot of this stuff actually with a kind of a side plug into UDT, so we'll actually pull some of the information in from there but most of this is coming from NPM and NCM together.
Well, and even things like being able to sort by access client type. I mean, the first thing when you are debugging or the help desk is trying to deal with troubleshooting for a remote client. I mean, nine out of ten times, they have an out-of-date client or the config's not right, or you need to send them a new package. So right away, you're going to be able to do that. Or again, it's a chance to run reports and regularly send emails to people who maybe need to update their client.
Exactly, and something also that a lot of people are using on the government side was when they were introducing this to me, was the contract work especially. They want to make sure that they're getting billable hours for which that they were on the network and were doing things, so this is another way that you're able to actually track that and report against to make sure that the contracting is what they're supposed to be using and for the amount of time in which they are.
Yeah, because in an environment like that, you really can't do the work unless you're VPN'd in.
There's no kind of remote work. Oh, I did this kind of thing, and then I'm going to go and connect and do it. No, it's got to be whole time on the network.
Would it be actually helpful? Because you can certainly have as a part of a report, almost like a blacklist report where if you took someone out of your environment, one of the things you might want to do is, are we continuing to get connections for that user ID?
That would be a pretty handy report.
Or even just connection attempts where they're trying to pass those credentials.
Yeah, because they're going to be failed, too.
Oh, that's right, because, aha.
Yep, and there's probably a couple ways that we could get that information.
Three at least come to mind right now. [Destiny chuckles]
Or actually, yeah, just go by the failures because then you don't need to maintain that list. You're just looking for people who regularly fail.
Because really, it's one or two phone calls. "Hey, can we help you?" Proactively. "Oh my gosh, the help desk called me to help me with my VPN." Or, "No, I didn't" Yeah, okay.
Or if it's especially nasty, find the IP that they're all coming from, go onto your firewall, and block it. Throw all the traffic away.
I mean, there's always a way.
Yep. So, that's kind of the VPN side in a nutshell. We got the site-to-site, we've got the remote access VPN, and that pretty much covers nearly every situation you're going to deal with, with the ASAs.
One thing we didn't yet cover is the multi-context, and I'll be completely honest. I haven't worked in the multi-context. It's not something I was ever comfortable with. My 5510 at my house was single layer only.
But we do expose all that information. So, that'll actually show up on the summary page, and what you'll get is, if you're in an environment now— This is one, like I said, I am comfortable with, and I'm comfortable in single context mode. You'll actually get listed here, the contexts.
And they'll have their own naming scheme, and they'll have their own availabilities so that you can differentiate which ones they are. The great thing that this is actually doing with the NCM side is that we are looking at each one as they're separate. So, what that means is, not only are we downloading your multi-context, If you remember, in the config, they're kind of like just overlaid within there. We pull them out and have them set up. That's great because you're able to change a multi-context and be able to do something within those, just that one. It's not seen as a complete config.
Yep, we still let you play with the complete config if you want. The other thing that's nice is most multi-contexts from my understanding, is they'll actually show up as additional IP addresses on the firewall. They'll actually show up in this list here. So, you'll actually have this context area where if you actually have multiple contexts, it'll say, "This is the Admin-Context," pretty much the out-of-the-box one when you turn on multi-context. But another one on that will be DMZ, or one will be web servers, and they'll show up, and they'll show up as unknown because we're currently not monitoring them. Just click on it, add node, next, next, finish.
In there, start polling configs on it. Now, we mentioned in the site-to-site and the remote user VPNs that you actually flag favorites. So. Oh, that looks interesting. There's your favorite site-to-site VPNs, so you know which ones are down, when they're down, so you don't have to go and dig and dig and dig. I think the real push recently on the platform has to give you the most information as quickly as possible so you can go and do your job.
Well, and this one's configured a little bit differently in this view. And this one, you didn't show a minute ago, because we're back in the home view, and I actually really also liked the VPN health overview because if you were maybe first-level help desk, being able to do, again— and for those of you who are creating custom views for a particular user groups, this is one that you might want to expose rather than all the details. Like, let them drill down into it, but the first one is if they're looking at that device and saying, "Well, how many of mine are actually down on this device?"
In theory, this could be a couple of different things. This could be a down hard circuit on a far side. Maybe it's a last mile thing. You have no chance.
You've called the provider; they're sending someone out to put new fiber in place. It happens. Maybe this is something malicious where someone actually, oh, I don't know, removed the firewall to try to break down...
Which is not out of character.
No, pull the card out to actually try to pull the encryption keys off. There's all kinds of things that can happen, so better safe than sorry. This is kind of the, "It's better to know than not," situation.
So, we've talked about how the bandwidth comes in from your favorite interfaces. We've talked about how your site-to-sites come in from your favorite VPN tunnels. We didn't talk about favorite users because everyone who's ever worked on help desk has your favorite users. We don't flag those. If you really need that, set yourself up an alert or set yourself up a watch list.
And if, of course, you maybe didn't want to use the UI to star favorites, is there some other mechanism that would be enabled that would allow you to do this programmatically?
Yes, there's several different ways you could do that. The one that immediately comes to mind is using SWIS or the Orion SDK, which we will not be talking about anymore this episode.
But this is all available for automation for some of our customers who use a lot of automation. Again, you can use SWIS to make these changes.
It's all in the API. And actually, there's new changes now on the SDK. Sorry, a small side part. There's changes now that we've added a search feature to the top of the SDK, so you can actually just put in what you're looking for, hit enter, and it tells you which fields it's in.
See how he said that he wasn't going to talk about it, but I got him to talk about SWIS.
No, no, no, no, no, no, no.
It was almost ninja-skill like.
No, no, I said I was going to let him talk about it.
See, see, you've got to listen. There's an in-out kind of crisscross there.
Oh, I don't like the firewalls.
Is it FIFO or LIFO?
I don't know. So, we've covered almost everything there is except the ACLs. Which, let's be serious...
Well, and firmware. We need to at least...
Oh, we do need to talk about the upgrades.
We need to show that.
Yeah, I'm going to start with ACL's, I think, and you can talk a lot more detail on that. All I know is they are huge, and they're really hard to read, and depending on how many— No, it's serious. Depending on how many years they've kind of been building slowly in there, you may have a lot that overlap. You may have some that never get hit. They've got zeros on them. And understanding what that all's about is kind of tricky and requires a certain mindset, but looking at it in a humongous config file is...
You're saying you should never try to eliminate large numbers of rules that have zero hits?
I don't see any reason for having zero hits.
It could go away.
Yeah, get rid of them.
Yes, and I was laughing because like I was telling you before, it's like you're having a conversation and you're not guarding the door and everybody's going behind you. But yet you knew to block those people, right? So it's like when you don't have the hits and you're getting these shadow rules like that, that's as simple as it really is. It's you're distracted, nothing's getting done, and people are just walking in behind you, and it's things that you could have been preventing if you weren't distracted.
You're going to have to explain shadow rules to me using simple terms. Do we have any Legos?
Okay, all right. So, the A-C-Ls, which is how I say it. Other people say "ackoles," however you want to put it.
Put that in the live chat. I'm really curious. I tend to say...
I'm super curious about a poll.
I tend to say ‘ackoles.’ If you say— Let us know. Just chat and let us know in the chat down below. Ackoles or A-C-Ls? You say A-C-Ls.
I say A-C-Ls.
Yeah, that's I've always done.
Which means that's probably the right way to say it.
All right, want to do-si-do here? Because you can talk about these a lot better than I can.
We can. We can do-si-do here. Okay, so something that I like that is very important here is that they actually do them by the name of which that you're having them set up that you have on here. We can quickly see over here if we go. It's an overlapping rule. So, when we want to drill into here to see why is it overlapping? Is this redundant? Is there things that are coming across here? Because you don't need to do that. Because as you can see, we have eight pages that have the ACLs that are on here. The great thing to this is that when you're looking at all of these that come across and you have overlapping rules, you have so many that you're going through. You don't want to be stuck on having your device to actually have all the CPU in the memory to deal with these.
You have better things to do. It has better things to do. So streamlining your ACLs is something that you need to really take to heart because we're going to be in here all the time. We have new applications, new users, new things that are coming in that we need to create, take away, and do. So, simplified, we can come in here and see the ASAs and immediately see if we have overlapping rules, see if there's anything that's out of character, and actually drill into what they look like.
So, what it's doing here is it's actually pulling the text that describes all of those ACLs, and then it's converting them into objects and then presenting them in the interface. So, this isn't just like Scrape Text or RegEx or something else. This is actually deconstructing them so that it can then do the analysis.
Exactly, and you're not having to do anything. We've downloaded the configs from the network configuration manager and the Network Insight is actually pulling these together, also together with your NPM and your NCM so that you know, are they working? Is there fails? Is there things? It's a whole team.
You guys have heard me make this joke before, I think. Probably. That no one ever gets to set up their own firewall. You can only inherit it from somebody else.
But I mean, this is that thing that— why, in some past gigs, the one thing that keeps me awake more than anything else is the first time you go in and look at the ACLs that are part of that firewall, and you say, "There's 800 of them," for example, right?
You have no idea which ones are vulnerability. The best thing that you can do is do an 8020 in the first week that you have it, try to chop out the big ones using alerts here, and then watch it over time. And so deconstructing that into something that's easy for you to go, and it's not actually painful to slowly improve it and cull them out over time is the way that you get to where, okay, now I can sleep, because I think I know what 95% of my goals are.
This makes them bite-sized, is the way I'm looking at it.
Because I've dumped an ASA config before, and they can be 12, 15 thousand lines for really complex ones that don't group things that actually have very specific rules. Parsing that out requires a mindset that I just don't have.
Let's take a look at one.
All right, let's go ahead and go into this one that has a child element to it. All right, so this is partly redundant. We can see that there's an issue that it sees on here. I'm going to drill in so that we can actually see the ACLs. So now, we can actually see across here that it has two of them here, and the order is important.
Right, so that's something to think about, too. And so we can actually see the line number and by the hit counts themselves. So this helps you quickly to see if there's anything that has no hit counts and it's been on here for a while, so we know that hey, it probably should have been used or why is it there, right? And so there's things that we can look at from that point. We're going to look over here across, and we can see this is an overlapping rule, and it says that it's partially redundant. So let's go ahead and go in here. And we'll look. So, it says that the rule number two is partially redundant because we have the any on here. So it's deny, and it's anything that's across here. But we already had a deny any, any.
So it would have been denied anyway.
Exactly, so we're kind of redundant here, as the name, right? But this is why simplicity actually helps us. Because if this was going through here, and say this ACL had numerous different things that were coming across here, you need to know which one's not being used and which ones are being used, right? So that you can actually see what's happening. So we can delete these accordingly. And obviously, we don't want to deny everything that's coming across here, so maybe we should look into here, but we need to see at least why these were overlapping.
Yeah, but imagine trying to find this in 12,000 lines.
And what happens if you actually were part, and you've actually done versioning? Because that's what that child element was. That's a version. You can actually compare the one from yesterday to the one from today if there was a change.
Right, and I'm glad that you said the compare because if we look here, you can actually go to compare your ACLs themselves. And so if there was another version that was across here, you'd be able to compare the ACL to see what had changed and what's vital to that is we make changes. We have new applications. We have new user information. We have new ports that we may need to have blocked or not blocked that come across, and we would be able to compare. We made a change yesterday, we can see the change here, and be able to see, hey, was this a valid change that we needed to do or not?
And so the way that that's working, and correct me if I'm wrong, is that that is basically using the diff functionality that's been a part of NCM for a while, only it's then narrowed down to this particular rule. So, instead of having to look at the whole 12,000 lines, it knows which lines you're talking about for that rule, and so you're going to get the diff over time.
That is exactly right. And so, what I also like is when we come across here to filter out the rules as well, you can filter them on the main screen, as you see here. But for me, I guess probably because I've used SolarWinds for so long, I like visual context, and I like kind of seeing how things are grouped logically in a database.
So, if you look to the left-hand side, you automatically see that this is denied. We can see the two deny sources that are coming across as well as the destination of which way that they're going. So, immediately I can see, okay, I'm wanting to look because somebody calls and says, "I can't access this." "I can't do this; I can't do that; duh, duh, duh, duh, duh." I can go through here and click on the denies to narrow down my ACLs on this device and say, okay, and then I can see from the host, see something that's there. But that's because I've got SolarWinds mindset, right? But that's something that we're all getting driven towards even in Cisco ASAs with the GUI and things for you to configure and do. So, we're mimicking and going across with you guys with the new technology. And so with my mindset, I used to be in this screen, and this is something that I would have to look at and go through. But now my mind is actually helping me more on the left-hand side, which I thought was kind of interesting because when this first came out, I was like, this is so awesome. But I noticed I was over on the left-hand side a lot.
Yeah, I mean, imagine a couple hundred lines for a single ACL, because it does happen for very specific ones.
Or show me all my denies.
Because if you're trying to find one rule, that can narrow it down a bunch.
And if you're looking at the full lines here in context, and then it's like I'm going through here and I'm still kind of reading it through a config. On the left-hand side, it's that extra filtering that this tells me exactly what's already here, so then I can filter instead of figuring out what's here.
Or like in this case, the source, for example.
So many times, you're going to start with— you know what the IP address is because that's where an issue is, so give me all of the ACLs that apply to that.
A matching source, yeah. Or matching destinations, depending on the...
Depending on the site, yeah.
Definitely. All right, so let's go ahead and switch places so that we can go over the firmware.
Okay, yeah, will do.
Another do-si-do. All right. [Patrick chuckles] What?
She's square dancing.
I am from Oklahoma.
Yeah, and I took it in elementary music class, actually. Yes.
Very. All right, so a couple things you need for the firmware. I know we've probably talked about it before, so we can kind of give the high level, but get the BIN files, put them in the repository, make sure Orion finds it, scans it, has it in there. Then...
Can we just have a quick amen for .BIN files?
Okay. So, what you can do is, you can build yourself a new firmware upgrade, and we actually have, what do you know? Out-of-the-box, multi-context, single context, single context, the 5512s and the 5510s. You can manage your own on these. It's really simple. Basically, it's just a series of script lines that you put together, scripting, and you go through and you say, "Do this first, this second, this third," if you match on these things specifically MD5 hash. Super important for these.
And, of course, I'm going to call out the Customer Success Center, which is a great place to go and actually get the step-by-step guides on how to do that.
And also, you can actually share these upgrade templates on THWACK, so check there first. See if someone's already written one for your specific device.
I feel a little bit like I'm looking at Patch Manager, but— do you know what I mean? Because...
Building custom third-party patches looks a lot like this.
Very similar. So, realistically, all you do is select the device— or, excuse me, the firmware upgrade. Now I don't know multi-context, so this is brilliant for me. So then, I select the image. We're going to go to the 916 because that's the latest one we have here.
So this is building on binary transfer that appeared in the last release, which was to support F5?
Yes. So I select it, select which nodes it applies to. What do you know? My Cisco ASAs. I can send them to all of them or individuals. Realistically in my environment, I would probably send this to one small one or a very small branch office that I can, I don't know, physically get to in case of a catastrophe. And then after I validate that, then send it out everywhere. That's just good practice.
You should always do the test beforehand. And it's kind of like with Patch Manager, as well, is that you want to test out in lab or, you know, small, and then go production.
Yeah, our poor Boston office. Always, always, always. So then, I'll go through and collect data, but just like the cooking channel, I've already done one here for us.
So, you can actually review this. [Chuckles]
So what this has done is, it's actually run through a series of scripts. We won't belabor this because we've talked about it before.
But you're going to get the log.
You'll get the log. You can generate the script for the actual upgrade process. For this one, I actually am really close on disc space. I actually went manually after the fact and cleaned it up so it didn't report in here, but it is good enough.
Which is bad, because that is a security concern. Because a lot of times, sometimes you can be in mid, and it takes up too much, and it'll delete the old, and you get in this weird situation where you're like...
Especially if they're an HA pair.
Super scary at those times. So, check the boxes, generate the script, watch it go through and build the scripts. So, first thing it does is make a backup, copy the files over etc, etc. We all know where this goes. And then I've confirmed it's ready to roll for this device. I want to confirm it for the next one. Lather, rinse, repeat. Next, next, finish. Get notifications when it's done. That's it.
And would you potentially, briefly go do a yellow state for, let's say, HA while it syncs between the two or are you going to be fine?
It depends on what you're doing with it. If you're in an HA state— I mean, honestly, any upgrade, I would do on a Solar one first. That's my...
Because you can do one or the other first, right?
Yes, if you're an active-active or active-passive, you can actually pick one, and most people will upgrade the passive one first so it has the least amount of downtime. And then manually failover and then do the active member.
It's kind of like F5, right?
Like you usually do the ones that are not in use at the time, and then you go over so you're not also flipping people back and forth.
Or switch from active-active to active-passive, update the passive, check, failover, and update the original one, then return it back to active-active.
Windows cluster patching. Anything we need, basically, clustering, this is the kind of way you want to do it. So, this is it. Send yourself an email notification when the job's all done and everything's happy, happy. And then make sure you rerun your reports so that you get the new firmware image listed in your inventory reports. And also the NCM connection, to do a proper scan to see if there's any vulnerabilities for it.
Exactly. [Electronic signals]
Yeah, so that was a really, really dense episode, but we had a lot to catch up on after THWACKcamp this year, so we hope you found it very helpful.
Yeah, like being able to graphically analyze access-list policy rules, do alerting on VPN failovers...
And pushing ASA firmware for multi- and single-context mode.
Yeah, oh, HA para monitoring built in. So make sure that you've upgraded to the new version of NPM and check it out. That's Version 12.2, and then the other one is NCM...
7.7 Yeah, so go ahead and upgrade and then let us know how Network Insight for ASA is working for you.
And where would they do that? At our home page, of course, lab.solarwinds.com. Chat with us, view all the past episodes, and better yet, sign up for reminders of upcoming topics that we're going to cover.
Like advanced scripting in SAM?
Yeah, how to script virtually anything on any system. No, we're not going to talk about SWIS or the SDK in this episode. Don't make that face. And Dash is a wonderful tool, and we will talk about it.
Okay, yeah, so we are going to talk about that. But also PowerShell and Python. Those are fantastic tools, too.
And that's another show, so let's wrap this up. It was great to see you again. Keep an eye on the schedule for the next episode. As for me, Patrick, and Kevin, thanks again for watching SolarWinds Lab. [whimsical digital music]