Securing Internet Services and Protocols

Introduction

Internet-facing services enable communication, name resolution, software delivery, file exchange, administration, and business operations. They also expose organizations to threats because attackers can reach these services from untrusted networks. Security therefore requires more than installing a firewall. It requires understanding how protocols operate, where trust is assumed, how data is protected, and how weaknesses are detected and contained.

This chapter examines security weaknesses and protections associated with TCP/IP, DNS, DHCP, ARP, HTTP and HTTPS, email, file transfer, remote administration, APIs, and common Internet-facing services. The emphasis is on practical foundations appropriate for entry-level cybersecurity professionals.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain the security roles and limitations of major TCP/IP protocols.
2. Identify common attacks against DNS, DHCP, ARP, web, email, file-transfer, remote-administration, and API services.
3. Select appropriate controls, including encryption, authentication, segmentation, filtering, logging, and patching.
4. Distinguish transport encryption from application authentication and authorization.
5. Assess an Internet-facing service using a structured security process.
6. Recognize operational, legal, ethical, and governance responsibilities when securing services.

1. The Internet Protocol Model and Its Security Assumptions

TCP/IP is a family of protocols rather than a single protocol. A practical four-layer model is:

Security controls should be placed at several layers. A firewall may restrict a port, but it cannot by itself determine whether an authenticated user is authorized to perform a particular operation. Similarly, HTTPS can encrypt a connection but does not make vulnerable application code safe.

Confidentiality, integrity, and availability

Confidentiality prevents unauthorized disclosure. Integrity protects data from unauthorized alteration. Availability ensures that authorized users can access a service when required. Authentication establishes identity; authorization determines permitted actions; accountability links actions to identities and records.

A useful assessment question is: “Which security property does this control provide, and which properties does it not provide?” For example, encryption primarily supports confidentiality and, when correctly authenticated, integrity. It does not automatically provide authorization or availability.

TCP and UDP

TCP provides connection-oriented, reliable byte-stream delivery. Its three-way handshake uses SYN, SYN-ACK, and ACK messages. Attackers can exploit this process through SYN flooding, in which many incomplete connections consume server resources. Defenses include SYN cookies, connection limits, rate limiting, load balancing, and upstream denial-of-service protection.

UDP is connectionless and does not provide delivery guarantees. It is useful for DNS, streaming, and real-time applications, but it is easier to spoof and is frequently abused in reflection and amplification attacks. Services using UDP should validate requests, limit response amplification, and apply network filtering.

IP does not prove that a packet came from the address shown in its source field. Source-address filtering, ingress and egress filtering, and authenticated higher-layer protocols reduce the consequences of spoofing. IPv6 introduces a much larger address space and mandatory support for certain protocol features, but it does not automatically make a network secure. IPv6 must be included in firewall rules, monitoring, vulnerability management, and incident response.

2. DNS: Name Resolution and Trust

The Domain Name System translates names such as example.org into resource records, including IP addresses. A resolver usually queries authoritative servers through a hierarchy of root, top-level-domain, and authoritative name servers. DNS commonly uses UDP port 53; TCP port 53 is also used for large responses and zone transfers.

Major DNS weaknesses

DNS was originally designed for availability and interoperability, not strong authenticity. Important threats include:

• Cache poisoning: false records are inserted into a resolver cache.
• DNS spoofing: a false response is presented to a client.
• Unauthorized zone transfer: a server reveals an entire zone to an untrusted requester.
• Subdomain takeover: a DNS record points to a deprovisioned cloud resource that an attacker can claim.
• Open recursion: a resolver answers arbitrary Internet queries and may be used for amplification.
• DNS tunneling: data is encoded in DNS queries or responses to bypass controls.
• Distributed denial of service: DNS infrastructure is overwhelmed directly or through reflection.

DNS protections

DNSSEC adds digital signatures to DNS data. A validating resolver can determine whether a signed response is authentic and has not been modified, assuming a trusted validation chain. DNSSEC does not encrypt queries and does not prevent every denial-of-service attack. Privacy-focused mechanisms such as DNS over TLS and DNS over HTTPS encrypt the connection between a client and a resolver, but they do not by themselves establish that every returned domain is safe.

Organizations should restrict zone transfers to authorized secondary servers, disable recursion on authoritative servers, separate authoritative and recursive roles where practical, monitor unusual query patterns, protect registrar accounts with strong multifactor authentication, and remove obsolete records promptly.

