Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Well, to be more specific, I don't want to include both 67 and 68 in sports and dports.
So for instance, if the linux machine is a dhcp client, is it ok to use in the INPUT chain --dport 68 and --sport 67 and if it is the dhcp server, the reverse, --dport 67 and --sport 68? Does that allow for a proper dhcp transfer? Or how should I do it?
Maybe if it's a dhcp client, I should just work at the OUTPUT chain and let iptables work out the relationship between 67 and 68? (you know, like the ftp conntrack module does, where you don't need to specify both 20 and 21 ports for the connection to be identified as established/related), and if it's the server, work only in the INPUT chain? Now that I think about it, a dhcp connection cannot actually be established, can it?
I guess I don't understand thoroughly how iptables deals with dhcp transfers.
I don't know that iptables can "work out" any relationships on it's own. Just block / open the ports for the protocols you want.
Easiest may be if you post your current config script, as any isolated lines we may be able to throw out here won't necessarily make sense in the context of your config.
That said, you might just want to close everything and then step by step open things up and just try if it works. That way you'll find out how big a hole you need...
Does that make sense?
So for instance, if, I am the dhcp client, what rule should I introduce?
what about access to UDP --sport 58 and --dport 57 in OUTPUT and the reverse in INPUT? Does this make sense?
I take it you mean 68 and 67, but basically what you say seems to make sense. However, Although I typically set up my firewall to block any incoming traffic except established traffic I never have to manually open either 67 or 68. I am thinking this is because, as a client, I am the one initiating the dhcp negotiation. So my guess would be that in combination with your established,related input rule it should be sufficient to allow 68->67 on output.
Again, if you want to find out, you can always just test what happens if you don't open these ports.
One thing I found very useful when investigating something similar was firewall logging.
You can log every packet and see where it comes and goes just before it gets dropped because no other rule applied.
That helps a lot to understand better.
It's the -j LOG option you should look at. Set the log level to 4 so it shows up in your system logs.
/sbin/iptables -A INPUT -j LOG --log-level 4 --log-prefix 'IN_FIREWALL '
This would go right before the DROP line.
The logging then happens in /var/log/messages (at least on Debian). You can also make it go to another logfile, but that's a story for a different thread I guess.
Of course, yes, I meant 67 and 68, not 57/58. In my second post I got it right
So, that's the weird thing. I've been connecting to my server remotely for several months now with this restrictive iptables and only now did it cross my mind to allow dhcp access. And I am still wondering how come the ip lease hadn't expired. I checked the /var/log/messages (iptables logs are redirected to /var/log/iptables.log), and it was full of messages like this one:
Apr 19 11:40:22 myhost dhclient: DHCPREQUEST on eth0 to X.X.X.X port 67 (xid=0x120a262c)
Apr 19 11:40:22 myhost dhclient: send_packet: Operation not permitted
After entering: iptables -I OUTPUT 10 -m conntrack --ctstate NEW -p udp --dport 67 -j ACCEPT
I finally got:
Apr 19 11:42:01 myhost dhclient: DHCPREQUEST on eth0 to X.X.X.X port 67 (xid=0x120a262c)
Apr 19 11:42:01 myhost dhclient: DHCPACK from X.X.X.X (xid=0x120a262c)
Apr 19 11:42:02 myhost dhclient: bound to MY IP -- renewal in 39881 seconds.
My server rebooted very often and my /etc/sysconfig/network-scripts/ifcfg-eth0 shows:
So I'm having a hard time understanding how dhcp works/-ed and what really happened here. How was my server still connected?