Posts Tagged admin

LCOD – 4.12.10 – Quick Mysqlreport to e-mail setup

This will be a quick install to setup your server to e-mail you daily mysql reports using the cool mysqlreport application at hackmysql.com

Click to continue reading “LCOD – 4.12.10 – Quick Mysqlreport to e-mail setup”

, , , , , , , ,

No Comments

LCOD – 11.17.09 – Simple page/alert email script

Here’s a quick page script for *nix boxes with mail.
I grabbed the mail / file redirect from

http://theos.in/shell-scripting/send-mail-bash-script/


#!/bin/bash
#Author : dougnaka@gmail.comThis e-mail address is being protected from spam bots, you need JavaScript enabled to view it
#Description : Quick alert/page script, edit EMAIL="" to include a comma separated list of emails to send to
#Usage : page.sh "Short or long message"
if [ "${1}" ]
then
SUBJECT="[ALERT] ${1}"
EMAIL=" someone@example.com"
EMAILMESSAGE="/tmp/`date +%s`-message"
echo "ALERT: at `date`" > ${EMAILMESSAGE}
echo "${1}" >> ${EMAILMESSAGE}
echo "From `hostname`" >> ${EMAILMESSAGE}
mail -s "${SUBJECT}" "${EMAIL}" < ${EMAILMESSAGE}
/bin/rm ${EMAILMESSAGE}
else
echo "Usage: ${0} MESSAGE"
exit 1
fi

, , , ,

No Comments

LCOD – 8.3.08 Get around annoying reboot during fdisk

Do you ever try to reformat / repartition disks and Linux complains the kernel is still using the old table and you have to REBOOT (a sin on any *NIX) to fix this?
The error is “WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.”

This annoys me, what was happening on my Ubuntu 7.10 computer was I had a disk that used to be Linux and I put it into a USB / Firewire enclosure and fdisk’d it and then formatted it, but the automounter sees the partition exists as soon as the kernel rereads the partition table and mounts it. This isn’t safe or a good idea really, so, if you’re going to nuke a disk you should zero out any previous partitions by nuking the master partition table.

THIS IS A POTENTIALLY DANGEROUS OPERATION, YOU PROCEED AT YOUR OWN RISK, I WILL NOT ASSUME LIABILITY FOR LOST DATA OR ANY DAMAGES.

Ok, so make 100% absolutely sure you know the drive letter you’re getting with something like

dmesg | tail

and you’ll see something like

sd 18:0:0:0: [sdf] 488397168 512-byte hardware sectors (250059 MB)
[3010413.606563] sd 18:0:0:0: [sdf] Test WP failed, assume Write Enabled
[3010413.606568] sd 18:0:0:0: [sdf] Assuming drive cache: write through
[3010413.607559] sd 18:0:0:0: [sdf] 488397168 512-byte hardware sectors (250059 MB)
[3010413.608807] sd 18:0:0:0: [sdf] Test WP failed, assume Write Enabled
[3010413.608811] sd 18:0:0:0: [sdf] Assuming drive cache: write through
[3010413.608815] sdf: sdf1 sdf2 < sdf5 >
[3010413.651837] sd 18:0:0:0: [sdf] Attached SCSI disk
[3010413.651880] sd 18:0:0:0: Attached scsi generic sg5 type 0
[3010415.111787] kjournald starting. Commit interval 5 seconds

Now run this (as root), substitude sdf for the device you found. BE WARNED that if Linux didn’t see your disk when you just plugged it in, you may be seeing the detection of an actual file system disk. The best way to tell is to run tail -f /var/log/kern.log (or /var/log/messages or something where the kernel logs, depending on your distribution of Linux)

fdisk -l /dev/sdf

This showed me

Disk /dev/sdf: 250.0 GB, 250059350016 bytes

255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000969e0

Device Boot Start End Blocks Id System
/dev/sdf1 * 1 30024 241167748+ 83 Linux
/dev/sdf2 30025 30401 3028252+ 5 Extended
/dev/sdf5 30025 30401 3028221 82 Linux swap / Solaris

Now I check df -h and see that Ubunu already mounted /dev/sdf1 on /media/disk
So I (as root) unmount it with
umount /dev/sdf1

Now I zero the partition table, THIS CAN TOTALLY MESS UP YOUR DISK IN AN UNRECOVERABLE FASHION, SO BE REALLY REALLY REALLY SURE YOU HAVE THE CORRECT DISK DEVICE NODE. IF YOU ARE UNSURE DO NOT PROCEED.
(More info about the master boot record on the wikipedia article here. )

dd if=/dev/zero of=/dev/sdf bs=512 count=1

Now, proceed with creating the partition(s) and formatting
fdisk /dev/sdf
select n,p,enter,enter,w
mkfs.ext3 /dev/sdf1

, , ,

No Comments

LCOD – 5.17.08 – Locking down ssh access

In light of an increase in ssh attacks , vulnerabilities and scans I am writing this guide to help you keep unwanted people from connecting to your server via SSH.

If you have generated any of your SSH keys on a Debian or Ubuntu system they are likely very vulnerable to guessing, e.g. someone could login to your box if they know the name of one of your users that you allow in via ssh within 30 minutes!
See here for more info: http://metasploit.com/users/hdm/tools/debian-openssl/

