comp.os.linux.networking

On 2008-04-08, David Brown wrote:
> Ignoramus10392 wrote:
>> On 2008-04-07, David Brown wrote:
>>> Chris Mattern wrote:
>>>> On 2008-04-07, Ignoramus10392 wrote:
>>>>> On 2008-04-07, Keith Keller wrote:
>>>>>> On 2008-04-07, Ignoramus10392 wrote:
>>>>>>> I do need from time to time to perform root tasks from scripts, for
>>>>>>> example restarting named after DNS zone files update.
>>>>>> That is what su and sudo are for.
>>>>>>
>>>>>>
>>>>> I thought that both su and sudo require the user to enter a password?
>>>>>
>>>> su does requires the password of the user you are switching to (unless
>>>> you're root already). sudo *normally* requires the password of the
>>>> user who invokes it as a additional security measure but can be
>>>> configured to not require it. I would regard setting up a utility
>>>> account with NOPASSWORD sudo privileges as more secure than letting
>>>> root log directly in via SSH, as you can limit the utility account
>>>> to be able to do as root only the things you list in sudo.
>>>>
>>> The other advantage of doing it this way is that any attacker using
>>> brute-force attacks needs to guess the name of the utility account as
>>> well as the password.
>>>
>>> Other useful tricks for ssh security are to rate-limit the port
>>> (especially on any internet-facing ports) - setting a limit of 3 per
>>> minute with a burst of 3 lets you easily log in, but will ruin brute
>>> force password crackers or denial of service attacks on the port. It
>>> can also be worth putting ssh on a non-standard port - use a high port
>>> number, and maybe have some automatic blacklisting for neighbouring
>>> ports, so that port scans will not catch the open ssh port.
>>
>> I am greatly interested in this ratelimit, what is the setting?
>>
>> I am getting probed, and fingered, a lot, and whatever I can do to
>> limit the chances, I would do.
>>
>> i
>
> If you are writing your iptables by hand (rather than using some sort of
> firewall/iptables front-end), you might have:
>
> iptables -A INPUT -p tcp --dport 22 -m limit --limit 3/minute
> iptables -A INPUT -p tcp --dport 22 -m limit --limit 3/minute
> iptables -A INPUT -p tcp --dport 22 -m limit --limit 3/minute
> iptables -A INPUT -p tcp --dport 22 -m limit --limit 1/minute
> iptables -A INPUT -p tcp --dport 22 -j DROP
>
> This setup will log accepted and dropped ssh attempts, but if there are
> too many drops, it will give a "flooded" log message rather than filling
> your log.
>
> You can think of a rule with "-m limit --limit 3/minute --limit-burst 5"
> as having a bucket with space for 5 tokens. A packet will only match
> the rule if it can get a token from the bucket, and the bucket refills
> at the rate of 3 per minute (1 per 20 seconds).
>
>
> If you are getting a lot of attempts on port 22, you might want to
> consider using a different port - it's just a matter of specifying "-p
> XXX" on the ssh command line when accessing the server. It's an easy
> trick that will spoil a very large percentage of automated attacks.
>
> You can also add rules to drop all ssh traffic that does not come from
> specific network addresses if you know what addresses might legitimately
> need access. If users need access from home using dynamic ip addresses,
> it is still possible to restrict access to an ISP's range of dynamic
> addresses.
>
>

I think that after limiting logon rights to a set of accounts, I am in
a good shape. These rate limiting rules can easily get me DOSed and
locked out. (unless the limits are per IP)

i