As long as I use iptables I was not able to use policies of reject. I
even remember the target 'REJECT' being a selectable kernel option.
Reject requires some ICMP action whereas DROP doesn't.

> I am just going through my firewall setup and I notice I can no longer
> do iptables -P INPUT REJECT

> when did this happen ? I could have sworn that is what I used to use as
> a default, yes I know I can drop and add a -A -j REJECT

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFG5j+TUubxfRxK3KIRAjkeAJ9bF0jWBXdhAnLfdZc9Y5 18rs3YRwCdGESG
uB+tVHUzHeqKMN/MRu7EJYo=
=hkly
-----END PGP SIGNATURE-----

On Tue, Sep 11, 2007 at 09:11:12AM +0200, Christopher Zimmermann wrote:
> As long as I use iptables I was not able to use policies of reject. I
> even remember the target 'REJECT' being a selectable kernel option.
> Reject requires some ICMP action whereas DROP doesn't.
I can understand the reasoning.

I will have to put it down to faulty memory on my part, thought I would ask
anyway
>
> > I am just going through my firewall setup and I notice I can no longer
> > do iptables -P INPUT REJECT
>
> > when did this happen ? I could have sworn that is what I used to use as
> > a default, yes I know I can drop and add a -A -j REJECT



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFG5liokZz88chpJ2MRAgSyAKDMcW4iZHlL9Mc+AeaRju GJzZsR8ACeMVnV
5NyQ3PI/DO4MsovYzfFznhM=
=RDvu
-----END PGP SIGNATURE-----

On Sep 11, 2007, at 12:11 AM, Christopher Zimmermann wrote:

> As long as I use iptables I was not able to use policies of reject. I
> even remember the target 'REJECT' being a selectable kernel option.
> Reject requires some ICMP action whereas DROP doesn't.

But be aware that DROP can cause unexpected side-effects in some
cases, because it's not what remote hosts expect.

I recall one instance where a mail server I'd configured couldn't
send mail to one particular system. Both systems could freely
exchange mail with other places.

The problem turned out to be that I was dropping packets sent to the
ident port. When my system tried to initiate an SMTP exchange, the
other system would try to do an ident callback against it. Since I
was dropping packets instead of rejecting them, the whole transaction
would come to a halt while the other system waited for the ident
connection to time out. By the time that happened, the SMTP daemon
on the other system had timed out, as well, so no mail ever got
delivered.

Once I started rejecting packets to ident instead, things worked,
since the ident callback would fail immediately. (Actually, since I
didn't have the REJECT target, I just opened the ident port and then
made sure identd wasn't running.)




--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

David Brodbeck wrote:
>
> On Sep 11, 2007, at 12:11 AM, Christopher Zimmermann wrote:
>
>> As long as I use iptables I was not able to use policies of reject. I
>> even remember the target 'REJECT' being a selectable kernel option.
>> Reject requires some ICMP action whereas DROP doesn't.
>
> But be aware that DROP can cause unexpected side-effects in some cases,
> because it's not what remote hosts expect.
>
> I recall one instance where a mail server I'd configured couldn't send
> mail to one particular system. Both systems could freely exchange mail
> with other places.
>
> The problem turned out to be that I was dropping packets sent to the
> ident port. When my system tried to initiate an SMTP exchange, the
> other system would try to do an ident callback against it. Since I was
> dropping packets instead of rejecting them, the whole transaction would
> come to a halt while the other system waited for the ident connection to
> time out. By the time that happened, the SMTP daemon on the other
> system had timed out, as well, so no mail ever got delivered.
>
> Once I started rejecting packets to ident instead, things worked, since
> the ident callback would fail immediately. (Actually, since I didn't
> have the REJECT target, I just opened the ident port and then made sure
> identd wasn't running.)
<snip>

That's why when I use 'DROP' as default policy on the INPUT chain I also
add:

... --dport 113 -j REJECT --reject-with tcp-reset


--
regards,
Georgi Alexandrov

key server - pgp.mit.edu :: key id - 0x37B4B3EE
Key fingerprint = E429 BF93 FA67 44E9 B7D4 F89E F990 01C1 37B4 B3EE


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFG5swT+ZABwTe0s+4RAvHfAJ0TjeFOp/7s0kGf54PcOXPzD+MOyACdES7r
iZ+Pjd10o0kH6aLvfecsafM=
=GdTz
-----END PGP SIGNATURE-----

On Tue, 11 Sep 2007 09:52:12 -0700
David Brodbeck <brodbd@u.washington.edu> wrote:

>
> On Sep 11, 2007, at 12:11 AM, Christopher Zimmermann wrote:
>
> > As long as I use iptables I was not able to use policies of reject. I
> > even remember the target 'REJECT' being a selectable kernel option.
> > Reject requires some ICMP action whereas DROP doesn't.
>
> But be aware that DROP can cause unexpected side-effects in some
> cases, because it's not what remote hosts expect.
>
> I recall one instance where a mail server I'd configured couldn't
> send mail to one particular system. Both systems could freely
> exchange mail with other places.
>
> The problem turned out to be that I was dropping packets sent to the
> ident port. When my system tried to initiate an SMTP exchange, the
> other system would try to do an ident callback against it. Since I
> was dropping packets instead of rejecting them, the whole transaction
> would come to a halt while the other system waited for the ident
> connection to time out. By the time that happened, the SMTP daemon
> on the other system had timed out, as well, so no mail ever got
> delivered.
>
> Once I started rejecting packets to ident instead, things worked,
> since the ident callback would fail immediately. (Actually, since I
> didn't have the REJECT target, I just opened the ident port and then
> made sure identd wasn't running.)

This is indeed a notorious issue. From the shorewall FAQ:

> (FAQ 4) I just used an online port scanner to check my firewall and it shows some ports as “closed� rather than “blocked�. Why?
>
> Answer: The default Shorewall setup invokes the Drop action prior to enforcing a DROP policy and the default policy to all zone from the internet is DROP. The Drop action is defined in /usr/share/shorewall/action.Drop which in turn invokes the Auth macro (defined in /usr/share/shorewall/macro.Auth) specifying the REJECT action (i.e., Auth/REJECT). This is necessary to prevent outgoing connection problems to services that use the “Auth� mechanism for identifying requesting users. That is the only service which the default setup rejects.

Celejar
--
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org