3. DHCP and ARP on Local Networks

DHCP

The Dynamic Host Configuration Protocol supplies clients with addresses, gateways, DNS servers, and lease durations. The normal exchange is often summarized as Discover, Offer, Request, and Acknowledgment.

DHCP has limited built-in authentication. A rogue DHCP server can provide a malicious gateway or DNS server, enabling interception or redirection. A DHCP starvation attack consumes available addresses, preventing legitimate clients from obtaining configuration.

Defenses include DHCP snooping on managed switches, trusted uplink configuration, rate limiting, port security, network access control, monitoring for unauthorized servers, and segmentation. DHCP logs should be correlated with switch and authentication records because addresses are leased and may change over time.

ARP

Address Resolution Protocol maps IPv4 addresses to hardware addresses on a local network. ARP generally accepts announcements without strong authentication. In ARP spoofing or poisoning, an attacker claims that the attacker’s hardware address corresponds to another host, commonly the default gateway. Traffic may then be intercepted, altered, or disrupted.

Controls include switch inspection features, static mappings for selected critical systems, host-based detection, encrypted application protocols, network segmentation, and careful monitoring of changes to gateway mappings. ARP protections reduce risk but do not replace end-to-end encryption.

4. HTTP and HTTPS

HTTP is an application protocol for requesting and delivering web resources. Traditional HTTP sends requests and responses without confidentiality or cryptographic integrity. Credentials, session identifiers, and personal information can therefore be exposed or modified in transit.

HTTPS is HTTP transported through TLS. A secure TLS connection provides encryption and server authentication when certificate validation succeeds. It does not guarantee that the website is honest, that the user is authorized, or that the server is free from vulnerable code.

Web-service attack surface

Common weaknesses include:

• injection, including SQL and command injection;
• cross-site scripting, in which attacker-controlled script executes in a user’s browser;
• cross-site request forgery, in which a browser is induced to send an unwanted authenticated request;
• broken access control, such as changing an identifier to view another user’s record;
• insecure session management;
• unrestricted file upload;
• security misconfiguration and exposed administrative interfaces;
• vulnerable dependencies;
• server-side request forgery, where a server is tricked into making unintended requests;
• inadequate logging and error handling.

The OWASP Application Security Verification Standard and OWASP Top 10 are useful awareness resources, but they do not replace context-specific testing.

Practical protections

Use TLS for all sensitive and preferably all web traffic. Redirect HTTP to HTTPS, enable HSTS after careful testing, protect cookies with Secure, HttpOnly, and appropriate SameSite attributes, and use short-lived sessions with server-side invalidation. Apply allow-list input validation, parameterized database queries, output encoding, anti-CSRF protections, and centralized authorization checks. Remove default accounts, minimize server information in responses, patch frameworks, and scan dependencies.

A reverse proxy or web application firewall can provide filtering, rate limiting, and TLS termination. These controls are useful layers, but they cannot repair flawed authorization logic or unsafe business processes.

5. Email Security

Email commonly uses SMTP for message transfer. Client submission generally uses authenticated SMTP with encryption, while IMAP or POP3 is used for mailbox access. Email was designed to interoperate across independent organizations, so sender identity is not automatically trustworthy.

Threats include phishing, business email compromise, malware attachments, malicious links, credential theft, spoofed sender addresses, mailbox takeover, and interception on poorly secured connections.

Three important domain-based controls are:

• SPF: identifies permitted sending hosts for a domain.
• DKIM: adds a cryptographic signature to selected message content and headers.
• DMARC: allows a domain owner to publish how receivers should handle messages that fail alignment and provides reporting.

These controls improve domain-level authenticity, but they do not prove that a message is benign. A compromised legitimate account can send convincing malicious mail, and a trusted domain can be abused.

Organizations should require multifactor authentication, disable legacy authentication where possible, use secure mail transport, scan attachments and URLs, protect high-risk accounts, train users using realistic exercises, and establish reporting procedures. DMARC policies should be introduced carefully: organizations should inventory legitimate senders before moving from monitoring to quarantine or rejection.

6. File Transfer Services

FTP transmits credentials and data without adequate protection in its basic form. FTPS adds TLS to FTP, while SFTP is file transfer over the SSH protocol; these are different technologies. HTTPS-based file exchange and managed file-transfer platforms are also common.

