Very Computer

Hello,

i am running a red hat 6.2 server which is used for internet ip traffic
measurement.
All clients connected to this server get a ip adress through dhcp. To be
sure that every client keeps getting the smake ip adress when it connects
the dhcp server gives ip adresses to the client pc's based on their mac
adress.  This works fine as long as the clients are not changing their ip
adress manualy.

Is there a way to prevent access to the linux server when the ip adress of a
certain client does not match the mac adress.

Thanks,

Kris Houben

RH 6.2 is best OS from RH 3 up to RH 9, for sure.

Quote:> > Is there a way to prevent access to the linux server when the ip adress of a
> > certain client does not match the mac adress.

> You could use iptable with the --mac-source check and the -s check to
> match both Mac and IP. If your version of iptable does support it.

iptables on rh6.2? no way :-)

On Tue, 31 Oct 2006, in the Usenet newsgroup comp.os.linux.networking, in

Quote:>i am running a red hat 6.2 server which is used for internet ip traffic
>measurement.

What possible reason do you have for using a six year old distribution that
has been unsupported for three and a half years?

Quote:>All clients connected to this server get a ip adress through dhcp. To be
>sure that every client keeps getting the smake ip adress when it connects
>the dhcp server gives ip adresses to the client pc's based on their mac
>adress.  This works fine as long as the clients are not changing their ip
>adress manualy.

Do you specifically need DHCP?  Are the systems moving between this, and
other networks? That's the only conceivable reason for using DHCP.

Quote:>Is there a way to prevent access to the linux server when the ip adress of a
>certain client does not match the mac adress.

Lessee, 6.2 came out of box with 2.2.14-5.0, and was updated over it's three
year life ending with 2.2.24-6.2.3 - that would still be IPCHAINS as a
firewall, and I don't recall it having a MAC address module.

I suppose the easiest way would be to use a static ARP setup. 'man arp' and
look at the -s (better still, the -f) option.  Obviously, this will ONLY
work where all hosts of concern are located on the same collision domain,
and no one is using proxyarp.

        Old guy

FC3 is 1 year old and no longer supported, so what is your point?

My point is that RH6.2 is working for him, and you * to him to
upgrade and not to help him resolve the issue.

Quote:> > iptables on rh6.2? no way :-)

> A good reason to update to something less geriatrical.

ipchains are working for him, he have RH6.2, accept it...

Quote:> David

be Good

I just checked my version of 6.1 and it has ipchain, 7.3 (my next version)
is running iptables. Iptables has much more features than ipchain. You may
be able to find a version of iptables packaged for 6.2.

I have a different opinion about upgrading than many. I figure if the
system is working well and doing everything you want, you shouldn't
upgrade. I have older systems running older versions of linux that I
wouldn't dream of upgrading. Sure it means knowing or researching legacy
apps if I ever need to change things, but upgrading just because you can
is an even greater waste of time. Often the upgrade is too big and bulky
for the older system anyways. I leave my older systems alone if I can and
just upgrade my new/unstable system.

It really depends.  We have some old 400Mhz machines in our lab running
RH 6.2 and 7.x.  They're just fine to route traffic and run nistnet.  I
doubt FC6 would even fit on their hard drives.

Anything in a DMZ or with a port that's open to the outside world is a
different story.  Once the bug fixes stop, they get upgraded or retired.

On Tue, 07 Nov 2006, in the Usenet newsgroup comp.os.linux.networking, in

Quote:>>> iptables on rh6.2? no way :-)

>> A good reason to update to something less geriatrical.
>I just checked my version of 6.1 and it has ipchain, 7.3 (my next version)
>is running iptables. Iptables has much more features than ipchain.

Prior to the 2.2.x kernel (1998), the firewall was controlled by "ipfwadm".
For 2.2.x, Rusty Russell reworked the firewall code in the kernel, and
introduced the IPCHAINS tool to control that. The code was again reworked
for the 2.4.x kernel in 1999, and the new user interface 'iptables' was
introduced.  I'm ignoring distribution specific and third party helper
tools that do the same thing.

Quote:>You may be able to find a version of iptables packaged for 6.2.

RH 6.2 began life March 27, 2000 with a 2.2.14-5 kernel out of box, and
ended up with a 2.2.24-6.2.3 kernel released March 19, 2003. Thus, it
was IPCHAINS only.

RH 7.0 was released in September 2000 with a 2.2.16-22 kernel, reaching
2.2.24-7.0.3 also on March 19, 2003. It was a very strange release, and
included pieces from a 2.4.0 pre-release candidate. Interestingly, it
came with both

       181327 Aug 30  2000 ipchains-1.3.9-17.i386.rpm
        74563 Aug 30  2000 iptables-1.1.1-2.i386.rpm

though I think everyone was using IPCHAINS (certainly it defaulted to
that).      RH7.1 introduced the 2.4.x kernel (2.4.2-2) in April 2001
and was updated to 2.4.20-30.7.legacy after end-of-life. Like 7.0, it
came with both ipchains-1.3.10-7 and iptables-1.2.1a-1, though the
built-in Red Hat tools (firewall-config-0.95-2) used IPCHAINS.  If I
recall correctly, the Red Hat "helper" tools didn't transition to using
iptables until RH 8.0.

Quote:>I have a different opinion about upgrading than many. I figure if the
>system is working well and doing everything you want, you shouldn't
>upgrade.

Are they totally inaccessible from any bad guys, or are you counting on
the fact that no one would believe you are still using wu-ftpd-2.6.1
(the last updated version supplied to RH 6.2), never mind patching all
of the rest of the security problems that have been uncovered since these
old releases became unsupported?  Don't forget, there was an exploit in
the wild that "got to" RH 6.2 boxes running the out-of-box applications.

Quote:>I have older systems running older versions of linux that I wouldn't
>dream of upgrading.

Sure - I know where a Red Hat 3.0.3 Picasso (March 1996, 1.2.13 kernel)
is on one of the isolated networks, and I think there is still a Red Hat
2.1 box from late 1995 back there as well. But they are not reachable
from the building network, never mind the company net or Internet.

Quote:>Sure it means knowing or researching legacy apps if I ever need to
>change things, but upgrading just because you can is an even greater
>waste of time. Often the upgrade is too big and bulky for the older
>system anyways.

It also means you have to take the responsibility for securing the box,
patching the security problems as they are reported - even though the
application author doesn't support it.

Quote:>I leave my older systems alone if I can and just upgrade my new/unstable
>system.

It's costing less than US$500 for the current crop of systems we're buying
for the users. Our servers tend to be cast-off user systems that have the
hard drives replaced, memory max'ed out, and eye-candy video card removed.
The software installs are standardized and semi-automated such that it
takes longer to unpack and cable the box than the tech spends configuring
the software install.    But how much does that $500 buy in admin time
trying to patch an unsupported distribution, or recover from an exploit.
Sorry - new hardware wins every time except in _most_ unusual circumstances..

        Old guy