Quote:
Originally Posted by kitek
Can someone treat me as a 5 year old and lets say add port 1000 to be allowed in.
|
While, in normal circumstances, I might take the opportunity to make some humorous comment, given that this is a sincere effort to learn, I'll hold back.
Quote:
Originally Posted by kitek
I have always struggled with this and all the docs just flood me with info but I do not understand them I have tried using webmin to do it as well but it is confusing sill.
|
I'd advise you to do two things, initially; one is to look through some example firewall scripts:
http://www.yolinux.com/TUTORIALS/Lin...rkGateway.html
http://www.linuxhomenetworking.com/w...Using_iptables
The first of those is the simpler example, the second goes into more depth. Both are worth reading.
Then, for the manual:
http://www.frozentux.net/documents/iptables-tutorial/
that is described as a tutorial, but honestly it is close to a manual as well. The iptables man page is good too 9and I wouldn't say that of every man page), but I find the frozentux document easier to go through. (In spite of it being ~500 pages, I printed it out. Alternatively, keeping a .pdf on your hard disk is good, too.)
Quote:
Originally Posted by kitek
...lets say add port 1000 to be allowed in. What is the command in the shell to do this and can you explain me the arguments please?
|
That always scares me a little bit. I'm always afraid that if you take a running iptables script an add or remove a rule, that you don't get the right one. You probably do get the right one when you first write and test it, but, when you make a change to something else, will you always remember that you have another script that is adding a rule at the end or deleting the last rule?
As a consequence, I'd always prefer to have 'one big bash script that creates the whole iptables ruleset'. Then you keep everything in one place.
Anyway, just to discuss port 1000, as a general example, there are several things that you can do. You could set up a rule that matches (see 'matches' in the frozentux guide) all traffic on port 1000. This is pretty permissive (for port 1000), and may or may not add much to your security (well, it'll do nothing for the security of what sits on port 1000, but the implication, if true, that you may dropping lots of stuff on other ports might be helpful for the things listening on those ports).
It
might be that you can say that whatever happens on port 1000 will always be initiated by your system, and you will expect a response from the far end, but the far end will never initiate a conversation with your system. In this case, you can allow whatever your system initiates on port 1000, and allow packets in that are in the states 'established' or 'related'. This is more secure than the previous option (if an external site tries to send you packets when you don't expect them, they'll be dropped), but will only work if you initiate all the port 1000 conversations. (The opposite might also be true - maybe it is the case that the far end always initiates the conversations.)
You might, for example, be able to say that you only expect UDP traffic on port 1000, and in that case, you can filter traffic to only allow the particular protocol that you want (UDP, in this example).
You could also do things like rate limiting - if, for example, you have a reason to think that some other site might try to flood your site with packets (...I don't know why you'd suspect this on port 1000 specifically, but you might...), you could set a rate limit, and packets above that rate limit will just be dropped (or, if you prefer, logged and dropped). Now this probably isn't a good idea for port 1000, but for something like ssh, where you might think that someone will try to bombard you with packets, as part of their attempt to 'brute force' passswords, it might have some function).
Of course, in this scenario, iptables doesn't have any notion of 'good' or 'bad' packets, it just drops packets above a certain limit, whether good or bad. That still may be better than getting a whole load of packets that you can't handle, but you are still likely to drop some good with the bad.
And finally (well, as far as I can think at the moment) you might decide that you want something different to happen when the packet comes from some addresses from what happens when it comes from others. So, you might have 'enumerated hosts' (ie, host computers that you have a list of ip addresses or ranges for) for which you are fairly permissive (eg, 192.168.x.y addresses, which would be local to your site) and others for which you are not permissive (you might say 'I allow this from my home computer, which will always be in this ip address range', or you might say 'I will not allow this range, which I know is in China (other countries that you could block exist) because I know that useful traffic will always come from my continent' - I'd be pretty careful with this, as you could end up with a difficult-to-manage, over-long list. If you are thinking about this kind of thing, you'd probably be better thinking about fail2ban, or similar).
Quote:
Originally Posted by kitek
I appologize in advanced.
|
No need for that.