Previous Semester

Lecture 1

ISO developed the Open Systems Interconnection (OSI) model.

The OSI model Divides network communication into 7 layers.

  1. Application (HTTP, FTP)
  2. Presentation (ASCII, GIF, JPG)
  3. Session (SQL)
  4. Transport (TCP, UDP)
  5. Network (IP)
  6. Data Link (802.11)
  7. Physical (Fiber)

In 1970, the transmission rate of a connection was 56 Kb/s. Today we have faster connections, a CAT7 cable can even transfer 10 Gb/s

A mobile hotspot is a form of ad-hoc networking

Some numbers about the internet in 2020.

The phyiscal layer is made of fiber, coaxial cable, radio signals

Interfaces include ethernet chips, as well as wireless chips.

Networks are built to withstand failure among its intermediary nodes. Given 100 components, where any given component is failing 1% of the time, there is a 63% that, at any given moment, at least one component is failing.

The ipconfig command first appeared in MacOS 10.0.

The basic components of a network include

The Internet Engineering Task Force (IETF) is a non-profit organization that seeks to standardize protocols across the world.

1961-1972 early packet switching principles

sputnik was launched in response, us founded ARPA, the advanced research project agency, and poured money into it

www was invented in 1990s

principles of internetworking

Woah, modem stands for modulator demodulator.

Digital Subscriber Line (DSL)

Digital Subscrible Line Access Multiplexer (DSLAM)

Data over DSL phone goes to internet. Voice over DSL phone goes to the telephone, but the problem with cable over a phone line is that cable is a shared medium, and a phone line is a dedicated medium.

Cable is a form of broadband.

Broadband transports multiple signals and traffic types

Among a continuous band of frequencies, bandwidth is defined as the difference between the upper and the lower frequencies.

Lecture 2

The CSCI 353 Layers

  1. Application

    • Provides network support for apps

  2. Transport

    • (Reliable) end-to-end delivery

  3. Network

    • Global best-effort delivery

  4. Link

    • Local best-effort delivery

  5. Physical

    • Bits on wire

Network Devices

Protocols

Inter-Layer Headers

IPv4 Datagram

TCP

Types of sockets

SOCK_STREAM
a.k.a. TCP
SOCK_DGRAM
a.k.a. UDP
SOCK_RAW
allows headers of lower level protocols to be constructed by the application

Taxonomy of Communication Networks

Multiplexing

Lecture 3

Lecture 4

Midterm

Lecture 5

Internet Names

Domain Name Service

Server Hierarchy

DNS Root Servers

Networking Techniques

Name Resolution

Name resolution starts with a recursive resolver (also known as a DNS recursor)

  1. requesting host trojan.usc.edu sends a request to local DNS server dns.usc.edu for the IP address for bruin.cs.usc.edu

  2. the local DNS server dns.usc.edu checks if it has cached the IP address of bruin.cs.usc.edu. If it's cached, the local DNS server sends the cached IP address of bruin.cs.usc.edu to the requesting host. The process is finished at this point, preventing the steps below from executing.

  3. the local DNS server dns.usc.edu asks root DNS server for the IP address of the TLD DNS server for edu

  4. the root DNS server sends the IP address of the TLD DNS server for edu to the local DNS server

  5. The local DNS server dns.usc.edu asks the TLD DNS server for the IP address of the authoritative DNS server

  6. The TLD DNS server sends the IP address of the authoritative DNS server to the local DNS server

  7. the local DNS server requests the authoritative DNS server for the IP address of the machine bruin.cs.ucla.edu

  8. the authoritative DNS server sends the local DNS server the IP address of the machine bruin.cs.ucla.edu

  9. the local DNS server sends the IP address of the machine bruin.cs.ucla.edu to the requesting host (and caches it as well)

Official 8-step Procedure

  1. A user types ‘example.com’ into a web browser and the query travels into the Internet and is received by a DNS recursive resolver.
  2. The resolver then queries a DNS root nameserver (.).
  3. The root server then responds to the resolver with the address of a Top Level Domain (TLD) DNS server (such as .com or .net), which stores the information for its domains. When searching for example.com, our request is pointed toward the .com TLD.
  4. The resolver then makes a request to the .com TLD.
  5. The TLD server then responds with the IP address of the domain’s nameserver, example.com.
  6. Lastly, the recursive resolver sends a query to the domain’s nameserver.
  7. The IP address for example.com is then returned to the resolver from the nameserver.
  8. The DNS resolver then responds to the web browser with the IP address of the domain requested initially.

