Security in Distributed Systems: Threats, Attacks & Defenses

TAKEAWAYS:

• Distributed systems face unique threats like man-in-the-middle (MITM) attacks, sybil attacks, and denial-of-service (DoS) due to decentralized communication and shared resources.
• Cryptographic protocols (e.g., TLS, SSH) and authentication mechanisms (e.g., digital signatures, OAuth) are critical to secure data integrity, confidentiality, and availability.
• Firewalls, intrusion detection systems (IDS), and access control lists (ACLs) mitigate attacks by filtering traffic, monitoring anomalies, and enforcing policies.
• Zero-trust architecture and end-to-end encryption are modern defenses against insider threats and unauthorized access in systems like eSewa’s payment gateways.
• Consistency models (e.g., strong vs. eventual consistency) impact security by balancing availability and fault tolerance, e.g., in NEPSE’s stock trading systems.
• Regulatory compliance (e.g., GDPR, PCI-DSS) is essential for distributed systems handling sensitive data, such as Ncell’s user records.

1. Introduction to Security in Distributed Systems

Distributed systems are vulnerable to security threats due to their decentralized nature, open communication channels, and shared resources. Unlike centralized systems, where security can be enforced at a single point, distributed systems require end-to-end security across all nodes, communication links, and services.

Key Security Objectives

Every distributed system must ensure:

• Confidentiality: Only authorized parties access data (e.g., eSewa’s transaction encryption).
• Integrity: Data is not altered in transit or storage (e.g., NEPSE’s trade order validation).
• Availability: Services remain operational despite attacks (e.g., Pathao’s ride-hailing uptime).
• Authentication: Verification of identities (e.g., Khalti’s two-factor authentication).
• Non-repudiation: Proving actions cannot be denied (e.g., Daraz’s order tracking logs).

2. Threats and Attacks in Distributed Systems

Distributed systems are targeted by attacks exploiting their heterogeneity, scalability, and dynamic nature. Below are the most common threats:

2.1 Classification of Attacks

2.2 Worked Example: MITM Attack on eSewa

Scenario: An attacker intercepts an eSewa payment transaction between User A and a merchant. Steps:

1. Phishing: The attacker sends a fake eSewa login page to User A.
2. Session Hijacking: User A enters credentials on the fake site, which the attacker captures.
3. Message Alteration: The attacker intercepts the actual payment request and modifies the recipient’s account (e.g., diverting funds to their own wallet).
4. Completion: User A believes the payment succeeded, but funds are lost.

Mitigation:

• Use TLS/SSL for encrypted communication.
• Implement digital signatures to verify message authenticity.
• Enforce two-factor authentication (2FA) for all transactions.

3. Security Mechanisms and Protocols

Distributed systems employ cryptographic techniques, authentication, and access control to counter threats.

3.1 Cryptographic Techniques

Visual: Asymmetric Encryption Workflow

sequenceDiagram
  participant Alice as User
  participant Bob as Server
  participant Eve as Attacker

  Alice->>Bob: Public Key + Encrypted Message
  Bob->>Alice: Decrypted Message (Private Key)
  Eve->>Bob: Intercepts Encrypted Message (Fails)
  note right of Eve: "Eve cannot decrypt without Alice’s private key"
  note right of Alice: "Alice signs message with her private key"
  note right of Bob: "Bob verifies signature with Alice’s public key"

3.2 Authentication and Authorization

• Authentication: Verifies identities using:

  • Passwords (weak, vulnerable to brute force).
  • Biometrics (fingerprint, facial recognition in Ncell apps).
  • OAuth/OIDC (used by eSewa for third-party logins).
  • Kerberos (used in enterprise distributed systems like banks).

• Authorization: Grants permissions based on roles (e.g., NEPSE’s "trader" vs. "broker" roles).

Visual: OAuth 2.0 Flow for eSewa Login

sequenceDiagram
  participant User as User
  participant eSewa as eSewa App
  participant AuthServer as Bank’s Auth Server
  participant Bank as Bank Server

  User->>eSewa: Login Request
  eSewa->>AuthServer: Redirect to Bank (OAuth)
  AuthServer->>User: Returns Authorization Code (via Bank)
  User->>eSewa: Sends Code to eSewa
  eSewa->>AuthServer: Exchanges Code for Access Token
  AuthServer->>eSewa: Returns Access Token
  eSewa->>Bank: Uses Token to Access User Data
  note over User,Bank: "Token expires after 1 hour (short-lived)"

3.3 Access Control and Firewalls

