Prevent access to linux server when mac adress does not match ip adress

Discussion in 'Linux Networking' started by kris houben, Oct 31, 2006.

  1. kris houben

    kris houben Guest


    i am running a red hat 6.2 server which is used for internet ip traffic
    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.


    Kris Houben
    kris houben, Oct 31, 2006
    1. Advertisements

  2. Gee... something more recent maybe?
    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.

    Davide Bianchi, Oct 31, 2006
    1. Advertisements

  3. RH 6.2 is best OS from RH 3 up to RH 9, for sure.
    iptables on rh6.2? no way :)
    Johny be Good, Oct 31, 2006
  4. yeah, sure, is also 10 years old and no longer supported.
    A good reason to update to something less geriatrical.
    Davide Bianchi, Oct 31, 2006
  5. kris houben

    Moe Trin Guest

    On Tue, 31 Oct 2006, in the Usenet newsgroup comp.os.linux.networking, in
    What possible reason do you have for using a six year old distribution that
    has been unsupported for three and a half years?
    Do you specifically need DHCP? Are the systems moving between this, and
    other networks? That's the only conceivable reason for using DHCP.
    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
    Moe Trin, Oct 31, 2006
  6. 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 bitch to him to
    upgrade and not to help him resolve the issue.
    ipchains are working for him, he have RH6.2, accept it...
    be Good
    Johny be Good, Oct 31, 2006
  7. 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.
    Duane Evenson, Nov 7, 2006
  8. 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.
    Allen McIntosh, Nov 8, 2006
  9. kris houben

    Moe Trin Guest

    On Tue, 07 Nov 2006, in the Usenet newsgroup comp.os.linux.networking, in
    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.
    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.
    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.
    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.
    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.
    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
    Moe Trin, Nov 8, 2006
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.