FreeBSD -ийн хамгаалалтын нэг механизм болох "Security run report"-ийг тохируулах.Security run report-оор асар их лог ирж залхааж байвал доорхи зөвлөмжөөс ашиглаарай.
-------------
Check out denyhosts, it's in the tree. It works well for me and is
easy to set up.
Beech
---------
In my home server, I put SSH on a higher port and use public key to
authenticate.
This should get you rid of those messages...
Hope this helps,
Pietro Cerutti
---------
One possibility:
http://www.potentialtech.com/cms/node/16
--------
I'm a noob to *BSD, so I'm not sure if not having IPF installed means
you still have another firewall option. If you do, I'd say following
Bill's [sp]age advice is best for your system security overall.
If you don't have a firewall, another option would be to disallow ssh
password logins. i.e. only allow login via public/private key
authentication. This is a server side option, so 'man sshd_config'
and look for the PasswordAuthentication option. You'll still get the
"Invalid user..." warning messages, but short of wasting your
bandwidth and (log) diskspace, they'll be useless cracker attempts.
(And if you're looking for how to create public/private keys, 'man
ssh-keygen'.)
In general, utilizing public/private keys for remote authentication
is /much/ more secure than passwords.
HTH,
Kevin
----------
On a system I administer I put SSH to a non-standard port (in this case
1234) and the brute force attempts has gone away since then. I suggest
you trying that. Besides, you can change to RSA/DSA auth, which is more
secure.
Regards,
Gabor
---------
I'm using BruteForceBlocker quite successfully.
I take the opportunity to thank danger for it :-)
http://www.freshports.org/security/bruteforceblocker/
--
Joao Barros
----------
well you could pretty much eliminate the problem by
disabling password logins to sshd and only accepting
keyed logins. Then only a key will work.
Frequently changing the keys would ensure hackers
would have to want to get in REALLY bad in order to
gain unauthorized access by a brute force attempt.
Depending on how hosts login and their systems, you
could perhaps run a login script that regenerates keys
automatically and distributes them to the user every
so many days or whatever so the system appears
passwordless to them, and secure to the outside. This
may be more trouble then you are looking for though.
In reality using passwords with SSH kinda defeats the
purpose of SSH.
-brian
----------
Which works with pf, as far as I can see. There also seems to be
security/bruteblock, which works with ipfw2.
----------
I like to protect myself by hiding what I have, which will reduce the amount
of direct or random attacks by a lot, then deal with attacks using tools
(like bruteforceblocker).
This is especially useful when attackers are using ip-range tools to scan
common ports for their associated service.
Why keep sshd on port 22?
Nicolas
----------
I'm a fan of security/sshit
David King
Computer Programmer
Ketralnis Systems
----------
Well, this is not really an answer, yet as you bring it up,
SecurityFocus had an article last week on this:
http://www.securityfocus.com/infocus/1876
Along with some good advice. First of all: ssh is not a public service
like http or smtp where you need anyone to be able to connect. So don't
let them in the first place.
Disable direct root login, in the article more than a third attempted to
login as root. Disable shell access for service accounts such as mysql,
www or ldap.
Use a scheme for choosing usernames that avoids common names like
"james" and avoid publishing usernames on web-sites, e-mail may differ
from the username.
Disable password based authentication and require ssh-keys if possible,
best if you can ensure both pasword and key based authentication.
You may still find sshd login denied entries in your log - so what? it
was denied! This is really only a problem if the traffics saturates your
connection, or your log files grow so much that you run out of diskspace.
The article also comments on moving ssh to a different port, but this
causes confusion and annoyance if you have many users and is
non-standard. Doing the other things works great, an ssh-key on a
usb-keyring is great.
Personally, I created a script for parsing the delegated files from the
different regional registries such as only to allow connection from EU
countries.
Since then, I get at most one attempt a week, few enough to manually
look up the ip with whois and decide if the host or network should be
blocked.
Cheers, Erik
--------------
If using pf, you can write rules like (original is one line):
pass in on $ext_if proto tcp from any to $ext_if port $tcp_login
flags
S/SA keep state (max-src-conn-rate 6/25, overload
flush global)
The rule follows traffic in ssh port (aliased $tcp_login in my config)
and in this case if the connection attempts exceed 6 in 25 seconds,
the offending IP is moved into "bad_hosts" table and ruleset is
flushed to get the blocking effective. The conn attempt/time ratio can
be about anything, I've found the one used good enough.
Then in the top of ruleset I have the following (the filtering rule
from above is further down):
block in quick on $ext_if from
The bad host table is initialised in my ruleset like this:
table persist { }
Just remeber to put it into right section of pf.conf.
pf is neat, thanks for the dev effort of getting it into FreeBSD
kernel!
-Reko
-----------
Сонголтоо та өөрөө хийгээрэй.
Амжилт хүсъе
Posts
