Currently (spring 2007), I am taking Network Security (CSCD 434/539) at EWU. This is my page for the class. Please note that the rest of my site (except, possibly, other pages linked from the body of this one) is not to be considered an extension of it.
Computer security is the field dealing with ensuring the safety, integrity, and availability of computer systems and networks for users and their data. Safety and integrity are vital; availability may be more or less critical depending on how important the provided service is.
(At the end of the quarter)
I am Daniel Dawson, a graduate student at EWU. The following is a summary of my background in computer science:
The following are security measures I use on my home system. Naturally, I learned all of them from somewhere, but I have no links to give for any of those sources.
This is a clever technique for protecting against port scanning. A daemon listens at the link layer for packets from a single host targetting a specific sequence of ports (which, because the daemon is listening at the link layer, the firewall can do anything with those packets, such as dropping them). If it receives the correct sequence within a given time limit, another port is unblocked (often for a limited time and for the knocking host only). In my case, I am running SSH on a non-standard, blocked port; I set up knockd for a two-port knock with a 30-second timeout, opening the SSH port for 45 seconds.
Port knocking is perhaps a weak measure, but when applied on top of already good security, I believe it does strengthen that security. (For instance, running SSH on a non-standard port is a good idea with or without port knocking.) Vulnerabilities in the knockd are possible, since it has to read packets. But I expect they are less likely, due to the relative simplicity of the code.
I don't claim to use the best technique(s) for generating passwords, but I have always, since the very first time I had to choose a password, and when given the choice, chosen passwords consisting of a meaningless quasi-random string of letters (and usually a number or two, and sometimes non-alphanumerics). I owe this to my earliest experience with BBSs, in which I observed the system giving me such a password. So, I suppose it was largely luck that I picked up such a habit early on. But I'm glad I did.
This only works for me because I happen to have a knack for
remembering meaningless strings of letters and numbers (albeit short
ones). There are mnemonics for creating passwords with similar
characteristics, though, such as remembering a phrase that means
something only to you and using the initial character of each word (e.g.
"to be or not to be, that is the question" becomes
"tbontbtitq"), taking a phrase and replacing some of the
letters by similar-looking numbers and symbols ("secret password" becomes
"53cr3t p@55w0rd"), etc. Ferguson and Schneier, in their
book Practical
Cryptography, even address the entropic
aspect of various types of passwords.
SYN packet, indicating a request to
open a connection, it responds with an appropriate
SYN-ACK packet, pretending to accept the
request, but with a very small receive window (e.g. 5 bytes).ACK set
(which normally is true until the connection is closed or reset),
it responds by advertising a window size of 0 and acknowledging the
beginning of the remote stream, effectively keeping the remote host
from sending data or believing that it has successfully sent any.
It may periodically send a "keep-alive" probe to make sure the
connection is still valid at the other end (the tarpit in this
case) and not give up for several minutes, consuming entries on its
OS relating to the
socket and TCP session. And if
it tries to open other connections, more memory will be
consumed.FIN) or reset
(RST) the connection; the tarpit ignores both of these
cases, so the remote host will have to time it out.So, if a remote host connects to some tarpitted port in an attempt to talk to a server, what it will see is an apparently open port, but it will get stuck unable to send anything; if it is a script that makes one connection at a time, a tarpit will slow it to a crawl. If, instead, it is a script that is doing a port scan (and is using OS services to try to make connections), useless but tenacious sockets will begin piling up on its side. This is assuming the remote host obeys the specs regarding connection states; otherwise, the tarpit doesn't help. It doesn't really hurt either, though; you use a little extra bandwidth, and that's it.
For the tarpitting host, the view is very different, as the tarpit is stateless. The only resources it consumes are space for its code and a little bandwidth to respond to certain packets.
By the way, certain sources (including the documentation that accompanies the TARPIT patch for Netfilter (Linux's packet filtering software)) claim that if you use it with connection tracking (used for stateful filtering), a TARPIT will consume conntrack entries. Using it with Linux 2.6.19.2, I have observed this not to be the case; it seems that perhaps the conntrack code has been fixed in this regard. It's certainly not the TARPIT patch, which clearly hasn't been updated to work with this version. (How then, you ask, did I get it to work? Well, the problem was easy to track down, since it failed to compile. There happened to be an immensely helpful comment stating where the code in question had been copied from (elsewhere in the kernel). So all I did was track down that source and more or less copy the new version. Lucky me. Not exactly intelligent hacking, and I wasn't sure it would actually work, but it seems to.)
It seems I didn't have much in the way of bookmarks for security-related sites. So, some of this, I found just for this class. Instead of posting links here (in the static content), I give you a feed from del.icio.us. Since I already use the site, it's less work for me, and we all benefit from the metadata, search, and cross-referencing features. Of course, depending on your browser and its settings, you may be able to see that list right below here, which will be automatically updated whenever I post appropriate links on del.icio.us, without my having to touch this site.
Browse these links on del.icio.us
Last updated: Tue Oct 02, 2007
E-mail (anti-spam mangled): ddawson at icehouse dot net
|
|
|
Preprocessed with 
