Jim's Depositorythis code is not yet written |
help |
femtoblogger has reached that odd state for software. It works well enough that I am happy using it. There are rough edges, but not rough enough that I will fix them.
The only thing I have changed recently is to add a meta robots tag to suggest the aggregate pages, like the front page and archive months, not be indexed. That should help keep the clicks on target. I already had robot tags to deter indexing of all the non-content pages.
There remain two rough points:
I suppose since femtoblogger has become stable it is time to move it into a public subversion repository.
A Debian administrator might want to install…
Think about running these regularly to catch your basic root kitter.
You could cron them, but I prefer to run them manually, since I know I'd pull the cron entry if I rooted you.
I suppose you could do a forced reinstall before running for a little extra comfort.
comment by jim, 8 days ago
I think a better tool would be one that used a central repository with a copy of each package and called on the observed machine to generate on the fly signatures of files with a random seed. A truly nasty rooter could still thwart that by faking things in either the C runtime library or the appropriate system calls.
I write from the end of June, 2008 having just completed a quarterly spam analysis and adjustment. Following is a brief description of the mail community, the incoming mail stream, how I process it, and the results.
The Mail Community
The Incoming Mail Stream
The Process
The Results
Maintenance
The bogofilter works best if it is trained regularly to follow spam trends. I have in the past manually sorted thousands of messages into good and bad piles for training, but that is mind numbing. For ongoing training I do the following:
Results
The end result is I spend dozens of man hours per year to stop 250,000 spam. I'd just hire google to front end filter our mail for $3/address/year, but the security policy won't allow that.
comment by jim, 13 days ago
Going forward: I will have to drop dcc. Their licensing is no longer free enough to be distributed by Debian. That will slow more messages, but in practice anything dcc catches is also caught by spamassassin.
I'd like to add an adaptive whitelist out front to prevent false positives and give me a stream of known good messages for training the bogofilter. I haven't found one I like yet, but I keep looking. Maybe I'll have to write it.
comment by jim, 13 days ago
An extra note on bogofilter: Bogofilter is built with a single user in mind. I'm sure it works better when it has a single user's mail to think about and can rely on the human to tag the false positives and negatives.
In a 150 user common filter you can rely on exactly 0 of them to report their miscategorized spam. If you try to force them to comply you will find that 10% of them do it backwards and pollute your statistics so badly you have to erase everything and start again.
That said, it works quite well and is speedy and doesn't rely on external network servers so it makes a good first line of defense.
This morning was 53°F in the cabin. When I awoke I didn't need to crawl out into the cold to open the curtains and check the local weather because I could use my iPhone to access my server in St. Louis, that displays data from my server in Reston that de-NATs the server in Wisconsin so I can download live video from the webcam looking out from the front of the cabin.
A different sort of geek might have built a heater.
I have a server which contains a bunch of virtual machines. These machines are continually harassed by script kiddies. I use Fail2ban to keep the trolling to a minimum.
Things that needed changing...
/etc/fail2ban/actions.d/iptables.conf... the actionstart and actionstop need to also put the chains into the FORWARD rule....
# Option: fwstart
# Notes.: command executed once at the start of Fail2Ban.
# Values: CMD
#
actionstart = iptables -N fail2ban-<name>
iptables -A fail2ban-<name> -j RETURN
iptables -I INPUT -p <protocol> --dport <port> -j fail2ban-<name>
iptables -I FORWARD -p <protocol> --dport <port> -j fail2ban-<name>
# Option: fwend
# Notes.: command executed once at the end of Fail2Ban
# Values: CMD
#
actionstop = iptables -D INPUT -p <protocol> --dport <port> -j fail2ban-<name>
iptables -D FORWARD -p <protocol> --dport <port> -j fail2ban-<name>
iptables -F fail2ban-<name>
iptables -X fail2ban-<name>
comment by jim, 7 weeks ago
Things you will want to know if you have to replace your OpenVPN certificates, because say you got caught in the Debian key entropy problem.
I had to resort to grepping syslog and dropping firewall blocks on people trying old certificates. I used another script watching my http logs to unblock people who had created new certificates. "TLS Error: TLS key negotiation failed to occur within 60 seconds" is a good bit to select IPs for blocking.
You know you have too many clients connected if you see "MULTI: new incoming connection would exceed maximum number of clients" in the syslog.
I've added a few features today.
And now 4 days later.
comment by jim, 2 months ago
comment by jim, 2 months ago
I have made contact with the robots. We should all be afraid. Thus far the robots have attempted to add these comments:
I suppose some filtering software will now block my site because it talks about sex.
I noticed that the Opera browser rocketed up to 38.4% of my hits. A quick dig of the logs shows that I am being drilled by bots that look to be trying to create link spam and masquerade as Opera browsers.
I suppose eventually they will have a human help them through the captcha and succeed. I have changed things about so untrusted users will get rel=nofollow tags on all their links. Maybe that will make them lose interest and go away.
I should probably make an RSS feed for comments while I'm at is so I notice when they get through the defenses.
While updating my systems monitoring I discovered Munin today. Munin captures a wide variety of system information and dumps it into RRD files to ultimately graph it at a central location.
The user interface doesn't communicate problems well, but it provides the underlying data for you to answer those nagging questions that come up, like "When did our email traffic get so high?" or "Has that disk always run that hot?"
And my install notes:
Sample bits of /etc/munin/plugin-conf.d/munin-node:
[hddtemp_smartctl]
user root
env.drives sda
env.type_sda ata
[smart_sd*] user root env.smartargs -H -c -l error -l selftest -l selective -d ata anonymous comment, 3 weeks ago
If you want to collect apache statistics with Munin you need to enable extended server status in apache. ExtendedStatus OnIf your web server does not bind to localhost (127.0.0.1), you need to define the server status URL in your /etc/munin/plugin-conf.d/munin-node config file. [apache_*] anonymous comment, 3 weeks ago
If you run sendmail as your mail server munin has 3 plugins that are in the base Debian install. Link all 3 into your /etc/munin/plugins directory. One, sendmail_mailqueue will work out of the box. The other two depend on sendmail stats files that do not get created in a base Debian install. To enable stats logging you must manually create the stats files.
Once these files have been created, with sendmail write permission, sendmail will start logging to them. Gotta love sendmail, "If you create the log file for me, I will write to it." You can test your mail statistics file creation manually with the mailstats command.
After decades of backing up with dump I no longer do it. I suppose I got in the habit back in the days of tapes and just stayed through the disk years.
rsync is far better. I should have switched years ago.
The first thing to do is to read about the rsync --link-dest option. It lets you use hard links to share the contents of files across days of your backups.
The second thing to do is to decide on your backup strategy. For many machines I just keep 7 days of backups, it makes things easy. There is a backup for each day of the week and they overwrite when it wraps. For other applications where I have to go further back I rename directories, much like logrotate would.
The third thing to think about is what happens if your ssh key or rsync password is compromised. If you are running backups from cron, then there will be a machine readable key on your machine somehow. This may or may not be a danger depending how you have things secured. In my setups if you could get the key you could have gotten the data anyway. (Remember that your backup archive machine needs to be at least as secure as the live machine.)
Enough talking, more sample code:
Scenario #1: Many big machines, lots of bits to push, on the same secure network. We want to go fast. All the machines have different security policies.
I use push in this situation. There is a dedicated backup machine to receive and hold the bits. Only two trusted people have access to this machine. The backup machine runs an rsync daemon with a module for each host that lets the host write backups (only in its host specific area, write only). On each host there is a root cron job with the rsync password embedded to run the backup.
Sample backup script... cron these, offset their run times so keep contention down....
#!/bin/sh
HOST=`hostname`
export RSYNC_PASSWORD=1234567890abcdef12345678890abcdef
DAY=`date +%a | tr '[A-Z]' '[a-z]'`
case $DAY in
sun ) PDAY=sat ;;
mon ) PDAY=sun ;;
tue ) PDAY=mon ;;
wed ) PDAY=tue ;;
thu ) PDAY=wed ;;
fri ) PDAY=thu ;;
sat ) PDAY=fri ;;
esac
OPTS="-aqH --link-dest=/$PDAY/ --no-devices --no-specials --exclude=/proc/ --exclude=/sys/ --exclude=/dev/ --exclude=/tmp/ --delete"
time rsync $OPTS / $HOST@warehouse.federated.com::$HOST/$DAY
Sample module from rsyncd.conf...
[nexus]
auth users = nexus
secrets file = /etc/rsyncd.secrets
use chroot = yes
path = /warehouse/nexus
numeric ids = yes
list = no
read only = no
write only = yes
uid = 0
gid = 0
hosts allow = 111.222.33.44
hosts deny = *
Scenario #2: Offsite backup of Virtual Private Server
I have a machine that lives in a hosting facility. I have broken my first rule of service providers. They are not close enough for me to pop over and wrap my hands around someone if there is a problem, so I content myself with a full backup and the ability to be up and running at a new provider in 60 minutes if needed. I don't want any credentials sitting on a machine at the hosting facility, so I do a pull in this situation. I also use ssh to protect my data in transit, but use the rsync daemon and modules on the far side to get better control, for instance to make it read only.
Cron job on my backup server (pardon the db_client related noise, that machine has to run dropbear instead of a more common ssh. But do notice that I have a --rsh to force a tunnel and a :: to use daemon mode and modules.)
#!/bin/bash
function saveone () { TAG=$1 SRC=$2 rm -rf vhosts/$TAG.9 [ -d vhosts/$TAG.8 ] && mv vhosts/$TAG.8 vhosts/$TAG.9 [ -d vhosts/$TAG.7 ] && mv vhosts/$TAG.7 vhosts/$TAG.8 [ -d vhosts/$TAG.6 ] && mv vhosts/$TAG.6 vhosts/$TAG.7 [ -d vhosts/$TAG.5 ] && mv vhosts/$TAG.5 vhosts/$TAG.6 [ -d vhosts/$TAG.4 ] && mv vhosts/$TAG.4 vhosts/$TAG.5 [ -d vhosts/$TAG.3 ] && mv vhosts/$TAG.3 vhosts/$TAG.4 [ -d vhosts/$TAG.2 ] && mv vhosts/$TAG.2 vhosts/$TAG.3 [ -d vhosts/$TAG.1 ] && mv vhosts/$TAG.1 vhosts/$TAG.2 [ -d vhosts/$TAG.0 ] && mv vhosts/$TAG.0 vhosts/$TAG.1 [ -d vhosts/$TAG ] && mv vhosts/$TAG vhosts/$TAG.0 RSYNC_PASSWORD=a8e261e7bac90138087f770caa5fea5b export RSYNC_PASSWORD OPTS="-aqHz --bwlimit=400 --exclude lost+found --exclude /tmp --exclude /var/tmp --exclude /proc --exclude /sys --no-devices --no-specials --delete" rsync $OPTS --rsh "dbclient -l root -i .ssh/id_archivist.db" --link-dest=/home/archivist/vhosts/$TAG.0/ $SRC /home/archivist/vhosts/$TAG/ > ~/$TAG.log } saveone studt-net rhth.lunarware.com::rhth
~root/.ssh/authorized_keys on the virtual private server (Look at the bit in front of the ssh-dss, it restricts what that key can do, in particular it makes it only able to run the rsync daemon.)
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="/rsync --server --daemon ." ssh-dss adfeadfaefasdfefeI_DELETED_MY_KEY_HEREadfasdfefadfae backups rsyncd.conf
[machine]
auth users = archivist
secrets file = /etc/rsyncd.secrets
path = /
numeric ids = yes
list = no
read only = yes
write only = no
uid = 0
gid = 0
There you have it. Reasonably safe backups. There is room for improvement, for instance, rather than coming straight into root with the restricted command it could be a different account and use "super" to run the command, and it should check the source IP and only work from the backup machine.
The femtoblogger software is being written by Jim Studt. The content of this page is provided by anonymous individuals. If you believe something on this page is innapropriate contact Jim Studt. |
Contributeloginlogout post create account (12 seconds) recent comments FilterSearchBrowsers
Archives
|