iptables: DROP or REJECT?

[Rossz]

I've added some iptables rules to limit ssh access to a limited set of
ip addresses due to the huge number of brute-force hits in the last
month or so (thousands per day, over 100,000 on the worst day).

One question, what is the better choice, DROP or REJECT, when an
unauthorized ip address attempts to connect? Why?

--
Rossz

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rossz wrote:
> I've added some iptables rules to limit ssh access to a limited set of
> ip addresses due to the huge number of brute-force hits in the last
> month or so (thousands per day, over 100,000 on the worst day).
>
> One question, what is the better choice, DROP or REJECT, when an
> unauthorized ip address attempts to connect? Why?

It depends on what you want to accomplish, and how strict you are with the rules.


DROP discards the packet silently, in violation of the requirements of the
TCP/IP standards. However, because of this, DROP doesn't increase the number
of packets traversing your interface, and (as a policy) reduces your exposure
to black hats by minimizing your TCP/IP "profile".

OTOH, REJECT discards the packet and sends an ICMP ERROR message back to the
originator of the packet (in conformance with the requirements of the TCP/IP
standards). However, because of this, REJECT increases the amount of traffic
over your connection (because of all those ICMP ERROR packets it sends) and
does nothing to minimize your profile.

So, it's your choice:
Break the rules of TCP/IP, but lower your communications load and achieve a
small bit of additional safety by using DROP, or conform to the rules,
maintain a load on your network, and be 'normal' with REJECT.

What's your preference?

- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)

iD8DBQFDRcLYagVFX4UWr64RAgDmAJ4kjx3Tng7BMKE7T4f8L1 Tw+sCILACcCY0O
RysWZDrWHjBO/KYz1OT5vQc=
=UmB+
-----END PGP SIGNATURE-----

[Grant]

On Thu, 06 Oct 2005 23:32:08 GMT, Rossz <rosszNOSPAM@sonic.net> wrote:

>I've added some iptables rules to limit ssh access to a limited set of
>ip addresses due to the huge number of brute-force hits in the last
>month or so (thousands per day, over 100,000 on the worst day).
>
>One question, what is the better choice, DROP or REJECT, when an
>unauthorized ip address attempts to connect? Why?

Or take an each-way bet:
....
MSTATE="--match state --state"
....
function install_input_reject_target # chain_name
{
iptables -N $1
iptables -A $1 -p tcp $MLIMIT 6/min --limit-burst 6 \
-j REJECT --reject-with tcp-reset
iptables -A $1 -p udp $MLIMIT 6/min --limit-burst 6 \
-j REJECT
# drop overflow + icmp
iptables -A $1 -p all -j DROP
}
....
install_input_reject_target ireject
....

Follow protocol rules for reasonable input, then DROP unreasonable
traffic, some call this 'adaptive' firewall or adaptive stealthing.

Grant.

[Mihai Osian]

Rossz wrote:

> I've added some iptables rules to limit ssh access to a limited set of
> ip addresses due to the huge number of brute-force hits in the last
> month or so (thousands per day, over 100,000 on the worst day).
>
> One question, what is the better choice, DROP or REJECT, when an
> unauthorized ip address attempts to connect? Why?
>

In addition to the replies above: if you use DROP, the connection
request will time-out, which can take quite some time. As explained by
Lew, if you use REJECT the other machine will get immediately an
explicit refuse.
Since IMHO foreign machines have no business accessing random ports on
my servers I won't make their life easier, so I use DROP on the external
interfaces. On the other hand, I am gentle with my LAN users and I use
REJECT for the internal interface. For example, if a user misconfigures
his e-mail client and sets POP instead of IMAP, he will get "connection
refused" immediately, instead of "connection time-out" over 60 seconds.
( I would recommend that you also log the packets from LAN before
rejecting them - it can help finding Windows malware).

Mihai

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mihai Osian wrote:
> Rossz wrote:
>
>> I've added some iptables rules to limit ssh access to a limited set of
>> ip addresses due to the huge number of brute-force hits in the last
>> month or so (thousands per day, over 100,000 on the worst day).
>>
>> One question, what is the better choice, DROP or REJECT, when an
>> unauthorized ip address attempts to connect? Why?
>>
>
> In addition to the replies above: if you use DROP, the connection
> request will time-out, which can take quite some time. As explained by
> Lew, if you use REJECT the other machine will get immediately an
> explicit refuse.
> Since IMHO foreign machines have no business accessing random ports on
> my servers I won't make their life easier, so I use DROP on the external
> interfaces. On the other hand, I am gentle with my LAN users and I use
> REJECT for the internal interface.

