[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: man-in-the-middle

On Thursday 07 October 2004 14:54, Hans du Plooy wrote:
> On Thursday 07 October 2004 14:30, maarten wrote:
> > Can you elaborate more on the network setup ?  I'm confused; if the
> > machines are on the same subnet, you can't prevent them from talking to
> > each other directly.
> Sure, they're not on the same subnet (unless you see the internet as one
> subnet).  They are both on public IPs - but for reasons that were not
> disclosed to me, they're not allowed to talk to each other directly, even
> though they can (I know, I'm itching to find out why too!).

Okay... So, the way they talk to each other is NOT though a hub/switch but 
through their respective <default gateways>, I must assume.
If so, this gives you a problem: Without access to either the gateways (or the 
machines) how can you override the route tables that are in place ?
Proxy-arp will not work unless both boxes believe they are on a shared 
network.  Let me put it this way: If box A has a netmask which includes box 
C, you can proxy-arp.  But if the respective netmasks do not include each 
other, there is little to none(*) you can do to prevent the boxes to send 
their request out to the gateway directly (thus your box will never even see 
them).  And that's... well, game over.

(*) well except for arp-spoofing the gateway and rerouting all that traffic by 
yourself, which I trust is really not where you wanna go...   

Another thing to consider is how they need to be connected. At which OSI layer 
level, let's say.  If they need protection from each other (worms, whatever) 
you cannot just bridge or route and be done with it. The level of protection 
will be effectively zero.  In this case, you'll need to proxy in some form or 
another, or filter, depending on the situation.

> Hence the box in the middle, which has two public IPs, so its basically
> just getting the box in the middle to act as a proxy of sorts between the
> other two (I do not know what the software is either - if it's something
> like Postfix there would be much cleaner ways to do this, but I don't know)
> without them knowing.
> > If they're not, there is a router somewhere, and
> > adding your box will certainly complicate the setup, both for you and for
> > the router-person. Also, does your box in the middle have one or two NICs
> > ?
> Two, each with a public IP.  I do not have the IPs yet, I'll only be given
> that when I'm taken to the server room (no idea why) but I need to know
> that I can do this before I waste my and the client's time going there.

Then you MUST know the netmasks, and whether they overlap or not.
Failing that, you cannot make any plan.  In my opinion at least.

Being able to set a routing entry on the boxes would certainly ease things...

You may also want to make sure that you're not held liable for rerouting 
traffic past their corporate firewalls (when applicable), because that is 
effectively what you're planning to do (again, depending on the setup, and 
the netmasks, and whatever).  

All in all, it sounds fishy to me.  That they want to keep box A and C in the 
dark about this I could understand, but not if you're also denied access to 
their routers (either directly or by -human- proxy).  At least, if I were the 
RP for those routers, I'd sure as hell want to know that you are doing this.
And from there it should be a small step to a little cooperation.

> > The thing is, if you just bridge everything, there is little use, is
> > there. The real question is _why_ do you need the box in the middle.  If
> > all it should look like to the boxen is just thin air, I don't see what
> > (legal) purpose that box would serve. Is it for protection ? Monitoring ?
> I wish I knew.  It's pretty senseless.
> > On that note: Do boxes A and C know that there is something in between
> > them?
> No, they shouldn't - that's the idea.  They are to believe that they are
> talking directly to one another, while they're actually talking to a linux
> box <evil grin :-> that's passing the message on, pretending to be the
> sender.  I hope that makes sense

If that is the case, aren't you afraid that an admin will note that there is 
something in between ?  By means of nmap OS scan, or by whatever means ?


When I answered where I wanted to go today, they just hung up -- Unknown

Reply to: