Mailing List Archive: Re: [ANNOUNCE] Netparse 0.1 - a network stream parser

Re: [ANNOUNCE] Netparse 0.1 - a network stream parser

mack.joseph at epa

Feb 2, 2001, 6:36 AM

Post #1 of 7 (1004 views)

Julian Anastasov wrote:
>
> Hello,
>
> I just completed (well, in usable form) my healthchecking
> tool.

I'd like (eventually) to be able to check services on the VIP on
VS-DR||VS-Tun real-servers. I assume this will require an agent
running on the real-server.

In production, for security, we don't want the real-servers with
ports exposed unneccessarily.

For VS-DR real-servers, there should
be no ports listening on the RIP. On the VIP, only the LVS services
should be listening. (Well you can have a few extra services on the
RIP, eg ssh for connection between the LVS machines,
ntp for time synchronisation).

For the director, the number of ports open should be minimised
on the IPs on the NICs and the VIP should be blocked for all
ports except those LVS'ed.

In the version of my configure script that I am working on now,
for checking, I run multiscan (http://sourceforge.net/multiscan)
to look at ports 1:1024 on all the IPs on machines in the LVS.
I run multiscan on the real-servers from the director by ssh to
look at ports on the real-servers:VIP.

This multiscan info
is for information only at the moment. People will have to
change from inetd to tcpserver for a start. Currently
cluster monitoring tools (eg mon, which I'm using),
need services running on the RIP to
infer services being alive on the VIP.

I need such checking in the configure script anyhow. People
on the mailing list setup VS-DR LVS's which don't work
because their http/https setup on the real-server is listening
to the RIP and not the VIP. The configure script needs to
be able to check for services running on the real-server:VIP
during setup.

Joe

--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@epa.gov ph# 919-541-0007, RTP, NC, USA

Re: [ANNOUNCE] Netparse 0.1 - a network stream parser [ In reply to ]

Feb 3, 2001, 7:59 AM

Post #2 of 7 (999 views)

Hello,

On Fri, 2 Feb 2001, Joseph Mack wrote:

> I'd like (eventually) to be able to check services on the VIP on
> VS-DR||VS-Tun real-servers. I assume this will require an agent
> running on the real-server.

Yep, I don't see other solutions. An agent in the real server
have to run these checks (for L4 they can be bind(), for L7 netparse
or other tools) and to report the status to the director. But the
simpler solution is when these checks can be made to RIP:RPORT
on the director. IMO, the security built on the bind() syscall is
very complex and I prefer my services to listen on 0.0.0.0 if
possible. They any checks can be performed from the director. But
of course there are some services that use the bind() model.

> In production, for security, we don't want the real-servers with
> ports exposed unneccessarily.

Yes, but they can listen to private addresses that are not
visible. The users have different setups and they can select from
different ways to run these checks.

> For VS-DR real-servers, there should
> be no ports listening on the RIP. On the VIP, only the LVS services
> should be listening. (Well you can have a few extra services on the
> RIP, eg ssh for connection between the LVS machines,
> ntp for time synchronisation).

Yes, this is when RIP is visible. We can define HRIP which can
be Hidden RIP in the private network 192.168/16 that can be used only
for internal communications.

> For the director, the number of ports open should be minimised
> on the IPs on the NICs and the VIP should be blocked for all
> ports except those LVS'ed.
>
> In the version of my configure script that I am working on now,
> for checking, I run multiscan (http://sourceforge.net/multiscan)
> to look at ports 1:1024 on all the IPs on machines in the LVS.
> I run multiscan on the real-servers from the director by ssh to
> look at ports on the real-servers:VIP.

Hm, I will look at this software now.

> This multiscan info
> is for information only at the moment. People will have to
> change from inetd to tcpserver for a start. Currently
> cluster monitoring tools (eg mon, which I'm using),
> need services running on the RIP to
> infer services being alive on the VIP.
>
> I need such checking in the configure script anyhow. People
> on the mailing list setup VS-DR LVS's which don't work
> because their http/https setup on the real-server is listening
> to the RIP and not the VIP. The configure script needs to
> be able to check for services running on the real-server:VIP
> during setup.

Yes, may be games with raw sockets can work but this is a
routing problem too. I don't see a way to run such checks in the
director. You already know that I prefer the solution with agents
reporting information.

> Joe

Regards

--
Julian Anastasov <ja@ssi.bg>

Re: [ANNOUNCE] Netparse 0.1 - a network stream parser [ In reply to ]

mack at ncifcrf

Feb 3, 2001, 11:29 AM

Post #3 of 7 (995 views)

On Sat, 3 Feb 2001, Julian Anastasov wrote:

> I prefer my services to listen on 0.0.0.0 if
> possible.

I assume there are some environments where people won't be happy about
exposing ports. Ratz deals with security more than I do, so he'll be able
say if this is important or not. At my work, the govt holds industry
information that is confidential that these industries don't want their
competitors to have (industry doesn't like giving info to the govt in the
first place). Our machines are routinely port scanned to make sure we
haven't added new services and are routinely attacked by some govt dept to
look for holes. I would assume people like this would not want ports
showing even on private IPs (once you break into the director, the
real-server's IPs aren't private anymore).

After reading about tcpserver, I decided that I should at least make it
possible for people who want to minimise port exposure, to be able to
do so.

> Yes, may be games with raw sockets can work but this is a
> routing problem too. I don't see a way to run such checks in the
> director. You already know that I prefer the solution with agents
> reporting information.

My configure script is now running everything from the director.
The rc.lvs files get copied by scp to the real-servers and the
setup on the real-servers (including port scanning the VIP)
is run by ssh from the director.

It would be easy enough to run the mon alerts on the real-servers
(instead of the director as they are now) and have them report to the
director by ssh about the status of services on the realserver's VIP.

Joe
--
Joseph Mack mack@ncifcrf.gov

Re: [ANNOUNCE] Netparse 0.1 - a network stream parser [ In reply to ]

Feb 6, 2001, 5:45 PM

Post #4 of 7 (998 views)

Joseph Mack wrote:
>
> I'd like (eventually) to be able to check services on the VIP on
> VS-DR||VS-Tun real-servers. I assume this will require an agent
> running on the real-server.
>
> In production, for security, we don't want the real-servers with
> ports exposed unneccessarily.

Yes, but the agents can be clients, i.e. they will push the information
instead of letting the director to pull it from the real servers.

--
Florin Andrei

Re: [ANNOUNCE] Netparse 0.1 - a network stream parser [ In reply to ]

mack.joseph at epa

Feb 7, 2001, 4:46 AM

Post #5 of 7 (999 views)

Florin Andrei wrote:

> >
> > In production, for security, we don't want the real-servers with
> > ports exposed unneccessarily.
>
> Yes, but the agents can be clients, i.e. they will push the information
> instead of letting the director to pull it from the real servers.

what are the advantages of doing it this way?

Joe

--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@epa.gov ph# 919-541-0007, RTP, NC, USA

Re: [ANNOUNCE] Netparse 0.1 - a network stream parser [ In reply to ]

Feb 7, 2001, 11:58 AM

Post #6 of 7 (992 views)

Joseph Mack wrote:
>
> Florin Andrei wrote:
>
> > >
> > > In production, for security, we don't want the real-servers with
> > > ports exposed unneccessarily.
> >
> > Yes, but the agents can be clients, i.e. they will push the information
> > instead of letting the director to pull it from the real servers.
>
> what are the advantages of doing it this way?

But you said that "we don't want the real-servers with ports exposed
unneccessarily". So, if the agents are clients, the port will be open on the
director, instead of the real servers.
Well, that's a problem, too, but anyway...

--
Florin Andrei

Re: [ANNOUNCE] Netparse 0.1 - a network stream parser [ In reply to ]

mack.joseph at epa

Feb 7, 2001, 12:50 PM

Post #7 of 7 (997 views)

florin@sgi.com wrote:

> But you said that "we don't want the real-servers with ports exposed
> unneccessarily". So, if the agents are clients, the port will be open on the
> director, instead of the real servers.

I didn't know, was just asking.

> Well, that's a problem, too, but anyway...

if all communication (eg to an agent on the real-server)
is run on the director by ssh, then you only have one extra port
(the sshd port) exposed on the real-server. I'm prepared to
defend doing that to someone who it concerned about security.
As long as you're only doing this every 15secs or so,
I would hope it wouldn't put too much load on the director.

Joe

--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@epa.gov ph# 919-541-0007, RTP, NC, USA