FWIW, my firewall rules explicitly DROP any packets from the internet to
my LAN that don't meet my requirements for passage (ie trying to access
priviledged ports, coming from a blacklisted IP address, etc).

OTOH, my firewall rules explicitly REJECT any packets from my LAN to the
internet that don't meet my requirements for passage (i.e. trying to
send to a private IP range or trying to send one of the ICMP messages
I've blacklisted).


- --

Lew Pitcher, IT Specialist, Enterprise Data Systems
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFDRmddagVFX4UWr64RAmAeAJ0Rp0ZRQvwITsb2SpHNNA v0qKe9CQCg3UhI
bETJKATYDqEnoT+dHLhBItQ=
=Bcft
-----END PGP SIGNATURE-----

[Moe Trin]

In the Usenet newsgroup comp.os.linux.security, in article
<1128677989.694645@seven.kulnet.kuleuven.ac.be>, Mihai Osian wrote:

> In addition to the replies above: if you use DROP, the connection
>request will time-out, which can take quite some time. As explained by
>Lew, if you use REJECT the other machine will get immediately an
>explicit refuse.

Most worms/trojans are running in parallel on the infected system, and
are quite unaffected by timeouts. The worm doesn't have to keep track
of the connection in the classical sense - sending identical packets
to multiple hosts means you only need to remember what was in any
packet. Any host that responds isn't going to know the difference,
and you can make as many connection attempts in a second as your bandwidth
allows. If none respond, you haven't lost anything, and if any (or all)
respond, pick up the SYN/ACK and start a new thread (or hand it off to
another instance of your k3w1 skript).

> Since IMHO foreign machines have no business accessing random ports on
>my servers I won't make their life easier, so I use DROP on the external
>interfaces.

You do realize that most of this stuff is automated, and even if there is
a skript kiddie behind it, he put in a range of addresses to try - he's
not likely to be setting at a keyboard typing in specific addresses to
try, one after another. That's way to much work for them.

Old guy

[Moe Trin]

In the Usenet newsgroup comp.os.linux.security, in article
<slrndkcsus.nsp.zawrotny@localhost.localdomain>, Michael Zawrotny wrote:

>It's not quite that simple. The tcp stack on the sender's machine may
>wait, then send another syn packet, and possibly repeat several times.
>In that case DROP may actually increase the incoming traffic.

Agreed. There is one advantage of DROP over REJECT. The remote host
can't fingerprint (identify the O/S of) a system that isn't responding.
The other minor advantage of dropping incoming (unrelated) UDP to
ports 1025-1030 or so (windoze messenger spam) is that these packets
are often using forged IP source addresses, and your ICMP Port Unreachable
is wasted bandwidth (goes to the wrong host, or is ignored because the
packets have already been delivered). For those of you in network
admin, port shifting OUTGOING UDP (almost always DNS queries) out of
the range 1025 - 1050 (or something) allows your upstream to block
INCOMING UDP to that range as almost certainly undesired crap.

>In addition to the suggestions from other posters, you can keep
>traffic down and minimize your profile by using REJECT with a "host
>unreachable" type instead of the default "port unreachable". By doing
>that it makes the sender think that either there is no machine there,
>or that it is down completely.

This has to be done on the router in front of the host being "attacked".
Otherwise you wind up with the rather st00pid situation of the "Host
Unreachable" message coming _from_ the unreachable host:

192.0.2.10 -> 198.18.10.20: Hello SSH daemon
198.18.10.20 -> 192.0.2.10: Sorry - host 198.18.10.20 does not exist.

Some of the suppliers of the windoze personal firewalls have tried to
adopt this technique, and can't understand why the same remote host keeps
trying to connect. A lot of people seem to forget that the specific code
returned in the ICMP Type 3 message means very little to the worm or trojan
that is attempting to connect, but the obvious inconsistency is easy to
spot.

>That of course is not true if you allow ping through and they use that
>to test first.

If you are going to 'DROP' or 'Host Unreachable' anything, you have to
do exactly the same for all ports, and all 139 protocols that are defined
(and the other 117 undefined) in an IP packet. And that includes 113/tcp
which might have an effect on your users who try to connect to some server
that is configured to require a response (either a REJECT or a "valid"
response) before proceeding. You _can_ configure things such that 113/tcp
"works" for specific hosts, or in specific states if needed.

Old guy

[Grant]

On Fri, 07 Oct 2005 08:17:34 -0400, Lew Pitcher <Lew.Pitcher@td.com> wrote:
>
>FWIW, my firewall rules explicitly DROP any packets from the internet to
>my LAN that don't meet my requirements for passage (ie trying to access
>priviledged ports, coming from a blacklisted IP address, etc).

