Shorewall users - Feb 2005 - shorewall friendly way of limiting ssh brute force attacks?

I was wondering if anyone had implemented rules like this in shorewall:
http://blog.andrew.net.au/tech

I see tons of brute force attempts on the machines I administer, and I like
the idea of limiting them without the need for extra daemons scanning for
attacks.

Thanks,
	Dale
-- 
Dale E. Martin - dale@the-martins.org
http://the-martins.org/~dmartin

Dale E. Martin wrote:
> I was wondering if anyone had implemented rules like this in shorewall:
> http://blog.andrew.net.au/tech
> 
> I see tons of brute force attempts on the machines I administer, and I like
> the idea of limiting them without the need for extra daemons scanning for
> attacks.
I''m currently looking at ways to integrate the
''recent'' match into
Shorewall for 2.3.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

I''d just add a "LIMIT" rule (or maybe RECENT not to confuse
it with the
existing LIMIT) with the "LIMIT" column being per-peer? It would be 
easier to see, than if it was a one-liner with ACCEPT...

Jan

Tom Eastep wrote:
> Dale E. Martin wrote:
> 
>>I was wondering if anyone had implemented rules like this in shorewall:
>>http://blog.andrew.net.au/tech
>>
>>I see tons of brute force attempts on the machines I administer, and I
like
>>the idea of limiting them without the need for extra daemons scanning
for
>>attacks.
> 
> 
> I''m currently looking at ways to integrate the
''recent'' match into
> Shorewall for 2.3.
> 
> -Tom

On Wed, 23 Feb 2005 07:04:40 -0800, Tom Eastep <teastep@shorewall.net>
wrote:
> Dale E. Martin wrote:
> > I was wondering if anyone had implemented rules like this in
shorewall:
> > http://blog.andrew.net.au/tech
> >
> > I see tons of brute force attempts on the machines I administer, and I
like
> > the idea of limiting them without the need for extra daemons scanning
for
> > attacks.
> 
> I''m currently looking at ways to integrate the
''recent'' match into
> Shorewall for 2.3.
> 
> -Tom
great idea tom¡¡ 

Im getting sick with ssh bruteforce bots¡¡ :(

thanks¡¡ 

Dale:
try Reducing the following values on sshd_config

MaxAuthTries  2 (default is 6)
MaxStartups  2 (default is 10) (tune it for your especific needs)

also remember disable root login.








On Wed, 23 Feb 2005 07:04:40 -0800, Tom Eastep <teastep@shorewall.net>
wrote:
> Dale E. Martin wrote:
> > I was wondering if anyone had implemented rules like this in
shorewall:
> > http://blog.andrew.net.au/tech
> >
> > I see tons of brute force attempts on the machines I administer, and I
like
> > the idea of limiting them without the need for extra daemons scanning
for
> > attacks.
> 
> I''m currently looking at ways to integrate the
''recent'' match into
> Shorewall for 2.3.
> 
> -Tom
Great idea Tom ¡¡:)

I think we are getting sick with ssh brute force bots ¡¡ :(

dale:

this can be a "little" help

1.disable root login 
2. modify /etc/ssh/sshd_config

MaxAuthTries 2 (default 6)
MaxStartups 2 (tune this value for your specific needs)

Jan Schermer wrote:
> I''d just add a "LIMIT" rule (or maybe RECENT not to
confuse it with the
> existing LIMIT) with the "LIMIT" column being per-peer? It would
be
> easier to see, than if it was a one-liner with ACCEPT...
I suggest that you:

a) Add LIMIT to /etc/shorewall/actions
b) Create /etc/shorewall/action.LIMIT (it will probably be empty)
c) Create /etc/shorewall/LIMIT and add the iptables commands you think
should implement ''LIMIT''
d) Let us know what you find...

Personally, I don''t think that defining LIMIT as an action is the way
to
go but I could be wrong...

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

Yes, Action is probably the way to go, but direct integration in 
shorewall would allow for a far more dynamic setups (like limiting a 
group of services with one recent match to disallow cracking 
ssh+pop3+... accounts at once - as they often share the password) - but 
not many people would use it I think.

Jan