Security requirements include encryption in transit, strong authentication, authorization by directory and operation, malware scanning, transfer logging, retention controls, integrity verification, and secure deletion where appropriate. Anonymous access should be avoided unless it is deliberately designed for public distribution and isolated from sensitive data.

File-transfer servers are frequently targeted because they hold valuable business data. They should be placed in a segmented zone, expose only required services, restrict administrative access, and apply upload size and file-type controls. File names and metadata should not be trusted as evidence of file content.

7. Remote Administration

Telnet and older remote-management protocols send credentials or sessions without adequate protection and should not be used for administrative access. SSH provides encrypted remote administration and can use passwords, public-key authentication, certificates, or hardware-backed credentials. Remote desktop technologies should likewise use strong authentication, encryption, network-level protection, and restricted exposure.

Best practices include:

1. Do not expose management interfaces directly to the entire Internet.
2. Require a VPN, zero-trust access gateway, or restricted bastion host.
3. Use phishing-resistant multifactor authentication for privileged access.
4. Prefer individual accounts and short-lived administrative privileges.
5. Disable direct root or administrator login where feasible.
6. Restrict source addresses and management ports.
7. Record commands, sessions, authentication events, and privilege changes.
8. Patch the operating system and remote-access software promptly.
9. Use separate administrative devices or hardened management workstations.

Remote administration is a high-value target. A stolen administrator credential can bypass many perimeter controls, so identity protection and least privilege are central controls.

8. APIs and Internet-Facing Applications

An API exposes functions or data for software clients. REST APIs commonly use HTTP methods and JSON, while other services may use GraphQL, gRPC, or message-oriented protocols. API security requires controls at the identity, object, function, input, transport, and operational levels.

Frequent API weaknesses include broken object-level authorization, excessive data exposure, unrestricted resource consumption, weak token handling, mass assignment, injection, insecure third-party integrations, and undocumented shadow APIs.

A secure API should:

• require TLS and validate certificates appropriately;
• authenticate clients and users with suitable mechanisms;
• authorize every object and action on the server side;
• validate types, lengths, formats, and ranges;
• return only fields needed by the client;
• limit requests by identity, operation, and resource cost;
• use short-lived tokens and protect signing keys;
• version and retire interfaces deliberately;
• log security-relevant events without exposing secrets;
• test negative cases, not merely successful workflows.

API gateways can centralize authentication, rate limiting, schema validation, and observability. They should not become a single point of unreviewed trust. Backend services must still enforce authorization.

9. A Structured Assessment Method

A practical assessment of an Internet-facing service can follow these stages:

1. Establish scope

Identify the service owner, business purpose, data types, dependencies, approved test window, and authorization boundaries. Testing systems without permission may be unlawful and may disrupt other users.

2. Build an inventory

Record domains, IP addresses, ports, protocols, certificates, cloud resources, APIs, administrative paths, and third-party providers. Include IPv4 and IPv6.

3. Model threats

Ask who may attack the service, what they want, which trust assumptions are weak, and what happens if confidentiality, integrity, or availability fails.

4. Verify configuration

Check encryption, certificate validity, authentication, authorization, exposure, default accounts, patch status, DNS records, email controls, logging, and backup arrangements.

5. Test safely

Use approved vulnerability scans and controlled manual tests. Avoid destructive payloads, excessive traffic, unauthorized data access, and tests that could affect production.

6. Prioritize findings

Consider exploitability, exposure, affected assets, data sensitivity, business impact, and existing compensating controls. A public administrative interface with weak authentication generally deserves urgent attention.

7. Remediate and verify

Assign an owner and deadline, implement the fix, retest it, and document residual risk. Security is a lifecycle rather than a one-time scan.

Security telemetry

Useful telemetry includes DNS query logs, web access and error logs, authentication events, firewall flows, endpoint alerts, API gateway records, mail authentication reports, and configuration changes. Logs should have synchronized time, controlled access, suitable retention, and protection against unauthorized alteration. Monitoring must respect privacy and applicable law.

10. Illustrative Case: Regional Healthcare Appointment Platform

Background

A regional healthcare provider operates a public appointment website, a patient API, email notifications, remote administration, and a file-transfer service for partner clinics. A security review discovers that the website uses HTTPS, but the administrative portal is reachable from the Internet, the API returns excessive patient fields, and an obsolete DNS record points to a discontinued cloud application.

