Mar 17, 2016
You're getting old if you consider sleeping until 0900 'sleeping in'.
When configuring a firewall with IPTables you have to specify the protocol before the port number(s) in each command. Do this:
iptables -A INPUT -s 22.214.171.124 -p tcp --dport 22 -j ACCEPT
and not this
iptables -A INPUT -s 126.96.36.199 --dport 22 -p tcp -j ACCEPT
If you don't, you'll see error messages to the effect of "Unknown arg '--dport'"
When writing Snort rules, there are a few things to keep in mind. First of all, rules come in two parts: the IP address specs and the packet analysis specs. They're easy to tell apart: The packet analysis specs are inside parenthesis. Second, always match paired characters - double-quotes and parenthesis come to mind. Keywords and their arguments are separated by colons: keyword:argument. Keywords and keyword:argument pairs are always separated from one another by semicolons: keyword1:argument1; keyword2:argument2. The last keyword in the packet spec must always be followed by a semicolon: keyword:argument;) If you're going to be using the new threshold functionality (which causes rules to trigger after a certain number fo hits), make sure that you put a sid:1000000 directive in your rule, otherwise Snort will error out with an "FATAL ERROR: Rule-Threshold-Parse: could not create a threshold object -- only one per sid, sid = 0" message. That means that it assigned the bad rule a sid of 0, but if you're running a set of rules already that means the very first rule in the set.. and it already has a threshold on it. It'll try to apply the threshold on your rule to the very first in the set, and die because it can't do that. So give your rule a sid value somewhere over one million to prevent this conflict.
If you're using the intrusion detection system Snort, logging everything to a MySQL database, and using ACID to analyze the results and figure out what's going on inside your network, you have the ability to archive alerts to a second database, usually called snort_archive. After a certain period of time you'll start running into failed moves and get the error message "Duplicate alert" all the time. This means that your archive database is full and can't store any more archived alerts. Use the mysqldump utility to make a backup copy of the snort_archive database and then either delete and recreate the database from the SQL scripts that come with Snort and ACID, or just delete the contents of the tables (I prefer the former due to all the stuff that ACID puts into its own reference tables, which I don't much feel like deleting, even accidentally) and you'll be able to archive alerts normally once more.
When trying to get one of those cheap pencams (digital cameras that look like fat, flat tongue depressors) working on a Linux system, try the stv680 module first. Then check the output of the dmesg command to see if you get a message like
stv680.c: [stv680_probe:1519] STV(i): STV0680 camera found.
stv680.c: [stv680_probe:1547] STV(i): registered new video device: video0"
That means it worked. If you get stuff output to your terminal from the command cat /dev/video then it really did work.
When you upgrade the kernel on a Redhat Linux machine by using RPM packages, don't use the rpm -Fvh /path/to/upgrade.rpm command because that removes the old kernel. If the new package you are installing is corrupt you're screwed - break out the rescue disk. Use the command rpm -i /path/to/upgrade.rpm because it leaves the old one in place. When you reboot pick the new kernel (and set it to the default kernel to boot, if everything works out for you).
SSH and OpenSSH support public key authentication: Using a cryptographic certificate to let a user log into a system instead of having to type a password every time. This makes it much safer to share accounts among members of a team because everyone on the team can use a copy of the authentication credentials, and as long as the private key stays safe, the accounts can't be compromised. Also, the account in question can be locked out (meaning that the password is set to a value which disables logging into the account), so there aren't any passwords to sniff. This is done with a pair of keys, a public key and a private key. The user(s) have a private key protected by a passphrase; the public key goes on each system the user(s) want to log into.
The first step is to generate the keypair:
ssh-keygen -b 2048 -t rsa -f ~/.ssh/id_rsa -C "Some comment here"
This command creates the SSH public/private keypair with a keysize of 2,048 bits (I like to use large keys), the key is used for RSA authentication, it will go into the file ~/.ssh/id_rsa, and you can give it a comment to remind you what it's used for. The public key then needs to be placed on the systems that you want to log into. If you're lucky enough to have all of the boxes on-site, you can copy the ~/.ssh/id_rsa.pub file onto a floppy disk or USB pen drive and copy it onto each system as ~/.ssh/authorized_keys2 (if you're using a default install of OpenSSH; check your sshd_config file option AuthorizedKeysFile to see what it should be named). If you're not, you're going to have to find a way to get that public key out there. I'm kind of partial to PGP-encrypted e-mail, but that's just me.
Now try logging in. If everything's gone well you should be able to just ssh firstname.lastname@example.org; you'll be asked for the passphrase by SSH and after you enter it you'll have logged into the other system. To keep from having to enter your passphrase every time you source out (which is kind of the point of public key authentication) check out the manual page for ssh-agent, which will ask for your passphrase only once for a given login session and conveniently forget it when you log out. Always raed the docs: There's a lot of neat stuff that can make life much easier in them if you look.
Some of the problems I had at first: Always make sure you know what the public key is supposed to be named on the remote system. Look in the config file for your ssh daemon; the option usually has the string 'Authorized' in it. Load the ssh daemon config file into a text editor and search for it. It'll tell you what the public key has to be named (as I mentioned earlier, on a standard installation of OpenSSH it has to be called ~/.ssh/authorized_keys2). Otherwise, it won't find the key and you'll drive yourself nuts trying to get it working. Secondly, the user account you're setting up to log into this way needs to have a valid shell (like /bin/bash or /bin/tcsh). It doesn't need to have a valid password (check out man passwd for more information) but it does need a shell, even if you only plan on SFTP'ing into the machine to transfer files. Third, ~/.ssh needs to have access permissions of 0755 and the public key file must have access permissions of 0600. Read the manpage for the chmod utility for more information.
Never date a woman named after a character in a Stephen King story.
Never date a political science major, either.
Don't expect the name of a software package to have anything to do with what that packages actually does. Marketing is far more powerful than logic. Take, for example, Tivoli Storage Manager. From reading the name of the system it could logically be said that it has something to do with managing the storage available on a file server, right?
Wrong. It's a data backup system, not a storage manager.
Someone who is a colleague might not be your friend. Never assume that.
Never assume that someone's your colleague, either. Politeness and propriety go a long, long way. That works in both directions.
It's always a good policy to not say anything that you don't have to. It keeps you from looking stupid.
When you walk into work, your personal life stays outside. It's safer that way.
Sometimes, just sometimes, it really is the firewall's fault.
If you're trying to compile something on a Debian (stable) machine that requires the Xft libraries, but the build dies with an error from pkg-config saying that it can't find the xft.pc file, su over to root and execute the command cd /usr/lib/pkgconfig ; ln -s pangoxft.pc xft.pc. Then try your build again - it should work. I had to do this with Mozilla when compiling with the --with-xft flag.