Yes, I have a blacklist too, just DROP 'em, part of reducing traffic
from stupid web-crawlers, drop by entire 'whois' CIDR block.

>
>OTOH, my firewall rules explicitly REJECT any packets from my LAN to the
>internet that don't meet my requirements for passage (i.e. trying to
>send to a private IP range or trying to send one of the ICMP messages
>I've blacklisted).

Was under impression one could only _drop_ ICMPs, not reject them,
per RFC <mumble>.

As far as rejecting goes, when I tested various reject options I found
some types of reject message types do increase unwanted traffic, the
current 'be reasonable then drop' workings has been in place for some
time, I become less aware of the firewall needing change.

Grant.

[Moe Trin]

In the Usenet newsgroup comp.os.linux.security, in article
<d4rdk1pcdlkcv9lqgdlfb2ofus72lrvphq@4ax.com>, Grant wrote:

> Lew Pitcher <Lew.Pitcher@td.com> wrote:

>>OTOH, my firewall rules explicitly REJECT any packets from my LAN to the
>>internet that don't meet my requirements for passage (i.e. trying to
>>send to a private IP range or trying to send one of the ICMP messages
>>I've blacklisted).
>
>Was under impression one could only _drop_ ICMPs, not reject them,
>per RFC <mumble>.

Bottom of page one of RFC0792

The ICMP messages typically report errors in the processing of
datagrams. To avoid the infinite regress of messages about messages
etc., no ICMP messages are sent about ICMP messages. Also ICMP
messages are only sent about errors in handling fragment zero of
fragemented datagrams. (Fragment zero has the fragment offeset equal
zero).

but I doubt Lew is "REJECT"ing ICMP. I suspect that's merely sentence
structure.

>As far as rejecting goes, when I tested various reject options I found
>some types of reject message types do increase unwanted traffic,

Details?

Old guy

[Grant]

On Sat, 08 Oct 2005 16:14:56 -0500, ibuprofin@painkiller.example.tld (Moe Trin) wrote:

>In the Usenet newsgroup comp.os.linux.security, in article
><d4rdk1pcdlkcv9lqgdlfb2ofus72lrvphq@4ax.com>, Grant wrote:
>
>> Lew Pitcher <Lew.Pitcher@td.com> wrote:
>
>>>OTOH, my firewall rules explicitly REJECT any packets from my LAN to the
>>>internet that don't meet my requirements for passage (i.e. trying to
>>>send to a private IP range or trying to send one of the ICMP messages
>>>I've blacklisted).
>>
>>Was under impression one could only _drop_ ICMPs, not reject them,
>>per RFC <mumble>.
>
>Bottom of page one of RFC0792
>
> The ICMP messages typically report errors in the processing of
> datagrams. To avoid the infinite regress of messages about messages
> etc., no ICMP messages are sent about ICMP messages. Also ICMP
> messages are only sent about errors in handling fragment zero of
> fragemented datagrams. (Fragment zero has the fragment offeset equal
> zero).
>
>but I doubt Lew is "REJECT"ing ICMP. I suspect that's merely sentence
>structure.
Yes, thinking of earlier mesg where Lew rejects towards localnet, drops
towards the world stuff.
>
>>As far as rejecting goes, when I tested various reject options I found
>>some types of reject message types do increase unwanted traffic,
>
>Details?
Using unusual *-prohibited ICMPs seemed to increase curiosity from
outsiders, so I settled for:

-A ireject -p tcp -m limit --limit 6/min --limit-burst 6 -j REJECT --reject-with tcp-reset
-A ireject -p udp -m limit --limit 6/min --limit-burst 6 -j REJECT --reject-with icmp-port-unreachable
-A ireject -j DROP

over the last few months, looking like a normal unix box, then
disappear into DROP mode if too much attention given. Figures
for last 12 hours or so: http://bugsplatter.mine.nu/bash/firewall/
has iptables -vnL + iptables-save if you're curious.

Cheers,
Grant.

[Jerry McBride]

Rossz wrote:

> I've added some iptables rules to limit ssh access to a limited set of
> ip addresses due to the huge number of brute-force hits in the last
> month or so (thousands per day, over 100,000 on the worst day).
>
> One question, what is the better choice, DROP or REJECT, when an
> unauthorized ip address attempts to connect? Why?
>

DROP them. The attacker would then be sending into a black hole with no
response from your computer (i.e. stealth mode). If you REJECT them, your
computer/firewall is acknowleging the connection, but sending back a "you
not welcome" message...
--

