blocking ports 1:1024

Hi all,

Is there any point to blocking ports 1:1024 through iptables from ips
other than 127.0.0.1? Of course, I would then overwrite that setting for
some ports, such as 80, 443, 21, 22, 25, etc to allow these services to
function properly. Does this provide any security, or is this completely
useless and only causes errors down the road?

Thanks,
Max

Max Nokhrin wrote on 30.07.2004 23:07:

> Hi all,
>
> Is there any point to blocking ports 1:1024 through iptables from ips
> other than 127.0.0.1? Of course, I would then overwrite that setting for
> some ports, such as 80, 443, 21, 22, 25, etc to allow these services to
> function properly. Does this provide any security, or is this completely
> useless and only causes errors down the road?

IMHO it's common practice to deny _all_ incoming connections except on
specified ports.

--
Walter

Walter Schiessberg wrote:

> Max Nokhrin wrote on 30.07.2004 23:07:
>
>> Hi all,
>>
>> Is there any point to blocking ports 1:1024 through iptables from ips
>> other than 127.0.0.1? Of course, I would then overwrite that setting
>> for some ports, such as 80, 443, 21, 22, 25, etc to allow these
>> services to function properly. Does this provide any security, or is
>> this completely useless and only causes errors down the road?
>
>
> IMHO it's common practice to deny _all_ incoming connections except on
> specified ports.
>

I tried that, but for some reason, it blocked out my FTP transfers doing
it that way. I would assume that once a connections is established,
iptables would let all subsequent connections through even on a blocked
port. Is that correct?

Max

> I tried that, but for some reason, it blocked out my FTP transfers doing
> it that way.

As a workaround, try establishing FTP connections in passive mode.

Unless the FTP client is running in 'passive' mode, the control connection
for ftp session is initiated from client to server, and all subsequent data
connections are initiated from server to client. In passive mode client
initiates all connections.

> I would assume that once a connections is established,
> iptables would let all subsequent connections through even on a blocked
> port. Is that correct?

Do 'man iptables' and look for information about STATE module. Is this what
you are thinking about? If it is, then yes, otherwise I'd say that if port
is blocked then it's blocked

Max Nokhrin wrote on 31.07.2004 00:07:

> Walter Schiessberg wrote:
>
>> Max Nokhrin wrote on 30.07.2004 23:07:
>>
[...]
>> IMHO it's common practice to deny _all_ incoming connections except on
>> specified ports.
>>
>
> I tried that, but for some reason, it blocked out my FTP transfers doing
> it that way. I would assume that once a connections is established,
> iptables would let all subsequent connections through even on a blocked
> port. Is that correct?

"Normal" FTP uses two connections: one you initialize to the remote
server and one back from the remote server to your machine (port 20).
Problem for iptables is now that this is a remotely initialized
connection and will therefore be blocked.
You won't have any problems with passive FTP.

--
Walter

"Max Nokhrin" <(E-Mail Removed)> wrote in message
news:410ac6cb$(E-Mail Removed)

>> IMHO it's common practice to deny _all_ incoming connections except
>> on specified ports.
>
> I tried that, but for some reason, it blocked out my FTP transfers
> doing it that way. I would assume that once a connections is
> established, iptables would let all subsequent connections through
> even on a blocked port. Is that correct?

"/sbin/insmod ip_conntrack_ftp" takes care of it.


tony

--
use hotmail for email replies

ynotssor wrote:

> "Max Nokhrin" <(E-Mail Removed)> wrote in message
> news:410ac6cb$(E-Mail Removed)
>
>
>>>IMHO it's common practice to deny _all_ incoming connections except
>>>on specified ports.
>>
>>I tried that, but for some reason, it blocked out my FTP transfers
>>doing it that way. I would assume that once a connections is
>>established, iptables would let all subsequent connections through
>>even on a blocked port. Is that correct?
>
>
> "/sbin/insmod ip_conntrack_ftp" takes care of it.
>
>
> tony
>
Thanks a lot!

