2009/6/28 Polytropon :
> On Sat, 27 Jun 2009 21:17:11 -0400, Daniel Underwood
> wrote:
>> Exactly. For example, the "server" in question is a desktop machine
>> at work. I regularly see transfer rates of 13MB/s. It's at a major
>> university, which is by itself another high-risk factor, precis
On Sat, 27 Jun 2009 21:17:11 -0400, Daniel Underwood
wrote:
> Exactly. For example, the "server" in question is a desktop machine
> at work. I regularly see transfer rates of 13MB/s. It's at a major
> university, which is by itself another high-risk factor, precisely
> because there are so man
> As I believe has already been answered in this thread, the better connected
> a server is to the Internet, the higher its value to several varieties of
> miscreants. Given a choice between a server connected via a close to
> saturated T1 somewhere in the back waters of the Internet and a server
Jos Chrispijn wrote:
Daniel Underwood wrote:
laptop to connect to the server. Due to the speed and location of the
connection, it's a relatively high-risk target.
Can you tell me what you mean with that? I mean, imho a server must been
consider always a risk target.
Perhaps I don't under
Daniel Underwood wrote:
laptop to connect to the server. Due to the speed and location of the
connection, it's a relatively high-risk target.
Can you tell me what you mean with that? I mean, imho a server must been
consider always a risk target.
Perhaps I don't understand.
Jos Chrispijn
On Wed, 24 Jun 2009 17:12:59 +0200
cpghost wrote:
> It all boils down to this: do you login from a secure machine
> or not? Each tool has its own set of uses. When I want to log in
> from a public terminal, I prefer OPIE;
OPIE is probably fine in almost all cases, but you may wish to read the
On Wed, Jun 24, 2009 at 04:50:01PM +0200, Erik Norgaard wrote:
> cpghost wrote:
> > On Wed, Jun 24, 2009 at 03:53:15PM +0200, Erik Norgaard wrote:
> > But port knocking can be useful and provide more security *if* you
> > modify the kocking sequence algorithmically and make it, e.g. a
> > function
cpghost wrote:
On Wed, Jun 24, 2009 at 03:53:15PM +0200, Erik Norgaard wrote:
But port knocking can be useful and provide more security *if* you
modify the kocking sequence algorithmically and make it, e.g. a
function of time, source IP/range (and other factors). This could
prevent a whole class
> Point remains: Adding port knocking does not solve any security problem, it
> only adds
> complexity, cost, points of failure, inconvenience etc while making your
> problem appear
> differently and leaving you with the illusion of being more secure.
I think that's grossly overstated, if not ju
On Wed, Jun 24, 2009 at 03:53:15PM +0200, Erik Norgaard wrote:
> RW wrote:
> > On Tue, 23 Jun 2009 22:37:12 +0200
> > Erik Norgaard wrote:
> >
> >> You're right, as long as port-knocking as a first pass authentication
> >> scheme is not in wide spread use, then any attackers will not waste
> >>
RW wrote:
On Tue, 23 Jun 2009 22:37:12 +0200
Erik Norgaard wrote:
You're right, as long as port-knocking as a first pass authentication
scheme is not in wide spread use, then any attackers will not waste
time port-knocking. If ever port-knocking becomes common, attackers
will adapt and start
On Tue, 23 Jun 2009 22:37:12 +0200
Erik Norgaard wrote:
> You're right, as long as port-knocking as a first pass authentication
> scheme is not in wide spread use, then any attackers will not waste
> time port-knocking. If ever port-knocking becomes common, attackers
> will adapt and start knoc
Bill Moran wrote:
In response to Erik Norgaard :
Bill Moran wrote:
In response to Erik Norgaard :
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 wi
In response to Erik Norgaard :
> Bill Moran wrote:
> > In response to Erik Norgaard :
> >
> >> - dynamically updating firewall rules on the interface facing the
> >> Internet is not on my list of good practices. loading or flushing rules
> >> continuously is the recipe for service interruption
Daniel Underwood wrote:
A port-knocking sequence is really nothing different than a shared password.
Technically and conceptually, that's true. But "practically", I'm not
sure you're right. If in addition to attempting to enumerate the
space of possible passwords, an attacker also enumerates
> A port-knocking sequence is really nothing different than a shared password.
Technically and conceptually, that's true. But "practically", I'm not
sure you're right. If in addition to attempting to enumerate the
space of possible passwords, an attacker also enumerates the space of
possible por
On Mon, Jun 22, 2009 at 22:50, prad wrote:
> On Mon, 22 Jun 2009 21:16:35 -0400
> Daniel Underwood wrote:
>
>> Due to the speed and location of the
>> connection, it's a relatively high-risk target.
>>
> why does the speed of a connection make it a higher risk?
> is it because bruteforce technique
Bill Moran wrote:
In response to Erik Norgaard :
You add an extra layer of inconvenience and complexity, more things that
can fail and possibly result in an insecure server:
I would agree with you, except ...
- dynamically updating firewall rules on the interface facing the
Internet is not
In response to Erik Norgaard :
> Daniel Underwood wrote:
> >> I do not believe that tricks like running ssh on a
> >> non standard port or using port-knocking provide
> >> much extra security.
> >
> > I can understand that varying the port is not a very strong defensive
> > measure, but I don't u
Daniel Underwood wrote:
I do not believe that tricks like running ssh on a
non standard port or using port-knocking provide
much extra security.
I can understand that varying the port is not a very strong defensive
measure, but I don't understand your point about port-knocking.
If you configur
> I do not believe that tricks like running ssh on a
> non standard port or using port-knocking provide
> much extra security.
I can understand that varying the port is not a very strong defensive
measure, but I don't understand your point about port-knocking.
If you configure a complex and seemi
"why does the speed of a connection make it a higher risk?"
Super-fast connections are ideal targets for people to install private
fileservers (among other things).
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/
99% of crack attempts are done by "kevin mitnick" methods, not password
cracking.
Absolutely true. Mitnick was an early exponent of Social Engineering
attacks, which are still the easiest and most effective methods for
Mitnick just chose the best possible friend - human stupidity. It never
f
99% of crack attempts are done by "kevin mitnick" methods, not password
cracking.
You're right about the probability of password breaking, but
personally I installed denyhosts just because I got sick of this:
indeed, it's very useful but it's not a requirement at all to be secure :)
The only
2009/6/23 Wojciech Puchar :
>> If for some reason you would prefer to use password authentication, I
>> would recommend that you look into automatic brute force detection.
>> There are a number of utilities in ports available for this purpose,
>> including security/sshguard and security/denyhosts.
You can't do more than maybe 10 attempts/second this way, while cracking
10 character password consisting of just small letters and digits needs
10 characters is a longer than usual password. Most people have been
conditioned into using a 7 or 8 character password, which is at least a
so that
Wojciech Puchar wrote:
>> If for some reason you would prefer to use password authentication, I
>> would recommend that you look into automatic brute force detection.
>> There are a number of utilities in ports available for this purpose,
>> including security/sshguard and security/denyhosts.
>
>
If for some reason you would prefer to use password authentication, I
would recommend that you look into automatic brute force detection.
There are a number of utilities in ports available for this purpose,
including security/sshguard and security/denyhosts.
good, but not really important with p
connection, it's a relatively high-risk target.
What are some good practices for securing this SSH server. Is using a
stored key safer than a password in this instance? I have no
If your password is not trivial, then it is secure.
using RSA/DSA keys is as good, if you are sure nobody will get
On Mon,06/22/09 [21:16:35], Daniel Underwood wrote:
> On a BSD box at work (at an extremely fast connection and static IP),
> I run an SSH server. I am the only person who uses the server, but I
> use it from some locations that are behind a dynamic IP (so I can't
> set pf rules to filter by IP).
Daniel Underwood wrote:
On a BSD box at work (at an extremely fast connection and static IP),
I run an SSH server. I am the only person who uses the server, but I
use it from some locations that are behind a dynamic IP (so I can't
set pf rules to filter by IP). I will always, however, use the s
On Mon, 22 Jun 2009 21:16:35 -0400
Daniel Underwood wrote:
> Due to the speed and location of the
> connection, it's a relatively high-risk target.
>
why does the speed of a connection make it a higher risk?
is it because bruteforce techniques can capitalize on the speed?
--
In friendship,
prad
On 6/22/09, Daniel Underwood wrote:
> On a BSD box at work (at an extremely fast connection and static IP),
> I run an SSH server. I am the only person who uses the server, but I
> use it from some locations that are behind a dynamic IP (so I can't
> set pf rules to filter by IP). I will always,
On Mon, Jun 22, 2009 at 9:16 PM, Daniel Underwood wrote:
> On a BSD box at work (at an extremely fast connection and static IP),
> I run an SSH server. I am the only person who uses the server, but I
> use it from some locations that are behind a dynamic IP (so I can't
> set pf rules to filter by
On Tue, Jun 23, 2009 at 9:43 AM, Benjamin Lee wrote:
> On 06/22/2009 06:16 PM, Daniel Underwood wrote:
>> On a BSD box at work (at an extremely fast connection and static IP),
>> I run an SSH server. I am the only person who uses the server, but I
>> use it from some locations that are behind a dy
On Mon, Jun 22, 2009 at 9:43 PM, Benjamin Lee wrote:
> On 06/22/2009 06:16 PM, Daniel Underwood wrote:
> > On a BSD box at work (at an extremely fast connection and static IP),
> > I run an SSH server. I am the only person who uses the server, but I
> > use it from some locations that are behind
On 06/22/2009 06:16 PM, Daniel Underwood wrote:
> On a BSD box at work (at an extremely fast connection and static IP),
> I run an SSH server. I am the only person who uses the server, but I
> use it from some locations that are behind a dynamic IP (so I can't
> set pf rules to filter by IP). I w
37 matches
Mail list logo
