Re: jpunix.com and MX'ing

PGP message

From: "John A. Perry" <perry@jpunix.com>

   > A question, from an internet mail novice:  How does the 'invisible'
   > remailer advertise itself as its 'visible' name in it's outgoing
   > mail?  

Perhaps the easiest thing to do is to add a Received: field to all
outgoing remailed mail so that it appears that the visible site is
handling the invisible site as if it were UUCP or a firewall or
mailhub or something.  Since anybody who really wants find out who
actually owns the machine is going to, you might as well indicate the
real relation up front, namely, that the owner of the visible machine
routs mail for the invisible one.  In other words, there would be two
Received: fields in outgoing remailed mail.  The first (lower, later
in the stream) Received: field would be generated by the remailer
software.  The second would be added by the system sendmail.
It will be tricky to make this look just right.

Another way to mask this is to give the remailer its own IP address.
It's easy to recompile extra slip interfaces into a kernel; each gets
its own IP address.  Routing the output of the remailer through these
extra interfaces can require some hackery, though.  I only know about
this second hand, but evidently the BSDI 1.1 release added some BSD
4.4 feature that makes this kind of IP hack much easier.  

With an extra IP address, you then register a full suite of domain
names just like normal.  This could be a new second-level domain or a
subdomain of, say, techwood.org.  You'll want SOA, A, MX, and PTR
records.  The NS entry for the relevant domains (esp. PTR records)
will generally reveal the computer/network operator, but again, this
is a technical relationship only.  What you have done is pretty
completely separated the technical infrastructure from the remailer
operation.

What we're creating here, of course, is virtual machines.  Unix
kernels have supported multiple processes and multiple users for a
long time.  I expect multiple virtual machines this decade.

   The MX record idea was not 
   meant to totally hide a remailer. It was meant to act as a "casual" 
   mask for the remailer.

And I think this mask is quite good.  It's generally a good idea to
try the easier-to-deploy solutions first and see if they work.  All
the IP spoofing above takes a bit of work to do.  Just using an MX
record and getting a second postmaster address is clearly the first
thing to do.

Eric

Eric Hughes says:
> Another way to mask this is to give the remailer its own IP address.
> It's easy to recompile extra slip interfaces into a kernel; each gets
> its own IP address.  Routing the output of the remailer through these
> extra interfaces can require some hackery, though.  I only know about
> this second hand, but evidently the BSDI 1.1 release added some BSD
> 4.4 feature that makes this kind of IP hack much easier.  

In 4.4 kernels, you just configure an alias address.

