Re: some reality about iptables, please
On Fri, 29 Aug 2003 14:42:46 -0700 Cam Ellison [EMAIL PROTECTED] wrote: * Steve Lamb ([EMAIL PROTECTED]) wrote: I beg to differ. When I installed shorewall, it gave some not-very-comprehensible options, and then did not give me what I wanted or needed. Erm, how hard can it be? For a single box, 1 interface: Edit interfaces. Add it as zone net, interface, detect. Now edit policy. Accept $FW to net and net to $FW. Drop net to all, and all to all. Type shorewall restart. You've now got your network interface accepting packets to the $FW (aka, the machine you're sitting on) and allowing packets out from the $FW to the net. Need a 2nd interface and NAT? Edit interfaces. Add 2nd interface as loc, interface, detect. Edit policy again. Accept loc to $FW, $FW to loc, loc to net and net to loc. Edit masq. Tell it the interface you want to masq out of and the interface you want to masq. Edit shorewall.conf, make sure that masq is turned on and packet forwarding is turned on. Type shorewall restart. Congrats. You now have a machine doing NAT. Need to lock it down a bit? Either edit policy to change the defaults of accept to reject or leave it. Go into rules. Common tasks: Port forward for NATed game machines and the like: DNAT net loc:192.168.0.1 tcp 9090 Locking down a service to the outside world: REJECT net $FW tcp 139 Accepting a service when policy is reject: ACCEPT net $FW tcp 139 There, in about 5 minutes I just gave a primer that covers about 80-90% of installs using Shorewall. I doubt you could do the same. Shorewall is not that hard. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgp0.pgp Description: PGP signature
Re: diagnosis - was Re: some reality about iptables, please
On Thu, Aug 28, 2003 at 06:36:00PM -0400, Bret Comstock Waldow wrote: No from Debian Mozilla. Here's an example of the messages: Aug 28 17:35:55 ganesha kernel: DROPl:IN= OUT=eth0 SRC=192.168.2.30 DST=205.156.51.200 LEN=44 TOS=0x00 PREC=0x00 TTL=64 ID=21328 DF PROTO=TCP SPT=34131 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 I'm curious that IN is blank. I'm going to pick up here.. I'll address some of your issues from other messages without quoting. I _think_ it's because it's an outoing packet.. From appearances, it looks like your first (SYN) packet from Mozilla is being blocked. I have to agree with the others that your best bet is to start from scratch and use one of the iptables setup tools. I used firestarter myself.. but there seems to be quite a bit of agreement that shorewall is good.. I'm sure either ( or possibly others) would do the job well. I think the main thing is to first sit down and work out exactly what your setup is, then go from there using the setup tool of your choice. I didn't study your rules, but from just scanning over them, there appears to be some redundancy in them.. RE: your complaint about the way the maintainer didn't write the rules for us.. I think that it would be impossible to write a general-purpose ruleset that would be appropriate for everyone.. and if he had attempted to do so, would probably have caused more problems and bug reports than he could handle. RE: where to put the rules.. Many like to put them in the ip-up.d directory, and this is the way firestarter did mine.. (I have a dial-up using ppp0 interface).. with the references to the outside made via the ip address. However, it seemed that doing all this setup might be taking too long to get me online, so I just changed these ip address references to the references to ppp0 and put them in the rc?.d directories, so now, this is all done at bootup rather than each time I dial up. AFAICT, this seems to be working well. With this setup, I'm not online for any brief instant where I'm open before policy is set to DROP. Also, for additional documentation, in your /usr/share/doc/iptables/html/ directory, you have the packet-filtering-HOWTO and the NAT-HOWTO. You may have this in your ruleset already, but with your setup, you will probably have to deal with NAT. Again, I really believe that you'd be best served to use a tool. Once these rules are in place, you can then go in and correct any problems you might have, and fine-tune anything you don't feel comfortable with. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: diagnosis - was Re: some reality about iptables, please
Bret Comstock Waldow wrote: On Thu, 2003-08-28 at 02:35, Jacob Anawalt wrote: [snip] Browser from Linux account or in VMWare Win98 works? Try both and let us know. IE from Win98 works, Mozilla from Debian doesn't. With these rules, samba couldn't restore the mapped drive I have from Win98 to /home/user. OK, lets start with just getting web browsing from Linux going. [snip] Does https to some secure server work from either/both? Yes from IE in Win98. No from Debian Mozilla. Here's an example of the messages: Aug 28 17:35:55 ganesha kernel: DROPl:IN= OUT=eth0 SRC=192.168.2.30 DST=205.156.51.200 LEN=44 TOS=0x00 PREC=0x00 TTL=64 ID=21328 DF PROTO=TCP SPT=34131 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 I'm curious that IN is blank. Thanks, Bret I don't know why IN is blank. A web browsing program running on your system (but not in VMWare) should only hit the OUTPUT chain. Looking at your rules on OUTPUT for www: Chain OUTPUT (policy DROP) target prot opt source destination [snip] DROPl tcp -- anywhere anywhere tcp dpt:www DROPl udp -- anywhere anywhere udp dpt:www [snip] REJECTlall -- anywhere anywhere Ok, so http/www traffic from anywhere to anywhere hitting the OUTPUT chain jumps to rule DROPl (drop log). I must have overlooked the DROPl for https, or it isn't there and https is hitting the last rule, REJECTl. Your log is for http://tgftp.nws.noaa.gov/, not an https example. Then again, you say ftp works (is that ftp using a web browser, or a command line FTP client that isn't in PASV mode?) If it is working from the command line in linux, then I guess these ftp rules are ACCEPTING the traffic, and https should work. ACCEPT tcp -- 192.168.2.30 anywhere tcp dpt:https flags:SYN,RST,ACK/SYN state NEW ACCEPT tcp -- 192.168.2.30 anywhere tcp dpt:ftp flags:SYN,RST,ACK/SYN state NEW ACCEPT tcp -- 192.168.2.30 anywhere tcp dpt:ftp-data flags:SYN,RST,ACK/SYN state NEW If that's the case, then I guess the ftp client is binding to 192.168.2.30 before starting traffic. Maybe Mozilla is trying to bind to your external or your loopback interfaces if https doesn't work. Anyway, my guess is that all the local http traffic is hitting the DROPl chain: Chain DROPl (168 references) target prot opt source destination LOGall -- anywhere anywhere LOG level warning prefix `DROPl:' DROP all -- anywhere anywhere So you can't browse the web, or use apt-get http://bla/ (Again, VMWare is a different case.) Maybe you meant to have some accept cases before the DROPl ones for specific types of HTTP traffic. Have you tried changing the default OUTPUT chain policy to ACCEPT and flush your OUTPUT chain for a minute? All you should be open to is software on your system (authorized or not) talking out on the internet. Lets see how that goes before tackling the SMB mount and VMWare email. Jacob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Aug 27, 2003 at 11:06:23AM -0400, Bret Comstock Waldow wrote: 1) If I use one of those tools, it does something, sets up something. What will it do? It's someone else's canned decisions about how to implement the choices I select from what it offers. What do I end up with? Are there any holes? How will I know if other choices I make open up holes because I don't know how it's all coordinated? You're welcome to go through the resulting config files and take a looksee for yourself. It's not like the Windows registry or reading an SQL database with less or anything like that. And I don't think leaving documentation like the above is very kind or useful for newbies. I apologize for sounding harsh, and I do remember my newbie days, but it appears that you missed the obvious. If I'm to figure out how to solve the problem, I need to know how, and leaving stress-inducing comments like that in released code is a cop-out. Howso? Why should the iptables maintainer be expected to write an end-to-end solution to this problem when there are tools already readily available that do exactly what you're asking? - -- .''`. Paul Johnson [EMAIL PROTECTED] : :' : `. `'` proud Debian admin and user `- Debian - when you have better things to do than fix a system -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/TzGnUzgNqloQMwcRAj31AJ9z5BIxKDN9putPlRcy69Ocj/Bp5ACfbAsJ K2UmCJdcSN52DO6OGCMGwnQ= =vHQJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
On Fri, 2003-08-29 at 06:57, Paul Johnson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Aug 27, 2003 at 11:06:23AM -0400, Bret Comstock Waldow wrote: 1) If I use one of those tools, it does something, sets up something. What will it do? It's someone else's canned decisions about how to implement the choices I select from what it offers. What do I end up with? Are there any holes? How will I know if other choices I make open up holes because I don't know how it's all coordinated? You're welcome to go through the resulting config files and take a looksee for yourself. It's not like the Windows registry or reading an SQL database with less or anything like that. The problem I am facing is I don't know enough (yet) to do that. Ok, learning is part of the deal. But I also wasn't finding answers to my questions. I found website after website that talked about the rules, but not so clear a discussion of where to put them, when to activate them, what to coordinate them with, all the surrounding aspects. What services get activated when? Which ones are relevant to this problem? To then run across one suggestion along with language suggesting he wasn't telling the whole story (so I could evaluate what to do with it) and inferring I'll have trouble if I use his suggestion was maddening. In jokes are great for people who are on the in - they may be at the expense of others. And I don't think leaving documentation like the above is very kind or useful for newbies. I apologize for sounding harsh, and I do remember my newbie days, but it appears that you missed the obvious. And if I did, what does that say about the documentation? Yes, I am an idiot sometimes. Perhaps this time too. If I'm to figure out how to solve the problem, I need to know how, and leaving stress-inducing comments like that in released code is a cop-out. Howso? Why should the iptables maintainer be expected to write an end-to-end solution to this problem when there are tools already readily available that do exactly what you're asking? No. I think a person can write whatever they like. I also think the standard for the documentation that's accepted for default installation with Debian maybe needs to meet a standard that does the job of providing useful information for as broad a range of users and skill and knowledge levels as can be arranged. Threatening doom and not saying why comes across a bit slack to me. Yes, this is a fun place we all get to be individuals in, joking with each other. OTOH, I'm a Software Quality Assurance Analyst for a living, and you don't leave users high and dry, and you don't play with them. That's not helpful. Bret -- bwaldow at alum dot mit dot edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
On 29 Aug 2003 10:26:57 -0400 Bret Comstock Waldow [EMAIL PROTECTED] wrote: Yes, this is a fun place we all get to be individuals in, joking with each other. OTOH, I'm a Software Quality Assurance Analyst for a living, and you don't leave users high and dry, and you don't play with them. That's not helpful. Why any user would want to start off with iptables when the examples provided point to several far easier and more comprehensive methods of handling those rules is beyond me. Stock answer to anyone who wants to muck around with firewall rules: aptitude install shorewall Until you got that down pat you've no business poking directly with iptables directly IMHO. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgp0.pgp Description: PGP signature
Re: some reality about iptables, please
On Fri, Aug 29, 2003 at 10:26:57AM -0400, Bret Comstock Waldow wrote: To then run across one suggestion along with language suggesting he wasn't telling the whole story (so I could evaluate what to do with it) and inferring I'll have trouble if I use his suggestion was maddening. In jokes are great for people who are on the in - they may be at the expense of others. [...] I also think the standard for the documentation that's accepted for default installation with Debian maybe needs to meet a standard that does the job of providing useful information for as broad a range of users and skill and knowledge levels as can be arranged. Threatening doom and not saying why comes across a bit slack to me. Yes, this is a fun place we all get to be individuals in, joking with each other. OTOH, I'm a Software Quality Assurance Analyst for a living, and you don't leave users high and dry, and you don't play with them. That's not helpful. I think you should mail the maintainer (via a bug report) and say so, then. He may well not read this list. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Aug 29, 2003 at 10:26:57AM -0400, Bret Comstock Waldow wrote: You're welcome to go through the resulting config files and take a looksee for yourself. It's not like the Windows registry or reading an SQL database with less or anything like that. The problem I am facing is I don't know enough (yet) to do that. OK, right now, go grab a shell prompt and start exploring the filesystem (there's very few places in the filesystem you can't change to as a normal user so don't bother going root), particularly through /etc. Things will start making *way* more sense. To then run across one suggestion along with language suggesting he wasn't telling the whole story (so I could evaluate what to do with it) and inferring I'll have trouble if I use his suggestion was maddening. Nobody else has the rest of the story, either. Not that it matters, odds are the guy working on the package knows what's wrong with his own package. Did you think of looking at the package information and perhaps emailing the maintainer for an explaination? Something like that isn't likely going to be answerable by the list (most of the developers don't read this list). And if I did, what does that say about the documentation? Yes, I am an idiot sometimes. Perhaps this time too. - -- .''`. Paul Johnson [EMAIL PROTECTED] : :' : `. `'` proud Debian admin and user `- Debian - when you have better things to do than fix a system -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/T24RUzgNqloQMwcRAqMBAJ4hZvRBawn1ZLAlXydzhLPDz9eRggCfa1hF BDeSblP7FSECttKh0wRFvo4= =9z1u -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
On Fri, 2003-08-29 at 10:44, Steve Lamb wrote: On 29 Aug 2003 10:26:57 -0400 Bret Comstock Waldow [EMAIL PROTECTED] wrote: Yes, this is a fun place we all get to be individuals in, joking with each other. OTOH, I'm a Software Quality Assurance Analyst for a living, and you don't leave users high and dry, and you don't play with them. That's not helpful. Why any user would want to start off with iptables when the examples provided point to several far easier and more comprehensive methods of handling those rules is beyond me. Stock answer to anyone who wants to muck around with firewall rules: aptitude install shorewall Until you got that down pat you've no business poking directly with iptables directly IMHO. And now I've heard your opinion. (No deprecation intended, please read on). Notice what I've gone through to get to a place where I get to hear it. Next, are you correct? Are you correct in my case? The reason I switched to Debian is that Red Hat is too proprietary. They make non-standard patches to the kernel, they've worked up a framework for administrating their distro, etc. that are proprietary. To work with it, I have to study Red Hat-isms, that don't apply to anything else. I've also used SuSE, which is great, but the same or worse than Red Hat. Suggestions I found on the web wouldn't work in either sometimes - they're set up in non-standard ways. So, I can invest my time into studying their proprietary systems, or... I went looking for something more just Linux, and Debian seems to meet the criteria (although the .deb system is specialized - still, it is widespread). So, the question is, what do I spend my time and attention studying? I've got two external intefaces, eth0 and ppp0. I've got two virtual internal interfaces to VMware, vmnet0 as a bridge to the Internet, and vmnet1 as a bridge to the host filesystem via samba. Lokkit locked up access to the host fs. firestarter also didn't handle vmnetX. fwbuilder looks great, but I need to know all the network stuff anyway to use it. How much study does it take for me to know enough about shorewall, fwbuider, firestarter, etc. to know it will solve my problems, how to use it, how to be sure of the implications, gotchas, etc.? And what do I have to study to know that? Should I put my effort into understanding iptables in the first place so I can evaluate what shorewall does, or put my effort into trying to get shorewall to do something (I can't evaluate if it's working - I don't know enough. What isn't it covering? How do I know?) Which comes first, the chicken or the egg? (I know - it's the rooster.) I got upset when the only answer I found was when someone implied they knew something important, but left few pointers to what it was. He was happy to spend a couple of paragraphs repeatedly emphasizing that there was something important - why didn't he spend a paragraph stating what it was? I don't like this because phrase #1 to look up on google, phrase #2 to look up on google, and/or phrase #3 to look up on google. Sorted. Done. Beyond that, I'm willing to put in the time to learn. I'm doing that now. Cheers, Bret -- bwaldow at alum dot mit dot edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
On Fri, 2003-08-29 at 10:42, Colin Watson wrote: On Fri, Aug 29, 2003 at 10:26:57AM -0400, Bret Comstock Waldow wrote: To then run across one suggestion along with language suggesting he wasn't telling the whole story (so I could evaluate what to do with it) and inferring I'll have trouble if I use his suggestion was maddening. In jokes are great for people who are on the in - they may be at the expense of others. [...] I also think the standard for the documentation that's accepted for default installation with Debian maybe needs to meet a standard that does the job of providing useful information for as broad a range of users and skill and knowledge levels as can be arranged. Threatening doom and not saying why comes across a bit slack to me. Yes, this is a fun place we all get to be individuals in, joking with each other. OTOH, I'm a Software Quality Assurance Analyst for a living, and you don't leave users high and dry, and you don't play with them. That's not helpful. I think you should mail the maintainer (via a bug report) and say so, then. He may well not read this list. I'm figuring on waiting until I understand enough to be sure I'm not just being an idiot to think so. If I turn out to be the only person on the planet who doesn't get this one - that's not a good reason to change things. Maybe the implications are clear as day to everyone else. When I can explain it myself, I'll understand it enough to speak to the issues. Cheers, Bret -- bwaldow at alum dot mit dot edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
On 29 Aug 2003 12:16:04 -0400 Bret Comstock Waldow [EMAIL PROTECTED] wrote: So, I can invest my time into studying their proprietary systems, or... All systems are proprietary. Debian is proprietary to Debian. Instead of learning Red-Hatisms you're learning Debianims. How much study does it take for me to know enough about shorewall, fwbuider, firestarter, etc. to know it will solve my problems, how to use it, how to be sure of the implications, gotchas, etc.? And what do I have to study to know that? The respective documentation? Should I put my effort into understanding iptables in the first place so I can evaluate what shorewall does, or put my effort into trying to get shorewall to do something (I can't evaluate if it's working - I don't know enough. What isn't it covering? How do I know?) Uh, by testing? It is far easier to set something up and test it than it is to learn the whole freakin' system from scratch. From what I've seen of your setup Shorewall would hand it trivially. Define 4 interfaces, define policy for those interfaces, define rules for which you need exceptions to policy. Done. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgp0.pgp Description: PGP signature
RE: some reality about iptables, please
Beyond that, I'm willing to put in the time to learn. I'm doing that now. Cheers, Bret If you want to spend some time getting down and dirty with iptables and Linux firewalls, I suggest reading a good book. I have the first and second editions of 'Linux Firewalls' published by New Riders and written by Robert Ziegler. I have found them very informative and extremely helpful. BTW, the first edition dealt with ipchains and the second edition with iptables. Get more information about the author here http://linux-firewall-tools.com/linux/ or just buy it the book here http://www.bookpool.com/.x/qe7qdiqfj4/sm/0735710996 -Jason -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
Apparently, Bret Comstock Waldow recently wrote: On Fri, 2003-08-29 at 10:44, Steve Lamb wrote: On 29 Aug 2003 10:26:57 -0400 Bret Comstock Waldow [EMAIL PROTECTED] wrote: Yes, this is a fun place we all get to be individuals in, joking with each other. OTOH, I'm a Software Quality Assurance Analyst for a living, and you don't leave users high and dry, and you don't play with them. That's not helpful. Why any user would want to start off with iptables when the examples provided point to several far easier and more comprehensive methods of handling those rules is beyond me. Stock answer to anyone who wants to muck around with firewall rules: aptitude install shorewall Until you got that down pat you've no business poking directly with iptables directly IMHO. And now I've heard your opinion. (No deprecation intended, please read on). Notice what I've gone through to get to a place where I get to hear it. Next, are you correct? Are you correct in my case? The reason I switched to Debian is that Red Hat is too proprietary. They make non-standard patches to the kernel, they've worked up a framework for administrating their distro, etc. that are proprietary. To work with it, I have to study Red Hat-isms, that don't apply to anything else. shorewall-evangelism-mode Seriously, I can't think of an easier and more powerful way to set up a firewall than to use shorewall. Even if you know iptables in and out, I can't see much reason(*) not to use shorewall. So, the question is, what do I spend my time and attention studying? I've got two external intefaces, eth0 and ppp0. I've got two virtual internal interfaces to VMware, vmnet0 as a bridge to the Internet, and vmnet1 as a bridge to the host filesystem via samba. I believe Steve is right. Try shorewall; it will do everything(*) you want, and is very well documented and easy to use. Should I put my effort into understanding iptables in the first place so I can evaluate what shorewall does, or put my effort into trying to get shorewall to do something (I can't evaluate if it's working - I don't know enough. What isn't it covering? How do I know?) Put effort into getting shorewall set up. It's very easy to get it up and running, and, IMHO, far surpasses most other firewall builder packages. There might be better ones that I haven't tried, but I have zero complaints about shorewall. Beyond that, I'm willing to put in the time to learn. I'm doing that now. http://www.shorewall.net - should have all the info you need. Just go try it; if I'm wrong about your needs(*), maybe shorewall isn't for you. But it will still take less time than squeezing answers out of debian-user, will take *far* less time than understanding iptables, and in the meantime, you'll have a lot better handle on exactly what functionality you need. (*) Unless the three things listed in http://www.shorewall.net/Shorewall_Doesnt.html are things you need (which is doubtful) this will probably get you up and running the fastest while giving you the widest range of flexibility. /shorewall-evangelism-mode Wes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
On 29 Aug 2003 10:26:57 -0400, Bret Comstock Waldow [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Yes, this is a fun place we all get to be individuals in, joking with each other. OTOH, I'm a Software Quality Assurance Analyst for a living, and you don't leave users high and dry, and you don't play with them. That's not helpful. ..uhoh. As you may remember from your too-prop Red Hat days, you needed to un-learn a lot of Wintendoism. Now you need to unlearn RedHatism. ;-) ..as root, do:' apt-get install shorewall '. Now. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
* Steve Lamb ([EMAIL PROTECTED]) wrote: enough. What isn't it covering? How do I know?) Uh, by testing? It is far easier to set something up and test it than it is to learn the whole freakin' system from scratch. From what I've seen of your setup Shorewall would hand it trivially. Define 4 interfaces, define policy for those interfaces, define rules for which you need exceptions to policy. Done. I beg to differ. When I installed shorewall, it gave some not-very-comprehensible options, and then did not give me what I wanted or needed. Nothing was going to get in, but it managed to prevent me from getting out, mis-assigned the interfaces, and was generally a PITA. I wiped it, and went back to adapting what I knew from ipchains. It wasn't easy at first to work directly from iptables, but once you wrap your head around the concepts, and have a look at scripts done by other people, it goes fairly well. Cam -- Cam Ellison Ph.D. R.Psych. From Roberts Creek on B.C.'s incomparable Sunshine Coast cam(at)ellisonet(dot)ca camellison(at)dccnet(dot)com cam(at)fleuryassociates(dot)com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
On Wed, 2003-08-27 at 14:12, Murray J. Brown wrote: BTW, the author's note was not a cop-out; it was actually an insightful remark, albeit terse and presumptive of some sophistication on the part of the user. I continue not to agree on this count. The note provided didn't say anything about _why_ it shouldn't be used. From a position of ignorance (newbie), I can infer, but can't know. Is it a security issue? A maintenance issue? Potential conflict with another commonly customized subsystem? Something else entirely? The author suggests he was hounded into providing it, despite the unexplained misgivings he had. I think his appropriate response if he thought there were serious problems with the approach would have been to say write it yourself if you think it's appropriate - I don't. Then, whoever wanted it would be responsible for making it work, explaining it, etc. As it is, he let the people who wanted it off the hook (so they don't take any responsibility), but he doesn't say why he doesn't think it should be used either - leaving people who don't have the background to do it without his contribution in the dark and uncertain. He's got a secret, but he isn't telling. I think that's a cop-out. The nature of IPtables isn't so fundamental as to allow me to expect everyone will have the background for it. He may be quite correct, and his advice (as far as it goes) valuable, but he sowed doubt, and didn't act to dispell it. And he could have. He's the one who knows. You probably know enough about IPtables to think of good reasons not to use the /etc/default/iptables method outlined, but you still can't be sure what _his_ reasons for deprecating it are. He might be thinking of something else. BTW, my previous post should have indicated PRE-up and POST-down clauses on the iface statement for the ppp connection. Thank you. I tried a few tools, but didn't understand some of what was occuring, and one of them wrote rules that screwed up my system's access. I'll look again. In the longer term, tying the rules to the network inits seems sensible. Cheers, Bret -- bwaldow at alum dot mit dot edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
On Wed, Aug 27, 2003 at 05:44:12PM +0100, Chris Wilcox wrote: First post folks so I'm unsure if we top post or not round here but everyone else seems to so I'll join in! :) We don't. Please post in conventional reading order, i.e. at the bottom! Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
Bret Comstock Waldow wrote: On Wed, 2003-08-27 at 14:12, Murray J. Brown wrote: BTW, the author's note was not a cop-out; it was actually an insightful remark, albeit terse and presumptive of some sophistication on the part of the user. I continue not to agree on this count. The note provided didn't say anything about _why_ it shouldn't be used. From a position of ignorance (newbie), I can infer, but can't know. Is it a security issue? A maintenance issue? Potential conflict with another commonly customized subsystem? Something else entirely? The author suggests he was hounded into providing it, despite the unexplained misgivings he had. I think his appropriate response if he thought there were serious problems with the approach would have been to say write it yourself if you think it's appropriate - I don't. Then, whoever wanted it would be responsible for making it work, explaining it, etc. As it is, he let the people who wanted it off the hook (so they don't take any responsibility), but he doesn't say why he doesn't think it should be used either - leaving people who don't have the background to do it without his contribution in the dark and uncertain. He's got a secret, but he isn't telling. The first paragraph of the document you were quoting from must not have stood out enough. I understand the frustration of things being different between distributions, and I have made the mistake of missing a critical piece of information that is already documented more than once. I hope this helps. [begin the big secret] $ head -11 /etc/default/iptables # /etc/init.d/iptables defaults file # INTRODUCTION: First thing first, I must warn you. The iptables # init.d setup and iptables tools themselves are VERY much capable # of locking you out of network services. This includes remote and # local network services, even localhost. You can even block local # console logins if authentication is network based. And please do # not be lulled into a false sense of security because you simply # installed the iptables package. It really does not provide a # firewall or any system security. # [end the big secret] So, to me it seems the author of the init.d script didn't want to make it because if you had saved some bad rules, it was slightly possible that you couldn't log into your system again after rebooting. I think it is good that they point out that just installing the iptables package doesn't provide a firewall or system security. They do go on to give directions on how to save and restore iptables rules after you have set them up. He doesn't talk about how to set up 'firewall' or 'nat' or any other rules in iptables (presumably) because the package isn't a firewall package. It is an 'IP packet filter administration tools' package. In the longer term, tying the rules to the network inits seems sensible. Cheers, Bret I hope that the network interface up/down scripts works for you. I agree it seems sensible (I just don't care to implement it myself at the moment.) Jacob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
Bret Comstock Waldow wrote: On Wed, 2003-08-27 at 00:39, Kevin Mark wrote: On Wed, 2003-08-27 at 00:19, Bret Comstock Waldow wrote: On Tue, 2003-08-26 at 23:14, Kevin Mark wrote: you can read /etc/init.d/iptables comments for info. Hmmm. On reading, I notice a function named initd_clear called by an argument of clear. Running this leaves the system open - all targets are ACCEPT. The README in /etc/init.d points at the Debian Policy manual, and this mentions several standard arguments for init.d scripts - clear isn't one of them. How would I find out what (if anything) calls with this argument? If some automated process is going to call this, it will leave my system with an open firewall, and I need to know to plan around it. snip the script can not be accessed by anyone. it can only be called inside the script which can only be run by a root user. So it doesnt see to be security concern (but I'm not a security expert -- will the local guru commment) I'll be interested to hear it too. In theory, there must be some reason it was put in the script in the first place... On my system the init.d scripts are o+rx, so anyone can read and execute them, so the script itself doesn't provide protection. I didn't change anything so I must assume this is the debian unstable default for /etc/init.d/ scripts. The commands the script tries to execute, iptables, iptables-save, iptables-root will not work from a normal user account. That the init.d script has a non-standard command targets isn't a bad thing, but it could re-inforce the fact that maybe running your iptables save/restore scripts from init.d isn't the most logical thing to do. My guess for the reason is simple. It is there because the script provides a conveniant interface to it. If you think of the iptables rules and the service they provide as an actual 'program' (instead of an interface to kernel ip rules) then 'starting' and 'stopping' that 'program' makes sense. If you think about it as an interface to the kernel ip rules then init.d script 'targets' such as clear, panic (RH7.3)/halt, load and save make sense. From your first message: Bret Comstock Waldow wrote: I can find all the sites and advice I want about how to form iptables rules, but I can't find any decent discussion of how to enable the damn things. I get the idea that an iptables firewall is set up by actually running a bunch of iptables -options lines, presumably from a script. But where do I put the script(s)? It's about as simple as this, as root, see if iptables is running and has rules you want or don't want. #iptables -L Now add the rules you want. I've seen lots of other replies with links to some informative pages. If you're still wondering, or looking I'd say this is the place to start: http://www.netfilter.org/ (aka) http://www.iptables.com/ And for specific documentation (in English): http://www.iptables.com/documentation/HOWTO//packet-filtering-HOWTO.html Check around the site. There are several links to HOWTOs and examples. You may find the same theme the author of the iptables init.d script used though. I'm a packet filtering interface not a firewall tool. _but_ the in iterface allows you to enter rules that you can call a firewall. [snip] I know generally about the /etc/init.d/rcX.d runlevel mechanism. Now I need a sensible discussion of when and HOW to run what sorts of iptables-rules-containing scripts so I can figure out how to protect my system. Please don't just tell me about runlevels - I know they exist already. You may understand this already, but indulge me anyway. I am going to re-explain a few things because questions I didn't directly address in all three quoted blocks from your emails have the same theme. How and when do my firewall rules get applied using this init.d script? Generally Debian systems run at init runlevel 3 (this is a change if you're reading about how to do things the RedHat way, or were use to it). When the init process enters a run level it runs start and stop scripts based on symbolic links in the /etc/rcrunlevel.d directory. Normally this is the only way the /etc/init.d scripts are called. You need to insert your own iptables rules to define your firewall and save them as 'active': /etc/init.d/iptables save active (Note, you may need to mkdir /var/lib/iptables.) You don't need to 'start' the iptables 'service' before doing this because unless you're running ipchains, iptables are always 'running', they just have an empty ACCEPT ruleset. The iptables init.d script may not be configured to 'run' automatically. If not, using update-rc.d iptables defaults may be what you want. Read man update-rc.d When the iptables init.d script runs automatically from the rcn.d init symbolic link or if you call it by hand, if an iptables-save file named 'active' exists in /var/lib/iptables then that file's rules are loaded using the iptables-restore program. Bret
Re: some reality about iptables, please
On Wed, 2003-08-27 at 23:13, Jacob Anawalt wrote: #192.168.1.1 doesn't get any traffic from us iptables -A OUTPUT -d 192.168.1.1 -j DROP That's the 'plumbing' level access to iptables which works for all Linux kernels supporting iptables, irreguardless of distribution. In other words, your rules failing on Debian should fail on RH or Mandrake. I think I've gotten a lot of the concept now, but this isn't what I meant. Initially I was coming from an understanding of fstab is a static file of rules the system reads to set up mounts, .gtkrc is a static file of rules the system reads to set up GUI... Later, there is the issue of when is the system in a configuration where it needs firewall rules? The Debian manual says runlevels 2-5 are user runlevels - these are enshrined in the update-rc.d defaults. K(ill) links are created by default in runlevels 0, 1, 6. Ok. But my network is up in runlevel 1. (From telinit 1. I haven't tried it from the boot prompt.) And then there's the question of coordination with who-knows-what other systems that are or aren't starting, stopping, etc. I meant a picture of where the rules are kept, how they're initialized, and what the implications are. I can find many sites with info about how to write rules that do X. I couldn't find a site that told me what file to put them in. Now I know there isn't one, and some other things about it all... A better post might be: What am I doing wrong with iptables rules Here are my rules. They block all access to the internet, but I cant see why. #iptables -L output from command #iptables -t other table(s) -L output from command(s) I've appended my current rules. Email fetches from my pop3 account ok, but the browser doesn't connect. It's pretty apparent that this text has bothered you. Perhaps you could post a bug against /etc/default/ipchains with a patch adding additional helpfull text, like a pointer to netfilter.org and the /usr/share/doc/ipchains/README.Debian.gz file and whatever other information you think is helpful for newbies. The solution isn't broken. 'Works for me' :) It just isn't optimal as the other posters have pointed out. The ifup-down method sounds very sensible. I didn't have an issue with the text, infact I had a good laugh reading it when I set up my sysem for /etc/init.d/iptables. I may. For now, I am going to keep studying until I do understand. Then I'll be in a better position to say why I think this isn't good language (if I still think it isn't when I get there). Cheers, Bret eth0: 192.168.2.30assigned by DHCP from gateway/router on cable modem. This is where I browse from. vmnet1: 192.168.174.1 virtual network device to communicate with VMware Windows 98 session. Requires no access to the outside. A bridge to eth0 provides Internet access from VMware. (I think.) iptables -t nat -L: Chain PREROUTING (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere Chain POSTROUTING (policy DROP) target prot opt source destination MASQUERADE all -- 192.168.174.0/24 anywhere ACCEPT all -- anywhere anywhere Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere iptables -L: Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- ganesha anywhere ACCEPT all -- 192.168.2.30 anywhere ACCEPT all -- 192.168.174.1anywhere DROPl all -- anywhere 255.255.255.255 DROPl all -- anywhere 192.168.174.255 DROPl all -- anywhere!192.168.2.30 DROPl all -- !192.168.174.0/24 anywhere DROPl tcp -- anywhere anywhere tcp dpts:0:tcpmux DROPl tcp -- anywhere anywhere tcp dpt:daytime DROPl tcp -- anywhere anywhere tcp dpt:linuxconf DROPl tcp -- anywhere anywhere tcp dpt:sunrpc DROPl tcp -- anywhere anywhere tcp dpts:netbios-ns:netbios-ssn DROPl tcp -- anywhere anywhere tcp dpts:161:162 DROPl tcp -- anywhere anywhere tcp dpt:445 DROPl tcp -- anywhere anywhere tcp dpt:1214 DROPl tcp -- anywhere anywhere tcp dpt:1999 DROPl tcp -- anywhere anywhere tcp dpt:2049 DROPl tcp -- anywhere anywhere tcp dpt:3049 DROPl tcp -- anywhere anywhere tcp dpt:4329 DROPl tcp --
Re: some reality about iptables, please
Bret Comstock Waldow wrote: On Wed, 2003-08-27 at 23:13, Jacob Anawalt wrote: #192.168.1.1 doesn't get any traffic from us iptables -A OUTPUT -d 192.168.1.1 -j DROP That's the 'plumbing' level access to iptables which works for all Linux kernels supporting iptables, irreguardless of distribution. In other words, your rules failing on Debian should fail on RH or Mandrake. I think I've gotten a lot of the concept now, but this isn't what I meant. Initially I was coming from an understanding of fstab is a static file of rules the system reads to set up mounts, .gtkrc is a static file of rules the system reads to set up GUI... Later, there is the issue of when is the system in a configuration where it needs firewall rules? The Debian manual says runlevels 2-5 are user runlevels - these are enshrined in the update-rc.d defaults. K(ill) links are created by default in runlevels 0, 1, 6. Ok. But my network is up in runlevel 1. (From telinit 1. I haven't tried it from the boot prompt.) And then there's the question of coordination with who-knows-what other systems that are or aren't starting, stopping, etc. I meant a picture of where the rules are kept, how they're initialized, and what the implications are. I can find many sites with info about how to write rules that do X. I couldn't find a site that told me what file to put them in. Now I know there isn't one, and some other things about it all... I feel I didn't make this clear enough then and I'm glad I understand you better now. If you use init.d/iptables, the rules are kept in memory while the system's running (ofcourse) and in the /var/lib/iptables/active file which is written by iptables-save when you run '/etc/init.d/iptables save active'. When the system reboots or changes runlevels, if you had run 'update-rc.d iptables defaults' and the /var/lib/iptables/active file exists, then those rules will be applied at runlevels 2-5. I've never tried to access networking from runlevel 1. I know from RH networking didn't start till runlevel 2, networking services (apache) didnt' start until runlevel 3, and X on runlevel 5. On Debian, I don't know, but I'll be interested if networking really is up at runlevel 1. I had always thought this was single-user, no networking but that may just be a RH idea. If networking is up at runlevel 1, just run update-rc.d for iptables runlevel 1-5. A better post might be: What am I doing wrong with iptables rules Here are my rules. They block all access to the internet, but I cant see why. #iptables -L output from command #iptables -t other table(s) -L output from command(s) I've appended my current rules. Email fetches from my pop3 account ok, but the browser doesn't connect. Wow, those were some rules. It will take a bit for me to get my head around them. Are you looking at a book on ipchains at the same time by chance? You have so many similar rules in the input, forward and output chains, that it reminds me of my old ipchains rules. I need to know some stuff though. Email from Linux account or VMWare client works? Try both and let us know. Browser from Linux account or in VMWare Win98 works? Try both and let us know. Also: Does ping to www.debian.org work from either/both? Does ftp to ftp.us.debian.org work from either/both? Does imap3 to some imap account (if you have one) work from either/both? Does https to some secure server work from either/both? Jacob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
On Wed, Aug 27, 2003 at 09:13:51PM -0600, Jacob Anawalt wrote: Bret Comstock Waldow wrote: On Wed, 2003-08-27 at 00:39, Kevin Mark wrote: the script can not be accessed by anyone. it can only be called inside the script which can only be run by a root user. So it doesnt see to be security concern (but I'm not a security expert -- will the local guru commment) I'll be interested to hear it too. In theory, there must be some reason it was put in the script in the first place... On my system the init.d scripts are o+rx, so anyone can read and execute them, so the script itself doesn't provide protection. I didn't change anything so I must assume this is the debian unstable default for /etc/init.d/ scripts. The commands the script tries to execute, iptables, iptables-save, iptables-root will not work from a normal user account. Yes. If you think about it: there's no point making the script unreadable by default, because anyone can download it from the Debian archive and read it there. Since it isn't set-id, there's no point not making it executable either, because anyone can just read it and execute the same commands from an interactive shell. If iptables worked as a non-root user, the security problem would be there, not in the calling script. In general I don't believe that there's ever any point making non-set-id scripts unreadable or unexecutable, except when they contain sensitive data. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
diagnosis - was Re: some reality about iptables, please
On Thu, 2003-08-28 at 02:35, Jacob Anawalt wrote: Wow, those were some rules. It will take a bit for me to get my head around them. Are you looking at a book on ipchains at the same time by chance? You have so many similar rules in the input, forward and output chains, that it reminds me of my old ipchains rules. The rules are from Real World Linux Security by Bob Toxen. I need to know some stuff though. Email from Linux account or VMWare client works? Try both and let us know. Email from Debian works. I don't get email via Win98 - I might as well douse myself in steak sauce and jump in the tiger pit at the zoo. Browser from Linux account or in VMWare Win98 works? Try both and let us know. IE from Win98 works, Mozilla from Debian doesn't. With these rules, samba couldn't restore the mapped drive I have from Win98 to /home/user. Also: Does ping to www.debian.org work from either/both? Debian: yes VMware: yes Does ftp to ftp.us.debian.org work from either/both? Debian: yes VMware: yes Does imap3 to some imap account (if you have one) work from either/both? Not a clue. I don't have an imap account. Does https to some secure server work from either/both? Yes from IE in Win98. No from Debian Mozilla. Here's an example of the messages: Aug 28 17:35:55 ganesha kernel: DROPl:IN= OUT=eth0 SRC=192.168.2.30 DST=205.156.51.200 LEN=44 TOS=0x00 PREC=0x00 TTL=64 ID=21328 DF PROTO=TCP SPT=34131 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 I'm curious that IN is blank. Thanks, Bret -- bwaldow at alum dot mit dot edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
On Tue, 2003-08-26 at 21:12, Bret Comstock Waldow wrote: I can find all the sites and advice I want about how to form iptables rules, but I can't find any decent discussion of how to enable the damn things. I get the idea that an iptables firewall is set up by actually running a bunch of iptables -options lines, presumably from a script. But where do I put the script(s)? There's a mechanism set up in /etc/default/iptables. I quote from the file: # A: I was pretty much hounded into providing it. I do not like it. #Don't use it. Use /etc/network/interfaces, use /etc/network/*.d/ #scripts use /etc/ppp/ip-*.d/ script. Create your own custom #init.d script -- no need to even name it iptables. Use ferm, #ipmasq, ipmenu, guarddog, firestarter, or one of the many other #firewall configuration tools available. Do not use the init.d #script. ... # Q: How do I get started? # A: (Did I mention do not use it already? Oh well.) For crissake! Can anyone point me at some sensible discussion of how the hell to go about putting firewall rules in place? I've got a laptop, usually on a cable modem, but sometimes using dial-up. I know generally about the /etc/init.d/rcX.d runlevel mechanism. Now I need a sensible discussion of when and HOW to run what sorts of iptables-rules-containing scripts so I can figure out how to protect my system. Please don't just tell me about runlevels - I know they exist already. The Debian Security manual is useless. It only give examples of a few iptables rules, says that's not enough, and speaks not at all (that I've found yet) about how to implement the damn things. Someone somewhere speaks to issue of the actual plumbing to implement iptables. Can anyone point me? snip you can read /etc/init.d/iptables comments for info. here is the short version: #clear out rules iptables -F #run script to load iptables rules into memory sh iptables.sh # make required directory? mkdir /var/lib/iptables #save active rule set /etc/init.d/iptables save active #flush rules -- inactive rule set iptables -F #save inactive rules set /etc/init.d/iptables save inactive # enjoy rules on next reboot or /etc/init.d/iptables start -Kev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
Thank you for this. My apologies to all for broadcasting my frustration. It's not the best way to handle things. Bret On Tue, 2003-08-26 at 23:14, Kevin Mark wrote: Someone somewhere speaks to issue of the actual plumbing to implement iptables. Can anyone point me? snip you can read /etc/init.d/iptables comments for info. here is the short version: #clear out rules iptables -F #run script to load iptables rules into memory sh iptables.sh # make required directory? mkdir /var/lib/iptables #save active rule set /etc/init.d/iptables save active #flush rules -- inactive rule set iptables -F #save inactive rules set /etc/init.d/iptables save inactive # enjoy rules on next reboot or /etc/init.d/iptables start -- bwaldow at alum dot mit dot edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
On Tue, 2003-08-26 at 23:14, Kevin Mark wrote: you can read /etc/init.d/iptables comments for info. Hmmm. On reading, I notice a function named initd_clear called by an argument of clear. Running this leaves the system open - all targets are ACCEPT. The README in /etc/init.d points at the Debian Policy manual, and this mentions several standard arguments for init.d scripts - clear isn't one of them. How would I find out what (if anything) calls with this argument? If some automated process is going to call this, it will leave my system with an open firewall, and I need to know to plan around it. Cheers, Bret -- bwaldow at alum dot mit dot edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
On Tue, Aug 26, 2003 at 09:12:15PM -0400, Bret Comstock Waldow wrote: I can find all the sites and advice I want about how to form iptables rules, but I can't find any decent discussion of how to enable the damn things. For network interfaces, I usually stick it as a pre-up item in the /etc/network/interfaces file: iface eth1 inet static address xxx netmask xxx network xxx broadcast xxx gateway xxx pre-up /etc/firewall/iptables.eth1 start post-down /etc/firewall/iptables.eth1 start For PPP connections, stick a script in the /etc/ppp/ip-up.d directory. -- Dave Carrigan Seattle, WA, USA [EMAIL PROTECTED] | http://www.rudedog.org/ | ICQ:161669680 UNIX-Apache-Perl-Linux-Firewalls-LDAP-C-C++-DNS-PalmOS-PostgreSQL-MySQL -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
On Wed, 2003-08-27 at 00:19, Bret Comstock Waldow wrote: On Tue, 2003-08-26 at 23:14, Kevin Mark wrote: you can read /etc/init.d/iptables comments for info. Hmmm. On reading, I notice a function named initd_clear called by an argument of clear. Running this leaves the system open - all targets are ACCEPT. The README in /etc/init.d points at the Debian Policy manual, and this mentions several standard arguments for init.d scripts - clear isn't one of them. How would I find out what (if anything) calls with this argument? If some automated process is going to call this, it will leave my system with an open firewall, and I need to know to plan around it. snip the script can not be accessed by anyone. it can only be called inside the script which can only be run by a root user. So it doesnt see to be security concern (but I'm not a security expert -- will the local guru commment) -k -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
On Wed, 2003-08-27 at 00:39, Kevin Mark wrote: On Wed, 2003-08-27 at 00:19, Bret Comstock Waldow wrote: On Tue, 2003-08-26 at 23:14, Kevin Mark wrote: you can read /etc/init.d/iptables comments for info. Hmmm. On reading, I notice a function named initd_clear called by an argument of clear. Running this leaves the system open - all targets are ACCEPT. The README in /etc/init.d points at the Debian Policy manual, and this mentions several standard arguments for init.d scripts - clear isn't one of them. How would I find out what (if anything) calls with this argument? If some automated process is going to call this, it will leave my system with an open firewall, and I need to know to plan around it. snip the script can not be accessed by anyone. it can only be called inside the script which can only be run by a root user. So it doesnt see to be security concern (but I'm not a security expert -- will the local guru commment) I'll be interested to hear it too. In theory, there must be some reason it was put in the script in the first place... Cheers, Bret, who wishes he could just get on with drinking tea and exploring Space-Time Physics -- bwaldow at alum dot mit dot edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
On 26 Aug 2003, Bret Comstock Waldow wrote: I can find all the sites and advice I want about how to form iptables rules, but I can't find any decent discussion of how to enable the damn things. I get the idea that an iptables firewall is set up by actually running a bunch of iptables -options lines, presumably from a script. Correct. But where do I put the script(s)? Depends. For networkcards use the pre-up and post-down directives in /etc/network/interfaces. I seem to recall that for ppp you would do this through the /etc/ppp/ip-up and /etc/ppp/ip-down scripts. I think man pppd will help you out in that case. Sorry, I haven't used ppp ever before... For crissake! Can anyone point me at some sensible discussion of how the hell to go about putting firewall rules in place? I've got a laptop, usually on a cable modem, but sometimes using dial-up. Well, this is only for plain NICs (e.g. ethx) and does not explain NAT, but maybe this is of some help to you: http://huizen.dto.tudelft.nl/devries/security/iptables_example.html I know generally about the /etc/init.d/rcX.d runlevel mechanism. Now I need a sensible discussion of when and HOW to run what sorts of iptables-rules-containing scripts so I can figure out how to protect my system. Please don't just tell me about runlevels - I know they exist already. Hmm, I am a proponent of not burdening the system unnecessarily. So, most of the time I advice against initializing the firewall from run-level x. I would suggest doing this where/when it is most appropriate (to me that is }:-), which to me is just before the interface is activated. Someone somewhere speaks to issue of the actual plumbing to implement iptables. Can anyone point me? plug class=shameless-but-well-meantread the page on the above URL/plug I wrote it in the hope it would be clear enough for people in just the situation you're finding yourself in right now. If you think it is missing something I'll try to improve it. HTH P.S. I just checked it and found that zless /usr/share/doc/iptables/README.Debian.gz will give you some useful examples. Grx HdV -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Aug 26, 2003 at 09:12:15PM -0400, Bret Comstock Waldow wrote: # A: I was pretty much hounded into providing it. I do not like it. #Don't use it. Use /etc/network/interfaces, use /etc/network/*.d/ #scripts use /etc/ppp/ip-*.d/ script. Create your own custom #init.d script -- no need to even name it iptables. Use ferm, #ipmasq, ipmenu, guarddog, firestarter, or one of the many other #firewall configuration tools available. Do not use the init.d #script. For crissake! Can anyone point me at some sensible discussion of how the hell to go about putting firewall rules in place? I've got a laptop, usually on a cable modem, but sometimes using dial-up. Oh, give us a break. You and the unsubscribers have something in common: You posted the solution to your problem. Use ferm, ipmasq, ipmenu, guarddog, firestarter, or one of the many other firewall configuration tools available. Do not use the init.d script. - -- .''`. Paul Johnson [EMAIL PROTECTED] : :' : `. `'` proud Debian admin and user `- Debian - when you have better things to do than fix a system -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/TJIgUzgNqloQMwcRAkF+AJ9h99AHUDYY2U2nSlzVmrxFriGaXwCZAajh UoFjcTaGZjIsot9EX98We74= =EZPF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
On Wed, 2003-08-27 at 07:12, Paul Johnson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Aug 26, 2003 at 09:12:15PM -0400, Bret Comstock Waldow wrote: # A: I was pretty much hounded into providing it. I do not like it. #Don't use it. Use /etc/network/interfaces, use /etc/network/*.d/ #scripts use /etc/ppp/ip-*.d/ script. Create your own custom #init.d script -- no need to even name it iptables. Use ferm, #ipmasq, ipmenu, guarddog, firestarter, or one of the many other #firewall configuration tools available. Do not use the init.d #script. For crissake! Can anyone point me at some sensible discussion of how the hell to go about putting firewall rules in place? I've got a laptop, usually on a cable modem, but sometimes using dial-up. Oh, give us a break. You and the unsubscribers have something in common: You posted the solution to your problem. Use ferm, ipmasq, ipmenu, guarddog, firestarter, or one of the many other firewall configuration tools available. Do not use the init.d script. But please notice two things: 1) If I use one of those tools, it does something, sets up something. What will it do? It's someone else's canned decisions about how to implement the choices I select from what it offers. What do I end up with? Are there any holes? How will I know if other choices I make open up holes because I don't know how it's all coordinated? I'm working with a copy of Real World Linux Security, and the fellow provides a complete firewall for SOHO, and then dissects it to show the concerns and his choices. He also links it to adaptive firewall rules to lock out attackers. And it's for Redhat, Mandrake, etc. I have to reconstruct it for Debian to use it. So I need to know how to plumb it. On running it by hand as an experiment, it locks all access - no browser, mail, etc., so I need to learn more so I can work it all out. And there isn't a lot of discussion I've found yet about the plumbing of firewalling. 2) Other people do indeed have answers to the question - and I haven't seen so much of a discussion of these issues in any of the sources I've Googled yet. The Debian Security manual really falls down on this issue. The book I'm reading points out that many people make the mistake of flushing the rules before adding the new ones - the default policy is ACCEPT. My upset isn't appropriate here. I apologize. I think my questions are appropriate, though. And I don't think leaving documentation like the above is very kind or useful for newbies. If I'm to figure out how to solve the problem, I need to know how, and leaving stress-inducing comments like that in released code is a cop-out. If it's broke, provide a solution, or at least a decent discussion of the issues involved, so I can work one out. Maybe I'll end up figuring one out. Cheers, Bret -- bwaldow at alum dot mit dot edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
Bret, I will address your question, but first: before delving into constructing your own iptables rules, I suggest you seriously look at might want to look at what some of the firewall tools can do for you unless you really understand what you're doing. I suggest you look at Shorewall and Bastille for IP filtering firewalls.(Bastille has some great scripts for platform hardening but I prefer shorewall's firewall configuration.) Zorp is an application-layer firewall that has gotten some attention lately but I haven't evaluated it myself -- I expect it might be good as a personal firewall to complement my site firewall, especially for catching unauthorized outbound traffic as might originate from a sploit, trojan or spyware. Assuming you already have your tables, policies and chain rulesets defined and assigned targets, you can use the iptables-save and iptables-restore commands (and/or their respective ip6tables counterparts) to save and restore the configuration. Once you've manually saved the iptables configuration, the /etc/init.d/iptables script can be used to restore a saved configuration at boot time. Better yet (as recommended in the bit of documentation you quoted), you can bind an initialization script to the device startup. For example, I use the up and down parameters on the iface statement in my network interface definition for my ppp connection (in the file /etc/network/interfaces), for example: auto ppp0 iface ppp0 inet ppp up /etc/init.d/firewall start down /etc/init.d/firewall stop Hope this helps. ...Murray On Tue, 2003-08-26 at 21:12, Bret Comstock Waldow wrote: I can find all the sites and advice I want about how to form iptables rules, but I can't find any decent discussion of how to enable the damn things. I get the idea that an iptables firewall is set up by actually running a bunch of iptables -options lines, presumably from a script. But where do I put the script(s)? There's a mechanism set up in /etc/default/iptables. I quote from the file: # A: I was pretty much hounded into providing it. I do not like it. #Don't use it. Use /etc/network/interfaces, use /etc/network/*.d/ #scripts use /etc/ppp/ip-*.d/ script. Create your own custom #init.d script -- no need to even name it iptables. Use ferm, #ipmasq, ipmenu, guarddog, firestarter, or one of the many other #firewall configuration tools available. Do not use the init.d #script. ... # Q: How do I get started? # A: (Did I mention do not use it already? Oh well.) For crissake! Can anyone point me at some sensible discussion of how the hell to go about putting firewall rules in place? I've got a laptop, usually on a cable modem, but sometimes using dial-up. I know generally about the /etc/init.d/rcX.d runlevel mechanism. Now I need a sensible discussion of when and HOW to run what sorts of iptables-rules-containing scripts so I can figure out how to protect my system. Please don't just tell me about runlevels - I know they exist already. The Debian Security manual is useless. It only give examples of a few iptables rules, says that's not enough, and speaks not at all (that I've found yet) about how to implement the damn things. Someone somewhere speaks to issue of the actual plumbing to implement iptables. Can anyone point me? thanks much in advance, Bret -- bwaldow at alum dot mit dot edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
First post folks so I'm unsure if we top post or not round here but everyone else seems to so I'll join in! :) It took me weeks of searching and asking of questions to a knowledgable friend before I even got close to understanding iptables. Although it's Red Hat based, I wrote up most of what I have learnt and stuck it on my website (running behind almost that exact script) if you're interested. It's basic I guess but 'may' be a good starting place: http://www.nryonline.co.uk/documents/html/iptablesFirewall.htm Hope it helps, Regards, nry Bret, I will address your question, but first: before delving into constructing your own iptables rules, I suggest you seriously look at might want to look at what some of the firewall tools can do for you unless you really understand what you're doing. I suggest you look at Shorewall and Bastille for IP filtering firewalls.(Bastille has some great scripts for platform hardening but I prefer shorewall's firewall configuration.) Zorp is an application-layer firewall that has gotten some attention lately but I haven't evaluated it myself -- I expect it might be good as a personal firewall to complement my site firewall, especially for catching unauthorized outbound traffic as might originate from a sploit, trojan or spyware. Assuming you already have your tables, policies and chain rulesets defined and assigned targets, you can use the iptables-save and iptables-restore commands (and/or their respective ip6tables counterparts) to save and restore the configuration. Once you've manually saved the iptables configuration, the /etc/init.d/iptables script can be used to restore a saved configuration at boot time. Better yet (as recommended in the bit of documentation you quoted), you can bind an initialization script to the device startup. For example, I use the up and down parameters on the iface statement in my network interface definition for my ppp connection (in the file /etc/network/interfaces), for example: auto ppp0 iface ppp0 inet ppp up /etc/init.d/firewall start down /etc/init.d/firewall stop Hope this helps. ...Murray On Tue, 2003-08-26 at 21:12, Bret Comstock Waldow wrote: I can find all the sites and advice I want about how to form iptables rules, but I can't find any decent discussion of how to enable the damn things. I get the idea that an iptables firewall is set up by actually running a bunch of iptables -options lines, presumably from a script. But where do I put the script(s)? There's a mechanism set up in /etc/default/iptables. I quote from the file: # A: I was pretty much hounded into providing it. I do not like it. #Don't use it. Use /etc/network/interfaces, use /etc/network/*.d/ #scripts use /etc/ppp/ip-*.d/ script. Create your own custom #init.d script -- no need to even name it iptables. Use ferm, #ipmasq, ipmenu, guarddog, firestarter, or one of the many other #firewall configuration tools available. Do not use the init.d #script. ... # Q: How do I get started? # A: (Did I mention do not use it already? Oh well.) For crissake! Can anyone point me at some sensible discussion of how the hell to go about putting firewall rules in place? I've got a laptop, usually on a cable modem, but sometimes using dial-up. I know generally about the /etc/init.d/rcX.d runlevel mechanism. Now I need a sensible discussion of when and HOW to run what sorts of iptables-rules-containing scripts so I can figure out how to protect my system. Please don't just tell me about runlevels - I know they exist already. The Debian Security manual is useless. It only give examples of a few iptables rules, says that's not enough, and speaks not at all (that I've found yet) about how to implement the damn things. Someone somewhere speaks to issue of the actual plumbing to implement iptables. Can anyone point me? thanks much in advance, Bret -- bwaldow at alum dot mit dot edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] _ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some reality about iptables, please
Hi Bret, On Wed, 2003-08-27 at 11:06, Bret Comstock Waldow wrote: On Wed, 2003-08-27 at 07:12, Paul Johnson wrote: [snip] But please notice two things: 1) If I use one of those tools, it does something, sets up something. What will it do? It's someone else's canned decisions about how to implement the choices I select from what it offers. What do I end up with? Are there any holes? How will I know if other choices I make open up holes because I don't know how it's all coordinated? I'm working with a copy of Real World Linux Security, and the fellow provides a complete firewall for SOHO, and then dissects it to show the concerns and his choices. He also links it to adaptive firewall rules to lock out attackers. And it's for Redhat, Mandrake, etc. I have to reconstruct it for Debian to use it. So I need to know how to plumb it. [snip] Perhaps your frustration is better directed at the author of your Perl book for not fully explaining how all the plumbing is implemented on *your* system of choice. ;-) You might want to consider that there is some merit to the other firewall solutions out there. Not to dismiss the book or it's author, but the wide acceptance of these other OPEN SOURCE tools, subject to harsh critical review by security professionals, does give some comfort. Yet, you're right to be critical yourself so another approach for you to consider might be to start with an existing tool (any of shorewall, guarddog or Bastille, would be a good choice) and dissect it to learn how it works, including how it's rules are generated, are related to each other and invoked during boot-up, network interface start/stop and/or upon detection of some event. You should use the knowledge gleaned from that book (and others) to assess the various strengths and weaknesses of the rulesets, scripts, etc... and tune/tweak or reinvent the wheel as you envisage it should be. ;-) In short, don't use that text as a cookbook but learn the fundamentals and apply them to assess/tune an existing solution that best fits your needs. 2) [snip] My upset isn't appropriate here. I apologize. I think my questions are appropriate, though. And I don't think leaving documentation like the above is very kind or useful for newbies. If I'm to figure out how to solve the problem, I need to know how, and leaving stress-inducing comments like that in released code is a cop-out. If it's broke, provide a solution, or at least a decent discussion of the issues involved, so I can work one out. A specific discussion on firewalls is perhaps better suited for a security-related mailing list or forum. Debian's plumbing is not that different from many other flavours of *nix so I'm sure you'll find any insights found there can be easily applied to your own circumstances. You might try the comp.security.firewalls news group. BTW, the author's note was not a cop-out; it was actually an insightful remark, albeit terse and presumptive of some sophistication on the part of the user. ...Murray BTW, my previous post should have indicated PRE-up and POST-down clauses on the iface statement for the ppp connection. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
