FIREWALL: look ok so far?
Just wanted input for this script i have cobbeled together. Its not done yet. I am trying to think of ways to close up my outgoing while maintaining full functionality of my laptop ( irc, web stuff, a torrent or two, etc.) . Anyways, I have done some myself; as well as, pulling bits and pieces from other stuff out on the web.
I am starting to wonder why i have to write a specific rule to check for spoofed packets if my default input is set top drop. wouldnt it be caught? Code:
#!/bin/bash |
Could you attach the output from running 'cat /proc/net/ip_tables_names | xargs -iT iptables -vxnL --line-numbers -t 'T';'?
|
i am not using the above, so the output would be pointless. HOWEVER....thanks for asking me to do that as i didnt change something that was running from a script i had used after install. real question is...how the hell did you know??? damn.
anyways, here is the info you asked for: Code:
Chain PREROUTING (policy ACCEPT 2571 packets, 544212 bytes) |
Quote:
|
well, all i am doing is putting together tidbits from assorted scripts. In doing so I am learning how to build a firewall ( well sorta). I am saying "spoofed" because when i google the above snipit is what should stop a spoof (tcp based) anyways. If you have any sugestions on search strings that i should check i welcome them. as i said, i am just trying to learn. My issue is that i have to learn SO MUCH. So, yeah, I was parroting what i had found via google.
|
Quote:
I have seen some very complex firewall scripts which block for everything under the sun. However, with a default DROP on INPUT why bother dropping certain packets that dont match ESTABLISHED, RELATED? I can understand LOG jumps, just cant wrap my head around the double drops. Anyways, I have put together the iptables portion of the script based on what i have seen out on the web. However, as stated above, the logic seems weird. Quote:
|
Quote:
Honestly, taking a few days to learn the fundamentals will be much more valuable to you than just mindlessly copy/pasting iptables commands from all over the Internet. |
Quote:
Code:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT Quote:
Quote:
FWIW, your script is enabling anti-spoofing measures in this section: Quote:
|
I understand your point. What I am saying is that each "attack" has a foot print. At the same time I wouldnt call it mindless copying / pasting. I have been searching info up on each command prior to adding it. For example: why do i have to run anything more than 2 rules on my INPUT chain? ESTABLISHED, RELATED or DROP.. But i see like a million rules for what appear to be very similar flags in the tcp header. could you explain that part? I thought conntracking was meant to take care of? I can see running packets through que and set...those make sense for nat and mangle . arrrgh....
|
I had misread your question in my previous reply. I thought you were asking about sending certain packets in state ESTABLISHED or RELATED to DROP. Evidently, you were asking about the inverse.
Quote:
|
Quote:
Quote:
But yeah, what you're referring to sounds like so-called "bad packet chains". With those, you're basically saying "I don't want packets that look like this to come into my network". Depending on how the bad packet chain is implemented, it could apply to packets regardless of what their state is. In other words, state doesn't need to be the ultimate determinant for whether a packet is granted or denied entry/exit. Quote:
|
Quote:
Quote:
As far as I can tell, you seem to be doing a bit of both, but not actually doing either thoroughly. The method suggested by win32sux worked for me (although I'd suggest that you download the pdf version, rather than browse to html one every time that you need it...you'll be looking at it more than once) but, if you have a different learning style, you might find that going the other way helps you to get started. But, you'll still want the froxentux manual for reference, when it comes to the syntax of commands. You have already found the linuxhomenetworking site, and that, and the companion book, The Linux Quick Fix Notebook (Harrison), has one of my favourite examples. You could also look at yolinux as an alternative and less complex treatment (actually, the only thing that I think is wrong with the Harrison treatment for a neophyte to firewalling is that he tries to cope with too many options in his script, which makes the script, but not necessarily the ruleset, a bit intimidating at first). The important thing is to thoroughly understand what the original author is doing and not just half understand and dive in making 'random' changes. Of course, you can argue that the difference between the two approaches is a bit like 'top down' and 'bottom up' software design and the advantages and disadvantages of the two approaches; in an ideal world, you'd master both, and be able to switch between the two ways of thinking, but you have to start from somewhere. |
At this point I guess it back to the tutorial stuff. I cant thanks you both enough.
@salasi> Yeah, I seem to pick things up better when doing hands on WITH a book. So, practical application along side a book tends to stick with me better. @win32suks> Your correct. Thanks |
All times are GMT -5. The time now is 06:22 AM. |