Quote:
Originally Posted by ciumcix
I was studing the configurations but I notice that is no coherent.
|
That probably wasn't as clear as you had hoped; there are things there that do not seem to make sense, but it is always clearer to look at the actual iptables ruleset rather than the commands that create the rules. So, if you follow unSpawn's suggestion, that should help.
Quote:
Originally Posted by ciumcix
Do you know why is bloquing port 15000?, What services is used the port 15000.
|
Well, I don't why it is blocking 150000, or even if it is blocking 15000. That should be clearer later. However, at little more detail on 15000 (from
here or by parsing /etc/services):
hydap 15000/tcp # Hypack Data Aquisition
hydap 15000/udp # Hypack Data Aquisition
and, this being exactly what the internet was invented for:
http://odomhydrographic.com/product/hypack/
HYPACK, Inc. develops PC-based software that brings together surveying, positioning and navigation into one flexible and user friendly program. Hypack provides the user with all of the tools necessary to plan a mission, collect data and post process.
If you feel convinced that your organisation has nothing to do with hydrographic data acquisition of this hypack program, what has almost certainly happened is that someone has thought 'I need one or more ports for this program/system that we are developing, what is a port number that we will never use for its assigned purposes?'. In that case, you will have to do some detective work, the difficulty of which might be set by your organisation's ability to document what it is doing, or your ability to find someone who acts as the corporate cultural memory bank...
Quote:
Originally Posted by ciumcix
I have notice too that rules are repeated...please send me your suggestions to correct this configurations.
|
Suggestion 1) Don't.
Suggestion 2) Don't, until you are certain that you know what you are doing, and you know for sure that you aren't about to bring the business to its knees. And, you have though about what happens if something goes wrong. And, you can define what problem you are trying to cure. OK, I'll allow that, potentially, 'It is a mess' is a problem, and that it is a problem that you can think about curing, but not working at all can well be a worse problem than 'working, but no one quite knows why or how' (which, if pushed, you'd have to describe as 'unmaintainable').
Presumably, this ruleset came about because someone created it; is that person still available to answer questions?
Just looking at a couple of the rules:
Quote:
Originally Posted by ciumcix
-A INPUT -s x.x.x.x/32 -p tcp -m tcp --dport 15000 -j ACCEPT
-A INPUT -s x.x.x.x/32 -p tcp -m tcp --dport 15000 -j DROP
x.x.x.x is a IP public
|
Presumably, in every case, x.x.x.x is
the same IP address.
As an exercise for the interested student (hint: that's you) and just to get you warmed up, you may want to think about what these two rules do (and, for extra points, whether the order of those rules is important). In doing this you can choose to use the materials contained in the
Frozentux tutorial on iptables. Or, some other material, if you prefer.