Problem

The organization faces several risks: credential attacks against the administrative portal, unauthorized disclosure through the API, and possible subdomain takeover. Its logs are distributed across providers and are not routinely reviewed.

Analysis

The HTTPS deployment addresses transport confidentiality but does not correct excessive API responses or weak administrative exposure. The obsolete DNS record creates a dependency on a resource no longer controlled by the organization. Lack of centralized monitoring reduces the likelihood of rapid detection.

Approach and solution

The organization removes the obsolete record and verifies all DNS assets through an ownership inventory. It places administration behind a restricted access gateway, requires phishing-resistant multifactor authentication, disables legacy accounts, and limits privileges. API responses are redesigned according to data minimization; object-level authorization is tested for every patient identifier. Rate limits and schema validation are added at the API gateway and in backend services. Centralized logging is implemented for DNS changes, administrative access, API denials, and unusual data volumes. The file-transfer service is moved to a segmented managed platform using encrypted transfer and separate partner accounts.

Outcome

A follow-up assessment confirms that the abandoned subdomain is no longer claimable, administrative access is restricted, and cross-patient API access attempts are denied. The provider also establishes quarterly Internet-asset reviews and a formal change process.

Learning points

Transport encryption is necessary but insufficient. Asset ownership, authorization, identity security, data minimization, segmentation, and monitoring must work together. The case also illustrates that a small configuration error in DNS can create a major application-security consequence.

11. Governance, Ethics, and Contemporary Developments

Internet services often process personal, financial, health, or operational data. Organizations should apply data minimization, purpose limitation, retention rules, access governance, breach-response procedures, and applicable privacy and cybersecurity regulations. Security testing requires documented authorization and proportionality. Researchers who discover weaknesses should avoid accessing unnecessary data and should use responsible disclosure channels.

Cloud services, software supply chains, container platforms, and service meshes have increased the number of Internet-facing components. Infrastructure-as-code scanning, software bills of materials, signed releases, secrets-management systems, and continuous exposure monitoring help address this complexity. Artificial intelligence can assist with log triage, anomaly detection, code review, and phishing analysis, but generated conclusions require human validation. AI systems can produce false positives, expose confidential data through prompts, or be manipulated by adversarial input; they should not receive unrestricted production authority.

Best-Practice Checklist

• Maintain an accurate inventory of services, domains, certificates, APIs, and owners.
• Expose only required ports and interfaces.
• Use current encryption and validate certificates correctly.
• Apply multifactor authentication, least privilege, and individual accountability.
• Protect DNS, DHCP, and network-management functions from unauthorized use.
• Patch operating systems, applications, libraries, and appliances.
• Validate input and enforce authorization on the server side.
• Segment public, application, data, and management networks.
• Rate-limit resource-intensive operations and prepare for denial of service.
• Centralize, protect, and review security logs.
• Test backups and incident-response procedures.
• Review Internet exposure and third-party dependencies regularly.

Chapter Summary

Internet services inherit weaknesses from protocol design, configuration, implementation, identity management, and operational practice. TCP can be exhausted by connection floods, UDP can support spoofed amplification, and IP does not authenticate source addresses. DNS requires protection against poisoning, unauthorized transfers, open recursion, and abandoned records. DHCP and ARP are especially dependent on local-network trust and benefit from switch controls and segmentation.

HTTP should be replaced or protected by HTTPS, but TLS does not fix vulnerable application logic. Email requires layered controls such as SPF, DKIM, DMARC, multifactor authentication, filtering, and user reporting. Secure file transfer and remote administration require encryption, strong identity controls, restricted exposure, and detailed logging. APIs must enforce object-level authorization, input validation, data minimization, rate limiting, and secure token management.

A defensible assessment establishes scope, inventories assets, models threats, verifies configuration, tests safely, prioritizes risk, and confirms remediation. Effective security is layered, continuously monitored, ethically conducted, and aligned with business and legal responsibilities.

Key Terms

TCP: A reliable, connection-oriented transport protocol.

UDP: A connectionless transport protocol without delivery guarantees.

DNS: A distributed system that maps names to resource records.

DNSSEC: A system of digital signatures that authenticates DNS data.

DHCP: A protocol that leases network configuration to clients.

ARP: A protocol that maps IPv4 addresses to local hardware addresses.

TLS: A cryptographic protocol providing protected network communication.

