Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
HI!
I am running a transparent box FC2 with squid 2.5 stable9.
I have implemented the mac check script with a little added spice that now I have binded an ip to a mac.
the problem is that the user can change their ips and mac addresses..uhhhh.....
Need to have some kind of reverse probe system to avoid this so the closed client remains closed even if he/she changes the ip and mac to an allowed clients record..
#ALLOW USERS
/sbin/iptables -I INPUT -p all -s $IP -m mac --mac-source $MAC -j ACCEPT
/sbin/iptables -I FORWARD -p all -s $IP -m mac --mac-source $MAC -j ACCEPT
#DENY USERS
/sbin/iptables -I INPUT -p all -s $IP -m mac --mac-source $MAC -j DROP
/sbin/iptables -I FORWARD -p all -s $IP -m mac --mac-source $MAC -j REJECT
********************************************************
now the same old question....
will the user be stoped even if they change their IP address and MAC address to an ip and mac address of an allowed user cause I did a test..
I blocked my own winxp systems ip and mac... then chenged my ip and mac (XP system) to an ip and mac of a client that was in the allowd list...
I started using the net...ufff.....
plz any directions pointers.... im all eyes and ears
any help in this regard will be much appreciated...
Take a look at arpwatch and arpstar. They both keep track of MAC-IP pairings and will notify you if it detects any changes or ARP poisoning. I haven't tried out Arpstar yet, but it looks like it can take some more pro-active measures when it detects anomalous traffic.
I have a feeling he used the INPUT chain because it's a transparent proxy, but you're right, it should be PREROUTING. The PREROUTING chain is processed before the INPUT chain anyway. Note that you need to append it to the nat table, like so
Code:
iptables -t nat -A PREROUTING <your rules>
There is, however, another potential problem with your firewall rules: why are you inserting instead of appending them? The -I directive tells iptables to put the rule at the top of the rule chain, so other rules in the same chain that come after won't be processed (becasue the packet will either be accepted or dropped, if they match those MAC rules, which I assume are exhaustive for your network).
Anyway, there is easier way to do MAC restricting
See man arp, the "-f" option. There you don't load iptables with useless rules.. the arp table always exist, so why don't use it
I'd stick with one of the two software that I posted earlier. Having arp poisoning occurring on an internal LAN is certainly something that should set off major redflags and you should want to know about immediately. Using arp -f is going to load a static arp table that you need to manually update everytime a new host is added and will also leave you blind to an arp poisoning attack occurring on the internal LAN. Plus arpstar has several features to protect the arp table in situations where it feels a poisoning might be occurring.
I'd also be very hesistant to do any type of filtering in the nat PREROUTING chain unless I knew for certain that packets were somehow being altered before they hit the FORWARD chain. The problem with filtering in the nat table chains is that only the first packet in a stream is checked and all subsequent packets are passed. In FORWARD all subsequent packets will be checked too. So unless I had a specific reason to filter in PREROUTING, I'd do so in FORWARD. There is actually a note in most of the netfilter guides not to filter in PREROUTING for that very reason
You could restrict the network access at the switch. There are switches which act as a RADIUS server.
If your switch supports RADIUS authentication I think this is the best method.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.