Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I am working on my filter script, totally new at it.
I assumed order was important and you just confirmed it there, it would take the 1st match and drop out of the chain with an ACCEPT REJECT .........
What I am wanting to know, (I have a NAT with a DMZ, so 3 nics .... I have read so many articals that ... )
Should I set my, say input policy to DROP 1st,
check for spoofing DROP, ( outside dhcp requests, time requests, DNS requests, ect ) DROP,
and then start excepting what I want, say SSH to the NAT, est connections, etc?
is that the safe way? does that slow the system down if it has to check all of that for each packet it gets?
If I do not check for those 1st, could some other rule let something in that should not?
Does anyone have a simple list / order of best practice for iptables chains / policies? for a newbie?
The default policy will always be the last rule in the firewall regardless of where you actually put it in your script. As a general rule, you'd want rules to block spoofing and junk packets, but not all packets need to go through those checks (for example it doesn't make sense to have UDP packets checked for bad TCP flags), so a good technique is to create user defined chains where specialized checks like that take place. Then only those packets that need to be checked are passed into that chain. That's a little more advanced though. The total number of rules shouldn't really affect network speed very much unless you have a *huge* number of rules. In most cases, you're looking at an added latency of a few microseconds.
I have read alot, that page is extensive. It will take time.
I like the idea of the user defined rules doing seperate tasks. That explains all the variations of scripts that I have seen. Makes it very confusing.
I can read a good bit of the lines now, it is things like the TOS, -m field etc.
I want to, in the future, put together a content filter. Partly for sites that are just a pain to filtering things that students should not be into in a school. I know there are tools out the. I like to do my own. I learn more that way. Plus, like with this, I still need to learn what needs through and what needs blocked. A great deal to find out.
If you are planning on doing content filtering, then you may want to consider setting up a transparent proxy using something like squid. Iptables is a little awkward for doing that and squid with it's acls is really designed exactly with that in mind. Plus there are already a number of places to get reasonably comprehensive blacklists for content filtering with squid. You'd still need to use iptables, but the idea is that iptables redirects outbound http requests to the squid proxy running locally. The traffic is then redirected on the way back, with the client never aware that the traffic was rerouted and filtered.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.