LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 12-11-2009, 08:29 AM   #16
salasi
Senior Member
 
Registered: Jul 2007
Location: Directly above centre of the earth, UK
Distribution: SuSE, plus some hopping
Posts: 4,070

Rep: Reputation: 897Reputation: 897Reputation: 897Reputation: 897Reputation: 897Reputation: 897Reputation: 897

Quote:
Originally Posted by boabbyrab1 View Post
Full egress and ingress filtering (i.e. defaults are all REJECT)
and

Quote:
-P sets the policy in this case REJECT but this sends ICMP messages back to sender saying that it's blocked but gives info about the firewall so DROP may be a better option.
The fundamental question here is whether you want to reject or drop. For debugging, reject has advantages, for resisting hacking drop is better, because it doesn't give any information away. So there isn't an absolutely clear answer as to which is best, but mentioning the advantages and disadvantages of the two approaches in your report, and so demonstrating understanding, seems reasonable.

In addition, you are told what to do with the defaults in the instructions, so this has to be at least an option, although you can argue for 'hooks' to change to the other behaviour, if this is felt more appropriate.

One way of 'squaring the circle' of apparently contradictory requirements, if you think that drop is the appropriate behaviour, is to set the policy (default behaviour for the chain) to REJECT but ensure that there is a DROP instruction (err, maybe log and drop as we'll get on to in a moment) just before that. This is the 'smartarse' solution and might annoy your tutor, but it does comply with the instructions and does actually DROP, for marginally better security, if and where you think that's appropriate.

On a more important note, I don't know what you are intending to do for testing and documentation of function.

I assume you have a machine (maybe virtual) on which to test your proposed ruleset (Note rule 1: If you don't know how to test it, you shouldn't write it).

My guess is that to make an optimal approach to full marks, some kind of evidence of testing and of functionality is required, and you say nothing about how you might approach that.
  • The simplest option is 'I tried this ruleset and nothing seemed to break'
  • An improved option is 'I didn't connect the mail client an no packets went down the mail chain and then I connected it up and packets flowed down the mail chain', but for that you would need to employ some packet counters in appropriate places.
  • Yet another improved option is to use logging in some places to demonstrate which packets went where. In a more general comment, it would make sense to use targets something like 'log and drop' at the end of chains so that you could get some diagnostics about which packets were being ignored, so that you could see, by looking at the logs, whether there was evidence of an attempted attack.

None of those things are directly required by the requirements, but, if you take security seriously, you'll want to know when an attack attempt is underway, and not just when it has succeeded, so you could regard that as 'security focussed'.

Additionally, this business of security isn't just a set of iptables rules. If you want to protect against, eg, 'syn flooding' attacks there is other stuff that you have to do, and I'm sure that one or another tutorial will have given you some hints about that. When you decide what you want to do about that, you also have to decide how. If your decision on that subject comes down to a bash (or other shell) script, then it is relatively easy and you can put all the stuff for both the iptables rules and the non-iptables stuff, in one shell script.

Equally (just one idea...), you could set at the top of the script, variables like, eg, debug_mode, where in debug_mode (or test_mode, or whatever you want to call it, but do call it something that helps readability) you enable all of the logging and debugging features in your ruleset, by means of conditional tests in your script. So, in your debug mode, if that's what you call it, you wouldn't put the 'drop' instruction in before the end of the chain.

For logging, at least in normal circumstances, you should consider rate limiting the logging to some obviously achievable level; otherwise a miscreant could try to either overfill the log files, or crash the firewall by giving it more connections and data than can be handled.

Quote:
after looking at some web site/tutorials i am under the impression that configuring eth0 usually involves ip addresses
Under normal circumstances, you would 'inherit' an eth already set up with an ethernet address, so you wouldn't have to set this up yourself. OTOH, that means you probably are not sure what that address actually is, unless you do something to find it out. And if the IP addresses are handed out in some clever way (dhcp/avahi/bonjour/mdns/networkmanager/wicd) it might get changed after your script is run. This would be very undesirable, if your script relies on the ip address, so it is advisable that this doesn't happen (some people would not consider using one of the 'clever' ways to manage server IP addresses, for exactly this kind of reason - I am unsure of your context).

Quote:
-F flushes out the table for a clean slate
True. You should flush a chain and then put in place your rules, otherwise you might get into a situation in which your firewall does different things, depending on the pre-existing situation.

Quote:
so if any linux gods out there could tell me if i am on right track
IANAG (amongst the many things that I am not), but you are on the right track, but you still have some distance to go. Deal with the points that have been raised and you'll be a lot closer.
 
Old 12-12-2009, 01:10 PM   #17
boabbyrab1
LQ Newbie
 
Registered: Nov 2009
Posts: 8

Original Poster
Rep: Reputation: 0
ran some of the code through college VM and it came back with iptables: bad policy name, so googled that and came up with REJECT does not work as a defult policy Use the drop target instead.However, the reject work on rules.
so if i use DROP as a policy i lock myself out of the VM (i just do a fresh install to start again) and the original questions says Full egress and ingress filtering (i.e. defaults are all REJECT.) so for setting the policy only DROP & ACCEPT will do but if i use both it will no longer be full ingress/outgress filtering.
and apoligies for calling people gods but if you help me with this one then in my opinion you are.
cheers & sorry for so many questions.
 
Old 12-19-2009, 10:53 AM   #18
boabbyrab1
LQ Newbie
 
Registered: Nov 2009
Posts: 8

Original Poster
Rep: Reputation: 0
thanks to all who helped with input, hopefully done enough to pass the assesment, dont think i would have done it without any input.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
interesting MySQL query/view query :s mjh Programming 3 03-25-2008 08:30 AM
mysql use output of one query in another query secretlydead Programming 2 11-19-2007 02:25 AM
router billion 5102 has firewall and software firewall tests aus9 Linux - Security 6 12-31-2006 11:09 PM
help with mysql query: return nth rows in query hawarden Programming 2 07-31-2006 07:36 PM
Firewall Builder sample firewall policy file ? (.xml) nuwanguy Linux - Networking 0 09-13-2003 01:32 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 08:23 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration