Q40/Linux Journal
Issue #3
www.geocities.com/SiliconValley/Pines/5865/q40lin.html
Editor: Timothy Swenson ([EMAIL PROTECTED])
Editor's Forumn
When I was working on the previous issue of Q40/Linux Journal, I
asked Richard Zidlicky to write something on the new 2.4 kernal
and some of the newer features that have been added in the
kernal. Richard was a little late in turning in the article, but
when he did, the article has become the whole issue. So, I turn
the rest of the issue over to Richard.
New Linux Kernal Features
By Richard Zidlicky
Kernel and other news
---------------------
Given the substantial amount of changes needed to run a 2.4 kernel and
our aging distribution which lacks quite a few modern applications a
new distribution would be nice. I have compiled parts of Redhat 7.0
which basically works, however the amount of work to be done makes it
impractical to do as a one man job. If there are volunteers to do some
work and testing I can provide compiler and basic libs and tools,
otherwise I would simply recommend everyone to upgrade to Debian-m68k.
2.2 kernels have reached good stability, 2.2.17 is the latest Q40 version.
It does fix quite a few things and provide new features, so upgrading is
a very good idea. No configuration changes are required to upgrade from
2.2.6, just install kernel and modules.
As it turned out older kernels had problems to use hard disks >8GB.
I am now looking into ways to make such disks better usable for SMSQ
- testers are wellcome.
Kernel 2.4.1 is the latest of the 2.4 kernels. The 2.4 branch is
considered very stable now and provides many new features.
Some user visible changes are:
- new kernel compiler REQUIRED - get 2.91.66. For 2.2.X kernels gcc2723
is still recommended. 2.91.66 may install incompatible c++ libs,
so don't build the c++ part.. this will also speed up things
a lot.
- new modutils and a few more /etc/modules.conf entries REQUIRED
- POSIX shared memory support. REQUIRES an entry in /etc/fstab
- new PPP stuff REQUIRED
- new greatly enhanced firewall/masquerading/routing code, requires
'iptables' tool. Old (2.0 and 2.2) tools and scripts will still
work.
- mount -t bind support. This allows anyone to 'mount' arbitrary
parts of filesystems (files, directories) into any location.
Might be usefull to mount /tmp over a read-only medium.
- UDF filesystem in mainstream kernel. Packetwriting for CD-R(W)
is available as patch somewhere.
- kernel ISA PnP support (may need change to config.in), with
apropriate hardware USB and IRDA may be easilly supported.
- Reiserfs is in the kernel but not big-endian clean so don't use it.
Code has been substantially reshufled so adding drivers (eg network
cards) for the Q40 should be trivial.
Ethernet with the Q40
-----------------------
Required kernel: 2.2.17
Supported Hardware: NE2000 compatible ISA cards. Some older cards have
been found to work very poorly, well tested is LCS-8634PTB from Longshine
(costs about 15 US$).
Jumperless (PnP) cards are supported only with extra software and
should be therefore avoided.
Installation
------------
Configure the card to a free IRQ and address. IO base 0x300 is default
for reasonable cards and works well. IRQ should be configured to 5 or 7.
IRQ 6 must remain reserved for floppy under any circumstances.
When the network cable is plugged in at boot time the NE2K may produce
spurious interrupts so the booting will appear to hang. Ususally booting
would continue after some delay. Fortunately this happens rarely and
rebooting with unplugged cable always helps.
To use the Ne2K driver, install the modules. As root, type
modprobe ne io=0x300 irq=5 bad=0xbad
ifconfig eth0 up 172.16.0.2
The bad=0xbad parameter can be often omitted but is required for my
Ne2K clone. If something goes wrong look for errors like
tail /var/log/messages
Provided that your other networked machine has an ethernet interface
configured to some other address in the 172.16.0.1 space ping and
everything else should work now - most likely with numeric addresses
only.
Small network hacking quide
---------------------------
in above example I have chosen 172.16.0.2 for the IP addr of my Q40.
The other machine should have for example 172.16.0.1, addresses in
this range are reserved for private networks and won't clash with any
other adresses on the internet. However, if you use your Q40 for
dialup connections to the internet make sure the address assigned
by you IP service provider doesn't fall into the same range, otherwise
you would need to mess with routing. You may instead choose addresses
from some of the other reserved netblocks like 10.0.x.x
Every machine can have any number of addresses, typically one per interface
(eth0, ppp0) or more if you use aliases. For normal use - one simple
ethernet network and one ppp connection to the internet - this does not
cause any complications. All the addresses should be mentioned in /etc/hosts
(with the exception of dynamicaly assigned ppp-addresses).
To get address resolving by name do
echo "order hosts,bind" >/etc/host.conf
echo "multi on" >>etc/host.conf
If there is an /etc/nsswitch.conf it should have a line like this:
hosts: files dns
and setup your /etc/hosts file. Mine looks like
127.0.0.1 FQDN localhost linux-q40-name
172.16.0.2 localhost linux-q40-name
172.16.0.1 linux-pc-name # the other computer
where FQDN should be the same name as in /etc/HOSTNAME and the same as
HOSTNAME in /etc/sysconfig/network. NETWORKING should be 'yes' in the
same file. linux-q40-name and linux-pc-name are name aliases for local
use.
Unfortunatelly a few programs, like sendmail do not use the standard resolver
and will ignore /etc/hosts for most purposes. Sendmail should be advised
not to use DNS, this can be done eg. with linuxconf.
Routing information is in newer kernels normally derived from the
IP(numeric) address where possible, so it should not be necessary to
mess with that. The interface to your internet connection should be
marked as default route, ppp does this by default.
Network Services
----------------
most services like rlogin and ftp server are available once inetd
is activated ('ntsysv'). Most remote services will not work for root
account and a password must be set to use them.
The X server on the Q40 has MIT authentification turned on. 'xhost +'
will still work but will loose you some functionality - eg the exmh mail
program requires MIT authentification.
There are several ways to avoid having to type password for every
rlogin etc. For simple homebrew networks you may use the ~/.rhosts
file. 'ssh' has a very secure method to do this using ssh-agent.
In addition to simple rlogin, ssh can transparently forward X
connections, exectue remote commands and copy files.
Ssh has been primarily designed to be very secure - beeing so secure
has a price, a comfortable ssh setup requires some manpage reading.
The sources for ssh are included on the distribution CD.
NFS operation
-------------
Server machine must have portmapper and nfsserver activated, both are
installed on the Q40 by default and need to be activated (eg using 'ntsysv'
on the Q40). It appears that the client may also require portmapper
running, this is probably because some versions of the nfsserver try
to use the lock or ugid manager. The ugid manager might be a good idea
anyway. If you get strange RPC messages on the client activate the
portmapper.
Next you need to specify which filesystems to mount. In clients
/etc/fstab add a line like
servername:/path_on_server /mountpoint nfs
wsize=1024,rsize=1024,user,noauto 0 0
On the remote server add this to /etc/exports:
/path_on_server client_name(rw)
Server and client names can be fully qualified names, aliases or IP
addresses - they just have to work (eg ping). All machines can act as
NFS client and server at the same time.
After activating/restarting nfsserver simply do 'mount /mountpoint'
on the client. Many howto's recommend larger wsize/rsize values for
performance reasons but this can also cause trouble with older NFS
implementations. Btw the throughput of the user-space NFS daemon
is not overwhelming, less than ftp, http or any other protocol.
The kernel nfs daemon has better performance but requires some
additional software and I haven't tried it.
One problem with NFS is that entries in /etc/{password,groups} must
by in sync on all machines - otherwise a single file may appear to
belong to different users on various machines. The ugid manager may
be used if this is not practical.
*** IMPORTANT ***
umounting NFS can hang under some circumstances when the server is not
available (turned off or whatever). This can cause shutdown/reboot
to hang with the result that local filesystems aren't properly
umounted. The best workaround is to find "Unmounting file systems"
section in /etc/rc.d/init.d/halt and modify it to
echo "Unmounting file systems"
umount -a -t nonfs
umount -a -t nfs&
sleep 1
mount -n -o remount,ro /
*****************
Firwalls
--------
With sendmail, portmapper, nfs and a few dozens of other services running
the system is is an interesting target to remote attacks. Luckilly most such
attacks will have little consequences for a Q40 because they are targeted
for more popular platforms like linux-x86 and most exploits depend on
that. However Linux has nice firewall software so there is no need to
rely on luck.
Various tools exist that claim to create firewalls easilly, some of them
also make very poor firewalls in my experience. After looking at some
example firewalls I found it much easier to write an own simple firewall
script than trying to understand the complicated mess of some automatically
generated one.
The firewall in Linux 2.2 is a packet filter, 2.4 has a statefull firewall.
Statefull firewalls are better because they can track and monitor state of
connections, however in practice the same level of security is achievable
with packetfilters.
By no means will a however smart firewall replace secure tools
like ssh or secure IP tunneling. Simple Firewalls will specifically
not provide much security when the potential attacker has full man-
-in-the-middle capabilities (your provider) or nearly unrestricted
sniffing - everyone who shares the same segment of a cable modem
provider.
Technically a packetfilter can do a variety of filtering tasks, on
a typical dialup box its job is simply to block unwanted connection
attempts from outside and allow all local traffic.
This is very easy for TCP connections, UDP has a few problems however.
The hardest problem is spoofing - you (and the firewall) must never
trust the source address of an UDP packet. Linux 2.4 firewalls improve
UDP tracking greatly but may also provide a false sense of security
if not used with caution.
Fortunatelly not many applications except nameserver access require
UDP.
I have previously published example firewall scripts, so I will
only explain here the DNS part of the configuration which is traditionally
one of the harder parts.
For nameserver/DNS there are a few possible solutions:
- use exclusively DNS of your provider: put 'nameserver remote-ip' into
/etc/resolv.conf
Applications needed name services open UDP port >=1024 and ask
remote DNS for information.
Disadvantage: UDP ports >=1024 must be opened but some dangerous
applications (nfs) also listen on UDP ports >1024. These can be
selectively closed (see socklist) for listening ports, requires
great care. Also every get*by* call in any application will cause
traffic over the typically not very fast dialup connection.
- use own DNS: put 'nameserver 127.0.0.1' into /etc/resolv.conf
and activate 'named'. If your provider advertises a DNS to use,
take advantage of it by putting forwarder info /etc/named.conf:
options{
......
listen-on {127.0.0.1; 172.16.0.2;};
forward first;
forwarders {
193.159.187.130; // IP of ISP's DNS
};
query-source address * port 1797;
.......
The 'listen-on' is important to tell named on which interfaces
to listen, put here addresses associated with your local 'lo'
and 'eth' (if needed) devices (see 'ifconfig')
The forward/forwarders options will instruct named to forward
all queries instead of doing a full recursive search, this does
not only speed up things, but allows you to specify a much
tighter rule which UDP packets you want to leave through.
Finally the query-source option tells named from which port
to send requests, restricting the necessary hole in the firewall
to a single port.
This is the ideal case of DNS configuration, it allows you
to use a very specific rule like
/sbin/ipchains -A input -i ppp+ -s 193.159.187.130 53 \
-d 0.0.0.0/0.0.0.0 1797 -p udp -j ACCEPT
If your ISP doesn't provide DNS services the forwarding option
obviously won't work and you have to allow any source address in
the above rule - not too bad considering that UDP addresses can't
be trusted anyway. It is also slightly slower before the cache
is built up. The rule would then look like
/sbin/ipchains -A input -i ppp+ -s 0.0.0.0/0.0.0.0 53 \
-d 0.0.0.0/0.0.0.0 1797 -p udp -j ACCEPT
The good thing - this works independently of you ISP's
DNS and is therefore much more reliable. If your ISP has
lots of problems with DNS you may use this solution even
if he advertises name servers.
Firewals should be tested, I found 'nmap' pretty usefull. Just
to avoid confusion, as long as UDP packets are DENYed all udp
ports will appear open to testing software. This is because
an open UDP port by default doesn't send any response to the
attacker which is the same as DENY does, a turned off computer
would produce much the same behaviour. You can use REJECT for
testing to be sure.
A note about masquerading: some ISP's prohibit the use of a single
connection by more than one computer. If you wonder whether they
can detect masquerading - pretty easilly. Normally applications
that don't request specific ports will be allocated ports from
1024 onwards.
Linux is the only OS that does masquerading and masqueraded
connections will appear as commming from ports 61000 onwards
which is an otherwise very unusual portnumber range and easy
to detect.
However that is very easy to change, just change PORT_MASQ_BEGIN
in /usr/src/linux/include/net/ip_masq.h
Random Notes
------------
it seems that /dev/console has not the proper major/minor numbers,
this will make the use of serial ports as console only half the fun.
To get it right, do this:
cd /dev
rm console
mknod -m 622 console c 5 1
-----------
And here is the rest of my firewall
############################################################
#!/bin/bash
# firewall (c) Richard Zidlicky
############################################################
# set a few kernel parameters. Most have reasonable defaults
# anyway, just be sure
# block incoming IP spoofing
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo 1 > $f
done
# Turn on SYN cookies
if [ -e /proc/sys/net/ipv4/tcp_syncookies ]
then
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
fi
#just for the joy of loging it :)
echo 1 >/proc/sys/net/ipv4/ip_forward
# Enable always defragging Protection
#echo 1 > /proc/sys/net/ipv4/ip_always_defrag
# Enable broadcast echo Protection
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
# Enable bad error message Protection
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
# disable ICMP redirect messages
for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do
echo 0 > $f
done
# Disable Source Routed Packets
for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do
echo 0 > $f
done
# Log Spoofed Packets, Source Routed Packets, Redirect Packets
for f in /proc/sys/net/ipv4/conf/*/log_martians; do
echo 1 > $f
done
################################################################
# delete any old chains and rules
/sbin/ipchains --flush
/sbin/ipchains -X
# set deafult policy
/sbin/ipchains -P input DENY
/sbin/ipchains -P forward DENY
/sbin/ipchains -P output ACCEPT
# allow all local traffic through 'lo' and eth0 interfaces
/sbin/ipchains -A input -i lo -j ACCEPT
/sbin/ipchains -A input -i eth0 -j ACCEPT
# allow TCP connections initiated from inside - assumes IP link on ppp+
/sbin/ipchains -A input -i ppp+ -p tcp ! -y -j ACCEPT
# accept a few selected ICMP messages, we are really picky
/sbin/ipchains -A input -i ppp+ -p icmp --icmp-type echo-reply -j ACCEPT
/sbin/ipchains -A input -i ppp+ -p icmp --icmp-type source-quench -j ACCEPT
/sbin/ipchains -A input -i ppp+ -p icmp --icmp-type time-exceeded -j ACCEPT
/sbin/ipchains -A input -i ppp+ -p icmp --icmp-type parameter-problem -j ACCEPT
/sbin/ipchains -A input -i ppp+ -p icmp --icmp-type destination-unreachable -j ACCEPT
# add a hole for local caching nameserver, THIS REQUIRES
# query-source address * port 1797;
# in /etc/named.conf !!!
# source address should be further restricted when a forwarding DNS is used
/sbin/ipchains -A input -i ppp+ -s 0.0.0.0/0.0.0.0 53 -d 0.0.0.0/0.0.0.0 1797 -p udp
-j ACCEPT
# reject ident requests, speeds up connection buildup sometimes
/sbin/ipchains -A input -i ppp+ --destination-port 113 -p tcp -j REJECT
# log and deny everything else
/sbin/ipchains -A input -j DENY -l
/sbin/ipchains -A forward -j DENY -l
# the output filter part. This doesn't really filter anything..
# This section manipulates the Type Of Service (TOS) bits of the
# packet. This can slightly improve responsivnes.
# Set ssh, www, smtp, pop3 and FTP for minimum delay
/sbin/ipchains -A output -p tcp -d 0/0 22 -t 0x01 0x10
/sbin/ipchains -A output -p tcp -d 0/0 80 -t 0x01 0x10
/sbin/ipchains -A output -p tcp -d 0/0 8000 -t 0x01 0x10
/sbin/ipchains -A output -p tcp -d 0/0 8080 -t 0x01 0x10
#/sbin/ipchains -A output -p tcp -d 0/0 23 -t 0x01 0x10
#/sbin/ipchains -A output -p tcp -d 0/0 21 -t 0x01 0x10
/sbin/ipchains -A output -p tcp -d 0/0 110 -t 0x01 0x10
#/sbin/ipchains -A output -p tcp -d 0/0 25 -t 0x01 0x10
# Set ftp-data for maximum throughput
/sbin/ipchains -A output -p tcp -d 0/0 20 -t 0x01 0x08
