Wersja polska

English version

Secure Systems and Networks

Lecture slides: here

Lecture

• Lectures are moved from 17:00-19:00 to 10:15-12:00 on Fridays in room L2.1 in Technopolis building (C-16), just before the lab/seminar that is starting at 12:15.

Seminar

Lab topics

• Introduction

  Introduction to lab environment, accounts setup, working with virtual systems in the lab, review of the Linux system basics

  ---

• network sniffing

  Preparation for lab:

  Students should find what programs in unix/linux system can be used for monitoring network traffic and sniffing packets off the network.

  Tasks to do during the lab:

  Using network sniffers you should capture packets allowing you to see how ping, traceroute and mtr programs work. Make screenshots, create report, explain how it works, show examples. Detailed tasks:

  • Check ping, traceroute, mtr -- what kind of packets do they send to discover the intermediate routers? Is it ICMP, TCP, UDP? What features they use to find routers?
  • Log in to some FTP site, for example ftp.icm.edu.pl or ftp.pwr.wroc.pl using "anonymous" acount (provide your email or some random data for the password) -- find out how this password information is sent over the network, use wireshark filters to get just the interesting packets, not all the rubbish that you can listen to on the network
  • Access a password protected WWW site: http://dream.ict.pwr.wroc.pl/ssn/secure/ -- use username "ssn" and password "Password". You may of course use a different password and see it fail. Observe how this user/pass information is sent from the web browser to the server.

  ---

• network scanning

  1. The lab room local network (e.g. 156.17.40/24 or 156.17.40.0/27) should be scanned for all services such as HTTP, HTTPS, SSH, SMTP, FTP as well as all interactive login services (telnet, rlogin, rsh and similar)

  2. The list obtained in (1) should be used to further investigate all servers found, in order to identify versions of software running particular services. Those considered "harmful" or "insecure" should be reported – i.e. a server accessible from network and running an obsolete, insecure version of service program. Consult google, computer security lists and other archives to find out which versions of servers should be considered insecure.

  The script you create in this task will be assessed from a viewpoint of a system administrator, whose task is to keep the network secure and find all user-created servers. It is not enough to run the script just once (some servers may be temporarily switched off and will not be reported by scanning), but rather run it from time to time to report all suspicious servers in a local network.

  3. All previously found mail servers should be tested whether they are "closed" or "open relay". AN open relay server is the one that allows any non-local user to send emails addressed to anybody in the world, i.e. allowing anybody to send spam to others. A closed server will allow only local users to send emails to the world, and "any" users from the world to send mail to local users, but not to just anybody.

  For testing purposes, a following cSMTP onversation may be used:

    220 cyber.ict.pwr.wroc.pl ESMTP Sendmail 8.9.3 Mon, 17 Apr 2000 21:00:00 +0200 (MET DST)
    ehlo okapi.ict.pwr.wroc.pl
    250-cyber.ict.pwr.wroc.pl Hello ts@okapi [156.17.42.30], pleased to meet you
    mail from: <santa@heaven.org>
    250 <santa@heaven.org>... Sender ok
    rcpt to: <xx@cyber.ict.pwr.wroc.pl>
    250 <xx@cyber.ict.pwr.wroc.pl>... Recipient ok
    rcpt to: <zxcvbnm@heaven.org>
    550 <zxcvbnm@heaven.org>... User not local, go away
  

  The 550 error in the above example means, that the server is not an open relay (it rejected mail being relayed through it). If the attempt to send non-local mail resulted in "250 ..." or "252 ..." answer code (the same as for the preceding xx@cyber.ict.pwr.wroc.pl recipient address), the server would be declared to be an open relay.

  Tools that may come handy for the task: netcat, chat (from the ppp/pppd package), awk, perl, sed, etc.

  ---

• SSL and certificates

  SSL resources
  Lecture slides
  

  Lab preparation:

  ...

  Create CA, create server certificate, sign it with CA,install apache to use this certificate

  Create user certificates, configure server to use them to allow access to some directories based on identity of a client, checked by the client certificate. Provide also some common directory for all clients signing with certificates issued by your CA.

  Tasks from the whiteboard

  ---

• Reverse engineering

  Download a binary application from this directory. Add execution bit (chmod a+x keygen-en) and run it. If you give user number "0" and password "12345678" it will say that "you passed". If user number is other than zero, the password is not so simple :-)

  Your task is to find out what password should be entered if you give your student ID number as user ID.

  Use the gnu debugger (gdb) or other tools (maybe some code de-compilers?) to find out what this program does, how the password is generated. The program does not have a symbol table, so in order to start it under the debugger, set breakpoint to:

  	break __libc_start_main
  

  then

  	run
  

  to start the program and catch it when it enters the main function. Another useful gdb command to use:

  	set disassemble-next-line on
  

  This will automatically disassemble few next lines every time the gdb stops program. At any time you may also issue disassemble command to see disassembled code of the sorrounding area, and use commands such as si (step instruction) or ni (next instruction) to do step-by-step program execution to find how it works.

  Also, remember about the p or print commands to inspect variables and registers, and x command to inspect the memory at a given address.