Tom Eastep wrote:
> Jan Schermer wrote:
> 
>>I''d just add a "LIMIT" rule (or maybe RECENT not to
confuse it with the
>>existing LIMIT) with the "LIMIT" column being per-peer? It
would be
>>easier to see, than if it was a one-liner with ACCEPT...
> 
> 
> I suggest that you:
> 
> a) Add LIMIT to /etc/shorewall/actions
> b) Create /etc/shorewall/action.LIMIT (it will probably be empty)
> c) Create /etc/shorewall/LIMIT and add the iptables commands you think
> should implement ''LIMIT''
> d) Let us know what you find...
> 
> Personally, I don''t think that defining LIMIT as an action is the
way to
> go but I could be wrong...
> 
> -Tom

It''s more tricky than I thought, I can write an Action like:

run_iptables2 -A INPUT -m recent --set

but I need to specify --name $UNIQ_NAME for each RECENT, preferably one 
specified in the rules file, is there a way to pass a variable?

Jan

Jan Schermer wrote:
> Yes, Action is probably the way to go, but direct integration in 
> shorewall would allow for a far more dynamic setups (like limiting a 
> group of services with one recent match to disallow cracking 
> ssh+pop3+... accounts at once - as they often share the password) - but 
> not many people would use it I think.
> 
> Jan
> 
> 
> 
> Tom Eastep wrote:
> 
>> Jan Schermer wrote:
>>
>>> I''d just add a "LIMIT" rule (or maybe RECENT not
to confuse it with the
>>> existing LIMIT) with the "LIMIT" column being per-peer?
It would be
>>> easier to see, than if it was a one-liner with ACCEPT...
>>
>>
>>
>> I suggest that you:
>>
>> a) Add LIMIT to /etc/shorewall/actions
>> b) Create /etc/shorewall/action.LIMIT (it will probably be empty)
>> c) Create /etc/shorewall/LIMIT and add the iptables commands you think
>> should implement ''LIMIT''
>> d) Let us know what you find...
>>
>> Personally, I don''t think that defining LIMIT as an action is
the way to
>> go but I could be wrong...
>>
>> -Tom
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Shorewall-users mailing list
> Post: Shorewall-users@lists.shorewall.net
> Subscribe/Unsubscribe:
https://lists.shorewall.net/mailman/listinfo/shorewall-users
> Support: http://www.shorewall.net/support.htm
> FAQ: http://www.shorewall.net/FAQ.htm

And another thing :) I think that recent match could be used for 
portknocking without the need of a daemon listening on the raw socket, 
maybe it''s worth implementing? Would be so coool to have this in 
shorewall...

Jan

Jan Schermer wrote:
> It''s more tricky than I thought, I can write an Action like:
> 
> run_iptables2 -A INPUT -m recent --set
> 
> but I need to specify --name $UNIQ_NAME for each RECENT, preferably one 
> specified in the rules file, is there a way to pass a variable?
> 
> Jan
> 
> Jan Schermer wrote:
> 
>> Yes, Action is probably the way to go, but direct integration in 
>> shorewall would allow for a far more dynamic setups (like limiting a 
>> group of services with one recent match to disallow cracking 
>> ssh+pop3+... accounts at once - as they often share the password) - 
>> but not many people would use it I think.
>>
>> Jan
>>
>>
>>
>> Tom Eastep wrote:
>>
>>> Jan Schermer wrote:
>>>
>>>> I''d just add a "LIMIT" rule (or maybe RECENT
not to confuse it with the
>>>> existing LIMIT) with the "LIMIT" column being
per-peer? It would be
>>>> easier to see, than if it was a one-liner with ACCEPT...
>>>
>>>
>>>
>>>
>>> I suggest that you:
>>>
>>> a) Add LIMIT to /etc/shorewall/actions
>>> b) Create /etc/shorewall/action.LIMIT (it will probably be empty)
>>> c) Create /etc/shorewall/LIMIT and add the iptables commands you
think
>>> should implement ''LIMIT''
>>> d) Let us know what you find...
>>>
>>> Personally, I don''t think that defining LIMIT as an action
is the way to
>>> go but I could be wrong...
>>>
>>> -Tom
>>
>>
>>
>>
------------------------------------------------------------------------
>>
>> _______________________________________________
>> Shorewall-users mailing list
>> Post: Shorewall-users@lists.shorewall.net
>> Subscribe/Unsubscribe: 
>> https://lists.shorewall.net/mailman/listinfo/shorewall-users
>> Support: http://www.shorewall.net/support.htm
>> FAQ: http://www.shorewall.net/FAQ.htm
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Shorewall-users mailing list
> Post: Shorewall-users@lists.shorewall.net
> Subscribe/Unsubscribe:
https://lists.shorewall.net/mailman/listinfo/shorewall-users
> Support: http://www.shorewall.net/support.htm
> FAQ: http://www.shorewall.net/FAQ.htm