DNS Records

Old-school Website Management

  1. Create a company "Example"
  2. Get a CIDR blcok from your ISP
  3. Register example.com with domain registrar
  4. Registrar inserts RR pairs ino the .com TLD server txt (mystartup.com, dns.mystartup.com, NS) (dns.mystartup.com, 212.44.9.129, A)
  5. Store appropriate records (A & NS) at dns.mystartup.com

Improving DNS Performance

User Datagram Protocol UDP { # UDP }

Pipelining

Sliding Window

Lecture 6

Review

General Terms Used

Question: Which algorithm would you choose for inter-domain routing? Link State (LS) vs. Distance Vector (DV)? Why? Answer: For inter-domain routing, I would choose distance vector over link state. With link state, every node in the network has a lot of information about the connections, which not only brings up privacy concerns, but also is more expensive to compute for large network topologies. With inter-domain routing, large topologies are rather common. BGP uses not distance vector, but a similar one, but certainly does not use link state.

RIP: Routing Information Protocol

Lecture 8 Question 6

Question: What could happen if routers lie? Answer: A router could lie if it wanted to redirect or attract traffic, which it could use to either sniff the packets to obtain information, or just gain information on where traffic is coming and going from (valuable!)

Question How can you prevent routers from deceiving other devices on the network? Answer You can configure your network to only communicate with trusted networks.

Lab 3

Snort resources. There's a Docker container for Snort built on top of Debian.

I found the Snort manual to be very helpful while working on this project.

For Snort to detect attacks and alert you when attacks occur, Snort needs to know where its rule base is. As a matter of convention, we place our custom rules for Snort in the file /prefix/snort/local.rules.

The general format of a Snort rule is as follows:

ACTION PROTO SOURCE_HOST SOURCE_IP DIRECTION DESTINATION_HOST DESTINATION_IP \[OPTIONS\]

A Snort rule can be broken down into two logical parts

  1. The rule header, which contains the following information:

    • Action to perform

    • Protocol that the rule applies to

    • Source and destination addresses and netmasks

    • Source and destination ports information

  2. The rule options, which allow you to

    • Create a descriptive message to associate with the rule

    • Check a variety of other packet attributes by making use of Snort's extensive library of plug-ins.

When a packet comes in, its source and destination IP addresses and ports are compared to the rules in the ruleset. If any of them are applicable to the packet, then the options are compared to the packet. If all of these comparisons return a match, then the specified action is taken.

Snort provides several built-in actions that you can use when crafting your rules.

Note the last three actions would only work in inline mode.

Shown below is a sample local.rules file:

alert icmp any any -> any any (msg: "Testing ICMP alert"; sid:1000001;)
alert udp any any -> any any (msg: "Testing UDP alert"; sid:1000002;)
alert tcp any any -> any any (msg: "Testing TCP alert"; sid:1000003;)

Currently protocols supported are TCP, UDP, ICMP and IP. Direction is specified using ASCII arrow syntax ->. The IP address and port number on the left-hand side of the direction operator is the source host, and the right-hand side is the destination host. <> can be used to represent a bidirectional arrow operator. Rule options are separated by ( ; ) and rule option keywords are separated from their arguments by a ( : ). The msg rule option is a simple text string to be printed along with the alert or the log. The sid keyword is used to identify Snort rules, custom defined rules should have a sid >= 1000000. rev is used to mark the revision numbers in conjunction with sid.

Breaking down the options used in the previous command:

Understanding Standard Alert Output

When Snort generates an alert message, it will usually look like the following:

[**] [116:56:1] (snort_decoder): T/TCP Detected [**]

The first number is the Generator ID, this tells the user what component of Snort generated this alert.

The second number is the SID or Snort ID (sometimes referred to as the Signature ID). Rule-based SIDs are written directly into the rules with the SID option. In this case, 56 represent a T/TCP event.

The third number is the revision ID.