For, say, SunOS 4.1.X, John Ioannidis released a virtual interface
driver; I saw the thing posted to the net recently so I suppose its
public now (though I'm not sure J.I. knew that was going to happen.)
Its not hard to set such things up; no real trickery needed.

Perry

From: "Perry E. Metzger" <perry@imsi.com>

   In 4.4 kernels, you just configure an alias address.

What is the mechanism by which a particular process picks an outgoing
IP address?

Eric

Eric Hughes says:
>    From: "Perry E. Metzger" <perry@imsi.com>
> 
>    In 4.4 kernels, you just configure an alias address.
> 
> What is the mechanism by which a particular process picks an outgoing
> IP address?

Same as always -- the bind system call! (Remember, machines have
always had multiple IP addresses, just not on the same interface.)

.pm

In message <9501231956.AA12009@snark.imsi.com> you write:
>
>Eric Hughes says:
>>    From: "Perry E. Metzger" <perry@imsi.com>
>> 
>>    In 4.4 kernels, you just configure an alias address.

That's what I just did on jpunix.com. It now answers to 198.133.124.3,
the block of IP addresses that belonged to jpunix.com. (jpunix had been
using an IP address "borrowed" from work)

 John A. Perry - KG5RG - perry@jpunix.com
 WWW - http://jpunix.com
 PGP 2.62 key for perry@jpunix.com is on the keyservers.
 PGP-encrypted e-mail welcome!
 
 Finger kserver@jpunix.com for PGP keyserver help.

eric@remailer.net (Eric Hughes) wrote:

>    From: "John A. Perry" <perry@jpunix.com>
> 
>    > A question, from an internet mail novice:  How does the 'invisible'
>    > remailer advertise itself as its 'visible' name in it's outgoing
>    > mail?  
> 
> Perhaps the easiest thing to do is to add a Received: field to all
> outgoing remailed mail so that it appears that the visible site is
> handling the invisible site as if it were UUCP or a firewall or
> mailhub or something.  Since anybody who really wants find out who
> actually owns the machine is going to, you might as well indicate the
> real relation up front, namely, that the owner of the visible machine
> routs mail for the invisible one.  In other words, there would be two
> Received: fields in outgoing remailed mail.  The first (lower, later
> in the stream) Received: field would be generated by the remailer
> software.  The second would be added by the system sendmail.
> It will be tricky to make this look just right.

This doesn't really sound too difficult.  Just have a script run as
user uucp which adds the header and hands the message to sendmail.

> Another way to mask this is to give the remailer its own IP address.
> It's easy to recompile extra slip interfaces into a kernel; each gets
> its own IP address.  Routing the output of the remailer through these
> extra interfaces can require some hackery, though.  I only know about
> this second hand, but evidently the BSDI 1.1 release added some BSD
> 4.4 feature that makes this kind of IP hack much easier.  

Yes, this can be done, but getting IP addresses isn't easy for most
people.  I would propose that we use the unassigned IP address blocks
which are reserved for private networks (see RFC 1597).  In fact,
we could even connect the remailer systems that use the private address
space via IP tunneling (swIPe maybe?  or SLIP over telnet?)  These
remailer hosts could then communicate with each other on a private
network, and gateway mail to the internet via "firewall" hosts.  This
approach would also allow us to connect private machines to the
remailer network by providing IP connectivity to hosts which currently
use software such as Term or TIA.  Having more remailers on private
machines would be a good thing IMHO.  Finally, such a network might
serve as a basis for building future untracable/anonymous IP routing
capability.

> What we're creating here, of course, is virtual machines.  Unix
> kernels have supported multiple processes and multiple users for a
> long time.  I expect multiple virtual machines this decade.

I wonder if the "Term" program could be modified to act as a virtual
machine?  For those not familiar with the program, it creates a unix
domain socket and supplies IP services via it, forwarding them over
a modem connection.  Many programs have been modified to work with
it.  Perhaps term could be modified to send its output to an IP
interface instead.  Each user on the system can run his own term
process and have his own virtual machine.

Again in the vein of simple to implement...you could set up several
ghost machines that don't really exist but look as if they where
connected to the IP machine through uucp.  I'm not really sure what
the From: address would look like, but it should be easy to generate.

If this was workable, you could create x ghost machines and randomly
pick a From: for each message.  True, the Inet box would be ID'ed,
but as a transmission agent, not an originator.

As I said, I don't know how uucp and Internet mix today, my e-mail
address used to say {...}!uunet!reign!storm.
--
America - a country so rich and so strong we can reward the lazy 
          and punish the productive and still survive (so far)

Don Melvin                  storm@ssnet.com                finger for PGP key.
 According to the obituary notices, a mean and unimportant person never dies.

> Again in the vein of simple to implement...you could set up several
> ghost machines that don't really exist but look as if they where
> connected to the IP machine through uucp.  I'm not really sure what
> the From: address would look like, but it should be easy to generate.
> 
> If this was workable, you could create x ghost machines and
> randomly pick a From: for each message.  True, the Inet box would
> be ID'ed, but as a transmission agent, not an originator.

Forwarded Message:


Received: by alpha.c2.org for me@alpha.c2.org
 From nobody@flame.sinet.org  Fri Jan 27 11:42:38 1995
Received: from myriad.pc.cc.cmu.edu (MYRIAD.PC.CC.CMU.EDU [128.2.93.177]) by infinity.c2.org (8.6.9/8.6.9) with SMTP id LAA24850 for <me@alpha.c2.org>; Fri, 27 Jan 1995 11:42:38 -0800
Received: from flame.sinet.org by myriad.pc.cc.cmu.edu 
                (Linux Smail3.1.28.1 #12)  
        id m0rXwcA-000vFYC; Fri, 27 Jan 95 14:45 EST
Message-Id: <m0rXwcA-000vFYC@myriad.pc.cc.cmu.edu>
Date: Fri, 27 Jan 95 14:45 EST
Subject: test
To: me@alpha.c2.org
From: nobody@flame.sinet.org (Anonymous)
Comments: This message did not originate from the above address.  It was automatically remailed by an anonymous mail service.  Please report inappropriate use to <complaints@flame.sinet.org>

John A. Perry wrote:
> 
> First of all, I hope you don't mind me posting this to a couple of 
> lists as I find your questions pertinent and should be of value to many 
> readers.

Oops, I actually meant to direct it to the list myself, but forgot
to edit my headers.  Sure.

> 
> > To what extent can the operator of such a remailer really hide his
> > actual site?
> 
> 	It depends on the level of control the remailer operator has on the 
> site that the remailer operates from.

Assume root.

I know that you can set the 'masquerade as' thing in sendmail, but
of course any other SMTP agents you deal with are going to
correctly identify you when you 'HELO' and you're going to wind
up in the header, somewhere... (well, except smail 3.1, and probably
others.)  -- I'm assuming here the best one will be able to do will
be equivalent to a forgery via port 25.

--Craig

"Craig A. Johnston" <caj@tower.stc.housing.washington.edu> wrote:
> John A. Perry wrote:
> >
> > First of all, I hope you don't mind me posting this to a couple of
> > lists as I find your questions pertinent and should be of value to many
> > readers.
> 
> Oops, I actually meant to direct it to the list myself, but forgot
> to edit my headers.  Sure.
> 
> >
> > > To what extent can the operator of such a remailer really hide his
> > > actual site?
> >
> >       It depends on the level of control the remailer operator has on
> > the site that the remailer operates from.
> 
> Assume root.

What if the remailer operator is not root?

I will offer to forward mail for MX records to any address via my
system (myriad.pc.cc.cmu.edu).  If you want to run a remailer, and
have it be completely hidden from nameserver lookups, ask John Perry
to create an MX record for your domain which points to
myriad.pc.cc.cmu.edu, and tell me the address you want it forwarded
to.  I will configure my SMTP daemon to forward all mail to your
domain to the email address your remailer is run on.

> I know that you can set the 'masquerade as' thing in sendmail, but
> of course any other SMTP agents you deal with are going to
> correctly identify you when you 'HELO' and you're going to wind
> up in the header, somewhere... (well, except smail 3.1, and probably
> others.)  -- I'm assuming here the best one will be able to do will
> be equivalent to a forgery via port 25.

Well, to obscure the origin of your outgoing mail, you could simply
forward via another remailer.  However, delivering directly to SMTP
port 25 would probably be a good idea.  Sendmail has an option to
set the from using -f, but you have to have it configured to allow
it.  Normally only root, uucp and daemon are allowed to use this
option.

On Sat, 21 Jan 95 22:12 EST  Matthew Ghio wrote:

>
>Well, to obscure the origin of your outgoing mail, you could simply
>forward via another remailer.  However, delivering directly to SMTP
>port 25 would probably be a good idea.  Sendmail has an option to
>set the from using -f, but you have to have it configured to allow
>it.  Normally only root, uucp and daemon are allowed to use this
>option.

This still won't quite do it. Clever mailers on the other end of
the connection (sendmail included) will do a name lookup based on
the IP address.  This will (usually) return the systems canonical
name, and sendmail will make sure to stick that in the header. In 
fact, if identd is running on the sending system, it will even stick
in the userid of the sender. 

The fix involves changing the in-addr.arpa domain tables for that ip
address to make it report another name.  This will take complicity on
the part of whoever manages those tables, and will complicate things
when dealing with hosts on the remailers local network. A good way to
work around this would be to slap another ethernet card in the machine
so it has two addresses, one configured normally for that network and
the other setup to be on remailer.net (or whatever.)

Since this includes the cooperation of a local network administrator
anyway, it makes most of the MX tricks a little less useful.
                                                    -- Dan
--
Dan Marner                             dmarner@mis.nu.edu
Network Weasel                         Finger for PGP 2.6 key including the
National University                    words "GMAAAEEAK", "god" and "JAAUR"

On Sat, 21 Jan 1995, Dan Marner wrote about one machine having two 
canonical names:

> A good way to
> work around this would be to slap another ethernet card in the machine
> so it has two addresses, one configured normally for that network and
> the other setup to be on remailer.net (or whatever.)

  or, a less expensive solution if you use BSDI or Linux, set up an alias 
or a dummy interface (virtual interface). (under linux you also have to 
add a route from your real interface to it.) it's what i do.
   this also requires another IP address and hence cooperation of whoever 
is giving you IP numbers, but it works like a charm.

-adam

Adam Feuer
adamfast@seanet.com