• Access Control Lists (ACLs): Define permissions for resources (e.g., restricting NEPSE traders to specific markets).
• Firewalls: Filter traffic based on rules (e.g., Ncell’s network firewall blocking malicious IPs).
• Intrusion Detection Systems (IDS): Monitor for anomalies (e.g., Pathao’s IDS detecting fake ride requests).

Visual: Firewall Rule Example for Ncell

(Image shows a firewall rule table with columns: Source IP, Destination IP, Port, Action (Allow/Deny). Example: Block 192.168.1.100:8080 → Any:TCP if flagged as malicious.)

3.4 Secure Communication Protocols

4. Security Challenges in Distributed Systems

5. Case Study: Security in NEPSE’s Distributed Trading System

Problem: NEPSE’s stock trading system must ensure:

• Integrity: Trade orders are not altered.
• Availability: The system remains operational during high traffic.
• Non-repudiation: Traders cannot deny executing orders.

Solutions Implemented:

1. Digital Signatures: Each trade order is signed by the trader’s private key.
2. Blockchain for Audit Logs: Immutable records of all trades (prevents tampering).
3. Rate Limiting: Prevents DoS attacks during market crashes.
4. Multi-Factor Authentication (MFA): Traders must verify via SMS/OTP.

Visual: NEPSE Trade Order Flow

sequenceDiagram
    participant Trader as Trader
    participant NEPSE as NEPSE Server
    participant Ledger as Blockchain Ledger

    Trader->>NEPSE: Signed Trade Order (Digital Signature)
    NEPSE->>NEPSE: Verifies Signature
    NEPSE->>Ledger: Records Order in Blockchain
    Ledger->>NEPSE: Confirmation
    NEPSE->>Trader: Acknowledgment

6. In the Real World

1. eSewa’s Payment Security:

   • Idea Used: End-to-end encryption (TLS 1.3) and tokenization (replacing card numbers with tokens).
   • How: When you pay via eSewa, your card details are encrypted and never stored on their servers. Only the bank sees the tokenized data.
   • Worked Example: If an attacker intercepts your eSewa transaction data, they only see encrypted blobs—useless without the private key.

2. Ncell’s Network Security:

   • Idea Used: Zero-trust architecture and intrusion detection systems (IDS).
   • How: Ncell assumes no user or device is trusted by default. Every request is authenticated, and traffic is monitored for anomalies (e.g., sudden spikes in data usage from one location).
   • Worked Example: During the 2022 Nepal earthquake, Ncell’s IDS detected and blocked a botnet attempting to exploit the network’s stress from emergency calls.

3. Daraz’s Inventory Management:

   • Idea Used: Distributed consensus (Paxos/Raft) for inventory synchronization.
   • How: When you order a product, Daraz’s distributed database ensures all warehouses reflect the same stock levels, even if some nodes are temporarily offline.
   • Worked Example: If a high-demand item sells out in Kathmandu but is still listed as available in Pokhara, Daraz’s consensus protocol ensures the inventory is updated across all nodes within seconds.

7. Exam Tip

• Focus on High-Weight Topics:

  • Cryptographic Protocols: Know how TLS, SSH, and digital signatures work in distributed systems. Draw a sequence diagram for TLS handshake.
  • Attack Vectors: Explain MITM, Sybil, and DoS attacks with real-world examples (e.g., eSewa vs. Ncell).
  • Security Mechanisms: Compare firewalls, IDS, and ACLs in a table. Mention their use in NEPSE or banks.
  • Zero-Trust: Always mention least-privilege access and multi-factor authentication as modern defenses.

• Common Pitfalls:

  • Don’t confuse confidentiality with integrity. Confidentiality = secrecy; integrity = unaltered data.
  • Avoid vague answers for attacks. Always tie to a real system (e.g., "In Ncell, a Sybil attack could flood the network with fake SIM registrations").
  • For cryptography, always include key exchange (e.g., Diffie-Hellman in TLS) and hashing (e.g., SHA-256 for file integrity).

• Diagrams Are Mandatory:

  • For TLS handshake, OAuth flow, or attack sequences, draw a sequence diagram.
  • For firewall rules or ACL tables, use a Markdown table.
  • For consensus protocols (e.g., Paxos), use a state diagram.

• Worked Example Practice:

  • Scenario: "How would you secure a distributed chat app like WhatsApp?"
    • Answer:
      1. Use end-to-end encryption (AES-256 + RSA).
      2. Implement forward secrecy (ephemeral keys).
      3. Add message timestamps to detect replay attacks.
      4. Use blockchain for message delivery receipts.