Tom Eastep wrote:
> Jan Schermer wrote:
> 
>>I''d just add a "LIMIT" rule (or maybe RECENT not to
confuse it with the
>>existing LIMIT) with the "LIMIT" column being per-peer? It
would be
>>easier to see, than if it was a one-liner with ACCEPT...
> 
> 
> I suggest that you:
> 
> a) Add LIMIT to /etc/shorewall/actions
> b) Create /etc/shorewall/action.LIMIT (it will probably be empty)
> c) Create /etc/shorewall/LIMIT and add the iptables commands you think
> should implement ''LIMIT''
> d) Let us know what you find...
> 
Notice that this is exactly what Dale can do to implement what he wants.

a) I would not specify ssh in the limit rule; specify it when you invoke
the action (see below).
b) There is no need to specify "-m state --state NEW".

The /etc/shorewall/LIMIT file would look something like this:

run_iptables -A $CHAIN -m recent --set --name LIM
run_iptables -A $CHAIN -j WHITELIST     # WHITELIST is another

                                        # action that accepts
                                        # connections from trusted
                                        # hosts
[ -n "$LEVEL" ] && \
	log_rule_limit "$LEVEL" "$CHAIN" LIMIT DROP \
        "$LOGLIMIT" "$TAG" -A -m recent --update --seconds
60 \
	--hitcount 4 --rttl --name LIM
run_iptables -A $CHAIN -m recent --update --seconds 60 \
	--hitcount 4 --rttl --name LIM -j DROP

Note that I have called the RECENT set ''LIM'' rather than
''SSH''.

c) The entry in /etc/shorewall/rules would be:

LIMIT[:<level>[:<tag>]]	net	fw	tcp	22

With this technique, more than just SSH can be funneled through the
LIMIT action.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

Wow, sweet :)
Thank you Tom!

Jan

Tom Eastep wrote:
> Tom Eastep wrote:
> 
>>Jan Schermer wrote:
>>
>>
>>>I''d just add a "LIMIT" rule (or maybe RECENT not
to confuse it with the
>>>existing LIMIT) with the "LIMIT" column being per-peer? It
would be
>>>easier to see, than if it was a one-liner with ACCEPT...
>>
>>
>>I suggest that you:
>>
>>a) Add LIMIT to /etc/shorewall/actions
>>b) Create /etc/shorewall/action.LIMIT (it will probably be empty)
>>c) Create /etc/shorewall/LIMIT and add the iptables commands you think
>>should implement ''LIMIT''
>>d) Let us know what you find...
>>
> 
> 
> Notice that this is exactly what Dale can do to implement what he wants.
> 
> a) I would not specify ssh in the limit rule; specify it when you invoke
> the action (see below).
> b) There is no need to specify "-m state --state NEW".
> 
> The /etc/shorewall/LIMIT file would look something like this:
> 
> run_iptables -A $CHAIN -m recent --set --name LIM
> run_iptables -A $CHAIN -j WHITELIST     # WHITELIST is another
> 
>                                         # action that accepts
>                                         # connections from trusted
>                                         # hosts
> [ -n "$LEVEL" ] && \
> 	log_rule_limit "$LEVEL" "$CHAIN" LIMIT DROP \
>         "$LOGLIMIT" "$TAG" -A -m recent --update
--seconds 60 \
> 	--hitcount 4 --rttl --name LIM
> run_iptables -A $CHAIN -m recent --update --seconds 60 \
> 	--hitcount 4 --rttl --name LIM -j DROP
> 
> Note that I have called the RECENT set ''LIM'' rather than
''SSH''.
> 
> c) The entry in /etc/shorewall/rules would be:
> 
> LIMIT[:<level>[:<tag>]]	net	fw	tcp	22
> 
> With this technique, more than just SSH can be funneled through the
> LIMIT action.
> 
> -Tom