Securing Legacy Systems

Created by: Jeff Mates, JHUISI, jmates1@jhu.edu,
Modified by: Jelena Mirkovic, USC/ISI, sunshine@isi.edu
Contents
  1. Overview
  2. Recommended Readings
  3. Introduction
  4. Assignment Instructions
    1. Setup
    2. Basic Tasks
      1. Activate Snort Without Rules
      2. Analyze Network Traffic
      3. Write Rules to Guard Against Simple Requests
    3. Intermediate Tasks
      1. DOS Defense
      2. Securing Traffic on the Network
    4. Advanced Tasks
      1. Code Execution Vulnerability
      2. Defend Against ASCII Encoding
    5. What Can Go Wrong
  5. Submission Instructions

Overview

This exercise demonstrates how Snort (version 2) and similar inline intrusion detection / prevention systems can be used to help secure legacy software by walking them through an environment that includes an extremely insecure application.

Depending on their skill level students will be asked to analyze network the network traffic produced by this program, to write Snort rules to protect against known attacks against this program and to create a sample attack against this program which they will be asked to guard against.

Recommended Reading

The following information may be useful in completing this exercise.

Introduction

When working in the field of network security it is not always possible to ensure the security of legacy applications. Many businesses and organizations use systems that are known to be highly insecure and will continue to do so for the foreseeable future as it would not be cost effective to replace or modify these programs. As such the best we can do to improve the security of these systems is to place them behind filters that can be controlled.

In this exercise you will be using Snort (version 2) to help secure a highly insecure application without modifying the application itself. This application functions as a simple password protected file server for plain text documents, and it is up to you to use Snort to help protect this information.

This network is broken into three chunks. The first chunk contains the work environment which houses the legacy server along with a single client machine. This network is protected by the Snort router, which is set not to permit any traffic through at at the start of this exercise. The second network contains a single outsider machine. Finally, the third contains two client computers. All of these networks are connected to each other using a single router.

Note: In this exercise you will use Snort version 2. There is now Snort version 3, with very different architecture and rule format.

Assignment Instructions

Setup

    1. If you don't have an account, follow the instructions here.

    2. Create an instance of this exercise by following the instructions here, using snort as Lab name. Your topology will look like below:

      .

    3. After setting up the lab, access your nodes.

Basic Tasks

Start Snort Without Rules

  1. Connect to the snort node and modify /etc/snort/snort.conf to set the DEBIAN_SNORT_HOME_NET to 100.1.10.0/24. Then type: 
          sudo snort --daq nfq -Q -v
  2. On client1 node type: 
          ftp server
      ...enter "anonymous" as username
      ...enter any string as password
      get ducky.xml
    You should see a large number of packets being reported by Snort. On router node run: 
    	  tcpdump -i ethX -nn -s 0 -X
    replacing ethX with the interface with the IP address 10.1.1.3.

    Questions:

    1. What happens to the traffic to client1 when Snort is running without any rules?
    2. Is this a good thing?
    3. Can you reconstruct contents of ducky.xml on router node?
    4. Based on Snort's output what can you say about the application? What port does it connect to?
    5. What does the "-Q" option do in Snort? Use man page to find out.
    6. What does the "--daq nfq" option do in Snort? Use man page to find out.

Write Rules to Guard Against Simple Requests

  1. In that terminal where snort is running stop it by using ctrl + c.
  2. Use any text editor to edit /etc/snort/rules/local.rules. Add the following snort rule that prevents .xml files from being sent out, 
    reject tcp 100.1.0.0/16 ANY -> 100.1.10.10 [Port from Question 3] (msg: "XML Read Attempt Detected"; sid:1; content:".xml";)
  3. Using this rule as an example write a rule that prevents classified data from being sent to the outsider computer, but does not prevent it from being sent to any other computers. Classified data is stored in files with names that share a prefix "classified".
  4. Start snort using your new rule with the command: 
          sudo snort  --daq nfq -Q -c /etc/snort/snort.conf  -A console
  5. Log onto client1, client2 and outsider to see if these rules worked. Try using ftp on these nodes to read classified files.

Questions:

  1. What happens to FTP traffic from client1 when you run snort? Show the FTP output as client1 tries to exfiltrate "classified.txt" file.
  2. What rule did you use to secure the "classified" files?
  3. Capture and compare the network traffic for the serverwhen filtering these results using your configuration file and when no file is used. Can you recover the contents of classified files?
  4. Can you think of any others files or extensions that should be filtered against? You can see what files server node has in its /srv/ftp folder.

Attack Defense

  1. Make sure you have your filtering rule engaged on Snort
  2. On outsider node install nmap: 
          apt update -y
      apt install nmap -y
  3. Run: 
          nmap 100.1.10.0/24
    to scan the server network, and check your Snort output.
  4. On outsider node run: 
         ping -f server
    to generate a flood of ICMP traffic to server node. Create a new Snnort rule that detects any ICMP packets sent from the outside into the network.

Questions:

  1. Show Snort alerts for NMAP.
  2. Show your new rule to detect ICMP traffic.
  3. Show Snort alerts for ICMP flood (a few alerts are enough).
  4. Try changing the action in the new rule to "reject" instead of "drop". What does this do to the traffic and why do you think this is? Is this a good or a bad thing?

What can go wrong

Submission Instructions

You should submit a document with the following items (label each section):
  1. An explanation of how Snort can be used to protect legacy systems
  2. Answers to all the questions in this file