and

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.

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).

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.

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.

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.

thanks to all who helped with input, hopefully done enough to pass the assesment, dont think i would have done it without any input.