|
---------------------------------------------------------------------------
B-08. What port is XXX on?
The file /etc/services on most Unix machines lists the port
assignments for that machine. For a complete list of port
assignments, read RFC (Request For Comments) 1700 "Assigned Numbers"
---------------------------------------------------------------------------
B-09. What is an anonymous remailer?
This FAQ answer was written by Raph Levien:
An anonymous remailer is a system on the Internet that allows you to
send e-mail or post messages to Usenet anonymously.
There are two sorts of remailers in widespread use. The first is the
anon.penet.fi style, the second is the cypherpunk style. The remailer
at anon.penet.fi is immensely popular, with over 160,000 users over its
lifetime, and probably tens of thousands of messages per day. Its main
advantage is that it's so easy to use. The cypherpunks mailers, which
provide much better security, are becoming more popular, however, as
there is more awareness of them.
The user of the anon.penet.fi system first needs to get an anonymous id.
This is done either by sending mail to somebody who already has one (for
example, by replying to a post on Usenet), or sending mail to
ping@anon.penet.fi. In either case, penet will mail back the new anon
id, which looks like an123456@anon.penet.fi. If an123456 then sends
mail to another user of the system, then this is what happens:
1. The mail is transported to anon.penet.fi, which resides somewhere in
the vicinity of Espoo, Finland.
2. These steps are carried out by software running on anon.penet.fi.
Penet first looks up the email address of the sender in its
database, then replaces it with the numeric code. All other
information about the sender is removed.
3. Then, penet looks up the number of the recipient in the same
database, and replaces it with the actual email address.
4. Finally, it sends the mail to the actual email address of the
recipient.
There are variations on this scheme, such as posting to Usenet (in which
step 3 is eliminated), but that's the basic idea.
Where anon.penet.fi uses a secret database to match anon id's to actual
email addresses, the cypherpunks remailers use cryptography to hide the
actual identities. Let's say I want to send email to a real email
address, or post it to Usenet, but keep my identity completely hidden.
To send it through one remailer, this is what happens.
1. I encrypt the message and the recipient's address, using the public
key of the remailer of my choice.
2. I send the email to the remailer.
3. When the remailer gets the mail, it decrypts it using its private
key, revealing as plaintext the message and the recipient's address.
4. All information about the sender is removed.
5. Finally, it sends it to the recipient's email address.
If one trusts the remailer operator, this is good enough. However, the
whole point of the cypherpunks remailers is that you don't _have_ to
trust any one individual or system. So, people who want real security
use a chain of remailers. If any one remailer on the "chain" is honest,
then the privacy of the message is assured.
To use a chain of remailers, I first have to prepare the message, which
is nestled within multiple layers of encryption, like a Russian
matryoshka doll. Preparing such a message is tedious and error prone,
so many people use an automated tool such as my premail package.
Anyway, after preparing the message, it is sent to the first remailer in
the chain, which corresponds to the outermost layer of encryption. Each
remailer strips off one layer of encryption and sends the message to the
next, until it reaches the final remailer. At this point, only the
innermost layer of encryption remains. This layer is stripped off,
revealing the plaintext message and recipient for the first time. At
this point, the message is sent to its actual recipient.
Remailers exist in many locations. A typical message might go through
Canada, Holland, Berkeley, and Finland before ending up at its final
location.
Aside from the difficulty of preparing all the encrypted messages,
another drawback of the cypherpunk remailers is that they don't easily
allow responses to anonymous mail. All information about the sender is
stripped away, including any kind of return address. However the new
alias servers promise to change that. To use an alias server, one
creates a new email address (mine is raph@alpha.c2.org). Mail sent to
this new address will be untraceably forwarded to one's real address.
To set this up, one first encrypts one's own email address with multiple
layers of encryption. Then, using an encrypted channel, one sends the
encrypted address to the alias server, along with the nickname that one
would like. The alias server registers the encrypted address in the
database. The alias server then handles reply mail in much the same way
as anon.penet.fi, except that the mail is forwarded to the chain of
anonymous remailers.
For maximum security, the user can arrange it so that, at each link in
the chain, the remailer adds another layer of encryption to the message
while removing one layer from the email address. When the user finally
gets the email, it is encrypted in multiple layers. The matryoshka has
to be opened one doll at a time until the plaintext message hidden
inside is revealed.
One other point is that the remailers must be reliable in order for all
this to work. This is especially true when a chain of remailers is used
-- if any one of the remailers is not working, then the message will be
dropped. This is why I maintain a list of reliable remailers. By
choosing reliable remailers to start with, there is a good chance the
message will finally get there.
---------------------------------------------------------------------------
B-10. What are the addresses of some anonymous remailers?
To see a comprehensive list on anonymous remailers point your web
browser to http://anon.efga.org/~rlist/.
For more information regarding anonymous email, check out
http://web.rge.com/pub/security/cypherpunks/.
The following URL's allow you to send anonymous e-mail via the world
wide web:
http://www.anonymizer.com/email/remailer-power.cgi?to=
http://www.contrib.andrew.cmu.edu/~gurevich/anonymous-email/index.html
http://www.ozemail.com.au/~geoffk/anon/anon.html
---------------------------------------------------------------------------
B-11. What is 127.0.0.1?
127.0.0.1 is a loopback network connection. If you telnet, ftp, etc...
to it you are connected to your own machine.
---------------------------------------------------------------------------
B-12. How do I post to a moderated newsgroup?
Usenet messages consist of message headers and message bodies. The
message header tells the news software how to process the message.
Headers can be divided into two types, required and optional. Required
headers are ones like "From" and "Newsgroups." Without the required
headers, your message will not be posted properly.
One of the optional headers is the "Approved" header. To post to a
moderated newsgroup, simply add an Approved header line to your
message header. The header line should contain the newsgroup
moderators e-mail address. To see the correct format for your target
newsgroup, save a message from the newsgroup and then look at it using
any text editor.
A "Approved" header line should look like this:
Approved: voyager@sekurity.org
There cannot not be a blank line in the message header. A blank line
will cause any portion of the header after the blank line to be
interpreted as part of the message body.
For more information, read RFC 1036: Standard for Interchange of
USENET messages.
---------------------------------------------------------------------------
B-13. How do I post to Usenet via e-mail?
Through an e-mail->Usenet gateway. Send an a e-mail messages to
<newsgroup>@<servername>. For example, to post to alt.2600 through
nic.funet.fi, address your mail to alt.2600@nic.funet.fi.
Here are a few e-mail->Usenet gateways:
group.name@news.demon.co.uk
group.name@charm.magnus.acs.ohio-state.edu
group.name@undergrad.math.uwaterloo.ca
group.name@nic.funet.fi
group.name.usenet@decwrl.dec.com
---------------------------------------------------------------------------
B-14. What is a firewall?
A firewall is a system that is set up to control traffic flow between
two networks. Firewalls are most commonly specially configured Unix
systems, but firewalls have also been built out of many other systems,
including systems designed specifically for use as firewalls. The most
common firewall today is CheckPoint FireWall-1, but competitions such as
Cisco's PIX are quickly catching up on CheckPoint.
Many people disagree on the definiton of a firewall, and in this
discussion I will use the term loosely.
One type of firewall is the packet filtering firewall. In a packet
filtering firewall, the firewall examines five characteristics of a
packet:
Source IP address
Source port
Destination IP address
Destination port
IP protocol (TCP or UDP)
Based upon rules configured into the firewall, the packet will either be
allowed through, rejected, or dropped. If the firewall rejects the
packet, it sends a message back to the sender letting him know that the
packet was rejected. If the packet was dropped, the firewall simply
does not respond to the packet. The sender must wait for the
communications to time out. Dropping packets instead of rejecting them
greatly increases the time required to scan your network. Packet
filtering firewalls operate on Layer 3 of the OSI model, the Network
Layer. Routers are a very common form of packet filtering firewall.
An improved form of the packet filtering firewall is a packet filtering
firewall with a stateful inspection engine. With this enhancement, the
firewall "remembers" conversations between systems. It is then
necessary to fully examine only the first packet of a conversation.
Another type of firewall is the application-proxy firewall. In a
proxying firewall, every packet is stopped at the firewall. The packet
is then examined and compared to the rules configured into the firewall.
If the packet passes the examinations, it is re-created and sent out.
Because each packet is destroyed and re-created, there is a potential
that an application-proxy firewall can prevent unknown attacks based
upon weaknesses in the TCP/IP protocol suite that would not be prevented
by a packet filtering firewall. The drawback is that a separate
application-proxy must be written for each application type being
proxied. You need an HTTP proxy for web traffic, an FTP proxy for file
transfers, a Gopher proxy for Gopher traffic, etc... Application-proxy
firewalls operate on Layer 7 of the OSI model, the Application Layer.
Application-gateway firewalls also operate on Layer 7 of the OSI model.
Application-gateway firewalls exist for only a few network applications.
A typical application-gateway firewall is a system where you must telnet
to one system in order telnet again to a system outside of the network.
Another type of application-proxy firewall are SOCKS firewalls. Where
normal application-proxy firewalls do not require modifications to
network clients, SOCKS firewalls requires specially modified network
clients. This means you have to modify every system on your internal
network which needs to communicate with the external network. On a
Windows or OS/2 system, this can be as easy as swapping a few DLL's.
---------------------------------------------------------------------------
B-15. How do I attack a remote network across the Internet?
On a theoretical level, attacking a remote network across the Internet
is very simple.
First, you research to discover all of the IP address ranges used by the
target. Search the web, search Usenet, search Internet, search RIPE,
search APNIC, search everywhere.
Second, you identify all hosts in those IP address ranges. This may be
as simple as pinging each possible host in those networks. Be warned,
however, that many hosts will be protected by firewalls that prvent ICMP
ECHO Requests (used by ping) from reaching them. Those hosts may still
have vulnerable services running on them.
Third, you identify all open ports on each of those hosts. For example,
one host may be providing dns, bootp, and time services. This is
normally done by "port scanning" the host. Port scanning UDP ports is
much slower than port scanning TCP ports. TCP ports will respond
negatively when they are not open. UDP ports require you to wait for a
timeout. You may choose to scan only known ports, or to scan only ports
below 1024, or to scan all 65,535 ports.
Fourth, you attack vulnerable services. If you see a time server
running and you know of a time server exploit, you try it out. Perhaps
the target is running an OS that is not vulnerable, or perhaps the
system administrator has patched the target host. Or, maybe you will
succeed. Vulnerability information can be gleaned from Internet WWW
sites or mailing lists, traded privately, or developed on your own.
---------------------------------------------------------------------------
B-16. What is a TCP sequence prediction attack?
TCP is a reliable connection-oriented layer 4 (Transport Layer)
protocol. Packet transfer between hosts is accomplished by the layers
below layer 4 and TCP takes responsibility to making certain the packets
are delivered to higher layers in the protocol stack in the correct
order. To accomplish this reordering task, TCP uses the sequence number
field.
To successfully mount a TCP sequence prediction attack, you must first
listen to communications between two systems, one of which is your
target system. Then, you issue packets from your system to the target
system with the source IP address of the trusted system that is
communicating with the target system.
The packets you issue must have the sequence numbers that the target
system is expecting. In addition, your packets must arrive before the
packets from the trusted system whose connection you are hijacking. To
accomplish this, it is often necessary to flood the trusted system off
of the network with some form of denial of service attack.
Once you have taken over the connection, you can send data to allow you
to access the target host using a normal TCP/IP connection. The most
simple way to do this is:
echo "+ +" > /.rhosts
This specific technique relies upon inherent weaknesses in the BSD Unix
`r` services. However, SunRPC, NFS, X-Windows, and many other services
which rely upon IP address authentication can be exploited with a TCP
sequence prediction attack.
An excerpt from RFC 793 concering the generation of TCP sequence numbers:
When new connections are created, an initial sequence number
(ISN) generator is employed which selects a new 32 bit ISN. The
generator is bound to a (possibly fictitious) 32 bit clock whose
low order bit is incremented roughly every 4 microseconds. Thus,
the ISN cycles approximately every 4.55 hours. Since we assume
that segments will stay in the network no more than the Maximum
Segment Lifetime (MSL) and that the MSL is less than 4.55 hours
we can reasonably assume that ISN's will be unique.
The developers of the BSD Unix TCP/IP stack did not follow these
recommendations. TCP/IP stacks based upon BSD Unix increase the
sequence number by 128,000 every second and by 64,000 for every new TCP
connection. This is significantly more predictable than the algorithm
specified in the RFC.
TCP sequence prediction attacks are stopped by any router or firewall
that is configured not to allow packets from an internal IP address to
originate from an external interface.
TCP Header Format
-----------------
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SECTION C
|
