CS78 Secure Server Installation & Administration
TCP/IP paper - "Intro to the IP Protocols"
Sockets: socket programming
stunnel - tunnel w/ssl
process UID control
tunnels & VPNs
This Website (http://homepage.smc.edu/morgan_david/cs78/) will be used to communicate with you. Announcements, grade reports, and assignments will be posted here. The site can be viewed from an internet-connected browser anywhere. You are responsible for awareness of the information posted here.
Thank you - for taking this course. It looks like cybersecurity will remain of relevant interest and concern to us as individuals and society for the indefinite future. You understand it better than 95% of the population. I hope you will be able to use your knowledge to your benefit. (8/13)
Other classes I teach - are known to you from the main website front page. There, you can see the class-specific pages from recent semesters for a fully concrete idea what they are.
CS40 - Operating Systems (3hr credit, next offered Spring 2016)
CS41 - Linux Workstation Administration (3hr credit, next offered Fall 2015)
CS70 - Network Fundamentals and Architecture TCP/IP networking (3hr credit, next offered Fall 2015)
CS75 - Network Protocols further depth and variety beyond CS70 (2hr credit, next offering unscheduled but under discussion for Spring 2016)
I also teach related courses at UCLA Extension including a new one on shells and shell scripting (UCLA's fall quarter, September) and a "linux intermediate" which amounts to system administration topics that go beyond my SMC CS41 curriculum.. They are more costly than those of community college, but are public and available. (8/13)
Grades up-to-date please check - includes the tunnels assignment. Current and complete as of 5pm today. Last call for you to let me know about anomalies/omissions etc while we can still maybe do something about them. (8/13)
Grades amended - with the several assignments you called to my attention individually in class last night. Also included is the in-class exercise from last night. These are my current best-effort set of grades, all that I have, as of mid-day today Wednesday. Please call other anomalies/omissions etc to my attention today or tomorrow. (8/12)
Grades - posted. Includes s-des and arpspoof exercises. Please check your grades and call any anomalies to my attention. (8/11)
Test - latter part of class at our final meeting August 13. Closed book. Please bring a scantron form 882. (8/11)
UCLA data breach(es) (8/9)
Don't be happy, worry - an
article I ran across today. The gist:
Sputnik is back - as of this evening. (8/6)
Test - probable, latter half of final class meeting August 13. (8/6)
Remaining topics I wish to cover - encrypted channels (tunnels/vpns), encrypted storage, key exchange. (8/6)
Application security - flaws or exploitable characteristics particular to
specific applications. You can optionally reproduce and observe the flaws
shown in the lecture slides.
The slides are at the link in the course
outline entitled "Software security".
"With heartbleed, what data do I get," I was asked after class yesterday. You get whatever data is neighbor in RAM to the heartbeat payload. The payload originates from the client; the server does a write/read depositing it in memory then reading it back to boomerang it to the client. But he reads back too much. What data lies adjacent to the payload? Whatever was placed there recently, by whoever placed it. It's a multiprogramming system and we don't know. The data coming back is unpredictable and uncontrollable by the attacker. In the slide below, I used the web form just to be able to get some known-quantity thing into the server's memory. Thereafter, I ran the exploit about 10 times, scrutinizing what came back trying to spot "EAZZZ...ZY2SEE..." The first 9 times it wasn't there, the 10th time, bingo, there it is (below). A real-world web form might have solicited something sensitive, like a credit card number or credential of some kind. Web forms are, after all, how you supply your card number to an online merchant. Not just apache, as here, but any software that uses memory (which doesn't?) may place its data in heartbleed's path. So session and private keys, if any software ever used them, might show up.
Please do not conclude from this slide that I deliberately constructed what you see. I hoped for what you see. I was on a fishing expedition and got lucky, eventually. But those trophy catch photos never tell that the fisherman labored in vain since sunrise before he finally hooked the big one.
"'Come on, fish,' he said. But the fish did not come...'Fish,' he said softly, aloud, 'I'll stay with you until I am dead.'" The Old Man and the Sea, Ernest Hemingway. (8/4)
Grades - posted. Includes gpg signing exercise (who signed what). (8/4)
Binary-to-text encoding - is why gpg keys are so funny looking! The keys themselves have arbitrary binary content. So you can't print them. Nor use them with protocols that don't handle what you can't print (email). For such problems, there are a number of encoding scheme solutions to map arbitrary binary bytes into a subset of bytes that are all printable. gpg uses one called Radix-64 (almost identical, better known as, base64). From a text or stream, it divides every 3 consecutive bytes (24 bits) into 4 units (6 bits apiece). Printing 8-bit units would require 256 distinct characters whereas printing 6-bit units would require 64. We don't have 256 characters. We have about 100. So while we don't have enough to go around for 256 values, we can accommodate 64 of them: with conversion we can print anything. (8/3)
Authentication without confidentiality - below is one of our slides. What's the stuff in the red box?
Note there is no encryption of the data, the purpose is not to obscure the data but to make certain it came from Fedora. (8/2)
Grades - posted. Includes manual RSA (personal decrypt) and encryption modes. (7/30)
Jet Propulsion Laboratory (JPL) internship opportunity. (7/30)
Three purposes of cryptography - 1) confidentiality, 2) sender authenticity, 3) data integrity. (7/30)
Grades - posted. Includes firewalls and one-time pad. (7/28)
DETER experiment on arp spoofing, will be assigned shortly after I
have a chance to test it. Then I will post a "green light" plus
due date message here.
student number" assignments:
Come 'n get it - your individual encrypted files are in sputnik's /home/common. If your last name is smith, your file is named ciphermessage-smith. Copy it into your home directory and decrypt it. Your tool for that can be the decr script located in /home/public. You can copy that over into your home directory too (or run it in place if you want). The plaintext I encrypted for you was just a single 3-letter combination, all uppercase letters randomly chosen. I made it short so as not take too much processing time. If you did not want to use the decr script, you could take the 3 numbers in your file and decrypt each individually and manually in bc with your private key like we did in class. But the script does that in a loop and is more automatic and labor-saving. You get credit for revealing to me what the 3-letter word is that I encrypted for you. (7/24)
Modified utility programs encr and decr - are now in sputnik's /home/public. I worked on them a little today, so that they would have default values making most of their arguments optional. Their calling conventions are:
encr <input file> [<RSA's e>] [<RSA's n>] [<output file>]
decr [<input file>] [<RSA's d>] [<RSA's n>]
(arguments in square brackets are optional). If you don't give encr an output file, or don't give decr and input file, by default they will use "ciphermessage". If you don't give encr a public key, or don't give decr a private one, encr uses 1943-and-7031 and decr uses 5783-and-7031 (which match as members of a working pair!). But if you want to supply your own filename or keys please do, per the calling conventions. (7/24)
Upcoming assignment - "GNUPrivacyGuard" link in course outline section 9. Preview it. (7/23)
Manual brute force solution by Nathan Cooper below. (7/21)
Grades - posted. Includes password work (hashcat screenshot and Mandylion spreadsheet) and message digests.. (7/20)
SonicWALL is a product in the security appliance category. Yoni Netkin in our class has one and we talked about it after class last night. To add practical real-world touch he offered to bring it in. He wants me to show and talk about it. I want him to be the one to do that. He will bring it Tuesday and we can decide what to do. I may take it home to look at it before Thursday and talk about it then. I don't want to spend time at the expense of other topics so if we talk about it the talk has to be planned and focused. If any of you have particular experience with a SonicWALL or other such device, and any suggestions, I'm open. (7/17)
Interesting list of privacy tools. (7/17)
Midterm exam - this course has no midterm exam. Plough your energy into the homework assignments. The homework is the thing. (7/14)
force password attack for you to perform-
My password is one of the English language's thirty-seven 2-letter words, which are:
ad ah am an as at aw ax ay
it's in lowercase. What is my password?
Get a program that calculates md5 sums ("md5sum" command in linux, google for one in Windows, I like HashCalc). Be a brute force algorithm, by doing what it would do. Student who reveals/explains at the next class meeting gets my never ending admiration. Sometimes I grade on admiration.
By the way, how much easier did
confining passwords to English make the brute force cracking job? You have
thirty-seven possible passwords to work through. With how many would you
have been faced if all 2-letter combinations, English or not, randomly,
had been allowed? (7/14)
Grades - posted. Includes DETER road test. (7/14)
Keys Under Doormats - paper published Tuesday by co-authors including the highest technical minds in computer security on the risks of mandating backdoors in encryption products. (7/10)
Going Dark: Encryption, Technology, and the Balance Between Public Safety and Privacy - Senate judiciary's Wednesday committee hearing.concerning mandating backdoors in encryption products. (7/10)
DETER ns-file fixed - with apologies to those of you who got the "bad" version I believe that the link to it now gives you the good one. (7/10)
Grades - posted. Includes uid.txt process experiment but not DETER road test. (7/9)
Assignment 5 - see Course outline
topic 5, homework column. (Yes, no assignment 4 has been given.) (9/26)
You should use a virtual machine as platform
for upcoming password cracking assignment - it's in a file named
kali-2015.zip. I've put copies in two places.
USB devices come in different classes-- storage, keyboard, microphone etc. The thing that differentiates them is software that they contain. The devices are reprogrammable; this software can be subverted. The vulnerability dubbed "Bad USB" was announced by researchers in 2014." (7/7)
Happy Independence Day - keep secure (from 1962 junior high school US history teacher Mrs. Mary Mareneck) (7/4)
yubikey device - comes from yubico. Google established a business relationship with yubico last fall for implementing 2-factor authentication using yubikeys. It uses a particular yubico product called Fido U2F security key. The FIDO ("fast identity online") alliance is an industry group promoting 2-factor authentication. (7/1)
DETER accounts were created - an advisory email message should be generated to each of you informing you of your account credentials and requiring you to make a minor change in your profile. It should be self-explanatory. The message will go to your smc email account. (7/2)
Remote unix accounts have been created - see the link below entitled "Remote Unix system account." Note the telephone-number derived password. Test your ability to log in. (6/30)
Grades - for the first (trivial, and minor) assignment have been posted. Please see the link at left entitled "Grade reports." (6/30)
Assignment 2 - su, suid, sudo and process UID control
Bruce Schneier is speaking in Tel Aviv today. I hope he brought a clean shirt. (6/24)
Passwords we assigned tonight while setting up our scratch laptop:
Assignment 1 - see/do the homework column of section 1 of the course outline (6/23)
Practicum - a couple of the better students from my Spring semester classes are now taking this one and expressed specific interest in practice as opposed to theory. Specifically, "I run a server and I want to learn what I need to do to it to give it better security." This course has a rich curriculum, but it isn't primarily a vocational how-to. However I think it would be fun to spend a little time on the side taking a virgin machine, installing an OS on it from scratch with security considerations in mind, and in following weeks, as we study them, looking at some of the things we could do to harden it. It will be unstructured. I have an available laptop and will install Fedora 17 on it as demonstration. (Things that may come up: setup passwords, bootloader password, disk encryption, streamlined service set, firewall, 2-factor authentication, TPM.)
Opportunity - I'm happy to tell you that as a class we have the fortunate invitation to use a network testbed facility operated by USC/ISI called DETER. I will request individual DETER accounts for you; when they are created you will get an email message with info and credentials. In class I will describe DETER and how we will use it. This will come some weeks into the semester. In the meantime, you can explore the links under the heading "DETER net testbed" at left if you like.
assignments - there will probably be 4:
Introductory - this class, this
This is a traditional on-ground class. I plan to use several supplementary, online vehicles to deliver it:
- a static website
More information about these will follow. As for what's on this website, there is more material on it than we will necessarily use. In particular the assignments shown at right are not specifically assigned to you merely due to their presence there. When I want you to perform one of them, you can be sure I will post an explicit instruction here, formally assigning exactly what I want you to do, simlar to the one I already posted above.
The primary "home" of the course is this website. Assignments and announcements will be posted here. I suggest you check regularly.
Operating system platform for studying computer security - doesn't matter! Security is operating-system-agnostic. Individual operating systems have their particular security characteristics and vulnerabilities but broad security concerns and topics span platforms and devices. For example, password strength and cracking are the same no matter where a password might be implemented. The implementation of a password system will differ between two OS's but a strong or weak password is strong or weak everywhere, intrinsically. Having said that, I am knowledgeable about linux and will tend to use it as the primary operating system environment where work in this class will be done. There will be some use of Windows. Knowledge of linux will be a big help to you, however exercises are usually designed to give you the commands you are supposed to run, in order to reveal whatever lesson I'm trying to convey. So, you don't have to know linux commands deeply because I'm going to give you the ones you need when you need them.
Categories of security to be
- local security
An example of local security is physical access-- whether a machine sits behind locked doors or not. Another is password strength. Those are considerations independent of the network, if any. An example of application security is a flaw in code, for example a stack overflow opportunity due to the way the code is written. This permits some side-effect behavior/result unintended by the programmer, classically a way to gain the privileges of the root/administrator/supervisor/superuser found in most operating systems. That's a shortcoming of the application. This problem too, like physical security or password strength, is unrelated to the network, if any. And "routine maintenance" practices to detect or prevent problems (security hardening, anti-virus software), detect them (intrusion detection, disk analysis), and recover from them (backup regimens, log analysis), are not specific to networks either. The network attacks in the news are dramatic and sexy, but though computer security encompasses concern for network security, my point is that it goes well beyond it. For a list of specific topics under these categories see the link entitled "Course description" under the Administrativa heading at upper left.
The class plan is to devote some initial time to some introductory concepts and "review" of important local security foundations having to do with resource/file access control-- users, processes, permissions. These are aspects of system administration (if you took my linux class at SMC this is in part review). But they are security aspects of the operating system environment. Indeed user authentication and resulting file access control are a cornerstone of system security. We simply could not omit them from a security class. Thereafter we'll cover some foundations of networking as we need to know them. After that comes all the other stuff. The "Course description" and the links on this page give you pretty good hints what we'll study.
I may post certain lectures, which I expect you to listen to. They consist of narrated powerpoint slides. You need an up-to-date browser and Flash installed. The lectures are fairly heavy, multi-megabyte files. Be patient while they load. If you have a dial-up connection go listen to them elsewhere (e.g., SMC computer lab would do). After they load they will play. You must click to advance slide-to-slide.
My assumptions about you -
My assumptions about your equipment-
Thanks for coming. I think we'll have fun.
you get the 'L'?
firewall construction (DETER)
Bastille - hardening
Arp spoofing (DETER)
Computer forensics (DETER)
Tunnels and vpns (DETER)