This applies to any PAM enabled Linux (or other PAM-enabled *nix like OS)

This guide will walk you through configuring your OpenSSH server to only allow public key authentication and limit that to specific users and groups. Errors in this guide or mistakes or differences in system configurations could lock you out of your own systems, be very careful and do not proceed unless you understand and assume the risk you are taking.

I assume no responsibility for YOUR actions. This guide was tested on Ubuntu 7.10 and fairly recent Gentoo system.

1. Limit SSH access to public/private keys only, deny X11 and TCP forwarding, and deny root ssh access
Step 1 Discussion:
Public/Private keys are not necessarily more secure than passwords, but it’s harder to guess a private key, and if your users put passwords on their keys then an attacker must have or guess 2 things, the key and its password.

The root user is GOD on almost every Linux/*nix system out there, and nobody should be able to login directly as root remotely. In addition it’s a very common user, on almost every Linux/*nix system.

TCP and X11 forwarding is one of the coolest features of an ssh server. Unless you want people to be able to use your ssh server like a full access vpn to your local network, or any other network (bounce their attacks through your server), then you want this disabled. And X11 forwarding is great, but I never run an X11 server on something that is a “production” environment. If something requires an X11 server, like Oracle, then I run vncserver and allow ssh port forwarding so people can connect via ssh. I make sure to have full deny by default firewalls on all machines like this, limiting outbound access.

Step 1 HOWTO
Edit /etc/ssh/sshd_config
Make sure the following lines are not commented out, and don’t say something different

Protocol 2
PermitRootLogin no
UsePAM yes
PasswordAuthentication no
PubkeyAuthentication yes
RSAAuthentication yes
PermitEmptyPasswords no
ChallengeResponseAuthentication no
AllowTcpForwarding no
X11Forwarding no

2. Create an ssh remote users group and add users to it who need remote ssh access
Step 2 Discussion:
The main reason I want to limit who has remote ssh access is because there are frequently system accounts or other automatically created accounts that I don’t want to have to monitor to make sure the installer didn’t just make a new user with a simple password or key. I want to have the default be nobody can ssh, and then I’ll add ssh permissions to users who need it.

Step 2 HOWTO:
Let’s call our remote ssh users list rsshusers, we create it with the command
groupadd rsshusers
Now let’s say we have a user named mikey already setup, let’s add him to our new rsshusers group, with the command
usermod -a -G rsshusers mikey
Do this for every user you want to have ssh in remotely. Note that if you’re used to logging in remotely as root and are going to stop doing that, make sure you user can su to root with the command su.
Login as the user, run
su
Put in your root password, if it accepts it and you are root (run whoami to verify) then you’re good to go. If it fails to let you su and you’re sure you have the password right you may need to be in the wheel group to us (default on FreeBSD and Gentoo).
Back as root run the following command to add your user (again, mikey in this example) to your wheel group.
usermod -a -G wheel mikey

Now we’re going to edit 2 files to limit remote ssh users to the group we made called rsshusers.
First, edit /etc/pam.d/sshd (this was ssh on my Debian/Ubuntu systems)
Add the line
account required pam_access.so

This enables access accounting based on the /etc/security/access.conf file, which is the next one we are going to edit.
On both my Gentoo and Debian system this file had every line commented out.
At the end I added the following lines.

-:ALL EXCEPT root mikey:LOCAL
+ : (rsshusers) : ALL
- : ALL : ALL

Initially I tried to use a group like @rsshusers, however this didn’t seem to work, but () designates explicitly a group.

Restart sshd
Gentoo:
/etc/init.d/sshd restart
Debian/Ubuntu:
/etc/init.d/ssh restart

Now, without closing your root terminal, open a new one and make sure you can ssh in as mikey, and su to root.

Assuming everything went well you could try ssh’ing in as another user whose public key is correctly in place, but who isn’t in the rsshusers group.

Related links:

PAM:

http://devmanual.gentoo.org/tasks-reference/pam/index.html

http://linuxdocs.org/HOWTOs/User-Authentication-HOWTO/x101.html

http://tldp.org/HOWTO/User-Authentication-HOWTO/

http://www.faqs.org/docs/Linux-HOWTO/Secure-Programs-HOWTO.html

OpenSSH:

http://www.openssh.com/

http://thinkhole.org/wp/2006/10/30/five-steps-to-a-more-secure-ssh/

http://www.cyberciti.biz/tips/rhel-centos-linux-install-configure-rssh-shell.html

http://geekzine.org/2007/09/28/easy-sftp-and-chroot-sftp-with-scponly/

Misc:
Securing RedHat

http://help.unc.edu/?id=1859

Debian SSLkeys

http://wiki.debian.org/SSLkeys

Links in post:

http://www.securityfocus.com/news/11518

http://metasploit.com/users/hdm/tools/debian-openssl/

, , , ,

No Comments

LCOD – 6.6.07 – Simple SSH remote command execution

ssh -X -C -f HOSTNAME PROGRAM

Of course you need to be running an X server (Linux/*BSD Desktop) on your client, and you need to have
ForwardX11 yes
or
ForwardX11Trusted yes

in your CLIENT’s /etc/ssh/ssh_config file
and
X11Forwarding yes
in /etc/ssh/sshd_config
on the SERVER.

, , , , ,

No Comments