GUI Dialogs from shell Scripts
If you want to use a GUI dialog from a shell script, you are in good hands. Try xmessage and/or kdialog:
xmessage "This is a message" kdialog --msgbox "this is a message"
Mounting SFTP Sites as a Local Filesystem
In Linux (RHEL4), get FUSER and ./configure, make, make install. Run 'up2date -u glib2-devel'. Then get SSHFS, run ./configure, make, make install. Try
mkdir /mnt/sftpdir sshfs myusername@mysftpserver: /mnt/sftpdir
If fuser complains that it could not find libfuse.so, put '/usr/local/lib' into /etc/ld.so.conf and run ldconfig.
To unmount, run
fusermount -u /mnt/sftpdir
Before FUSE-ssh there was LUFS, and before that was shfs. To use shfs try this (thanks to the Yodster):
$ tar zxf shfs-0.35.tar.gz -C /tmp $ cd /tmp/shfs-0.35 $ make $ make rpm $ su - # rpm -ihv /tmp/shfs-0.35/rpm/RPMS/i686/shfs* # chmod u+s /usr/bin/shfs*mount # exit ------------------------ [yo@kva ~]$ shfsmount server: mnt #mounts home directory [yo@kva ~]$ shfsumount mnt
Be careful, on kernel updates, these kernel specific modules will need to be regenerated. The good news is that as of kernel 2.6.14 (and 2.4.21) FUSE is part of the default kernel.
Also, you can use sftpdrive in Windows.
Nmap is Your Friend (except for MSS)
We all know Nmap can be used to perform a network scan on a host/network. Many of us would trust Nmap with our careers. There is just one thing... it is really easy to make Nmap lie to it's owner. Try adding this to your iptables config file:
-A INPUT -p tcp -m tcp ! --tcp-option 2 -j REJECT --reject-with tcp-reset
This line instructs iptables to reject TCP packets that do not set
option 2, the MSS (Maximum Segment Size - the largest data size to
send). Guess what Nmap does not do in its default scan (stealth SYN
scan)? It does not set option 2, so Linux responds with an RST/ACK
which means the port is not open! In essence, Nmap will see all TCP ports as closed on a SYN scan no matter what. Nmap is still your friend, but maybe don't trust your whole career to it.
Udev Abuse
The udev subsystem provides modern Linux with "on-the-fly" device file creation. The udev system is what gets notified that device blahblah is attached and the corresponding device file needs to be created. The admin actually has quite a bit of control of this system, such as creating special device filenames for certain devices. The following work has been done with RHEL4 U3.
Let's say one wants to butcher a mouse to provide spinner control functionality (like the controls on Tempest, the old upright video game). This actually has been done, and there are several project descriptions available on the web. We can edit /etc/udev/rules.d/09-myrules.rules to specify that a device plugged in at a certain location shows up as a certain device filename, or a device with a certain serial number is treated differently. The files in /etc/udev/rules.d are all rules processed in the order of the starting number of the filename (hence 09-myrules.rules is processed before 50-udev.rules. Let's look at an example:
# USB mouse plugged into a specific port to be called spinner KERNEL="event*", BUS="usb", PLACE="1-8.1", NAME="input/knob"
The above would create a device file called /dev/input/knob when the kernel informs udev that an "event" source (like a mouse) is plugged in to USB port 1-8.1 (that is "port 1 on USB hub 1-8"). One can also use 'serial="BADBEEF"' as a term to select a given device. Note that mice seem to not carry serial numbers, but USB mass storage devices often do.
When your changes to the rules files are complete, run 'udevstart' to reload udev. This works well, but there are a couple of things to address. 1) USB mice plugged into the system show up in _SIX_ places by default: /dev/mouse$, /dev/event#, /dev/input/mouse#, /dev/mice, /dev/input/mice, and /dev/input/event# 2) ALL detected mice are multiplexed on /dev/mice and /dev/input/mice. 3) With the kernel we wereplaying with, there was no way to have a mouse NOT participate in the /dev/mice multiplex. Under these circumstances it is not surprising to find that the spinner will move the mouse in X Windows. The only solution is to tell X to use a specific mouse. We have read that newer kernel will allow the term "ignore _device" which may be added to have the "mice" devices ignore the mouse acting as a spinner.
Want to know how to query USB to figure out what all the positions and serial numbers for devices are currently? First try 'udevinfo -d | less' and look for the device's associated name (like "/class/input/event2"). Then try 'udevinfo -a -p /class/input/event2' to get all the gory details. Remember syslog usually keeps logs of dynamic plugins as well. One more thing: you can set 'udev_log="yes"' in /etc/udev/udev.conf to get crazy amounts of data in syslog (/var/log/messages).
X Tunneling via SSH Through a Firewall
One good practice when building secure systems is to remove unnecessary software. On dedicated firewall deployments, we try to keep X Windows off of the system. We recently were at a site where the users needed to SSH in through a firewall and have X displays show up on their external systems. It would not work.
It turns out that SSH X tunneling makes use of the xauth subsystem. This usually comes with X Windows so firewalls with X Windows installed can tunnel X windows via SSH. For firewalls without X Windows, more work needs to be done. First, check to see if your distribution has broken out the xauth subsystem into it's own package. RHEL 4, for instance, now has a package called xorg-x11-xauth. RHEL 4 firewalls with out X installed can install this and SSH X tunnelling will operate correctly. For those not lucky enough to be working with a distro with xauth as a separate package, here is a hack . On a similar system (read "nearly identical, except with X Windows installed"), run 'ldd /usr/X11R6/bin/xauth' . This will return a list of files which need to exist on the target system for xauth to run. Check the target for these files and copy over any which are missing... and do not forget to copy /usr/X11R6/bin/xauth itself.
WARNING: We did the copying of xauth and its dependencies once and blindly copied over ALL of the xauth dependencies. One of those dependencies was libc.so. Guess what happened when we copied over a running libc.so? The target froze.... when we restarted it, the libc.so was corrupted and the target would no longer boot! The fix was simple enough: boot to rescue media and copy libc.so over cleanly. Still, be careful and only copy over the files which are missing.
Use Swatch for Log Watching
Good sysadmin have long known that keeping centralized logfiles is a good idea... in some cases secured centralized logs are required by the lawyers. In any case, there is a program called Swatch for looking at incoming messages and perform actions based on what is seen.
make a config file like this:
watchfor /UncorrectableError/
exec=echo '$_' >> /var/log/swatch_crits.txt
throttle=01:00
watchfor /unable to read inode block/
exec=echo '$_' >> /var/log/swatch_crits.txt
throttle=01:00, use regex
Then start with:
/usr/bin/swatch --config-file=/etc/syslogger.swatchrc
(the above assumes /var/log/messages is the target)
This may be put into the syslog startup:
start() {
echo -n $"Starting Swatch: "
daemon /usr/bin/swatch --config-file=/etc/syslogger.swatchrc &
echo
echo -n $"Starting system logger: "
daemon syslogd $SYSLOGD_OPTIONS
RETVAL=$?
echo
echo -n $"Starting kernel logger: "
daemon klogd $KLOGD_OPTIONS
echo
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/syslog
return $RETVAL
}
stop() {
echo -n $"Shutting down Swatch: "
killproc /usr/bin/swatch
echo
echo -n $"Shutting down kernel logger: "
killproc klogd
echo
echo -n $"Shutting down system logger: "
killproc syslogd
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/syslog
return $RETVAL
}
This seems to work OK, it even crosses logrotates successfully.
Using Syslog-ng
1. get the latest syslog-ng and libol (1.6.5 and 0.3.14) from >>http://www.balabit.com/downloads/syslog-ng/ & install flex too!
2. unpack libol and run configure, make, make install
3. unpack syslog-ng and run configure --enable-tcp-wrapper, make, make install
4. cp contrib/init.d.RedHat /etc/init.d/syslog-ng
5. cp contrib/syslog-ng.conf.RedHat /etc/syslog-ng.conf
6. copy the chkconfig lines from top of /etc/init.d/syslog to syslog-ng
7. runchkconfig --add syslog-ng
8. runchkconfig syslog off
9. runchkconfig syslog-ng on
10. modify /etc/init.d/syslog-ng with correct path: /usr/local/sbin/syslog-ngINIT_PROG="/usr/local/sbin/syslog-ng"
Windows event logs => syslogger
1. Goto >>http://www.edoceo.com/creo/winlogd/ and get winlogd.exe
2. put in system32
3. runwinlogd.exe -i
4. use regedit to set server
5. runnet start winlogd