On 2012/08/08 04:52, Tim wrote:
On Wed, 2012-08-08 at 15:26 +0530, Jatin K wrote:
is there any way or method available to configure iptables to allow only
dhcp server assigned ip , means if user manually sets his/her systems ip
address then Linux gateway(FC16) should reject it .
user must use the ip address which is assigned by dhcp, ( dhcp server is
running on the same machine where iptables are installed, and machine is
acting as a gateway )
You could script something so that a computer added to the DHCP pool
gets added to the iptables rules, but can you actually achieve what you
want?
Are you simply blocking the client's access to the DHCP server (gateway
on it)? That's easy enough to block via an IP rule.
Are you trying to block the client to anything, in which case your
gateway must actually be *between* the client and other things (merely
being on the same network isn't enough). Otherwise, the gateway can
simply be bypassed.
And if a user manually assigns themselves the same IP, coincidentally,
should it be allowed or blocked? Do you just care about the address, or
do you need a DHCP client acknowledge?
It sounds more like you need some sort of authentication system, rather
than just IP assignment.
Such a script has one significant problem.
Let's go over what it must do. First the script would read the log file
to determine DHCP activity. When it detects a newly assigned address it
must allow it in iptables. When it discovers an address being relinquished
it must disallow that address in iptables.
That sounds fairly simple. What could possibly go wrong? Well, for one
try pulling the Ethernet cable on a machine before you shut it down. There
is no message for that machine relinquishing its address. So the address
remains open. That's just one mechanism for failure of log monitoring
techniques or any other technique that relies only on what DHCPD knows.
So can we play smarter? I'd try the basic DHCP monitoring, Then I'd find
or develop a tool for periodically (on a seconds basis) check to see if
all the dhcp assigned boxes on the local net are still there. As soon as
they are registered as "not there" a flag is set with the former MAC and
IP addresses associated with the flag. If it remains disconnected for
more than five minutes inform DHCPD, somehow, to forcibly flush the
address that is no longer being used.
That is generally going to be safe from a set of naive users. If you have
ONE smart user who diagnoses what you are doing he can wait for a machine
to go down, using the same technique you used to detect it, and jump in
almost immediately spoofing that machine's MAC address. DHCP never learns
that the machine is down. And you still have the system penetrated.
Methinks what I'd do is put in two distinct network segments. One is open
to the world. The other is open to the too easily hackable wireless
router. Both get DHCP addresses from two different DHCP servers. The
access from machine to machine would require an ssh login. As long as the
ssh login remains the iptables configuration on the "gateway" machine
would open up to the internal network using two way IP address translation
to a distinct address per box. As soon as the ssh connection is shown to
be down, the door slams shut. The ssh connection could simply send a small
handshake packet periodically to perform this test.
Methinks I'll look into implementing that latter trick. I sort of like it.
And I have three different DHCP servers around here to play with in this
regard. All I need is a very serous round-tu-it.
{^_^}
{^_^}
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
