Re: Firewall-troubleshooting
Daniel Pittman wrote: ... So, probably, the best way to go is allowing the R/E packets alongside their new state counterparts. It also clarifies where the packets are accepted and WHY. Also, iptables -v should be a lot more useful than before. That was my point, basically. Thanks for actually saying it in a clear and comprehensible fashion. Daniel, would you mind showing me an example of what you think is a wise/correct/whatever use of R/E rules? The reason i'm trying to work through all of this is that i'm a Shorewall developer and would like to make sure it works in a way that makes security sense to other firewall users. -- Paul http://paulgear.webhop.net -- Did you know? Using Microsoft Internet Explorer can make your computer less secure. Find out more at http://browsehappy.com. signature.asc Description: OpenPGP digital signature
Re: Firewall-troubleshooting
On 5 Jul 2005, Paul Gear wrote: Daniel Pittman wrote: ... So, probably, the best way to go is allowing the R/E packets alongside their new state counterparts. It also clarifies where the packets are accepted and WHY. Also, iptables -v should be a lot more useful than before. That was my point, basically. Thanks for actually saying it in a clear and comprehensible fashion. Daniel, would you mind showing me an example of what you think is a wise/correct/whatever use of R/E rules? Sure, no problem. What I am talking about is something like this set of rules generated by firehol, to allow inbound http to the current machine: /sbin/iptables -t filter -A in_world_http_s1 -p tcp --sport 1024:65535 --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT /sbin/iptables -t filter -A out_world_http_s1 -p tcp --sport 80 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT Note that for both directions firehol specifies the protocol and ports that are valid. That, basically, is the restriction that I am talking about. The reason i'm trying to work through all of this is that i'm a Shorewall developer and would like to make sure it works in a way that makes security sense to other firewall users. Sure. I am very glad to see y'all taking such an active interest in the security of your package. It confirms my feeling that Shorewall is one of the better options for Linux firewall management out there. Daniel -- Most people's C programs should be indented six feet downward and covered with dirt. -- Blair P. Houghton -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firewall-troubleshooting
On Tue, Jul 05, 2005 at 10:00:53PM +1000, Daniel Pittman wrote: /sbin/iptables -t filter -A in_world_http_s1 -p tcp --sport 1024:65535 --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT /sbin/iptables -t filter -A out_world_http_s1 -p tcp --sport 80 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT IMHO, this is fairly redundant (and inefficient) unless you don't trust your firewall. (And in that case, why use it?) The examples of things that might require additional checking (e.g., ftp data connection) are arguably valid valid, but those are *RELATED* sessions, not *ESTABLISHED* sessions. If you're going to do something like the above you're better off just unloading the state module and setting up port filters (which is effectively what you're doing). Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firewall-troubleshooting
On 5 Jul 2005, Michael Stone wrote: On Tue, Jul 05, 2005 at 10:00:53PM +1000, Daniel Pittman wrote: /sbin/iptables -t filter -A in_world_http_s1 -p tcp --sport 1024:65535 --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT /sbin/iptables -t filter -A out_world_http_s1 -p tcp --sport 80 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT IMHO, this is fairly redundant (and inefficient) unless you don't trust your firewall. (And in that case, why use it?) The examples of things that might require additional checking (e.g., ftp data connection) are arguably valid valid, but those are *RELATED* sessions, not *ESTABLISHED* sessions. I probably should have posted an example that actually used RELATED connections, I guess. As to trusting the firewall, or not, there has been at least one bug where attackers could manipulate the content of the conntrack expect table remotely. Other bugs, local or remote, are not out of the question. If you're going to do something like the above you're better off just unloading the state module and setting up port filters (which is effectively what you're doing). An example with RELATED involved would have been more helpful, I guess. Anyway, I think we disagree about the value of this - I have less faith in the implementation than you do, which is fine, and see an advantage in the extra work to check ESTABLISHED things are going to the right place. Regards, Daniel -- When you are a Bear of Very Little Brain, and you Think of Things, you find sometimes that a Thing which seemed very Thingish inside you is quite different when it gets out into the open and has other people looking at it. -- A.A.Milne, _The House at Pooh Corner_, 1928 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firewall-troubleshooting
On Tue, Jul 05, 2005 at 11:57:37PM +1000, Daniel Pittman wrote: As to trusting the firewall, or not, there has been at least one bug where attackers could manipulate the content of the conntrack expect table remotely. Other bugs, local or remote, are not out of the question. No they're not. But if you cripple the firewall and rules to the extent you're doing you might as well just not use connection tracking. You've effectively turned the rules into stateless port filters anyway. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firewall-troubleshooting
Michael Stone wrote: On Tue, Jul 05, 2005 at 11:57:37PM +1000, Daniel Pittman wrote: As to trusting the firewall, or not, there has been at least one bug where attackers could manipulate the content of the conntrack expect table remotely. Other bugs, local or remote, are not out of the question. No they're not. But if you cripple the firewall and rules to the extent you're doing you might as well just not use connection tracking. You've effectively turned the rules into stateless port filters anyway. Mike Stone I disagree. I think you're missing the point. Just imagine I have a firewall with a mailserver and a ssh server behind it. Let me use: iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -m state --state NEW -p tcp -d mailserver --dport 25 -j ACCEPT iptables -A FORWARD -j DROP No one on the internet can reach the ssh server. Now we have a bug in the connection tracking module which permit an attacker to add expected tuples. Something like tcp 6 4 ESTABLISHED src=attacker dst=sshserver sport=1025 dport=22 ... You're exposed. But using iptables -A FORWARD -m state --state ESTABLISHED -p tcp -d mailserver --dport 25 -j ACCEPT you're fine. And you're not using iptables as a stateless firewall, because you're not allowing spurious packets, but only ESTABLISHED or NEW. Regards. Radel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firewall-troubleshooting
On Tuesday, 5 de July de 2005 14:11, Michael Stone wrote: On Tue, Jul 05, 2005 at 10:00:53PM +1000, Daniel Pittman wrote: /sbin/iptables -t filter -A in_world_http_s1 -p tcp --sport 1024:65535 --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT /sbin/iptables -t filter -A out_world_http_s1 -p tcp --sport 80 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT IMHO, this is fairly redundant (and inefficient) unless you don't trust your firewall. (And in that case, why use it?) The examples of things that might require additional checking (e.g., ftp data connection) are arguably valid valid, but those are *RELATED* sessions, not *ESTABLISHED* sessions. Let's write another example, where you allow navigation from 14 to 16 : iptables -A ACCEPTRE -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A ACCEPTRE -j LOGREJECT iptables -A FORWARD -i eth0 -s 192.168.0.0/24 -o eth1 -p tcp --dport 80 -m time --timestart 14:00 --timestop 16:00 --days Mon,Tue,Wed,Thu,Fri -j ACCEPT iptables -A FORWARD -o eth0 -d 192.168.0.0/24 -i eth1 -p tcp --sport 80 -m time --timestart 14:00 --timestop 16:00 --days Mon,Tue,Wed,Thu,Fri -j ACCEPTRE Does that make any more sense? If you accept all R/E packets at the beggining of the script, you won't be able to stop the connections. May the user have a proxy somewhere, those time-based rules are easily fooled. If you accept the R/E packets at the end of the script, you must yet do exactly the same thing I've done or reject the incoming packets in all other time spans. But the same applies to any other rule where you must control things down to the packet level. Think of packet size, marking, logging, level7 filtering, complicated routing (even load balancing/bonding), and so on. About this being inefficient : current typical firewall computers are grossly overpowered, so some low-time-consuming additional rules won't make any difference. CPU consumtion in a firewall comes from squid, level7 filtering, logging, etc... not from some basic iptables rules. And about this cluttering the firewall: usually the FORWARD chain is splitted in source-destination chains, so not only the added rules don't clutter the chains, but also the *clarify* what's going on in them. If you're going to do something like the above you're better off just unloading the state module and setting up port filters (which is effectively what you're doing). That's not true. Notice the STATE module. It's not the same as unstateful firewalling, where you can be easily fooled by tcp-flags weird games. We talk about using the stateful filtering, without limiting ourselves by its easy shortcut. When the ipchains to iptables switch is done, the first thing one thinks is : yahoo! let's forget about states! But the purpose of the STATE and CONNTRACK modules is to empower the user with the ability to deploy a stateful firewall, not to provide a single and universal shortcut that prevents the usage of other nifty modules. Also think about debugging : - With the explicit R/E accepting you get to know where (and so, why) a packet is accepted, and the path through there. It even enables you to do basic accounting. - With the accept R/E first you only know that the packet belongs a established or related connection. And may a conntrack module misbehave, not even that. - With the accept R/E last, you know the same as the 2nd case. The difference lies in that this way you can easily shoot yourself in your foot, and you won't easily know why. All it takes is some discipline when handwriting your firewall. And if you are using a tool, not even that. But for that the tools must not shoot their user's feet ;) -- - Eloi Granado ([EMAIL PROTECTED]) PGP Key: http://eloi.millorsoft.es/pgp-publickey.asc - pgpZ1wo0zHYXb.pgp Description: PGP signature
Re: Firewall-troubleshooting
Hi! On Tuesday 05 July 2005 14:00, Daniel Pittman wrote: /sbin/iptables -t filter -A in_world_http_s1 -p tcp --sport 1024:65535 --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT /sbin/iptables -t filter -A out_world_http_s1 -p tcp --sport 80 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT Note that if you don't allow RELATED packets for _all_ connections, you will have to explicitly allow at least fragmentation-needed icmp packets. Otherwise you will get problems with PMTU discovery which will lead to other obscure problems. Allowing some other icmp packets is probably a good idea as well (e.g. all destination-unreachable packets). Cheers, Stefan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firewall-troubleshooting
Daniel Pittman wrote: ... Am i right in understanding that you consider accepting RELATED/ESTABLISHED packets a bad thing? No. Accepting *any* RELATED/ESTABLISHED packets is, though, if someone finds an attack to generate entries in the conntrack table. Like, say, the active FTP NAT PORT bug from quite some time ago, which would allow remote attackers to do just that. :) Limiting the RELATED/ESTABLISHED packets to what you actually expect (part of an established connection to a service you actually use) is a more secure policy. I mustn't be understanding you here. Isn't the very definition of RELATED/ESTABLISHED that the packet is part of an established connection to a service actually used? How would you expect a RELATED/ESTABLISHED rule to be used, and how does this contrast with the way that shorewall or the OP's script works (i'm not sure which one you're inferring is not using RELATED/ESTABLISHED in the preferred way)? -- Paul http://paulgear.webhop.net -- Did you know? If you use two dashes followed by a space as your signature separator, good email programs will chop them off automatically, reducing noise in email replies. signature.asc Description: OpenPGP digital signature
Re: Firewall-troubleshooting
On Mon, Jul 04, 2005 at 07:45:47PM +1000, Paul Gear wrote: I mustn't be understanding you here. Isn't the very definition of RELATED/ESTABLISHED that the packet is part of an established connection to a service actually used? RELATED and ESTABLISHED are two different things. You've defined ESTABLISTED. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firewall-troubleshooting
On 4 Jul 2005, Paul Gear wrote: Daniel Pittman wrote: ... Am i right in understanding that you consider accepting RELATED/ESTABLISHED packets a bad thing? No. Accepting *any* RELATED/ESTABLISHED packets is, though, if someone finds an attack to generate entries in the conntrack table. Like, say, the active FTP NAT PORT bug from quite some time ago, which would allow remote attackers to do just that. :) Limiting the RELATED/ESTABLISHED packets to what you actually expect (part of an established connection to a service you actually use) is a more secure policy. I mustn't be understanding you here. Isn't the very definition of RELATED/ESTABLISHED that the packet is part of an established connection to a service actually used? I think I explained very badly: firehol restricts, by default, to matching on E/R packets *and* the permissible service ports, so that even if someone trick the system into expecting connections on a port you didn't open, the packets are not allowed through. The FTP 'PORT' bug I talk about above did allow this: by sending an appropriately formatted PORT string through an FTP connection, *anything* could be made into a 'RELATED' connection. So, if they wanted to talk to your SMB service, connect to FTP, send the string, then the blanket allow of RELATED packets would allow them to connect to the SMB server. Firehol would, by default, not have permitted that -- they could have created the 'RELATED' entry in the conntrack table, but the firewall would (probably[1]) still have refuse it, because RELATED packets to that specific port were not allowed. I hope that is clearer, and you can see where the difference in approach comes from now. How would you expect a RELATED/ESTABLISHED rule to be used, and how does this contrast with the way that shorewall or the OP's script works (i'm not sure which one you're inferring is not using RELATED/ESTABLISHED in the preferred way)? I can't comment on how shorewall works, because I have not looked at its code in the last year, or longer. Some of the similar scripts still stick a single allow for any E/R packet at the top, though. Most iptables documentation suggests the same, so I don't think it is particularly bad of the authors of these scripts. God knows I didn't do anything different when I had to write it all out by hand. Daniel Footnotes: [1] Some services you allow might have made it possible by allowing connections to this port. -- We do not talk--we bludgeon one another with facts and theories gleaned from cursory readings of newspapers, magazines, and digests. -- Henry Miller, _The Air-Conditioned Nightmare_ (1945) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firewall-troubleshooting
Michael Stone wrote: On Mon, Jul 04, 2005 at 07:45:47PM +1000, Paul Gear wrote: I mustn't be understanding you here. Isn't the very definition of RELATED/ESTABLISHED that the packet is part of an established connection to a service actually used? RELATED and ESTABLISHED are two different things. You've defined ESTABLISTED. You're missing my point. I understand the difference between related and established. I was oversimplifying for the sake of clarity. What i'm trying to work out is what Daniel is meaning when he says: It also tends to encourage shortcuts in the firewall, like accepting any RELATED/ESTABLISHED packets, because each option in the configuration file is actually an if statement around a bit of hand crafted firewall. and: Accepting *any* RELATED/ESTABLISHED packets is, though, if someone finds an attack to generate entries in the conntrack table. Like, say, the active FTP NAT PORT bug from quite some time ago, which would allow remote attackers to do just that. :) Limiting the RELATED/ESTABLISHED packets to what you actually expect (part of an established connection to a service you actually use) is a more secure policy. Or more to the point, how is Daniel suggesting to structure rules to make more secure use of RELATED/ESTABLISHED? Is it something to do with the ordering of rules, or perhaps splitting related and established and putting them at different points in the chains? -- Paul http://paulgear.webhop.net -- Did you know? Email viruses spread using addresses they find on the host computer. You can help to reduce the spread of these viruses by using Bcc: instead of To: on mass mailings, or using mailing list software such as mailman (http://www.list.org/) instead. signature.asc Description: OpenPGP digital signature
Re: Firewall-troubleshooting
On Sunday, 3 de July de 2005 23:24, Paul Gear wrote: Daniel Pittman wrote: It also tends to encourage shortcuts in the firewall, like accepting any RELATED/ESTABLISHED packets, Am i right in understanding that you consider accepting RELATED/ESTABLISHED packets a bad thing? It simplifies the deployment of handcrafted firewalls, but it can strike back when you want to control certain things. Specially when allowing R/E packets is the first thing you do. For example, time dependant rules like allow navigation/ftp from 14 to 16 hours translate into allowing NEW connections like allow new ftp connections from 14 to 16, and let them stay open for ever. Obviously, that's not what you probably meant when writting those time based rules. Problems would also arise with individual packet logging. You could move all those weird rules before the R/E packet acceptance, but that would make the handcrafted firewall unmantainable. Leaving the R/E packets acceptance to the end should solve all this problems, but that would mean that your R/E packets would be traversing all your firewall rules, so extra care should be taken. Also some people will have something to say about performance and delays, but with current typical horsepower it shoudn't matter. So, probably, the best way to go is allowing the R/E packets alongside their new state counterparts. It also clarifies where the packets are accepted and WHY. Also, iptables -v should be a lot more useful than before. Regards, Eloi Granado pgpUNHQGNulY2.pgp Description: PGP signature
Re: Firewall-troubleshooting
On 5 Jul 2005, Eloi Granado wrote: On Sunday, 3 de July de 2005 23:24, Paul Gear wrote: Daniel Pittman wrote: It also tends to encourage shortcuts in the firewall, like accepting any RELATED/ESTABLISHED packets, Am i right in understanding that you consider accepting RELATED/ESTABLISHED packets a bad thing? It simplifies the deployment of handcrafted firewalls, but it can strike back when you want to control certain things. Specially when allowing R/E packets is the first thing you do. For example, time dependant rules like allow navigation/ftp from 14 to 16 hours translate into allowing NEW connections like allow new ftp connections from 14 to 16, and let them stay open for ever. Obviously, that's not what you probably meant when writting those time based rules. Hrm. There you go: a problem I hadn't considered for the blanket accept all R/E. [...] So, probably, the best way to go is allowing the R/E packets alongside their new state counterparts. It also clarifies where the packets are accepted and WHY. Also, iptables -v should be a lot more useful than before. That was my point, basically. Thanks for actually saying it in a clear and comprehensible fashion. Daniel -- He uses hate as a weapon to defend himself; had he been strong, he would never have needed that kind of weapon. -- Kahlil Gibran -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firewall-troubleshooting
Daniel Pittman [EMAIL PROTECTED] wrote: Sure, a lot of them suck. In fact, most of them *really* suck, in my opinion. I found that 'firehol' was quite a surprise to me -- not only didn't it suck, it actually improved my hand-written firewall somewhat. Firehol still sucks: It's bash-dependant (no good for OpenWRT), the output script isn't self-contained, and it takes forever to run on a Pentium 166. That being said, it's still my choice of firewalling tool. Writing firewalls with iptables directly is like programming in assembler - do it once just to learn how to do it and to learn why not to do it. -- Sam Eddie Couter | mailto:[EMAIL PROTECTED] Debian Developer| mailto:[EMAIL PROTECTED] | jabber:[EMAIL PROTECTED] OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C signature.asc Description: Digital signature
Re: Firewall-troubleshooting
On Sun, 03 Jul 2005 05:07:02 +0200, Daniel Pittman [EMAIL PROTECTED] wrote: I found that 'firehol' was quite a surprise to me -- not only didn't it suck, it actually improved my hand-written firewall somewhat. Unlike everything else, it doesn't tell you to fill in three values in a configuration file and expect to have a full firewall. All it does is help take the tedious bits out of writing an iptables firewall. I'd like to know what you think of shorewall? Is it good firewall or should I switch to that firehol you write about? I have heared some opinions like shorewall is bad so I'm really thinking of switching to something else. But I dont't know why... noone was able to give me a good reason. -- Jakub Sporek -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firewall-troubleshooting
Daniel Pittman wrote: ... Finally, that is a pretty complex firewall script, and obviously somewhat hard to maintain. Maybe you would get better value for your time by using an existing firewall helper like 'firehol', or something, than re-doing the work that went into the existing tools? Of course, if your aim is to learn iptables rather than just get it working, that loses. ;) Yes the script is kind of long and tedious in its respects. Well, a decent firewall is when you express it in iptables -- the assembly language of firewalls. ;) Well-put. Once i learned the assembly language basics, i gave up in favour of a higher-level language equivalent: shorewall. I was sold on it from the day i rewrote my 1000-line ipchains script with 50 lines of shorewall configuration. See http://www.shorewall.net for details. ... On most of the systems that people use for firewalling these days, the performance cost of the various tests is next to invisible, because the machines are grossly overpowered. Once again, nicely put! :-) For example, the smallest thing I look after that does firewalling is my P3-550 at home, which replaced a Pentium-233, both of which could have handled vastly more firewall rules than I ever had, despite a much more complex setup than your script manages. So, unless you actually notice a performance problem you are probably wasting your time trying to micro-optimize your firewall that way, in my opinion. Indeed. I recently upgraded my main firewall at home to a beefy Celeron 600! :-) -- Paul http://paulgear.webhop.net -- Did you know? Using accepted quoting conventions makes your email easier to understand. Learn how at http://www.netmeister.org/news/learn2quote.html. signature.asc Description: OpenPGP digital signature
Re: Firewall-troubleshooting
On 3 Jul 2005, Jakub Sporek wrote: On Sun, 03 Jul 2005 05:07:02 +0200, Daniel Pittman [EMAIL PROTECTED] wrote: I found that 'firehol' was quite a surprise to me -- not only didn't it suck, it actually improved my hand-written firewall somewhat. Unlike everything else, it doesn't tell you to fill in three values in a configuration file and expect to have a full firewall. All it does is help take the tedious bits out of writing an iptables firewall. I'd like to know what you think of shorewall? Is it good firewall or should I switch to that firehol you write about? I didn't like shorewall when I evaluated it, but not for reasons of security. Shorewall, like many firewall packages, gives you[1] a whole bunch of configuration options, which turn on or off features in the pre-packaged firewall you have. This tends to make it hard to do strange things like playing with DSCP tagging of packets, or deciding to use the 'uid' option to an iptables rule, or whatever. The recent ipt_recent protection against SSH, etc, brute force attacks is a good example of this sort of stuff. It also tends to encourage shortcuts in the firewall, like accepting any RELATED/ESTABLISHED packets, because each option in the configuration file is actually an if statement around a bit of hand crafted firewall.[2] These points may or may not apply to Shorewall - I didn't evaluate down to that level when I was looking at it, and things may have changed since. On the other hand, they do normally make it easier to have a working firewall in less time, and potentially with less understanding[3], than raw iptables, or firehol, demand. This doesn't really suit me, because I want to do occasional odd stuff, and because when I have evaluated the few tools that didn't restrict me too much I found that the generated firewall wasn't up to scratch. Shorewall was *NOT* one of the tools that I evaluated to the level of a generated firewall -- it didn't let me do some of the stuff I was doing already, so I didn't try it. Firehol, on the other hand, is a tool that makes it *easier* to write an iptables firewall by doing all the tedious work for you. Instead of writing out a hundred stanzas with a couple of changes, it lets the computer do all the hard work of turning ten lines into that hundred. For example, my current firewall has on the order of eight hundred individual iptables rules covering traffic through it. Writing that by hand would be ... impossible, or pretty close to it. On the other hand, my firewall also includes a handful of raw iptables level rules, because there were things that firehol *didn't* support when I last touched the configuration. Firehol suits me, personally, because it makes it easy to write a really good and secure firewall, because it takes the hard work out of iptables, but it still doesn't get in the way of doing, well, anything I want. I have heared some opinions like shorewall is bad so I'm really thinking of switching to something else. But I dont't know why... noone was able to give me a good reason. All my reasons are personal taste, basically, and I certainly don't advise that you change your firewall tool on the basis of my personal taste. ;) Also, in general I don't recommend changing *anything* just because someone else tells you they don't like it -- and if they can't tell you *why*, it is just that they don't like it. However, if you do want to consider another firewall tool, firehol is a good choice, in my opinion. OTOH, you may hate it with a passion, since your style of firewall building may be totally different from mine. Oh, and if you do use it, *do* use 'firehol try', which is one of the finest features of the package. :) Finally, a hint for anyone who read this far: for most configurations, the firewall is really quite static. It doesn't change based on anything other than you editing a file, and it /is/ pretty slow for a complex rules file. So, treat firehol like a compiler: run it when something changes, and use iptables-save(8) and friends at boot time to restore the rules. Viola, the low performance is something that doesn't bother you much of the time. Daniel Footnotes: [1] So far as I can tell. I have not looked in, oh, a year or so, so things may be dramatically different these days. [2] I don't know if shorewall actually works like this, or more like firehol internally, but all the other [3] This is not to say that using Shorewall is a sign that you are a bad, or ignorant, administrator, by any stretch of the imagination. -- Our undisciplinables are our proudest product... Let us hope our output of them will never cease. -- William James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firewall-troubleshooting
On Sun, 03 Jul 2005 12:23:13 +0200, Daniel Pittman [EMAIL PROTECTED] wrote: Thanks a lot! It was really comprehensive! And according to what you wrote - I'll stick with shorewall since it does everything I need and it's easy to manage. On the other hand - I'll start to learn iptables because I'm becoming interested in it :) -- Jakub Sporek -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firewall-troubleshooting
Daniel Pittman wrote: ... Shorewall, like many firewall packages, gives you[1] a whole bunch of configuration options, which turn on or off features in the pre-packaged firewall you have. This tends to make it hard to do strange things like playing with DSCP tagging of packets, or deciding to use the 'uid' option to an iptables rule, or whatever. The recent ipt_recent protection against SSH, etc, brute force attacks is a good example of this sort of stuff. It also tends to encourage shortcuts in the firewall, like accepting any RELATED/ESTABLISHED packets, Am i right in understanding that you consider accepting RELATED/ESTABLISHED packets a bad thing? ... Shorewall was *NOT* one of the tools that I evaluated to the level of a generated firewall -- it didn't let me do some of the stuff I was doing already, so I didn't try it. What were the main things you wanted that shorewall didn't do? ... Firehol suits me, personally, because it makes it easy to write a really good and secure firewall, because it takes the hard work out of iptables, but it still doesn't get in the way of doing, well, anything I want. You can integrate arbitrary iptables commands into shorewall also. ... I have heared some opinions like shorewall is bad so I'm really thinking of switching to something else. But I dont't know why... noone was able to give me a good reason. ... Also, in general I don't recommend changing *anything* just because someone else tells you they don't like it -- and if they can't tell you *why*, it is just that they don't like it. Couldn't agree more. -- Paul http://paulgear.webhop.net -- Did you know? Many viruses specifically target Microsoft Outlook and Outlook Express. You can help to keep your computer free of viruses by using one of the more secure alternatives from http://mozilla.org. signature.asc Description: OpenPGP digital signature
Re: Firewall-troubleshooting
On 4 Jul 2005, Paul Gear wrote: Daniel Pittman wrote: ... Shorewall, like many firewall packages, gives you[1] a whole bunch of configuration options, which turn on or off features in the pre-packaged firewall you have. This tends to make it hard to do strange things like playing with DSCP tagging of packets, or deciding to use the 'uid' option to an iptables rule, or whatever. The recent ipt_recent protection against SSH, etc, brute force attacks is a good example of this sort of stuff. It also tends to encourage shortcuts in the firewall, like accepting any RELATED/ESTABLISHED packets, Am i right in understanding that you consider accepting RELATED/ESTABLISHED packets a bad thing? No. Accepting *any* RELATED/ESTABLISHED packets is, though, if someone finds an attack to generate entries in the conntrack table. Like, say, the active FTP NAT PORT bug from quite some time ago, which would allow remote attackers to do just that. :) Limiting the RELATED/ESTABLISHED packets to what you actually expect (part of an established connection to a service you actually use) is a more secure policy. Obviously, none of this is a *huge* risk, but if it comes for free... ... Shorewall was *NOT* one of the tools that I evaluated to the level of a generated firewall -- it didn't let me do some of the stuff I was doing already, so I didn't try it. What were the main things you wanted that shorewall didn't do? At the time, some UID based stuff, as I recall. This was over a year ago, though, so things have probably changed (and my memory is a bit fuzzy). ... Firehol suits me, personally, because it makes it easy to write a really good and secure firewall, because it takes the hard work out of iptables, but it still doesn't get in the way of doing, well, anything I want. You can integrate arbitrary iptables commands into shorewall also. Cool. Either I missed it at the time, or it is a new feature, but it is nice to see that it is there. Shorewall /does/ seem like a very sound choice for firewalling, even if it isn't my cup of tea. :) ... I have heared some opinions like shorewall is bad so I'm really thinking of switching to something else. But I dont't know why... noone was able to give me a good reason. ... Also, in general I don't recommend changing *anything* just because someone else tells you they don't like it -- and if they can't tell you *why*, it is just that they don't like it. Couldn't agree more. *nod* I sure don't think that my personal taste is a strike against Shorewall. Daniel -- Life is about not knowing, having to change, taking the moment and making the best of it, without knowing what's going to happen next. Delicious ambiguity. -- Gilda Radner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firewall-troubleshooting
Hi, My firewall script doesn't have a problem with it's rules it is just missing something important because when firehol tries it it doesn't give any significant errors. When I turn on my previous firewall it works fine. The place I am working in is a remote place where I am just setting up a network. I have a small sized network here and my connection is rogers cable. I seem to have problems just accepting anything. I believe it to be the cause of some faulty strategy I had when making these rules up, or maybe I need something extra that I haven't yet added. I am going to display the iptables-save output in the hopes that someone might understand the problem quicker then me. Best Regards kc # Generated by iptables-save v1.2.11 on Sun Jul 3 18:18:43 2005 *nat :PREROUTING DROP [0:0] :POSTROUTING DROP [0:0] :OUTPUT DROP [0:0] COMMIT # Completed on Sun Jul 3 18:18:43 2005 # Generated by iptables-save v1.2.11 on Sun Jul 3 18:18:43 2005 *mangle :PREROUTING DROP [939:56233] :INPUT ACCEPT [37647:1995360] :FORWARD ACCEPT [120683:61189142] :OUTPUT DROP [128:10168] :POSTROUTING ACCEPT [157981:67483601] COMMIT # Completed on Sun Jul 3 18:18:43 2005 # Generated by iptables-save v1.2.11 on Sun Jul 3 18:18:43 2005 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] :EXT-icmp-in - [0:0] :EXT-icmp-out - [0:0] :EXT-input - [0:0] :EXT-log-in - [0:0] :EXT-log-out - [0:0] :EXT-output - [0:0] :connection-tracking - [0:0] :destination-address-check - [0:0] :local-dhcp-client-query - [0:0] :local-dns-server-query - [0:0] :local-tcp-client-request - [0:0] :local-tcp-server-response - [0:0] :local-udp-client-request - [0:0] :log-tcp-state - [0:0] :remote-dhcp-server-response - [0:0] :remote-dns-server-response - [0:0] :remote-tcp-client-request - [0:0] :remote-tcp-server-response - [0:0] :remote-udp-server-response - [0:0] :source-address-check - [0:0] :tcp-state-flags - [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -j tcp-state-flags -A INPUT -j connection-tracking -A INPUT -i eth1 -p udp -m udp --sport 67 --dport 68 -j remote-dhcp-server-response -A INPUT -p ! tcp -j source-address-check -A INPUT -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j source-address-check -A INPUT -j destination-address-check -A INPUT -d 192.168.3.1 -i eth1 -j EXT-input -A INPUT -d 224.0.0.0/240.0.0.0 -i eth1 -p udp -j DROP -A INPUT -j EXT-log-in -A OUTPUT -o lo -j ACCEPT -A OUTPUT -p tcp -j tcp-state-flags -A OUTPUT -j connection-tracking -A OUTPUT -o eth1 -p udp -m udp --sport 68 --dport 67 -j local-dhcp-client-query -A OUTPUT -j destination-address-check -A OUTPUT -s 192.168.3.1 -d 224.0.0.0/240.0.0.0 -o eth1 -p udp -j DROP -A OUTPUT -s 192.168.3.1 -o eth1 -j EXT-output -A OUTPUT -j EXT-log-out -A EXT-icmp-in -f -j LOG --log-prefix Fragmented incoming ICMP: -A EXT-icmp-in -f -j DROP -A EXT-icmp-in -p icmp -m icmp --icmp-type 0 -j ACCEPT -A EXT-icmp-in -s 24.156.100.1 -p icmp -m icmp --icmp-type 8 -m state --state NEW -j ACCEPT -A EXT-icmp-in -s 24.156.100.1 -p icmp -m icmp --icmp-type 8 -j ACCEPT -A EXT-icmp-in -p icmp -m icmp --icmp-type 3 -j ACCEPT -A EXT-icmp-in -p icmp -m icmp --icmp-type 12 -j ACCEPT -A EXT-icmp-in -p icmp -m icmp --icmp-type 11 -j ACCEPT -A EXT-icmp-in -p icmp -m icmp --icmp-type 4 -j ACCEPT -A EXT-icmp-out -f -j LOG --log-prefix Fragmented outgoing ICMP: -A EXT-icmp-out -f -j DROP -A EXT-icmp-out -p icmp -m icmp --icmp-type 8 -m state --state NEW -j ACCEPT -A EXT-icmp-out -p icmp -m icmp --icmp-type 8 -j ACCEPT -A EXT-icmp-out -d 24.156.100.1 -p icmp -m icmp --icmp-type 0 -j ACCEPT -A EXT-icmp-out -p icmp -m icmp --icmp-type 3/4 -j ACCEPT -A EXT-icmp-out -p icmp -m icmp --icmp-type 12 -j ACCEPT -A EXT-icmp-out -p icmp -m icmp --icmp-type 4 -j ACCEPT -A EXT-input -p udp -m udp --sport 53 --dport 53 -j remote-dns-server-response -A EXT-input -p udp -m udp --dport 1024:65535 -j remote-udp-server-response -A EXT-input -p icmp -j EXT-icmp-in -A EXT-log-in -p icmp -m icmp ! --icmp-type 8 -m limit --limit 3/hour -j LOG -A EXT-log-in -p tcp -m tcp --dport 0:650 -j LOG -A EXT-log-in -p udp -m udp --dport 0:110 -j LOG -A EXT-log-out -j LOG -A EXT-output -p udp -m udp --sport 53 --dport 53 -j local-dns-server-query -A EXT-output -p tcp -m tcp --sport 1024:65535 --dport 53 -j local-dns-server-query -A EXT-output -p tcp -m tcp --sport 53 --dport 1024:65535 ! --tcp-flags SYN,RST,ACK SYN -j remote-dns-server-response -A EXT-output -p tcp -m tcp --dport 1024:65535 ! --tcp-flags SYN,RST,ACK SYN -j local-tcp-server-response -A EXT-output -p udp -m udp --sport 1024:65535 -j local-udp-client-request -A EXT-output -p icmp -j EXT-icmp-out -A connection-tracking -m state --state RELATED,ESTABLISHED -j ACCEPT -A connection-tracking -m state --state INVALID -j LOG --log-prefix INVALID packet: -A connection-tracking -m state --state INVALID -j DROP -A destination-address-check -d 255.255.255.255 -j DROP -A destination-address-check -d 192.168.3.0 -j DROP -A destination-address-check -d 192.168.3.255 -j DROP -A
Re: Firewall-troubleshooting
On 4 Jul 2005, KC wrote: [...] *nat :PREROUTING DROP [0:0] :POSTROUTING DROP [0:0] :OUTPUT DROP [0:0] COMMIT I thought that using a policy of DROP in the nat tables would result in anything that wasn't NAT-ed being prevented from passing through by iptables. I can't find any documentation one way or the other, though, and don't want to test on my live systems. Maybe you can try varying that? Daniel -- I never watch television because it's an ugly piece of furniture, gives off a hideous light, and, besides, I'm against free entertainment. -- John Waters -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Firewall-troubleshooting
Hi
I need help understanding what goes wrong in this script. I cannot ping
anyone and cannot resolve as well. In fact I believe the only thing I can
get is an ip address from my isp's dhcp server.
Best Regards
kc
## FIREWALL ##
## Symbolic Constants
CONNECTION_TRACKING=1
LOCAL=eth0
INTERNET=eth1
LOOPBACK_INTERFACE=lo
MY_ISP=24.0.0.0/8
LOOPBACK=127.0.0.0/8
IPADDR=`ifconfig eth1|awk '/inet/{print $2}'|awk -F ':' '{print $2}'`
INTERNAL_IP=`ifconfig eth0|awk '/inet/{print $2}'|awk -F ':' '{print $2}'`
LOCAL_NET=192.168.3.0/24
BROADCAST_SRC=0.0.0.0
BROADCAST_DEST=255.255.255.255
PRIVPORTS=0:1023
UNPRIVPORTS=1024:65535
SUBNET_BASE=192.168.3.0
SUBNET_BROADCAST=192.168.3.255
## Hosts
DESKTOP=host2
DESKTOP2=host
WWW=host3
#MAIL=192.168.2.5
#IRC=192.168.2.40
#IMAP_CLIENTS=continued...
TIME_SERVER=time.server.address
HOSTS_PING=isp subnet
NAMESERVER=nameserver1
DHCP_SERVER=dhcp-server1
## PORTS
IRC_PORT=6667
WEB_PORT=80
SSL_PORT=443
SSH_PORTS=445
DK_PORT=4660
XWINDOW_PORTS=6000:6063
TRACEROUTE_SRC_PORTS=32769:65535
TRACEROUTE_DEST_PORTS=33434:33523
## Private Class Networks
CLASS_A=10.0.0.0/8
CLASS_B=172.16.0.0/12
CLASS_C=192.168.0.0/16
CLASS_D_MULTICAST=224.0.0.0/4
CLASS_E_RESERVED_NET=240.0.0.0/5
## Flush the chains of all rules
iptables --flush
iptables -t nat --flush
iptables -t mangle --flush
echo Flushed rules for all chains
## Show Internal and External Addresses and enable forwarding
echo External IP $IPADDR
echo Internal IP $INTERNAL_IP
#echo 1 /proc/sys/net/ipv4/ip_forward
## Enable broadcast echo Protection
echo 1 /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
## Disable Source Routed Packets
for p in /proc/sys/net/ipv4/conf/*/accept_source_route; do
echo 0 $p
done
## Enable TCP SYN Cookie Protection
echo 1 /proc/sys/net/ipv4/tcp_syncookies
## Disable ICMP Redirect Acceptance
# A redirect message SHOULD be silently discarded if the new gateway
address it specifies is not on the same subnet that it came from.
for p in /proc/sys/net/ipv4/conf/*/accept_redirects; do
echo 0 $p
done
## Don't send redirect Messages
for p in /proc/sys/net/ipv4/conf/*/send_redirects; do
echo 0 $p
done
## Drop Spoofed Packets coming in on an interface, to which a reply would
result in going out a different interface.
for p in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo 1 $p
done
## Log packets with impossible addresses.
for p in /proc/sys/net/ipv4/conf/*/log_martians; do
echo 1 $p
done
## Unlimited traffic on the loopback interface
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# POLICY #
## Default Policy
iptables --policy INPUT DROP
iptables --policy OUTPUT DROP
iptables --policy FORWARD DROP
iptables -t nat --policy PREROUTING DROP
iptables -t nat --policy OUTPUT DROP
iptables -t nat --policy POSTROUTING DROP
iptables -t mangle --policy PREROUTING DROP
iptables -t mangle --policy OUTPUT DROP
iptables --delete-chain
iptables -t nat --delete-chain
iptables -t mangle --delete-chain
# DNS
iptables -A OUTPUT -o $INTERNET -p udp -s $IPADDR --sport $UNPRIVPORTS -d
$NAMESERVER --dport 53 -j ACCEPT
iptables -A INPUT -i $INTERNET -p udp -s $NAMESERVER --sport 53 -d $IPADDR
--dport $UNPRIVPORTS -j ACCEPT
iptables -A OUTPUT -o $INTERNET -tcp -s $IPADDR --sport $UNPRIVPORTS -d
$NAMESERVER --dport 53 -j ACCEPT
iptables -A INPUT -i $INTERNET -p tcp ! --syn -s $NAMESERVER --sport 53 -d
$IPADDR --dport $UNPRIVPORTS -j ACCEPT
iptables -A OUTPUT -o $INTERNET -p udp -s $IPADDR --sport 53 -d $NAMESERVER
--dport 53 -j ACCEPT
iptables -A INPUT -i $INTERNET -p udp -s $NAMESERVER --sport 53 -d $IPADDR
--dport 53 -j ACCEPT
### STEALTH SCAN POLICY ###
# All of the bits are cleared
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
# SYN and FIN are both set
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
# SYN and RST are both set
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
# FIN and RST are both set
iptables -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j DROP
# FIN is the only bit set, without the expected accompanying ACK
iptables -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j DROP
# PSH is the only bit set, without the expected accompanying ACK
iptables -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j DROP
# URG is the only bit set, without the expected accompanying ACK
iptables -A INPUT -p tcp --tcp-flags ACK,URG URG -j DROP
## Refuse packets from the following ban list
## example
iptables -I INPUT -i $INTERNET -s 72.21.42.186 -j DROP
#iptables -I INPUT -i $INTERNET -s address/mask -j DROP
## Packet State Validation
if [ $CONNECTION_TRACKING = 1 ]; then
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state INVALID -j LOG --log-prefix INVALID
input:
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A OUTPUT -m state --state INVALID -j
Re: Firewall-troubleshooting
On Sat, Jul 02, 2005 at 04:46:29PM -0400, KC wrote: I need help understanding what goes wrong in this script. I cannot ping anyone and cannot resolve as well. In fact I believe the only thing I can get is an ip address from my isp's dhcp server. There's no way I'm going to read through all of that and try to understand it. Perhaps you'd be better off starting with a smaller firewall script and then adding to it as you need? One thing did stand out though, you don't allow outgoing connections generally. These lines: iptables --policy OUTPUT DROP iptables -t nat --policy OUTPUT DROP iptables -t mangle --policy OUTPUT DROP They seem to say no output except that which is explictly allowed. For a big network I too would restrict outgoing connections, but for a home machine with only trusted hosts? It's an additional complication which doesn't gain you much. (Sure if you had a trojan which phoned home, or tried to compromise other hosts .. it would help. But .. in general it less useful than it appears). Steve -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firewall-troubleshooting
On 3 Jul 2005, KC wrote: I need help understanding what goes wrong in this script. I cannot ping anyone and cannot resolve as well. In fact I believe the only thing I can get is an ip address from my isp's dhcp server. With sufficiently modern kernels, the DHCP client uses raw sockets, so it can (AIUI) bypass firewall rules that would otherwise stop it getting through. I can't spot anything wrong with your script, which means that it isn't an obvious stupid mistake (congratulations ;). You have some work to do, I guess. :) Two things that are generally helpful in debugging iptables/firewall problems: The logs of dropped packets, which I note you have added, may show you where things are getting discarded. A *default* log at the end, showing everything else, is also really helpful. Watching the output of 'iptables -L' will show you where packets are flowing: each time they pass a rule, or chain, they bump up the packet count. This can show that, say, one of your rules is eating all the packets -- they get that far, then stop. Finally, that is a pretty complex firewall script, and obviously somewhat hard to maintain. Maybe you would get better value for your time by using an existing firewall helper like 'firehol', or something, than re-doing the work that went into the existing tools? Of course, if your aim is to learn iptables rather than just get it working, that loses. ;) Daniel -- A cathedral, a wave of a storm, a dancer's leap, never turn out to be as high as we had hoped. -- Marcel Proust -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firewall-troubleshooting
Hi, Yes the script is kind of long and tedious in its respects. My initial purpose was to set this up at a remote facility with around 20 systems. I have also tried to get info from iptables -L chian, but noticed that the rules seem to be ok. If people want I can put the output for iptables -L chain. I am trying to block out everything accept what i need. I think that my firewall optimization is kind of crap but I am in process of working on that. The other thing that I just noticed is that my order for rules is not very properly laid out. I should have had the most active rules up ontop right before all the drop rules. I am asking for help if anyone notices anything interesting or decides to just suggest a more optimized approach to things let me know. I tried some automated firewall scripting programs, and just feel that a lot of them are just designed to save time for the lazy, and then you waste a lot of time trying to correct the script. These programs have their users I am just not one of them. I have also learned that iptables have some very interesting and helpful modules. If someone knows anything about that, then I would appreciate if they let me know where I could get them. Best Regards kc Daniel Pittman wrote: On 3 Jul 2005, KC wrote: I need help understanding what goes wrong in this script. I cannot ping anyone and cannot resolve as well. In fact I believe the only thing I can get is an ip address from my isp's dhcp server. With sufficiently modern kernels, the DHCP client uses raw sockets, so it can (AIUI) bypass firewall rules that would otherwise stop it getting through. I can't spot anything wrong with your script, which means that it isn't an obvious stupid mistake (congratulations ;). You have some work to do, I guess. :) Two things that are generally helpful in debugging iptables/firewall problems: The logs of dropped packets, which I note you have added, may show you where things are getting discarded. A *default* log at the end, showing everything else, is also really helpful. Watching the output of 'iptables -L' will show you where packets are flowing: each time they pass a rule, or chain, they bump up the packet count. This can show that, say, one of your rules is eating all the packets -- they get that far, then stop. Finally, that is a pretty complex firewall script, and obviously somewhat hard to maintain. Maybe you would get better value for your time by using an existing firewall helper like 'firehol', or something, than re-doing the work that went into the existing tools? Of course, if your aim is to learn iptables rather than just get it working, that loses. ;) Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firewall-troubleshooting
On 3 Jul 2005, KC wrote: Daniel Pittman wrote: On 3 Jul 2005, KC wrote: I need help understanding what goes wrong in this script. I cannot ping anyone and cannot resolve as well. In fact I believe the only thing I can get is an ip address from my isp's dhcp server. [...] I can't spot anything wrong with your script, which means that it isn't an obvious stupid mistake (congratulations ;). You have some work to do, I guess. :) [...] Finally, that is a pretty complex firewall script, and obviously somewhat hard to maintain. Maybe you would get better value for your time by using an existing firewall helper like 'firehol', or something, than re-doing the work that went into the existing tools? Of course, if your aim is to learn iptables rather than just get it working, that loses. ;) Yes the script is kind of long and tedious in its respects. Well, a decent firewall is when you express it in iptables -- the assembly language of firewalls. ;) [...] I am trying to block out everything accept what i need. That is a good policy. I think that my firewall optimization is kind of crap but I am in process of working on that. The other thing that I just noticed is that my order for rules is not very properly laid out. I should have had the most active rules up ontop right before all the drop rules. So-so. On most of the systems that people use for firewalling these days, the performance cost of the various tests is next to invisible, because the machines are grossly overpowered. For example, the smallest thing I look after that does firewalling is my P3-550 at home, which replaced a Pentium-233, both of which could have handled vastly more firewall rules than I ever had, despite a much more complex setup than your script manages. So, unless you actually notice a performance problem you are probably wasting your time trying to micro-optimize your firewall that way, in my opinion. [...] I tried some automated firewall scripting programs, and just feel that a lot of them are just designed to save time for the lazy, and then you waste a lot of time trying to correct the script. Sure, a lot of them suck. In fact, most of them *really* suck, in my opinion. I found that 'firehol' was quite a surprise to me -- not only didn't it suck, it actually improved my hand-written firewall somewhat. Unlike everything else, it doesn't tell you to fill in three values in a configuration file and expect to have a full firewall. All it does is help take the tedious bits out of writing an iptables firewall. You can also use, well, anything iptables-ish if you want. I would suggest giving it a whirl at some point, just because it doesn't suck the same way all the other tools do. These programs have their users I am just not one of them. I have also learned that iptables have some very interesting and helpful modules. If someone knows anything about that, then I would appreciate if they let me know where I could get them. Well, if you want the latest patch-o-matic stuff, netfilter.org will help you. If you have specific questions, just ask. :) Daniel -- ...I've seen things you people wouldn't believe. Sun monitors on fire off the side of the multimedia lab. I've seen NTU lights glitter in the dark near the Mail Gate. All these things will be lost in time, like the root partition last week. Time to die... -- Peter Gutmann, _alt.sysadmin.recovery_ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firewall-troubleshooting
Hi, I am tring out firehol right now on a fresh optimized version of this firewall that I decided to make from scratch. The damn thing still won't work. I know I am missing something important in both these scripts because in both cases it drops everything and my rules are not functioning at all. Best Regards kc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
