7:36 p.m.
I've been reading a bit about port knocking as a security tool. It makes pretty good
sense for a private box, at least for stuff like ssh and ftp. Does anybody know of a
good tutorial/example/script for fedora for this?
Thanks!
billo
10:24 a.m.
On Wed, Nov 19, 2014 at 06:38:04AM -0600, Bruno Wolff III wrote:
>If the main concern is ssh hacking, you might consider denyhosts
(yum
>install denyhosts). It's easy to set up and seems to be effective. The
>logs make fascinating (and scary) reading.
openssh stopped supporting tcpwrappers/libwrap in version 6.7 (which
isn't in Fedora yet), so this will stop working in the not too
distant future unless the Fedora maintainer puts that feature back
in.
Use fail2ban -- it can manage iptables rules instead.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
8:58 a.m.
On Wed, 19 Nov 2014, Patrick O'Callaghan wrote:
On Tue, 2014-11-18 at 21:25 -0600, Bruno Wolff III wrote:
> On Wed, Nov 19, 2014 at 01:36:46 +0000,
> Bill Oliver <vendor(a)billoblog.com> wrote:
>>
>> I've been reading a bit about port knocking as a security tool. It makes
pretty good sense for a private box, at least for stuff like ssh and ftp. Does anybody
know of a good tutorial/example/script for fedora for this?
>
> If your threat is password guessing, you can use two factor.
> It is easy to require both a password and a public key to connect, with
> the public key authentication required before any guessing of the password
> can be done.
>
> If your threat is preauthentication attacks versus the service itself, using
> a firewall is probably simpler. But you need to be able to restrict the
> allowed IPs to some small fraction of the internet. And there may be blind
> spoofing attacks that can get through the firewall. Port knocking can
> provide some additional coverage, but this adds risk of the port knocking
> service having bugs, extra work setting things up, and it isn't going to
> stop some potential attackers.
If the main concern is ssh hacking, you might consider denyhosts (yum
install denyhosts). It's easy to set up and seems to be effective. The
logs make fascinating (and scary) reading.
And of course for ftp you *are* using sftp aren't you? In that case
you're covered as well.
poc
Well, to be honest, I don't know of any big specific threats other than
the usual random people from China, Russia, and Korea that seem to attack
everybody. And there's some guy in France that knocks on my door every
now and then. I use denyhosts, and it works well, and yeah, I use sftp.
I was just reading about port knocking and thought I'd play with it a bit
to see how much of a hassle it was to use.
billo
7:39 a.m.
On Wed, 2014-11-19 at 11:58 +0000, Patrick O'Callaghan wrote:
If the main concern is ssh hacking, you might consider denyhosts
(yum
install denyhosts). It's easy to set up and seems to be effective. The
logs make fascinating (and scary) reading.
To my mind, something like this ought to be part of the SSHD
configuration - a configurable quota of allowed connection attempts to
the daemon within a certain time period from the same source. Notch up
say, three failed logins, and you can't login from that address for an
hour. And not require some external thing to protect it.
Likewise, I think that sort of thing (configurable quota filter) should
be a standard part of the firewall that you already have, where you can
apply a simple connection limiter to particular ports of your choosing
(SSH, HTTP, etc). Naturally, to avoid accidental denial of services, a
firewall needs to be able to differentiate between multiple okay
connections (e.g. browsing a webserver) and multiple not-okay
connections (e.g. not accepted SSH login attempts), not just dumbly
throttle so-many connections per minute. And, theoretically, that
shouldn't be impossible (using lack of response, or particular denial
responses from known services being a trigger it can use).
Of course a hack attempt could be made from a plethora of addresses, to
try and get past that type of entry guard, but each one should fail and
get ignored. You need a really good passphrase, and hopefully a paired
certificate, to stand against any external hack attempt, that's the real
defense. The statistics of guessing a good passphrase should be
astronomical. You don't know how many letters and/or numbers that I've
used, whether it's a real word, or several words. Nor do you know if my
password is the same now, as it was two days ago, or three minutes ago.
Your previous discarded attempts maybe shouldn't be discarded, but tried
several times. So to guess the actual one you've got nothing to work
with. To put that another way, how well can *you* pick all the winning
numbers in a lottery? And would anyone be able to win it if we didn't
know how many numbers to pick, nor within what range?
--
tim@localhost ~]$ uname -rsvp
Linux 3.17.2-200.fc20.i686 #1 SMP Tue Nov 4 18:28:00 UTC 2014 i686
All mail to my mailbox is automatically deleted, there is no point trying
to privately email me, I will only read messages posted to the public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
7:11 a.m.
The most effective thing I've found for preventing SSH attacks is
simply to listen on a different port. Yes, it's security by obscurity
so you should also deploy other counter measures, but if you choose
your non-standard port wisely you can avoid most, if not all, casual
attacks. Some tips:
Avoid obvious alternatives like 222 and 2222.
Don't use a port that is used for another popular service (80 would be *bad*!)
Ideally use a port below 1,024 as these can only be bound to by
daemons started as root.
So far, I've had exactly *one* kiddie stumble across my home server's
SSH port on a scan in several years, and that was only because they
did a brute force scan of every port below 1024 and a large number of
selected high ports. All to no avail as my IDS had already detected
the scan and denied the IP long before they reached any open ports.
--
Andy
The only person to have all his work done by Friday was Robinson Crusoe
5:58 a.m.
On Tue, 2014-11-18 at 21:25 -0600, Bruno Wolff III wrote:
On Wed, Nov 19, 2014 at 01:36:46 +0000,
Bill Oliver <vendor(a)billoblog.com> wrote:
>
>I've been reading a bit about port knocking as a security tool. It makes pretty
good sense for a private box, at least for stuff like ssh and ftp. Does anybody know of
a good tutorial/example/script for fedora for this?
If your threat is password guessing, you can use two factor.
It is easy to require both a password and a public key to connect, with
the public key authentication required before any guessing of the password
can be done.
If your threat is preauthentication attacks versus the service itself, using
a firewall is probably simpler. But you need to be able to restrict the
allowed IPs to some small fraction of the internet. And there may be blind
spoofing attacks that can get through the firewall. Port knocking can
provide some additional coverage, but this adds risk of the port knocking
service having bugs, extra work setting things up, and it isn't going to
stop some potential attackers.
If the main concern is ssh hacking, you might consider denyhosts (yum
install denyhosts). It's easy to set up and seems to be effective. The
logs make fascinating (and scary) reading.
And of course for ftp you *are* using sftp aren't you? In that case
you're covered as well.
poc
9:25 p.m.
On Wed, Nov 19, 2014 at 01:36:46 +0000,
Bill Oliver <vendor(a)billoblog.com> wrote:
I've been reading a bit about port knocking as a security tool. It makes pretty good
sense for a private box, at least for stuff like ssh and ftp. Does anybody know of a
good tutorial/example/script for fedora for this?
If your threat is password guessing, you can use two factor.
It is easy to require both a password and a public key to connect, with
the public key authentication required before any guessing of the password
can be done.
If your threat is preauthentication attacks versus the service itself, using
a firewall is probably simpler. But you need to be able to restrict the
allowed IPs to some small fraction of the internet. And there may be blind
spoofing attacks that can get through the firewall. Port knocking can
provide some additional coverage, but this adds risk of the port knocking
service having bugs, extra work setting things up, and it isn't going to
stop some potential attackers.
8:30 p.m.
On Tue, Nov 18, 2014 at 5:36 PM, Bill Oliver <vendor(a)billoblog.com> wrote:
I've been reading a bit about port knocking as a security tool. It makes
pretty good sense for a private box, at least for stuff like ssh and ftp.
Does anybody know of a good tutorial/example/script for fedora for this?
Thanks!
you might google for scripts using nmap...
hth,...
billo
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
6:38 a.m.
On Wed, Nov 19, 2014 at 11:58:11 +0000,
Patrick O'Callaghan <pocallaghan(a)gmail.com> wrote:
If the main concern is ssh hacking, you might consider denyhosts (yum
install denyhosts). It's easy to set up and seems to be effective. The
logs make fascinating (and scary) reading.
openssh stopped supporting tcpwrappers/libwrap in version 6.7 (which
isn't in Fedora yet), so this will stop working in the not too distant
future unless the Fedora maintainer puts that feature back in.
12:44 p.m.
On 11/19/2014 11:04 AM, Patrick O'Callaghan wrote:
On Wed, 2014-11-19 at 06:38 -0600, Bruno Wolff III wrote:
> On Wed, Nov 19, 2014 at 11:58:11 +0000,
> Patrick O'Callaghan <pocallaghan(a)gmail.com> wrote:
>>
>> If the main concern is ssh hacking, you might consider denyhosts (yum
>> install denyhosts). It's easy to set up and seems to be effective. The
>> logs make fascinating (and scary) reading.
>
> openssh stopped supporting tcpwrappers/libwrap in version 6.7 (which
> isn't in Fedora yet), so this will stop working in the not too distant
> future unless the Fedora maintainer puts that feature back in.
Well that's just great. Thanks for the heads up. I guess I'll have to
get into fail2ban after all (I had opted for denyhosts because at the
time it seemed easier).
poc
Look at OSSEC, too.
--
-- Steve
11:04 a.m.
On Wed, 2014-11-19 at 06:38 -0600, Bruno Wolff III wrote:
On Wed, Nov 19, 2014 at 11:58:11 +0000,
Patrick O'Callaghan <pocallaghan(a)gmail.com> wrote:
>
>If the main concern is ssh hacking, you might consider denyhosts (yum
>install denyhosts). It's easy to set up and seems to be effective. The
>logs make fascinating (and scary) reading.
openssh stopped supporting tcpwrappers/libwrap in version 6.7 (which
isn't in Fedora yet), so this will stop working in the not too distant
future unless the Fedora maintainer puts that feature back in.
Well that's just great. Thanks for the heads up. I guess I'll have to
get into fail2ban after all (I had opted for denyhosts because at the
time it seemed easier).
poc
10:36 a.m.
On 11/19/2014 07:38, Bruno Wolff III wrote:
On Wed, Nov 19, 2014 at 11:58:11 +0000,
Patrick O'Callaghan <pocallaghan(a)gmail.com> wrote:
>
> If the main concern is ssh hacking, you might consider denyhosts (yum
> install denyhosts). It's easy to set up and seems to be effective. The
> logs make fascinating (and scary) reading.
openssh stopped supporting tcpwrappers/libwrap in version 6.7 (which
isn't in Fedora yet), so this will stop working in the not too distant
future unless the Fedora maintainer puts that feature back in.
I've found fail2ban to be the weapon of choice. Not only will it block
brute force attempts by bad guys for SSH, but you can also configure it
to block attempts against other services. For example, I use it to
block attempts to send email through the server from addresses that may
be forged. It works like a charm, is easy to configure and use, and yum
should give it to you in a snap.
Tom
3498
days inactive
3498
days old
12 comments
10 participants
participants (10)
-
Andy Blanchard -
Bruno Wolff III -
Garry Williams -
Jack Craig -
Matthew Miller -
Patrick O'Callaghan -
SternData -
Tim -
Tom Rivers -
William Oliver