HTTPS: HTTP carried through TLS.

SPF: A domain policy identifying permitted email sending hosts.

DKIM: A cryptographic signature mechanism for email messages.

DMARC: A policy and reporting framework for domain-based email authentication.

SFTP: File transfer provided through SSH.

SSH: An encrypted protocol commonly used for remote administration.

API: An interface through which software exchanges functions or data.

Authentication: Verification of an identity.

Authorization: Determination of what an authenticated identity may do.

Rate limiting: Restriction of request frequency or resource consumption.

Segmentation: Dividing a network or system into controlled security zones.

DNS tunneling: Encoding data within DNS queries or responses.

Least privilege: Giving an identity only the access required for its task.

Review Questions

Short Answer Questions

1. Why does HTTPS not guarantee that a web application is secure?
2. What is the purpose of DNSSEC, and what limitation does it have?
3. How can a rogue DHCP server harm a local network?
4. Distinguish SFTP from FTPS.
5. Why is object-level authorization important in an API?

Long Answer Questions

1. Explain the principal security weaknesses of DNS and describe layered protections for an organization’s DNS infrastructure.
2. Compare the security properties and risks of TCP and UDP, including appropriate defensive measures.
3. Discuss how SPF, DKIM, and DMARC work together and why they do not eliminate phishing.
4. Design a secure remote-administration architecture for a small enterprise.
5. Explain a complete lifecycle for assessing and remediating an Internet-facing service.

Analytical / Application Questions

1. A public API returns a patient’s full record whenever a valid user changes a numeric patient identifier in the request. Identify the weakness, explain the likely impact, and propose controls.
2. A company discovers an abandoned DNS record pointing to a deleted cloud application. Analyze the threat and describe a safe response and prevention process.
3. A web server uses HTTPS but permits unlimited login attempts and exposes its administration portal to the Internet. Prioritize the risks and propose a layered remediation plan.

Multiple Choice Questions with Answers

Question 1

Which protocol is primarily responsible for mapping domain names to IP addresses?

A. DNS

B. DHCP

C. ARP

D. SSH

Correct Answer: A. DNS

Question 2

What does DNSSEC primarily provide?

A. Confidentiality for DNS queries

B. Authentication and integrity of signed DNS data

C. Automatic malware removal

D. Guaranteed DNS availability

Correct Answer: B. Authentication and integrity of signed DNS data

Question 3

Which attack involves an attacker supplying a false default gateway address through local network resolution?

A. DNS tunneling

B. SYN flooding

C. ARP poisoning

D. Credential stuffing

Correct Answer: C. ARP poisoning

Question 4

What is a principal limitation of HTTPS?

A. It cannot encrypt traffic

B. It does not automatically correct insecure application authorization

C. It works only with UDP

D. It prevents all denial-of-service attacks

Correct Answer: B. It does not automatically correct insecure application authorization

Question 5

Which email control publishes a policy for handling messages that fail domain-based authentication alignment?

A. ARP

B. DKIM

C. DMARC

D. SFTP

Correct Answer: C. DMARC

Question 6

Which service is generally preferred for encrypted command-line remote administration?

A. Telnet

B. FTP

C. SSH

D. HTTP

Correct Answer: C. SSH

Question 7

A user is authenticated to an API but can change an object identifier and retrieve another customer’s record. What is the primary weakness?

A. Broken object-level authorization

B. DNS cache poisoning

C. DHCP starvation

D. TLS certificate expiration

Correct Answer: A. Broken object-level authorization

Question 8

Which measure most directly reduces the risk of a rogue DHCP server on a managed switched network?

A. Disabling HTTPS

B. DHCP snooping and trusted-port configuration

C. Increasing DNS TTL values

D. Using anonymous FTP

Correct Answer: B. DHCP snooping and trusted-port configuration

Question 9

Why are public administrative interfaces especially risky?

A. They cannot generate logs

B. They expose privileged functions to broad attack attempts

C. They always use UDP

D. They prevent multifactor authentication

Correct Answer: B. They expose privileged functions to broad attack attempts

Question 10

Which practice best supports reliable incident investigation across DNS, web, and authentication systems?

A. Disabling all logging to preserve performance

B. Using synchronized time and protected centralized logs

C. Allowing shared administrator accounts

D. Keeping logs only on individual laptops

Correct Answer: B. Using synchronized time and protected centralized logs