Re: jpunix.com and MX'ing
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
participants (9)
-
Adam Feuer -
Craig A. Johnston -
Dan Marner -
eric＠remailer.net -
ghio＠myriad.pc.cc.cmu.edu -
John A. Perry -
nobody＠flame.sinet.org -
Perry E. Metzger -
storm＠marlin.ssnet.com