What's involved in server and system administration?
We'll find out more next as we get started.
>> You're watching ITProTV.
[MUSIC]
[BLANK_AUDIO]
>> That's right.
As we continue on through our Palo Alto course, we are now up to this point
where you may not be as familiar with the idea of server administration or
system administration.
But we have Mike Rodrick who actually is, so Mike help us out what if
we actually don't know, even though we hear the term server administrator,
we hear system administrator, but we're not exactly sure what's going on here.
Where are we going to begin?
>> Well, server administration is administering service, right now,
we're gonna go into a little more depth than that, right.
And that's a great question, Ronnie.
What do they mean?
Cuz you do hear that a lot, I'm in server administration or system administration.
What does that actually entail?
Enjoy me on my screen here.
I wanna pull up a quick list of some common tasks that we're gonna be
responsible for as server and system administrators, account provisioning and
deprovisioning, right.
As people joined the organization.
As people leave the organization, we have to create identities for
them accounts that represents them in our network and
we'll create those when people are coming in.
But just as important as deprovisioning those are removing them when people leave.
So we don't have orphaned accounts,
accounts sitting out there that have permissions, but nobody's using them.
Those are unmonitored typically and those can lead to trouble.
Managing account permissions, right?
Making sure that everybody has the permission they need to do their job, but
nothing more, right.
We wanna make sure we follow the principle of least privilege and
Ronnie needs read access to this resource, but not right.
So I'm not gonna give him full control.
I'm gonna do my job, give him what he needs.
So controlling or managing those permissions.
Installing and maintaining server software, right.
We access those applications running on those servers.
Or we take advantage of those services like DNS and DHCP or
line of business applications who installed those, right.
Who configures those?
You do the server administrators, right.
You might be responsible for a particular type of server,
like just DNS servers or all of the servers across your network.
Installing security patches, just like our endpoints,
our servers need to be kept up to date.
So we need to make sure that all of those systems are being updated on a regular
schedule.
System and data backup and recovery.
This again falls on our good old server and system administrators if a server
fails, I sure hope I have a recent backup so that we can restore that with as little
downtime as possible and as little data loss as possible.
So for maintaining those data backups and
recovery processes that falls under our system administrators, right.
Monitoring network communications and server logs, making sure the servers
are able to do what they're supposed to do when they're needed to do it.
Monitoring the logs is not so fun, right.
But it is something that we have to do.
We've talked in other episodes about SIEM systems, how we can start pulling these
logs together from multiple devices that can make it easier.
And a lot of those tools have the ability to filter and search,
which makes life a little bit easier.
But it is important.
We're doing it.
Those logs are there for a reason, right?
It's our system telling us what's going on, potentially what's going wrong,
giving us warnings of things that might go wrong if we don't do something about it.
But if we don't look at them, they're just, they're out there, right.
And we didn't take advantage of that.
So that's not a good thing, right?
And troubleshooting and resolving when something goes wrong,
guess who they're calling, Ronnie?
>> Yeah.
>> The system administrator, right.
The server administrators, we get to go figure out what the heck is wrong.
And they never call you when things are going well,
only when things have gone wrong.
All right, so let's talk a little bit about some of those and break them down
a little bit further, some categories that Palo Alto wants us to be familiar with.
We think about identity and access management or IAM, IAM is the acronym.
You'll see nowadays this is responsible for providing that authentication,
authorization and access control, right?
Making sure you are authorization.
Who are you?
Let me validate you buy requiring a pin or a password or
facial recognition, authorization.
Now that I know who you are, let me determine what you should or
should not have access to.
And then access control enforcing that authorization, making sure that you can
only access these resources or you cannot access these resources.
That's all part of identity and access management.
All gets lumped together.
Directory services plays a big part in IAM.
This is how we, in directory services where we store the identities, right?
The user account that you log in with,
that you access corporate resources with, right.
That is stored in directory services.
There's different flavors most commonly we'll think of as our Microsoft solution
that I know.
I like Ronnie.
>> Yeah Microsoft Active Directory I believe is the favorite that you'd like
to work in.
>> Yeah, that's the one I typically spend most of my time in.
But there are other solutions is probably one of the more common ones.
But directory service database that contains information about the users,
the resources and the services that are available on our network.
Think of it like a phone book for your network, right?
So when you log in,
we can verify your account by going into that directory service.
When you need to access a service that's being provided by a server,
how does your device find that service?
It contacts the phone book, right.
The directory services say, hey, what server, what's the IP address of
the server that's providing DNS I need to talk to him, right?
That's all done through directory services.
Active Directory again is my favorite.
That's Microsoft's implementation of a directory service.
LDAP or Lightweight Directory Access Protocol is a protocol we use to connect
to and talk to these different directory services.
Active Directory, for example, uses LDAP along with Kerberos and
a couple of other protocols to provide these services.
Vulnerability and patch management.
I said this is a big responsibility for our sys admins.
They discover new vulnerabilities all the time.
I'm sure you read the news, you hear about, what's the latest one?
I think solar winds, right?
We we hear about these different vulnerabilities and
they're coming out all the time.
Many that you never even hear about.
But it requires patch management, right?
Because as they discover the vulnerabilities,
these vendors that create the product that the vulnerability was discovered
in are gonna create patches that we can implement to eliminate that vulnerability
to protect against that vulnerability.
But that means we have to do our job and apply those patches.
If the patches out there but we never apply it, our system is vulnerable and
we have no protection against that vulnerability, right?
The downside is its only protection after the vulnerability is discovered,
somebody has to discover the vulnerability and hopefully the good guy discovers it.
For example, let's take Microsoft, right.
Microsoft pays people to look for.
Ad then when they discover the vulnerabilities,
Microsoft can develop a patch for it and
they can push that out through Windows updates and we can protect our systems.
What if the bad guy finds the vulnerability first?
Is he gonna contact Microsoft or her?
Probably not, right.
They're gonna write some type of malware that takes advantage of that
vulnerability.
So that's the downside of this type of protection is we have to wait till
somebody discovers the vulnerability.
Then we have to wait for a patch to be developed and put tested and
implemented before we can get protection that could be days, weeks or even longer,
depending on what the vulnerability is.
If it's deep into an application or a piece of hardware, for example,
the software that's running that hardware, the firmware,
they can take a long time to develop a patch for that.
No protection against zero-day exploits.
We've talked about those in other episodes that when that exploit is first written,
if somebody the bad guy finds the vulnerability, writes the exploit,
right, writes the tool to take advantage of that and starts using it,
we have no protection because nobody's ever seen it before.
There's no patch for it.
I'm just stuck.
It's not good.
[LAUGH] Configuration management is another concept or
area that we as server and system administrators gonna focus on.
This is making sure that all of our systems are compliant and
configured properly, right?
We know systems come with default configurations.
Typically those are not all that secure.
So we need to make sure we are applying configuration to those devices,
turning on that firewall, configuring exceptions for whatever it is.
So this is applications, devices, systems oops, I'mma go back to that.
And it is a formal process that we go through with this, right?
And making sure that we as we always say apply this consistently across devices.
>> And now speaking of that, when we start talking about this administration side of
things, that sounds like a lot.
And at one point and time really when somebody was a server administrator,
they'd have to do all this by themselves.
But in today's environment we've seen that where there's really specializations of
these kind of spreading out and there's more people actually being more
specialized than I am and more people specialized in configuration
management and even the patch management side of things.
And the reason for
that is of course the access into the cloud as well as on premises environment.
So it sounds a little bit overwhelming Mike if we don't kind of
spread out that the roles that we have to.
>> Yeah, absolutely.
It is small organization, you might be responsible for
all of these different areas, but most likely in a larger corporate environment,
it's definitely gonna be broken down and you'll be responsible for
a portion of this so that you can not spread yourself too thin and
make sure you because you can see most of these seem like full time jobs, right?
And they very well can be, especially in large organizations, all right.
When it comes to troubleshooting alright.
Obviously it probably goes without saying, but
a failure could have a negative impact on your organization.
And I like the way Palo Alto says this could have,
I mean there's potentially a failure that really doesn't impact anybody if it's
a service that's not used often.
Maybe it fails and I can get it fixed before it really caused any problems.
Most of the time, these kind of failures are gonna cause a problem.
If I can't reach the DNS server for example, I can't resolve names and
IP addresses and I can't connect heck.
I probably can't even log on, all right?
So when we think of network failures, typically we're thinking negative impact.
What happens Ronnie when the email server goes down?
Is that a problem?
>> Yes, definitely.
When the email server goes down,
that's really the communication lifeblood of your company.
So we have to at least begin to to have steps in place that we got.
What are we actually gonna start doing so we can get things running back up?
>> Yeah, you're definitely gonna hear about that failure.
So we want to have a process and it needs to be what they call a systematic process.
In other words, we don't just go in and wing it, right?
That might work now and again, but you really want to have a formal systematic
process that you go through because it's going to help you solve the problem
quicker and more efficiently, right?
And that's the whole idea,
is I need to get that network fixed as soon as possible if it's causing downtime.
If I've got workers that can't do their job, if I've got services that can't be
provided to the public, I've got [UNKNOWN] Potentially that I have to provide, right.
I have a level of up time that I am guaranteeing to my customers if failures
is going to cause a problem with that.
So I need to get this up and running as soon as possible.
So, having a systematic approach allows me to do this more efficiently.
And I don't want to introduce new issues.
It's another thing about trying to wing it, like, let me just try this and
it might fix the problem you are looking at,
but it might cause more problems on the other side.
And that's not a good thing, right?
Now, you've got other problems that you've got to deal with.
You just move the problem, basically, and we don't want that.
So, having a good systematic approach to troubleshooting is key.
>> Right. >> Now,
there's there's two tasks that occur before any problems ever occur, right?
You don't wait until the problem occurs to develop this methodology, and
it doesn't start when the problem occurs, it actually starts before that.
That's baselining and documentation.
These are gonna be key to making sure that you can do efficient troubleshooting.
So before the problem occurs, baselining means I want to create quantifiable
metrics that we measure periodically of what my systems look like normally.
How do I know if this system is not performing well?
If I don't know what well is right?
>> Right. >> So measuring systems while they're good
and while everything's working, understanding what the response time is,
understanding what the performances of those systems gives
me a point that I can compare to right?
Then when somebody calls me up and says, hey, this system seems really slow.
I can look at what it usually does.
I can look at what it's currently doing and I can say you're right,
it is really slow.
What is the problem or no, it's actually doing exactly as we expect it,
this is normal performance, right?
Without that baseline I can't make those decisions though.
I can't make that measurement.
And then documentation, understanding what you have before things go wrong.
Both logical and physical diagrams of your network, right?
How data flows through that network.
When a web front end has to be able to talk to this mid tier, it has to be
able to talk to that back end database in order for this application to work.
Having an understanding of that when I'm troubleshooting the web app,
why isn't it working?
Well it's not just the web app I need to troubleshoot, there's that middle tier,
there's that back tier that could also be the problem.
It's the communication between those tiers.
So understanding what you have is going to help you and
then change management logs, right?
What's changed?
If I don't document the changes that are occurring over time, I can't go back and
say, maybe this change caused a problem.
What was the last thing we did and did that introduced this problem?
Can I roll back that change to see if that fixes the problem?
So documenting that change is gonna be key.
So, Ronnie these are things that we we tend to forget right, or
sometimes but these are very important when it comes to troubleshooting.
>> They have to be because the idea of trying to troubleshoot something of
whether it's operating normally or not,
it's almost impossible if you don't have that baseline.
If you don't know what the networks actually doing in terms of documentation,
it's even harder because you don't know if you're actually fixing something or
were actually causing a problem.
So starting at this point is actually key.
Now, Mike, once we get started and we realize that there is really a problem,
how do we actually get started in terms of troubleshooting?
>> That's a great question, right?
Do your baselining, do your documentation and then there are several methodology or
steps, right?
That we can go through.
Palo Alto has, theirs many different organizations push out or
publish different methodologies or steps you should follow.
So let's go over the one that we might get tested on for this exam, but
they're all almost the same, honestly.
So the first thing is discover the problem right?
Before I can troubleshoot anything, I have to know something has gone wrong.
Typically I don't have to worry about this because I've got end users, I've got
customers, I've got alarms, right that are telling me something has gone wrong.
So discover what the problem is.
Hey, there's something wrong.
I can't send email.
I can't connect to your website, that kind of thing.
Evaluate the configuration against the baseline, right?
Let's take what we had before when known good compared to what we're seeing now and
see if we can see what is different.
Track the possible solutions, right?
Think about what I might be able to implement to fix this problem.
What are let's brainstorm this.
Figure out what are possible solutions are, execute a plan, right?
Implement one of those solutions and then check the results and
see if that did indeed fix the problem.
Verify, in other words, the solution and verification of the solution
not only involves you, but it also involves the customer.
Whether that's an end user, whether that's a public customer of your website.
I can say the problem is resolved, but if the end user doesn't think the problem is
resolved then the problem isn't resolved right?
And if you're unsuccessful at this step You go back and do it again, right?
You say, okay, well let's see what else we can try to fix the problem and
then deploy the solution.
Once you verify that it is the solution, it is going to be the fix,
then we can deploy that out to the rest of the systems that have been affected.
I'm going to add one, document.
I think this should be in every troubleshooting methodology,
document what you did, what you found, what you did, how you fixed it.
Because if you run into this problem again,
I don't want to have to go through all of this discovery process again.
I wanna be able to say, yeah, the last time this happened,
this is what we did, here it is, boom, boom, boom and we're done, right?
That kind of documentation is key, especially for
those people sitting at the help desk and even the upper tiers of support.
Now Ronnie, when it comes to methodology, there's several different methods we
can use and and we've got that good old OSI model sitting here.
And I think you mentioned this in the episode where we went over the OSI model
is this is a logical representation.
And it really helps in troubleshooting.
It gives me logical areas where I can go and look for trouble, right?
>> Right, yeah, so when it comes down to using the OSI model,
it really helps us to break down where we're having the issues and
only needing to deal with those issues as well.
So when we talk about the idea of actually using a particular model is not just
the steps here, you can actually use many.
But this is one the most effective ones because this is how your network actually
communicates or devices on your network communicate.
That really is helpful.
>> Yeah, this gives us that logical process to go through, right?
That systematic approach to troubleshooting starts right here
with this model.
This is a great way to do things, right?
And you can do it, as Ronnie said, you can do it a couple of different ways.
You can go top down, right, I want to start at the application and
see if that's working properly.
If that's working properly, then we go down to that presentation layer, right?
We think about presentation, maybe this is encryption or
how the application is presenting or preparing that data for the network.
We get down to the session layer, we're thinking, okay, now, maybe, I don't know,
the computer went to sleep.
Right, that could be a simple problem with that session layer.
Transport, we start breaking that information up into packets or
frames to get onto the network.
Our network layer, we're thinking addressing.
Data link, again, we're kind of getting down into the Mac address layers there,
the physical, the wiring, right?
The network adapters, the physical, the wireless, that kind of thing.
But the point is start at the top and work your way down and
figure out where that problem lies.
But maybe you'd rather start from the bottom up.
I know I kind of like the bottom up Ronnie,
especially if I'm dealing with an endpoint because yeah, it's easier to detect.
Okay, your network cable's unplugged.
>> Yeah, the unusual thing about this, right?
It depends on your perspective, but
if I know that I'm having issue from my computer and
the other side's not seeing it, I'm gonna troubleshoot from the top down.
But if I know on my end I think everything's good,
I'm going to start at the bottom and actually verify and
work my way up to see if I actually am having basic connectivity issues, and
that they're just not receiving, and all the way up at the application layer.
So it really is about your perspective on which one actually works better for
you in that context of what needs to be done.
>> And that's a great point, Ronnie,
that you don't have to stick with the same one every time.
This time top down works better, but this time bottom up works better, right?
And there's also what they call divide and conquer.
Let's divide this and see in which half the problem might lie.
Once I figure out what half the problem lies in, we divide that again and
kind of repeat that process.
There's also an educated guess, right?
I mean, sometimes this is a valid methodology.
If it's something where you can say, you know what,
I think I know what the problem is, let's start there.
That might be a more efficient route.
Substitution method, hey, you know what, I think it's the network adapter.
Let's put a known good network adapter in there and
see if that fixes the problem, right?
So just substitute the potential problem with a known good problem.
So all good, valid methodologies, you should be familiar with all of them so
that you can take advantage of the one that fits the current situation.
>> Well, when it comes down to server and system administration,
Mike has actually introduced us to at least the topics that we'll probably
end up covering as well as the troubleshooting aspects as well.
Because all these are actually important as you get more experience in the realm of
cybersecurity.
Well that will do it for us as well.
So signing off for IT Pro TV, I'm your host, Ronnie Wong.
>> I'm Mike Rodrick.
>> Make sure you stay tuned for
more of our Palo Alto Networks Cybersecurity Fundamentals.
>> Thank you for watching IT Pro TV.
[BLANK_AUDIO]