Max Nokhrin <(E-Mail Removed)> writes:

]Walter Schiessberg wrote:

]> Max Nokhrin wrote on 30.07.2004 23:07:
]>
]>> Hi all,
]>>
]>> Is there any point to blocking ports 1:1024 through iptables from ips
]>> other than 127.0.0.1? Of course, I would then overwrite that setting
]>> for some ports, such as 80, 443, 21, 22, 25, etc to allow these
]>> services to function properly. Does this provide any security, or is
]>> this completely useless and only causes errors down the road?
]>
]>
]> IMHO it's common practice to deny _all_ incoming connections except on
]> specified ports.
]>

]I tried that, but for some reason, it blocked out my FTP transfers doing
]it that way. I would assume that once a connections is established,
]iptables would let all subsequent connections through even on a blocked
]port. Is that correct?

No, It lets through only those connections which are paired with the
outgoing ones, but these are usually for ports beyond 1024.
Sounds like you did not let through outgoing ftp.

Bill Unruh wrote:

> Max Nokhrin <(E-Mail Removed)> writes:
>
> ]Walter Schiessberg wrote:
>
> ]> Max Nokhrin wrote on 30.07.2004 23:07:
> ]>
> ]>> Hi all,
> ]>>
> ]>> Is there any point to blocking ports 1:1024 through iptables from ips
> ]>> other than 127.0.0.1? Of course, I would then overwrite that setting
> ]>> for some ports, such as 80, 443, 21, 22, 25, etc to allow these
> ]>> services to function properly. Does this provide any security, or is
> ]>> this completely useless and only causes errors down the road?
> ]>
> ]>
> ]> IMHO it's common practice to deny _all_ incoming connections except on
> ]> specified ports.
> ]>
>
> ]I tried that, but for some reason, it blocked out my FTP transfers doing
> ]it that way. I would assume that once a connections is established,
> ]iptables would let all subsequent connections through even on a blocked
> ]port. Is that correct?
>
> No, It lets through only those connections which are paired with the
> outgoing ones, but these are usually for ports beyond 1024.
> Sounds like you did not let through outgoing ftp.
>

You mean 20? Or add 21/20 in the OUTPUT chain?

Another question: if I DROP all packets in the INPUT chain, should I add
a rule that ACCEPTS all packets from 127.0.0.1 overriding the default
DROP policy for the INPUT chain?

Thanks,
Max

Max Nokhrin <(E-Mail Removed)> said:
>Bill Unruh wrote:
>> Max Nokhrin <(E-Mail Removed)> writes:
>> ]Walter Schiessberg wrote:
>> ]> IMHO it's common practice to deny _all_ incoming connections except on
>> ]> specified ports.
>>
>> ]I tried that, but for some reason, it blocked out my FTP transfers doing
>> ]it that way. I would assume that once a connections is established,
>> ]iptables would let all subsequent connections through even on a blocked
>> ]port. Is that correct?
>>
>> No, It lets through only those connections which are paired with the
>> outgoing ones, but these are usually for ports beyond 1024.
>> Sounds like you did not let through outgoing ftp.
>
>You mean 20? Or add 21/20 in the OUTPUT chain?

Well, do you have restrictions in the OUTPUT chain? If you want the machine
to act as a ftp client, you must allow outbound ftp (tcp/21). For active
ftp, you must also handle the connections from ftp servers back to your
machine to port tcp/20. This is handled by having the ip_conntrack_ftp
module loaded, as was described in another message.

>Another question: if I DROP all packets in the INPUT chain, should I add
>a rule that ACCEPTS all packets from 127.0.0.1 overriding the default
>DROP policy for the INPUT chain?

First: Consider chain policy as the last rule in the chain -- so, just one
step below the last visible rule.

Second: Rules in a given chain are applied in the order they appear in the
chain. ACCEPT, DROP and REJECT actions are "terminal" -- that is, once
packet matches a line that has one of these actions specified, no further
processing is done to the packet -- the judgement is final and standing.

So, if you have INPUT chain that just has the policy of DROP, then
all packets will be dropped - including those from the localhost.
In most cases it makes sense to allow all traffic within the local
machine, in chich case it's best to allow all packets that arrive from
the 'lo' interface (don't use addresses -- they can be spoofed; use
interfaces; also, on Linux, allowing traffic with 'lo' as the incoming
interface will allow machine to contact itself with any of its allocated
IP addresses, instead of just allowing the localhost address).

If you still have problems/questions, it'd be good if you could post
the output of iptables-save command - it'll contain all the rules
active on your machine.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)