[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dragonidsuser
Subject:    Re: drider with multiple IPs
From:       "Josh Larsen, Monitored Security"              <josh.larsen () MONITOREDSECURITY ! CO
Date:       2001-08-20 17:06:55
[Download RAW message or body]

Yes, this is more along the lines of what I am trying to do.
Unfortunately , I am in a position where running reverse NATs and/or
hacked up port redirectors and whatnot are not an option.  It's ok if it
is not possible to assign multiple IPs to a particular dragon, I just
need a definitive answer.  I am in a production environment, so I have a
limited testing capacity.

Am I correct in assuming that this would not be possible with the
current architecture?


Thanks,

Josh Larsen


-----Original Message-----
From: Hank Leininger [mailto:hlein@PROGRESSIVE-COMP.COM]
Sent: Monday, August 20, 2001 3:47 PM
To: DRAGONIDS-USERS@PEACH.EASE.LSOFT.COM
Subject: Re: drider with multiple IPs


On Mon, 20 Aug 2001, Ron Gula wrote:

> >T1s.  The device arbitrarily assigns NAT IPs to the host(s) behind it
-
> >there is a static NAT defined for the Dragon on each external
network.
> >This creates a problem with said Dragon Sensor when it attempts to
> >communicate with the manager.  It could (and does) try to communicate
> >with the manager with a different source IP.
>
> something like 208.200.28.13. At the Dragon Server, a connection
> entry should be set up for the outside NAT address with the Sensor
> name. If all four T1s are monitored with a Dragon Sensor each, then
> you have to put the IP address in the driders.cfg file four times.

I could be wrong but I read the above to mean that a single sensor might
go out any of the four paths, and will thus be seen on the outside as
one of four different IPs.  So, he could define four different sensors
in driders's config, but then a)the logs wouldn't be consolidated and
b)at any time three bogus red-blinkeys would show in driders' status.
...Unless you can define a single sensor to have one-of-these-IPs
instead of this-IP?

<hack>
One thing you could do, is run a NAT and/or small application-level TCP
plug proxy at the server side that accepts connections from any of the 4
possible IPs, and connects to the driders process from a static IP.

For instance, on the server run plug-gw on externalIP:9111 and have it
forward to 127.0.0.2:9111, configured to accept connections only from
the four IPs that the sensor might come in as (plug-gw is part of the
fwtk; there are other similar simple TCP-forwarding proxies, or as I
said do it with NAT).  Configure driders to think that that sensor's IP
is 127.0.0.2 (on some OSs you will have to add 127.0.0.2 as another IP
for the loopback device; try just pinging 127.0.0.2 and see if loopback
responds).  (If?) Driders is listening on IN_ADDR_ANY:9111, it will see
and accept the connection bound for 127.0.0.2, and as a side effect will
see the connection come *from* 127.0.0.2.  So, define that sensor as
being at IP 127.0.0.2, and it should Just Work[TM].
</hack>

Hank Leininger <hlein@progressive-comp.com>
E407 AEF4 761E D39C D401  D4F4 22F8 EF11 861A A6F1

[prev in list] [next in list] [prev in thread] [next in thread]