Kontrol' polosy propuskaniya
http://www.atmsk.ru/popups/articleswindow.php?id=27&print=print
Material ne gotov, poka syuda svalivayutsya zametki i informaciya
k razmyshleniyu.
Probros (tunnelirovanie) portov cherez ssh
Imeem wneshnijserver i vnutrennyuyu mashina za fajrvollom.
mashina$ ssh -R new_port_tam:localhost:port_nash wneshnijserver
mashina$ ssh -C -L port_tam:localhost:new_port_nash wneshnijserver
-L - pritashchit' port k nam na localhost
-R - vytashchit' nash port na udalennyj host.
-C - kompressirovat' trafik
1. Obespechit' login iz interneta na vnutrennyuyu mashinu
mashina$ ssh -R 2222:localhost:22 wneshnijserver
wneshnijserver@username password:
wneshnijserver$
Proveryaem:
wneshnijserver$ netstat -an | grep 2222
tcp 0 0 127.0.0.1:2222 0.0.0.0:* LISTEN
Loginimsya:
wneshnijserver$ ssh -p 2222 localhost # esli na mashina ssh2
wneshnijserver$ ssh -1 -p 2222 localhost # esli na mashina ssh1
2. Projti s vnutrennej mashiny na naruzhnyj port, zashchitiv i skompressovav
trafik
mashina$ ssh -C -L 3128:localhost:8080 wneshnijserver
Proveryaem
mashina$ netstat -an | grep 8080
tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN
Ispol'zuem:
Netscape > Preference > Proxy > localhost: 8080
Kak ogranichit' dostup k squid
1. Privyazyvaem squid tol'ko k odnomu interfejsu
http_port 10.10.10.7:3128 # bylo http_port 3128
http_port 12.0.0.7:3128
2. Propisyvaem gruppy pol'zovatelej
# acl rfc-user ident moshkow root
# adresa, s kotoryh puskaem po IP
acl our_network src 10.10.10.1-10.10.10.4
acl our_network2 src 12.0.0.0/255.255.255.0
# s drugih adresov puskat' pol'zovatelej, skazavshih parol'
acl passwd_user proxy_auth REQUIRED
http_access allow our_network
http_access allow our_network2
http_access allow passwd_user
http_access deny all # ostal'nym - nel'zya
# programma, kotoraya budet proveryat' paroli iz fajla /etc/passwd
authenticate_program /usr/lib/squid/ncsa_auth /etc/passwd
####################################
/usr/lib/squid/ncsa_auth /etc/passwd
Password:
root parolroota
OK
### s /etc/shadow etot fokus ne projdet - net prava na chtenie
10 - vnutrshka, 172 - snaruzhi
1.
vklyuchit' ip forwarding, vozmozhno vklyuchen po umolchaniyu,
/sbin/sysctl -w net.ipv4.ip_forward = 1
2.
/sbin/iptables -t nat -A POSTROUTING -s 10.0.0.0/255.255.255.0 -o if1 -j SNAT --to-source 172.10.10.1
3.
/sbin/iptables-save > /etc/sysconfig/iptables
chkconfig --levels 2345 on
Ogranichenie polosy - ipfw ili altq.
Ogranichenie trafika - ipa + paru skriptov na perle.
Dva ranyh default gatevaay dlya raznyh adresov
Iproute2 sozda£sh' dve tablicy, u odnoj odin default route, u drugoj - drugoj.
I raskidyvaesh' v nih vs£ po ishodnym adresam.
Primerno tak
ip route add default via a.c.b.c table tablenumberone
ip rule add from v.x.y.w/24 table tablenumberone
Analogichno postupaetsya so vtoroj tablicej. I s tret'ej. I, podozrevayu, s dve sotni pyat'desyat pyatoj.
Vtoroe pravilo mozhet, naprimer, vyglyadet' kak-to tak
ip rule add from v.x.y.w/24 table to k.l.m.o tablenumberone
Ob®yasnyat', dumayu, ne stoit.
Voobshche, ochen' udobnaya veshch'. Na redkost' moshchnaya i universal'naya. YA imeyu v vidu iproute2.
Mozhno, konechno, i iptables vs£ regulirovat', no mne vysheoboznachennyj variant bol'she po dushe.
I ty dazhe ne predstavlyaesh', skol'ko vsego gugl pokazyvaet, esli ego ob iproute2 sprosit' :-).
No nachinat' stoit s http://lartc.org.
Rabota s ipchains. Redhat 7.0
# ubedilis', chto v yadre est' podderzhka
ls -al /proc/net/ip_fwchains
# zapret tcp-paketov s zdannogo adresa
ipchains -A input -s 155.208.157.51 -p tcp -j DENY
ipchains -L # prosmotr pravil
ipchains -F # udalenie pravil
Zapusk maskaradinga dlya dialap-klientov. IPFWADM, redhat 6.2
echo 1 > /proc/sys/net/ipv4/ip_forward # bez forvardinga ne zarabotaet
ipfwadm -F -p deny # zapretit' vsem
ipfwadm -F -a m -S 195.0.0.2/0 -D 0.0.0.0/0 # razreshit' adresu 195.0.0.2
Ogranichit' traffik konkretnoj mashiny v seti
while sleep 5
do
ipfw add 111 drop ip from baduser.host.name to any
sleep 15
ipfw delete 111
done
Antisirkamizaciya sendmail
HContent-disposition: $>CheckSircam
SCheckSircam
Rmultipart message $#error $@ 5.7.1 $: 554 Sircam infected message
NET-3 HOWTO (razdel "IP Accounting") i "man ipfwadm"
Probros so svoego porta na chuzhuyu mashinu
myhost:82 -- > secondhost:8499
ipfwadm -Fa accept -b -P tcp -S 0/0 82 -D secondIPaddr/32 8499
Nastrojka paketnogo fil'tra
Date: 7 May 1998
From: Igor Mikhayliuk
Kak-to raz, Sreda Maj 06 1998 10:06, Dima Volodin pisal All:
DV > Net takogo standarta. Est' takoe _umolchanie_, chto esli port ne ukazan, to
DV > eto - 80 v sluchae http i 443 v sluchae https. Pro voobshche zhe govorya, vot
DV > zhivoj primer iz zhizni - popavshi kak-to za firevol, skonfigurennyj odnim
DV > umel'cem ot NT, ya nikak ne mog vospol'zovat'sya poiskom po CNNovskomu
DV > sajtu - on u nih (u CNN) visit na kakom-to levom portu (skazhem, 8765).
DV > Razdrazhalo strashno. Prishlos' sdelat' konfiguraciyu iz treh pal'cev, ssh i
DV > dalekogo proxy. Slava bogu, chto hot' 22 port otkryt byl (posle nekotorogo
DV > bryzgan'ya slyunoj s moej storony).
Zlobnyj kakoj admin popalsya, horosho, hot' ne vlagostojkij.
;)
DV > Koroche, sut' v tom, chto u "ne hotyashchego razbirat'sya s kazhdoj ocherednoj
DV > inetovskoj progoj" ves'ma smutnoe predstavlenie o TCP v chastnosti i ob IP
DV > voobshche, i taki emu nado by snachala razobrat'sya s predmetom, a potom uzhe
DV > pristupat' k konfigureniyu firevolov.
|to, vidimo, zayavlenie iz serii: "WinNT admin suks' i mastdaj"?
DV > I v menee razdrazhennom tone -
Vot eto est' horosho ves'ma.
:)
DV > okryvat' nado vse _ishodyashchie_ TSRshnye
DV > soedineniya, vhodyashchie zhe puskat' tol'ko na konkretnye hosty i porty,
DV > na
DV > kotoryh visyat publichno dostupnye servisy. Krome togo, obychno otkryvayut
DV > UDRshnyj trafik na domain (53), ntp (123), real-chego-to tam i t.d. i, dlya
DV > bleziru, vhodyashchij icmp. CHtoby rabotal ping, nado okryt' i ishodyashchij icmp,
DV > i chtoby rabotal traceroute - udp na teh verhnih portah, kotorymi on
DV > besstydno pol'zuetsya. Hotya, naskol'ko ya slyhal, MSovskij tracert rabotaet
DV > ne tak, kak yuniksnyj traceroute, tut ne mne rasskazyvat'. Nu i,
DV > estestvenno, blokiruetsya ves' ishodyashchij trafik s chuzhimi src (eto ne
DV > stol'ko security, skol'ko horoshij ton), ves' vhodyashchij trafik na chuzhoj dst
DV > i ves' vhodyashchij trafik so svoim src.
V obshchem szhato i ochen' horosho opisal, spasibo.
DV > Skoree vsego, chego-to zabyl, no tut dostatochno narodu, chtoby ispravit' i
DV > dopolnit'.
A teper', vse-taki utochnyu, otkuda rastut nogi u moego ishodnogo pis'ma. Vell
noun servajses na to i vell noun, chtoby vse znali, kakie protokoly/porty oni
ispol'zuyut. Vsem izvestno, chto FTP po umolchaniyu ispol'zuet 21-yj port, a
nekotorym dazhe izvestno, chto eshche i 20-j. No kogda delo dohodit do chego-to menee
tradicionnogo, voznikaet problema. Ona reshaetsya putem posledovatel'nogo chteniya
doki, esli ne pomoglo, poiska v Inete, na hudoj konec, s ispol'zovaniem
sniffera. Estestvenno na eto uhodyat sily i vremya.
Poetomu mne kazalos' logichnym, chto gde-nibud' sushchestvuyut nakoplennye dannye o
tom, kakie programmy chto yuzayut. U menya dazhe est' podozrenie, chto v helpe/dokah
na krutoj fajrvoll, sniffer i t.p. takoe vpolne mozhno najti. I ya poprosil
pomoshchi
kluba.
Vozmozhno, nezhelanie razbirat'sya v kazhdoj prinesennoj yuzerom mul'ke kazhetsya tebe
lamerizmom, no mne zhalko tratit' na eto vremya. A inogda ya prosto ne znayu, kak s
etim spravit'sya. ZHivoj primer - mne uzhe temechko prodolbili s setevoj chatilkoj
WinTalk. SHtuka dejstvitel'no udobnaya, no doki k nej voobshche netu, s avtorom
svyazat'sya ne udalos', ves'ma ogranichennyj sniffer, kotorym ya raspolagayu,
pokazyvaet mne tol'ko rezul'tat - sessiyu na pare posledovatel'nyh proizvol'nyh
portov za 1024. Kak ona ustanavlivaet sessiyu, ponyatiya ne imeyu. YA dazhe napryagsya
i
skachal trialku kakogo-to monstroobraznogo sniffera, Guardian Session Wall-3, i
byl ves'ma obradovan, kogda obnaruzhil, chto etot monstr, s bolee, chem
dvadcatimetrovym distributom blagopoluchno trapaet videopodsistemu.
:(
V obshchem, otnesis' s ponimaniem k tomu, chto adminu NTevoj setki tak zhe slozhno
nahodit' infu/programmy, kasayushchiesya WAN, kak yuniksoidu kakoj-nibud' DTP paket.
A cheloveku, kotoryj rabotaet v malen'koj firme i, krome setki, kovyryaetsya v
zheleze, vytiraet sopli yuzeram, soprovozhdaet DB i mnogo chego eshche delaet po
rabote, ne vsegda hvataet vremeni na glubokoe osvoenie tonkostej setevogo
vzaimodejstviya.
:)
Sentry Port Scan Detector 0.60
Date: 28 May 1998 05:45:05 -0000
From: crowland@psionic.com
Sentry is a port scan detector for Linux, *BSD, and most UNIX variants.
Sentry monitors your systems for port probing activity and will then take
any of the following actions:
1) Log the attacker hostname/IP and ports probed.
2) Run external program.
3) Configure routing table to drop route of attacking host.
4) Configure local packet filter (ipfwadm/ipfw) to drop all packets from
attacking host.
Sentry will now detect and respond to stealth scans against your host from
advanced scanners such as nmap:
http://www.insecure.org/nmap/index.html
* Eshche dlya firewall potrebuetsya *
NAT - Network Address Translation - nastraivaetsya v yadre komandoj
ipfwadm
Otklyuchit' routing.
Kernel reconfigure
Zakryt' vhodnye servisy.
TCPD
Proxy dlya httpd, ftp, i t.d.
squid
Proxy dlya telneta, ftp, X11
TIS fw tollkit
Proxy dlya proizvol'nogo TCP vsego
socks5
Primer nastrojki fil'tra IPFWADM
Date: 17 Jun 1998
From: MushyPea
On Tue, 16 Jun 1998, Avery Pennarun wrote:
> Here is the script I use on my home IP masquerade system. It is designed
> to deny everything except what is specifically allowed in some of the
> definitions near the top. Note that there is one fatal problem -- the
> input firewall is changed to allow incoming data back to ports 1024
> through 65535, because any of those might have been used to create an
> _outgoing_ connection (and thus might have data been sent back to them).
> NFS servers might run on one of these high port numbers, so watch out.
I do the following:
1) To make the script more readable, use variables:
ME="a.b.c.d/32"
HI="1024:65535"
ANY="0.0.0.0/0"
2) Use "-y -o" options to log all connection attempts (ie. SYN bit set) to
syslog (you need verbose firewall logging compiled into the kernel), and
accept the packets in both directions for these connections.
2a) Example of a bi-directional service
# SMTP mail traffic
/bin/echo -n "SMTP/"
/sbin/ipfwadm -O -a accept -P tcp -S ${ME} ${HI} -D ${ANY} 25 -y -o
/sbin/ipfwadm -O -a accept -P tcp -S ${ME} ${HI} -D ${ANY} 25
/sbin/ipfwadm -I -a accept -P tcp -S ${ANY} 25 -D ${ME} ${HI}
/sbin/ipfwadm -I -a accept -P tcp -S ${ANY} ${HI} -D ${ME} 25 -y -o
/sbin/ipfwadm -I -a accept -P tcp -S ${ANY} ${HI} -D ${ME} 25
/sbin/ipfwadm -O -a accept -P tcp -S ${ME} 25 -D ${ANY} ${HI}
2b) A tricky one - FTP
# Incoming FTP
/bin/echo -n "FTPin/"
/sbin/ipfwadm -I -a accept -P tcp -S ${ANY} ${HI} -D ${ME} 20:21 -y -o
/sbin/ipfwadm -I -a accept -P tcp -S ${ANY} ${HI} -D ${ME} 20:21
/sbin/ipfwadm -O -a accept -P tcp -S ${ME} 20:21 -D ${ANY} ${HI}
3) Drop everything else - note, the 'without logging' section only applies
if you ever set your interface(s) into promiscuous mode... it's wise not
to log packets to/from elsewhere, otherwise the machine load hits the
roof, and the log file expands rapidly... I found out the hard way. ;)
# Deny everything else
# with logging... (target = me)
/sbin/ipfwadm -I -a deny -S 0/0 -D ${ME} -o
/sbin/ipfwadm -O -a deny -S ${ME} -D 0/0 -o
# without logging... (target != me)
/sbin/ipfwadm -I -a deny -S 0/0 -D 0/0
/sbin/ipfwadm -O -a deny -S 0/0 -D 0/0
Hope that's of some help - oh, one thing - if you decide to use logging,
make sure the logfile is on another partition somewhere, in case someone
floods your box to try and fill up the disk! Logging is worth the effort
- I've detected port scans and other such nasties this way.
Ian.
--
Ian Marsh
mushypea@dominion.net.uk ... Email
http://www.etchq.demon.co.uk/ ... WWW
http://www.dominion.net.uk/ telnet://dominion.net.uk:2468/ ... Dominion
http://www.alpha4.com/ telnet://alpha4.com:3214/ ... MBa4
rc.firewall:
ifconfig eth0 promisc
ifconfig eth1 promisc
ifconfig eth1 arp
ifconfig eth0 arp
route add -net default gw 193.232.173.45 dev eth1
brcfg -enable >> /dev/null
ipfwadm -I -f
ipfwadm -O -f
ipfwadm -F -f
ipfwadm -I -a reject -S 0.0.0.0/0.0.0.0 -D 0.0.0.0/0.0.0.0
ipfwadm -I -i accept -S 195.231.183.1/255.255.255.255 -D 0.0.0.0/0.0.0.0
ipfwadm -I -i accept -S 195.231.183.2/255.255.255.255 -D 0.0.0.0/0.0.0.0
ipfwadm -I -i accept -P tcp -S 195.231.183.0/255.255.255.0 ftp telnet -D 0.0.0.0/0.0.0.0
ipfwadm -O -a reject -P tcp -k -S 195.231.183.0/255.255.255.0 -D 0.0.0.0/0.0.0.0 137 138 139
From: Adam Sulmicki
One of reasons for presenting is that in all examples shown so far
it seemed that everyone suggested to leave named full-open. However,
it does not always have to be case. Say, if you are running an private
network then you want just to allow named get data transfers from
trusted host and that is all.
[root@eax /root]# cat ipfwadm-named
#!/bin/sh
#allow connection only from trusted named servers
ME="1.2.3.4" # MY ip
NS1="10.20.30.41" # IP of the primary name server
NS2="10.20.30.42" # IP of the secondary name server
NS3="10.20.30.43" # IP of the trietary name server
SRV="domain"
/sbin/ipfwadm -I -f
/sbin/ipfwadm -I -a accept -D ${ME} $SRV -W eth0 -P udp -S $NS1 $SRV
/sbin/ipfwadm -I -a accept -D ${ME} $SRV -W eth0 -P tcp -S $NS1 $SRV
/sbin/ipfwadm -I -a accept -D ${ME} $SRV -W eth0 -P udp -S $NS2 $SRV
/sbin/ipfwadm -I -a accept -D ${ME} $SRV -W eth0 -P tcp -S $NS2 $SRV
/sbin/ipfwadm -I -a accept -D ${ME} $SRV -W eth0 -P udp -S $NS3 $SRV
/sbin/ipfwadm -I -a accept -D ${ME} $SRV -W eth0 -P tcp -S $NS3 $SRV
/sbin/ipfwadm -I -a reject -D ${ME} $SRV -W eth0 -P tcp -o -v -x -e
/sbin/ipfwadm -I -a reject -D ${ME} $SRV -W eth0 -P udp -o -v -x -e
And while we are speaking about named. Here is an example
as someone from "Catholic liberal arts institution" (as per their web
page) connecting to my box. I assume that person was scanning
whole subnet searching for vulnerable versions of named.
O statistike i podschete traffika
Stavite mrtg, i schitaete cherez smnpget.
"ipfwadm configuration utility"
http://www.ejj.net/~sonny/fwconfig/fwconfig.html
I voobshche, dlya nachala oznakomit'sya s dokumentaciej
1. Security Problems in the TCP/IP Protocol Suite
-- S.M. Bellovin then of AT&T
ftp://research.att.com/dist/internet_security/ipext.ps.Z
2. A Weekness in the 4.2 BSD Unix TCP/IP Software
-- R.T. Morris then of AT&T
ftp://research.att.com/dist/internet_security/117.ps.Z
*3.* Network (In)Security Through IP Packet Filtering
-- D. Brent Chapman
ftp://coast.cs.purdue.edu/pub/doc/firewalls/Brent_Chapman_packet_filtering.ps.ZOn the subject of firewall and IP packet filtering just go
to (and read the whole directory):
ftp://coast.cs.purdue.edu/pub/doc/firewalls/
In case of interest, the source of the IP filter that
OpenBSD uses, are at:(claims it runs under linux 2.0.31 too)
http://cheops.anu.edu.au/~avalon/
But one of the best monitoring tools is tcpdump, its
current version being 3.4, and you need libpcap-0.x, to
work. Both of the packages are ready to download from:
ftp://ftp.ee.lbl.gov/tcpdump.tar.Z
ftp://ftp.ee.lbl.gov/libpcap.tar.Z
ftp://ftp.ee.lbl.gov/tcpslice.tar.Z
The last one is for reading files with live snapshots
from your net, these written by tcpdump, at later times,
when needed.
WARN: untar libpcap where your *current untarred* tcpdump
files lie, in other words under the tcpdump-3.4 directory!
Eshche odin firewall - LRP
From: Rob Bringman
To:
linux-security@redhat.com
I am the Firewall-1 administrator where I work and it has a very nice
GUI tool for defining objects (can be hosts, networks, DNS domains,
groups of hosts, etc.) and a straightforward way of building a
rulebase.
At home I use the LRP with a mini-qmail daemon forwarding the e-mail
via qmqp to the real mailhost, and sshd for remote admin. It has
ipautofw, ipportfw and masquerading.
I really can't think of anything I can do with the Firewall-1 machine
that I can't do with this LRP machine. The whole OS used to fit on a
floppy until I added the mini-qmail and sshd packages. Now it boots
off a small HD and runs only on ramdisks. Except for the GUI and the
price, I'd say they are about equal in terms of power and protection.
I've looked into TIS but never used it. It involved running proxy
daemons on the firewall for telnet ftp and snmp. I like the LRP much
better.
(for those that don't know, LRP is the Linux Router Project. see
http://www.linuxrouter.org )
# /etc/hosts/deny
#
# deny all, send an alert email to root...
ALL : ALL : \
banners /etc/banners/deny : \
spawn ( \
/bin/echo -e "\n\
TCP Wrappers\: Connection Refused\n\
By\: $(uname -n)\n\
Process\: %d (pid %p)\n\
\n\
User\: %u\n\
Host\: %c\n\
Date\: $(date)\n\
" | /bin/mail -s "$(uname -n) wrappers\: %d refused for %c" \
root@localhost ) &
====8<------ end of cut --------------------------
This will deny access to anyone not specifically allowed (from
/etc/hosts.allow), give banners message (specific for the daemon being
called - see the man pages), and generate a very informative mail message
sent to root. (You can add other recipients to that line, btw).
We have found this to be VERY useful here...
[mod: Some remarked that things like "%u" are "client controlled" and
could be used to exploit Tony's system. The manual however claims:
Characters in % expansions that may confuse the shell
are replaced by underscores.
so that should be OK. -- REW]
No ya vse zhe predpochtu zapisyvat' eti logi v fajl a ne napryagat' svoj send
mail - inache atakuyushchij povysiv chastotu popytok zavesti moyu mashinu.
Kak u ipfILTER obnulit' statistiku bez perezagruzki?
ipf -z -f my_ipfilter_rules_file
Dlya togo, chtoby ispol'zovat' ssh1 & ssh2 odnovremenno, nado:
1. Postavit' ssh-1.2.26 (pervym!)
2. Postavit' ssh-2.x.x
3. V "sshd2_config" dobavit' (vozmozhno izmeniv puti):
Ssh1Compatibility yes
Sshd1Path /usr/sbin/sshd1
4. V "ssh2_config" dobavit' (vozmozhno izmeniv puti):
Ssh1Compatibility yes
Ssh1Path /usr/bin/ssh1
Nastroit' v ssh2 ogranicheniya dostup neprosto, poetomu samyj prostoj sposob -
zapuskat' ego cherez inetd.conf i dostup regulirovat' standartnymi fajlami TCP-wrappera hosts.allow/hosts.deny
/etc/inetd.conf
ssh2 stream tcp nowait root /usr/sbin/tcpd sshd2 -i
/etc/hosts.allow
sshd2 : 123.232.175.0/255.255.255.0, 127.0.0.0/255.0.0.0, 234.567.890.12
Esli posmotret' logi Linux serverov, to mozhno obnaruzhit' bol'shoe kolichestvo
soobshchenij ot demona sshd, svidetel'stvuyushchih o popytke podbora parolej po ssh.
Dec 6 11:03:11 artur sshd[2177]: Invalid user test from 193.220.141.151
Dec 6 11:03:11 artur sshd[2177]: Failed password for invalid user test from 193.220.141.151 port 46079 ssh2
Dec 6 11:03:15 artur sshd[2180]: Failed password for root from 193.220.141.151 port 46144 ssh2
Obratite vnimanie na zaderzhku mezhdu popytkami - neskol'ko sekund. Na toj
storone nahodyatsya "roboty". CHtoby ogranichit' kolichestvo popytok soedineniya
s odnogo IP adresa mozhno vospol'zovat'sya modulem recent netfil'tra.
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --update --seconds 20 -j DROP
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --set -j ACCEPT
nastrojka protstogo shlyuza
# iptables -F INPUT
# iptables -A INPUT -m state -state EASTABLISHED,RELATED -j ACCEPT
# iptables -A INPUT -i lo -j ACCEPT
# iptables -P INPUT DROP
# iptables -F FORWARD
# iptables -P FORWARD ACCEPT
# iptables -t nat -F
# iptables -t nat -A POSTROUTING -o {vneshnij interfej} -j SNAT to {vneshnij IP}
# Esli ip dinamicheskij to
# iptables -t nat -A POSTROUTING -o {vneshnij interfejs} -j MASQUERADE
Last-modified: Sun, 08 Jan 2006 12:19:38 GMT