Whew. Last chapter. What a ride it's been.
Chapter 15 was the shortest since something like chapter 2. It covered some final points of managing a network that don't fall (completely anyway) under accessibility and integrity. The chapter touched on things like documentation, which, while not strictly an integrity thing, will sure help when the printer at IP address 192.168.4.7 stops talking to the printer server at 172.100.38.9.
The chapter also covered baseline measurements, policies, procedures, and regulations, network management software, system and event logs, traffic shaping, and forth.
The real unifying theme amongst all of this material was that it's the tools you need to accomplish the things in chapters 12, 13, and 14. Sudden spike in inbound traffic? Is that a hacker, or were we just slashdotted?
The chapter also covered the day-to-day tasks of network management like updating obsolete hardware and software, scheduled maintenance, and so forth.
A final note: Thanks, Mike. It's been a good class.
Wednesday, December 16, 2009
Tuesday, December 15, 2009
Chapter 14: Integrity and Availability
Chapter 14 dealt with the finer points of keeping a network working and useful, or, as the title indicates, maintaining integrity and availability.
Integrity is the soundness of a network - how reliable the OS and hardware are.
Availability is how much "uptime" the network has and how, well, available it is for the user to use.
This chapter covered a lot of very practical, day-to-day stuff. Backups, malware protection, and things like error log checking, redundancy, and so forth were covered, as well as power protection via generators and Uninterruptible Power Supplies, Network Attached Storage, Storage Area Networks, firewalls, RAID systems, and all sorts of other wonderful toys and procedures that make paranoid users like myself all warm and fuzzy inside. If it has to do with preparedness, efficiency, or protection, it's covered either by this chapter or chapter 12. I spent a good chunk of the time reading this feeling incredibly vindicated about a lot of stuff about responsible computing that I've told people over the years.
I loved this chapter, I loved the classroom discussion that followed, and I really look forward to this part of my future career. I like making things work better and keeping them working come what may.
Integrity is the soundness of a network - how reliable the OS and hardware are.
Availability is how much "uptime" the network has and how, well, available it is for the user to use.
This chapter covered a lot of very practical, day-to-day stuff. Backups, malware protection, and things like error log checking, redundancy, and so forth were covered, as well as power protection via generators and Uninterruptible Power Supplies, Network Attached Storage, Storage Area Networks, firewalls, RAID systems, and all sorts of other wonderful toys and procedures that make paranoid users like myself all warm and fuzzy inside. If it has to do with preparedness, efficiency, or protection, it's covered either by this chapter or chapter 12. I spent a good chunk of the time reading this feeling incredibly vindicated about a lot of stuff about responsible computing that I've told people over the years.
I loved this chapter, I loved the classroom discussion that followed, and I really look forward to this part of my future career. I like making things work better and keeping them working come what may.
Monday, December 14, 2009
Chapter 13: Troubleshooting network problems
Chapter 13 dealt with what to do when something on a network inevitably goes wrong.
Most systems eventually experience some kind of trouble, and when they do, it's imperative that the trouble be as short-lived as possible. When something does crop up, it's best to identify what the problems and symptoms are (often, this will be obvious) and then move on to a fix. The first step in this direction often takes the form of identifying the affected area, determining what changed to cause the problem in the first place, and then making adjustments of one sort or another (replacing cables, updating or rolling back updates, fixing faulty hardware, reconfiguring something, and so forth) until the problem is solved and then documenting it afterwards.
The chapter also covered various types of troubleshooting tools - various instruments and devices for checking the integrity of a network's cables, the quality of its power flow, and even the traffic emitted by its nodes were discussed. I now want a butt set, a multimeter, and a wireless network testing tool.
An interesting chapter, if for no other reason than I see this kind of stuff as where a lot of the real fun of working with computers comes in. Problem solving is good.
Most systems eventually experience some kind of trouble, and when they do, it's imperative that the trouble be as short-lived as possible. When something does crop up, it's best to identify what the problems and symptoms are (often, this will be obvious) and then move on to a fix. The first step in this direction often takes the form of identifying the affected area, determining what changed to cause the problem in the first place, and then making adjustments of one sort or another (replacing cables, updating or rolling back updates, fixing faulty hardware, reconfiguring something, and so forth) until the problem is solved and then documenting it afterwards.
The chapter also covered various types of troubleshooting tools - various instruments and devices for checking the integrity of a network's cables, the quality of its power flow, and even the traffic emitted by its nodes were discussed. I now want a butt set, a multimeter, and a wireless network testing tool.
An interesting chapter, if for no other reason than I see this kind of stuff as where a lot of the real fun of working with computers comes in. Problem solving is good.
Thursday, December 10, 2009
Chapter 12: Network Security
This chapter covered something of a "pet subject" of mine - network security. The fact of the matter is that the modern computing world is analogous to a bad neighborhood and if one isn't careful, horrible fates can befall any network out there.
The weakest link in many networks is often the group of people using it, either the authorized users or outside intruders. Problems can arise from user negligence, policy problems, or deliberate outside attacks. Things as simple as weak passwords or infrequently changed ones can turn into serious security breaches. For example:
There are also risks associated with the equipment itself. Easily-accessed ports or terminals just invite an attack. Wireless signals can be captured and spoofed. Improperly-configured firewalls and routers can be bypassed.
And then there are software risks. TCP/IP wasn't designed with security in mind, so it has several holes. No NOS is completely bulletproof (even the most secure versions of BSD have had one or two successful attacks over the years) and even one improper setting can provide a malicious hacker an entry point.
To combat all of this, good security policies need to be in place. The goal of these policies is to prevent unauthorized access and damage to hardware or software, intentional or unintentional, from happening. Securing data and providing for what to do when an attack inevitably happens should also be on the list of goals for a security policy. Also important is a clear definition of what "confidential" means in an organization.
The chapter also covered encryption, authentication protocols, and wireless network security.
The weakest link in many networks is often the group of people using it, either the authorized users or outside intruders. Problems can arise from user negligence, policy problems, or deliberate outside attacks. Things as simple as weak passwords or infrequently changed ones can turn into serious security breaches. For example:
Bad Password: "Rover" (The name of the user's dog) - short, a word from a dictionary, and easily discovered through social engineering.
Good Password: 7391-d4V3*ln80 - long, special characters, no recognizable words. In this case, it could be the first 4 digits from the user's library card, a password set on a Wednesday, after the user bought his third Volkswagen and his wife's maiden initials and birth year. If you knew everything about the user and his life, the contents of his wallet, and so forth, you might be able to guess this, but it would be hard.
Excellent password: "xq'@R$JD/W`hn`.*;XvHULwbv+CFP9Y.H<"C$]4lR6(ci/nAhuvU;Yg&Z.rM3S;" - long, random, derived from a random password generator rather than a human mind, uses the full ASCII set, nearly impossible to brute force
There are also risks associated with the equipment itself. Easily-accessed ports or terminals just invite an attack. Wireless signals can be captured and spoofed. Improperly-configured firewalls and routers can be bypassed.
And then there are software risks. TCP/IP wasn't designed with security in mind, so it has several holes. No NOS is completely bulletproof (even the most secure versions of BSD have had one or two successful attacks over the years) and even one improper setting can provide a malicious hacker an entry point.
To combat all of this, good security policies need to be in place. The goal of these policies is to prevent unauthorized access and damage to hardware or software, intentional or unintentional, from happening. Securing data and providing for what to do when an attack inevitably happens should also be on the list of goals for a security policy. Also important is a clear definition of what "confidential" means in an organization.
The chapter also covered encryption, authentication protocols, and wireless network security.
Subscribe to:
Posts (Atom)