************************************************** ****************************
Registered Linux User Number 185956
FSF Associate Member number 2340 since 05/20/2004
Join me in chat at #linux-users on irc.freenode.net
Buy an Xbox for $149.00, run linux on it and Microsoft loses $150.00!
10:39am up 21 days, 1:04, 1 user, load average: 0.06, 0.08, 0.09

[Moe Trin]

In the Usenet newsgroup comp.os.linux.security, in article
<0pkgk15j5h5926koujukod39ktvemnh79d@4ax.com>, Grant wrote:

>Using unusual *-prohibited ICMPs seemed to increase curiosity from
>outsiders,

RFC1812 is a little out of the ordinary - but I normally wouldn't
expect to many people actually looking at the code number. It's
normally just taken as a rejection and that's the end of that.

>so I settled for:

>over the last few months, looking like a normal unix box, then
>disappear into DROP mode if too much attention given.

OK - got it.

Old guy

[Grant]

On Wed, 12 Oct 2005 04:02:29 GMT, rossz <rosszNOSPAM@vamos-wentworth.org> wrote:
>
>After reading all the responses to my inquiry, I've decided to use
>REJECT on the ecommerce server. For my home server I could compile a
>new kernel that supports additional filtering options, so I decided to
>send the potential troublemakers off to TARPIT.

You may find tarpit results in retaliation, no point starting a
personal 'arms race' with script kiddies?

read about 'recent' for locking out repeat offenders (also locks out
valid user' retries)

Grant.

[Petr Pisar]

Grant napsal(a):
> On Wed, 12 Oct 2005 04:02:29 GMT, rossz <rosszNOSPAM@vamos-wentworth.org> wrote:
>
>>After reading all the responses to my inquiry, I've decided to use
>>REJECT on the ecommerce server. For my home server I could compile a
>>new kernel that supports additional filtering options, so I decided to
>>send the potential troublemakers off to TARPIT.
>
> read about 'recent' for locking out repeat offenders (also locks out
> valid user' retries)
>
And therefore you need make decision on the application layer and not
network one. Parse sshd logs or use any PAM module (pam_abl or pam_tally).

--Petr

[Grant]

On Wed, 12 Oct 2005 09:06:15 GMT, Petr Pisar <petr.pisar@atlas.cz> wrote:

>Grant napsal(a):
>> On Wed, 12 Oct 2005 04:02:29 GMT, rossz <rosszNOSPAM@vamos-wentworth.org> wrote:
>>
>>>After reading all the responses to my inquiry, I've decided to use
>>>REJECT on the ecommerce server. For my home server I could compile a
>>>new kernel that supports additional filtering options, so I decided to
>>>send the potential troublemakers off to TARPIT.
>>
>> read about 'recent' for locking out repeat offenders (also locks out
>> valid user' retries)
>>
>And therefore you need make decision on the application layer and not
>network one. Parse sshd logs or use any PAM module (pam_abl or pam_tally).

Funny, that was my first reaction, think about it... First attempt, okay
or fail, cracker will retry --> locked out, meanwhile valid user notices
nothing, unless they mistype password, also need to wait out the lockout
period. Mind you, this is story I was told, I closed port 22 here ;)

Grant.

[Petr Pisar]

Grant napsal(a):
> On Wed, 12 Oct 2005 09:06:15 GMT, Petr Pisar <petr.pisar@atlas.cz> wrote:
>
>>Grant napsal(a):
>>
>>>On Wed, 12 Oct 2005 04:02:29 GMT, rossz <rosszNOSPAM@vamos-wentworth.org> wrote:
>>>
>>>>After reading all the responses to my inquiry, I've decided to use
>>>>REJECT on the ecommerce server. For my home server I could compile a
>>>>new kernel that supports additional filtering options, so I decided to
>>>>send the potential troublemakers off to TARPIT.
>>>
>>>read about 'recent' for locking out repeat offenders (also locks out
>>>valid user' retries)
>>>
>>
>>And therefore you need make decision on the application layer and not
>>network one. Parse sshd logs or use any PAM module (pam_abl or pam_tally).
>
>
> Funny, that was my first reaction, think about it... First attempt, okay
> or fail, cracker will retry --> locked out, meanwhile valid user notices
> nothing, unless they mistype password, also need to wait out the lockout
> period. Mind you, this is story I was told, I closed port 22 here ;)
>

Have you ever seen pam_abl? It is capable block attacker comming from IP
address A and don't disturb valid login attempts from IP address B. Also
it doesn't volatile yet established valid session originated from IP A.


--Petr