UPI Study › Courses › Ethics in Technology › Free lessons › Lesson 10.6 Free with a free account
Common Weaknesses in Network Systems
Ethics in Technology · Chapter 10: Defending the Network: Firewalls, VPNs, and Security PoliciesSection 10.6 · lesson 57 of 11616 min · free with a free account
Free preview
Create a free account to keep watching
It takes a minute and costs nothing. Your free account unlocks all of Chapter 1 and 3 more lessons of Ethics in Technology.
Lesson complete
Earn the 3 college credits for Ethics in Technology
Enrolling adds a quiz after each lesson, the graded work and the official transcript. Recommended for credit by NCCRS.
Next lesson: Secure Encrypted Tunnels for Remote Access →← How Firewalls Filter Traffic and Enforce Network BoundariesNext lesson: Secure Encrypted Tunnels for Remote Access →
In this lesson
Exposure, deceptive paths, availability, and device upkeep.
- Reduce unnecessary services and enforce protected protocol use.
- Distinguish wireless impostors, local address deception, and DNS misdirection.
- Match denial-of-service pressure to prepared defenses.
- Assign ownership for inventory, patching, replacement, and verified outcomes.
Free study notes
Get this lesson's notes by email
The key points and 4 practice questions with answers, in your inbox. One email, free.
One email. Unsubscribe in one click.
Transcript
Everything said in the video, section by section (1,830 words). Read along, or search it.
Chapter 10
Common Weaknesses in Network Systems
Network weaknesses combine technical design, exposure, and organizational decisions. Every unnecessary service creates potential attack surface and a maintenance obligation. Unprotected protocols can expose credentials or content, while protected replacements require correct enforcement. A familiar wireless name does not by itself authenticate the network owner. False local address mappings can put an intermediary into a relevant traffic path. Wrong DNS answers can misdirect a careful user who enters the correct name. Signed DNS data, encrypted resolver transport, and service certificates protect different boundaries. Denial of service targets availability through bandwidth, protocol, or application pressure. Network devices need inventory, ownership, patching, recovery, and planned replacement. The web server, airport network, bank, charity, and remote gateway cases connect these decisions with consequences. We match each weakness to defensive measures, retaining practical limits instead of assuming a single control solves everything.
Listening Services
A Useful Listener Still Needs a Purpose, an Owner, and Restricted Reachability
A listening service waits for traffic addressed to a suitable endpoint or port. Its actual reachability depends on network binding, paths, permissions, and filtering. The source's public web service has a reason to accept internet traffic. Remote administration is needed by two engineers, through a restricted management arrangement. The database listener should serve only the required application-server path. File sharing left by an old project needs a present purpose and dependency review. An unexplained printer service deserves investigation and safe removal if unnecessary. The monitoring agent needs only its justified internal path. Defaults, installers, and a project from two years earlier can leave forgotten components. Forgotten services may miss maintenance, but actual discovery and patching gaps vary. For the review server's fourteen listeners, a firewall alone does not establish harmlessness. Inventory purpose and ownership, disable unnecessary functions safely, restrict the remainder, and verify exposure through authorized scans from relevant locations.
Legacy Protocols
Choose Protection and Enforce It, Rather Than Leaving a Cleartext Fallback
Legacy protocol protection must be evaluated by actual configuration, rather than name recognition. Ordinary Telnet can expose administration credentials and commands; use suitable SSH with intended-host verification. Plain FTP lacks transport confidentiality for credentials and transferred content. SFTP uses SSH, while FTPS uses TLS; they are different protected transfer mechanisms. Plain HTTP exposes relevant content to observation or alteration along the path. Use correctly verified HTTPS and appropriate strict-transport policy, instead of relying on a redirect alone. Early community-string SNMP does not encrypt its secret. Supported SNMP version three needs authentication and privacy enabled; the version number alone is insufficient. Retire obsolete file sharing and use maintained versions with appropriate signing and encryption. Directory access needs enforced, authenticated transport protection where relevant data or credentials would otherwise cross unprotected paths. Disable unintended cleartext fallback and verify what actually negotiates. Inventory listeners, restrict necessary sources, maintain software, and rescan so protection reflects reality rather than only intention.
Wireless Impostors
A Familiar Network Name Is a Label, Not Proof of Its Owner
Rogue and impostor access points describe different problems. A rogue point is unauthorized equipment attached to the organization's network. It may result from convenience or malicious intent, and can create an unplanned entry path. An impostor advertises a familiar or convincing name to attract connections. Network names alone do not prove ownership, and ordinary browsing may continue without an obvious symptom. Saved-network policies, security mode, certificate validation, and device selection logic affect whether connection succeeds. A stronger signal alone is not a universal guarantee. For the airport example, disable unnecessary automatic public-network reconnection and verify intended services. Respect certificate warnings, and use suitable protected connections or a trusted VPN for its configured route. A trusted mobile connection reduces that local impostor exposure without eliminating every security risk. Organizations should validate enterprise authentication, control attachment, and observe unexpected wireless equipment alongside internal and resource safeguards.
Local Address Resolution
A False Local Mapping Can Put an Intermediary in the Traffic Path
Local address resolution answers a different question from internet name resolution. On common version four IP local links, ARP maps a network address to a link-layer address. Its original design does not authenticate whether an address claim is truthful. An accepted false mapping can redirect a relevant exchange through an intermediary. The actual outcome depends on endpoint behavior, local access, and configured network protections. The two parties may expect a direct exchange while traffic is forwarded between them. Unprotected content can then be available for reading or alteration. Correctly protected communication with intended-peer verification retains its expected payload confidentiality and integrity. Timing, volume, some address information, and interruption can remain exposed. Compromised keys, endpoints, or trust configuration can undermine that expectation. Wireless impostors, compromised routers, and name misdirection can create related positions through different starting points. The defensive lesson is to protect the relevant endpoints and path, without assuming every network accepts identical mapping abuse.
Address-Path Defenses
Protect Endpoints and Reduce Local Opportunities
Encryption with verified peer identity can protect content without identifying every intermediary first. It does not guarantee availability or conceal every aspect of traffic. Segmentation limits unnecessary local exposure and permitted movement between relevant areas. A printer should not automatically have the path needed to reach finance workstations. Actual routing and enforcement must support that separation. Managed switches may offer validation of local address claims. Dynamic ARP inspection is one supported approach, using dependable mapping information and configured trust boundaries. Incorrect bindings or trusted-port choices can weaken protection or disrupt legitimate work. Duplicate claims and sudden mapping changes can supply useful investigation signals. Legitimate changes also occur, so interpret evidence in context. Missing telemetry can hide abuse, while preventive controls can still stop an unwanted path without an alert. Combine protected identity, restricted reachability, suitable switch safeguards, and accountable monitoring rather than expecting one measure to solve every consequence.
DNS Misdirection
Correctly Typing the Name Does Not Guarantee a Correct Resolution Answer
DNS translates a name into the information needed to reach the intended service. A wrong answer can therefore misdirect a correctly typed bank name or saved bookmark. One route is forged information accepted and stored by a resolver. Another is a compromised resolver supplying untrustworthy information directly. A device can also be configured to consult an attacker-chosen resolution service. Altered authoritative records or compromised registrar administration can change information at its source. Caching stores answers for reuse, increasing both speed and the reach of an affected answer. A busy resolver may repeat incorrect data to many people querying that record. It does not redirect every name or necessarily affect every user globally. TTL, cache policy, refresh, validation, and alternate resolver paths affect duration and scope. Careful link selection alone cannot repair an untrustworthy directory answer. Defenders must protect resolution, service identity, and authoritative administration instead of assuming a misdirected user necessarily made a mistake.
DNS Protection
Signed Data, Encrypted Transport, and Service Certificates Solve Different Problems
DNS security measures protect distinct boundaries and should be combined deliberately. DNSSEC authenticates signed data through a validating chain of trust. It does not encrypt queries or guarantee that compromised authoritative administration supplies honest data. Authenticated encrypted DNS transport protects the configured path to the chosen resolver. That resolver remains a trust dependency, and transport protection does not itself prove authoritative signature validation. Correct HTTPS identity verification limits an impostor unable to establish the intended name's accepted identity. Certificate issuance, domain control, keys, and trust configuration still need protection. Never dismiss a certificate warning merely because the address was typed correctly. Protect registrar and DNS administration with suitable strong authentication and controlled access. Phishing-resistant authentication can limit misuse by an unrelated origin posing as the bank. It cannot repair compromise of the intended origin or solve every endpoint attack. For the bank case, combine signed-data validation, protected transport, verified service identity, and secure authoritative control, with their actual limits understood.
Denial of Service
Pressure Can Exhaust Bandwidth, Protocol Resources, or Application Work
Denial of service disrupts useful availability by consuming or interfering with necessary resources. Distributed attacks involve multiple sources or distributed paths, including compromised devices or third-party reflectors. Volumetric pressure fills connection capacity before useful processing can occur. A destination filter cannot restore an upstream link already saturated before traffic reaches it. Protocol pressure targets connection tracking or other network and server protocol resources. Application pressure targets expensive operations such as searches, reports, or sign-ins. Reflection directs third-party responses toward the victim; amplification can make responses larger than the initiating traffic. Prepare upstream capacity, appropriate rate controls, protocol-aware protection, and resilient application design. Content distribution and protected origin reachability help when correctly designed; hiding an address alone is insufficient. Some harmful requests resemble legitimate work, while useful patterns may still distinguish them. Arrange provider contacts, authority, and an exercised response before the emergency, avoiding broad blocks that unnecessarily exclude real visitors.
Ethical Responsibility
The Small Charity’s Outage Involves More Than the Person Launching It
The small charity's outage illustrates distributed harm and unequal access to protection. Thousands of sources cannot be safely reduced to one simple deny rule. Shared networks contain real visitors, while some participating device owners do not know their equipment is involved. Reflectors may be legitimate servers rather than compromised machines. The person launching the attack remains responsible for deliberate disruption. Abuse-service operators make disruptive capability easier to obtain and spread. Manufacturers influence risk through secure defaults, update mechanisms, support duration, and replacement expectations. Owners need feasible ways to maintain supported devices. Network operators can restrict spoofed-source traffic and improperly exposed amplification services. Schools, hospitals, charities, and independent publications may struggle to afford adequate mitigation. Large providers can supply capacity, while dependence also concentrates traffic visibility and influence over continued availability. Consider affordability, product support, provider accountability, and responsible network operation alongside individual wrongdoing, without treating unmeasured demand claims as universal statistics.
Network Devices
Treat the Remote-Access Gateway as a Sensitive System With a Maintenance Owner
Routers, switches, firewalls, wireless controllers, and VPN gateways run software that needs maintenance. Updates can be deferred because a shared outage is difficult to schedule. Long uptime can encourage complacency, but it does not establish actual patch or support status. Unclear ownership leaves nobody accountable for completion. Unsupported equipment may lack a fix, requiring replacement planning and assessed interim safeguards. Missing inventory leaves exposure, monitoring, and maintenance gaps. The review company patches servers within one week but has left its remote-access gateway untouched for three years. Assess the gateway's actual version, published vulnerabilities, exposure, credentials, and support immediately. Elapsed time alone does not prove a specific vulnerability, but indefinite deferral leaves unmanaged risk around sensitive access. Plan routine and emergency maintenance, suitable redundancy, restricted administration, protected backups, and verified recovery. Compare predictable maintenance interruption with uncontrolled compromise, and replace unsupported equipment before waiting for a fix that may never arrive.
Matching Defenses
Use the Control That Addresses the Actual Weakness, Then Verify It
Match each weakness to the measure that addresses its actual mechanism. For unnecessary listeners, inventory purpose and dependencies, disable safely, restrict necessary sources, and verify exposure. For unprotected protocols, enforce suitable protected replacements with identity checks and no accidental cleartext fallback. For wireless impostors, validate authentication, protect traffic, control attachment, and observe unexpected equipment. For false local mappings, protect peer identity and configure segmentation and suitable switch validation. For wrong resolution answers, combine signed data, protected transport, service certificates, and secure authoritative administration. For denial of service, prepare upstream capacity, appropriate limits, resilient architecture, and exercised response. For neglected devices, assign inventory and patch ownership, restrict management, verify recovery, and replace unsupported equipment. Three habits recur: know what is deployed, protect and verify communication, and limit reachability. Implementation costs, effectiveness, and priorities depend on the actual organization. The fourteen-listener server, airport network, bank, charity, and gateway cases therefore require different justified combinations. Accountability means verified outcomes and maintained responsibilities, rather than unmeasured claims about every network's history or the majority of all intrusions.
About Ethics in Technology at UPI Study
Ethics in Technology (Computer Science 195) is a self-paced online course of 116 video lessons in 15 chapters, from cybersecurity basics, privacy and surveillance to big data, hacking, malware, network defense, intellectual property, cybercrime, encryption, emerging technology and digital citizenship. It carries a NCCRS credit recommendation for 3 semester credits.
Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Enroll now → Course details Download the syllabus All Computer Science courses
Compare: Cybersecurity vs Ethics in Technology · Which ethics course?
Why take it here
Why students take Ethics in Technology with UPI Study
Where the credit goes
Universities that work with NCCRS
Ethics in Technology carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.
FAQ
Questions students ask us
About Common Weaknesses in Network Systems
Why are unnecessary open ports and services a security risk?
What are secure replacements for Telnet, FTP, and HTTP?
What is ARP spoofing?
What is DNS cache poisoning and how is it prevented?
About the Ethics in Technology course
How many college credits is Ethics in Technology?
How much does Ethics in Technology cost and what is included?
Which universities accept UPI Study credits?
How long does Ethics in Technology take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in Ethics in Technology.
116 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →