Bill Moran wrote:
In response to Erik Norgaard <norga...@locolomo.org>:
Bill Moran wrote:
In response to Erik Norgaard <norga...@locolomo.org>:
I do, you can put your interface in promiscuous mode and let the daemon
grab packets before they are filtered by the firewall, or open in your
firewall for a range of port your knock deamon will listen to. In either
case you add an extra daemon, an extra point of failure, an extra piece
of code that can undermine your security.
In your earlier message you argued that promiscuous mode is a bad idea, and
when I show that it's not the case, you magically change your argument to
be about extra processes running. Please keep your argument consistent.
My argument is consistent: I still think promiscuous mode is a bad idea
as it allows to circumvent the firewall.
I then argue that the alternative is also a bad idea since, while you
may have got rid of the promiscuous mode problem which in itself is a
bad idea, you still introduce a service that will need to listen on a
number of ports.
The alternative is to have a daemon parsing firewall log files, this is
the old solution which has been abandoned if you check portknocking.org
And it can result in people being unable to access if the knocks are
filtered at the source.
Which can happen anyway if you have an ISP who filters out ssh traffic
(which isn't unheard of).
There's no point in adding this argument, in that case you have no
connection with or without port knocking. Sticking to standard protocols
on standard ports is the best way to ensure your ISP doesn't get in your
way.
Both false. Quite frequently I've moved services to a nonstandard port
because it was the _only_ way to get a service.
Please read again. I here argue against port knocking not against
running on a non-standard port.
If you have a problem running your ssh on some port - standard or not -
then you will likely also have trouble getting port-knocking working.
If you don't have a problem running you ssh on the standard port, then
you may still find problems deploying port-knocking.
Your argument is logically inconsistent.
... an the _best_ way to ensure your ISP doesn't pull that kind of crap
on you is to use an ISP that won't do that. Not everyone has that option,
though.
The best way to get your ISP to allow connections is to use standard
well documented protocols on standard ports as it is fairly easy to
convince them that this is a standard service and should be enabled.
And it's not only ISPs, it's also the other sites your users visit,
businesses that may employ their policies. The more you divert from
standards the more likely you are to have your connection blocked by a
policy some where, and the more difficulty you'll have convincing that a
change should be made.
So your argument about port knocking boils down to getting rid of some
log entries, while annoying your users?
Nay. It boils down to making log entries _useful_. And if your users
are annoyed, you're not doing your job. Something like puTTY (for example)
allows you to set up a profile. Just set the port in the profile and
the user never need remember it again.
Yes, changing to a non-standard port is not excessively annoying and I
agree that this measure cannot compromise the security. But I think
port-knocking is annoying, it may cause security problems and it does
not add any real security.
And if catering to users who don't know how to switch ports is more important
than making your logs useful, then do that instead. I'm not arguing that
it's the correct solution for everyone, I'm simply arguing that it's not
totally useless, which seems to be your point.
It is security by obscurity not adding any real security but potentially
worsening it or causing denial of service - no in the sense of DOS
attacks but in the sense that it doesn't allow ordinary users to login
and get stuff done.
Now, how about your logs of failed port knocking attempts? Because, you
log that, right? If your idea gains traction, then attackers will start
knocking ports randomly ... you'll just have those logs filling up instead.
Once attackers start trying random keys instead of passwords, will you
abandon PKI as well?
Bad example. The only valid point you have demonstrated thus far is that
you get less log entries. I am not convinced that this compensates for
the problems you face deploying it. And, then also I argue that your
only valid point only remains valid as long as I am correct in my analysis
Security has been, and always will be, keeping one step ahead of your
attackers. Take the opinion that you can't stay ahead of them, and you've
already lost the war.
Best way to stay ahead is to deploy solutions that add real security and
not solutions that add complexity and obscurity.
if this is your main concern, why don't you just filter out the failed
attempts? after all they failed. If you do proper security monitoring,
your tools can be tuned to look at the interesting part of the logs.
Because a successful attack is already too late. I want to know who is
_attempting_ to break in and prevent them from having additional time
to keep trying.
You can perfectly filter a lot of failed attempts. If you deny users
other than those in the group users, then the failed login attempts for
the user "games" are really not very interesting. Filtering your logs
and keep the interesting part is a standard job. But it is a completely
different problem.
LoginGraceTime
MaxAuthTries
MaxSessions
MaxStartups
All of these are valid _parts_ of a comprehensive security approach to
SSH. Any one of them alone is not very strong, but combine them with
a strong password policy and other tools, and you'll have a site that's
very secure.
I don't argue that they add much security, but they may reduce the log
load that annoys you so much, and buy you time.
Also, very effective, identify address ranges where your users will
never connect from and black list them in the first place.
If that's possible. It frequently is, but what if you have users who
travel worldwide? Heck, something as simple as nationwide quickly
makes it difficult to reliably block enough ranges to be effective.
Certainly, if you have a large organization with lots of people
travelling such that the yearly exception is not a working solution -
hey you could have the secretary tell when tickets are purchased to do
add exceptions without the fuzz.
The typical solution is not to add complexity in services but to isolate
the systems these people can access and restrict the services available
such as to limit the impact of any successful attack.
My point in all this is not that your suggestions are bad. It's just
that your discounting of knock methods an moving ports is a bit
extreme. There are a number of cases where those techniques are very
useful in combination with other security practices.
My point is that any theoretical security that may be gained with
port-knocking does not compensate for the all real and potential
problems you will likely run into.
Now instead of being woken up by the salesman that can't access from
some remote country, you'll be woken up by the same salesman that can't
access because the knocking sequence is filtered.
There are so many more efficient ways of improving security, I have yet
to be convinced of the existence of a scenario where port-knocking will
create a measurable increased effect that cannot be achieved with more
easily with off-the-shelf solutions.
BR, Erik
--
Erik Nørgaard
Ph: +34.666334818/+34.915211157 http://www.locolomo.org
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
