Possible attack? - Security

This is a discussion on Possible attack? - Security ; Sylvain Robitaille wrote: > Prime wrote: > >> It does no one any good to provide additional resources for newbie >> skript kiddies ... > > obscurity != security I don't totally agree but I do understand your point ... ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 43

Thread: Possible attack?

  1. Re: Possible attack?

    Sylvain Robitaille wrote:
    > Prime wrote:
    >
    >> It does no one any good to provide additional resources for newbie
    >> skript kiddies ...

    >
    > obscurity != security


    I don't totally agree but I do understand your point ... but why advertise?

    Are you prepared to publish all of the exploits, exploit analysis etc
    that you have on file ... what about a detailed look at all of the
    security measures you employ on your host(s) ... I think not.

    I've seen regular advice regarding running ssh on an obscure port to
    make it more difficult to find ... therefore obscurity = slightly better
    security.

    > Plain and simple.
    >
    > Besides, the script kiddies get the tools. You should never assume that
    > because you haven't seen pointers to them directly, that they haven't.


    My point also mentioned "Newbie skript kiddies" ... why make it easy for
    them ... make them earn their stripes.

    > What the OP did was make it possible for us (and himself) to examine the
    > exact tools used by his intruder, giving him a better chance of ensuring
    > thorough cleanup (and us an additional opportunity at detecting the use
    > of these tools against our own systems).


    I must have missed something ... apart from a brute force attack (which
    seemed to have worked against one of his lame users' lame passwords)
    there was nothing to indicate an exploit of any sophistication that
    needed thorough cleanup. I didn't see anything in a very cursory look
    that even indicated the kiddie had obtained root.

    The kiddie didn't even automate his attack ... it was completely manual ...

    What DID need attention was password security (and or better
    authentication methods) ... revealing a kiddies toys revealed nothing of
    any worth in the analysis of his problem.

    I am surprised that no one has piped in earlier demanding that he unplug
    his hosts from the net, completely wipe the affected system and then
    re-install ... but hey ... most of you thought he was being attacked not
    doing the attacking so I guess that is easily explained.

    Come on guys ... lets put all of this into perspective.

    I suggested (not attacked) that publishing a kiddie's toy box wouldn't
    help anyone; maybe I'm right, maybe not, but at the end of the day, the
    cause of the initial problem was poor password security/user scrutiny.

    More words have been typed regarding my post than there were assisting
    the OP to strengthen his security.

    Lets get back on topic.


  2. Re: Possible attack?

    Anon E. Muss wrote:
    > On Fri, 19 Sep 2008 09:56:24 -0500, Allen Kistler
    > wrote:
    >
    >> Anon E. Muss wrote:
    >>> I recently noticed excessive acitivity on my router's activity LED and
    >>> did a little investigating. As immediate action, I used a big hammer
    >>> and firewalled off 218/8 until I can figure out what is going on here.
    >>> Yesterday, it was 201/8.
    >>>
    >>> Below is most of output of netstat. Can someone let me know what is
    >>> going on here? SynFlood?? Also, any suggestions??
    >>>
    >>> ===== BEGIN =====
    >>> Active Internet connections (w/o servers)
    >>> Proto Recv-Q Send-Q Local Address Foreign Address State
    >>>
    >>> [snip]

    >> Welcome to the Internet. It's been here for a while. Where have you been?

    >
    > Been here a while.
    >
    >> If you have services offered to the world, lots of people are going to
    >> try to break in. If you have ssh turned on with guessable usernames
    >> (like, you know, root, ftp, httpd, or bin) and authentication using only
    >> password enabled, eventually someone is going to guess your lame password.

    >
    > Not *my* password.
    >
    > I will go through the users and find out who used a lame-o password.
    >
    > Thanks for the help.


    Ahh. You misunderstand: a lot of that is script kiddies, attacking your
    services, and guessing good password's like Governor Palin's zipcode for her
    login password on Yahoo. (Follow her adventures with Wikileaks if you're curious.)

  3. Re: Possible attack?

    Prime wrote:
    > Sylvain Robitaille wrote:
    >> Prime wrote:
    >>
    >>> It does no one any good to provide additional resources for newbie
    >>> skript kiddies ...

    >>
    >> obscurity != security

    >
    > I don't totally agree but I do understand your point ... but why advertise?


    Because it's useful to the honest people to have a hint as to what this week's
    s script kiddies are using.

  4. Re: Possible attack?

    Prime writes:

    >Unruh wrote:


    >>> Unruh wrote:


    >>
    >> We are constrantly telling people to provide information when they post
    >> here with problems. He posts his information and you attack him. That info
    >> can be useful in deciding to advise him how to handle the attack.


    >There is a limit ... I personally disagree with providing too much info
    >in open forums ... and lets face it, half of the initial responses
    >(including your first response) didn't even read correctly the log
    >information that was provided.


    I agree I did misread it.

    >Secondly, I didn't attack him ... I pointed out in direct language
    >exactly what he had done.


    And the difference between :attack" and "pointed out in direct language" is
    what?


    >The one thing that was correct in David Brown's post was the statement
    >that "... it was unnecessary to post the whole log file". I agreed then
    >and my post stated a similar position now.


    I would far rather he post too much info than too little. I agree that he
    posted too much, but how was he to know what "too much" and "too litlle"
    is? He is confused, and thus his judgement about the relevance of data is
    impaired. In that case going overboard is far better than giving to little.


    >I was a regular contributor to this forum many years ago and we had a
    >problem then with overzealous contributors who got it wrong.


    Many years ago modems were common and overposting took forever to load. No
    longer true in general.


    >Cheers


    >Luke


  5. Re: Possible attack?

    Unruh wrote:

    > And the difference between :attack" and "pointed out in direct language" is
    > what?


    Direct Language:
    Congratulations ... you just posted the url's for a couple of tools that
    this amateur skript kiddie is using.

    Attack:
    You would have to be one of the most ignoarant sys admins I've ever come
    across ... idiot! why would you be so stupid as to post the urls that
    this amateur skript kiddie is using ...

    .... do I need to go on?

    >> The one thing that was correct in David Brown's post was the statement
    >> that "... it was unnecessary to post the whole log file". I agreed then
    >> and my post stated a similar position now.

    >
    > I would far rather he post too much info than too little. I agree that he
    > posted too much, but how was he to know what "too much" and "too litlle"
    > is? He is confused, and thus his judgement about the relevance of data is
    > impaired. In that case going overboard is far better than giving to little.


    Perhaps had you not been overwhelmed with too much information you might
    have read the log file correctly?

    Clearly you and I need to agree to differ. Lets just leave it at that.

    Cheers

    Luke

  6. Re: Possible attack?

    Nico Kadel-Garcia wrote:
    > Prime wrote:
    >> Sylvain Robitaille wrote:
    >>> Prime wrote:
    >>>
    >>>> It does no one any good to provide additional resources for newbie
    >>>> skript kiddies ...
    >>>
    >>> obscurity != security

    >>
    >> I don't totally agree but I do understand your point ... but why
    >> advertise?

    >
    > Because it's useful to the honest people to have a hint as to what this
    > week's s script kiddies are using.


    Ok, given the "kit" that I downloaded, the SK's ability has diminished
    somewhat in the last 7-8 years.

    Also, don't be under any illusions that crackers are continually
    monitoring this and other forums. I'd hate to see this forum become a
    swap meet for cracking tools in the name of openness for the honest people.

    Cheers

  7. Re: Possible attack?

    Prime wrote:

    > Are you prepared to publish all of the exploits, exploit analysis etc
    > that you have on file ... what about a detailed look at all of the
    > security measures you employ on your host(s) ... I think not.


    For what it's worth, most of the exploits I've examined were readily
    available, and obtained via pointers posted to newsgroups or mailing
    lists I subscribe to (with an intended audience of "the good guys").
    Details of how my systems are secured aren't readily available, true,
    but certainly there are outlines that are. I don't feel a need to hide
    everything I do, though I'm not about to divulge exactly *how* I do it.

    Your post was the first I've ever seen suggesting that someone shouldn't
    have posted a link to a publically available exploit tool. Then again,
    I don't monitor this newsgroup as religiously as I think I should, so
    very often long times go by between when I get around to reading this
    group (and my returns are usually accompanied by a lot of messages that
    are let go, unread).

    > I've seen regular advice regarding running ssh on an obscure port to
    > make it more difficult to find ... therefore obscurity = slightly
    > better security.


    I disagree on that, and have expressed that the notion of moving any
    service (ssh included) to a non-standard port (what, exactly, is an
    "obscure port"? Nmap will find ssh at any port) is completely the wrong
    way to do things. There is a lot of advice out there, intended to help
    secure systems that is misguided at best.

    I have Ssh running on every system I manage, on TCP/22. I see lots of
    evidence of attempted brute-force attacks against user passwords on at
    least some of those systems. I have yet to discover a compromise that I
    can show occured because of an attack against Ssh. I don't want to say
    that it has never happened, but in more than 12 years as a system
    administrator (including using Ssh even before its use was very
    widespread), I've not *seen* a compromise that I could attribute to Ssh.

    Weak user passwords can be compromised at any port. Someone looking to
    break into a system, especially manually, won't be slowed very much by
    having to point his/her Ssh brute-force attack at port 22222 (for
    example) rather than 22.

    > My point also mentioned "Newbie skript kiddies" ... why make it easy
    > for them ... make them earn their stripes.


    My point is that it's already easy for them. Why make it harder for
    *us* to find the tools they're using than it is for them?

    > I didn't see anything in a very cursory look that even indicated the
    > kiddie had obtained root.


    Agreed. I have the same impression. What does that have to do with
    whether the OP should have posted the unsanitized command history?

    > ... revealing a kiddies toys revealed nothing of any worth in the
    > analysis of his problem.


    Disagreed. Obfuscating the sources of the intruder's tools would have
    offered us no useful information whatsoever about the scans originating
    from his system (and no doubt many others out there).

    > I am surprised that no one has piped in earlier demanding that he
    > unplug his hosts from the net, completely wipe the affected system and
    > then re-install ...


    You and I agree that it doesn't appear, from the data that was posted
    here, as though the system was compromised at any level higher than an
    unprivileged user account. Unless the OP has evidence to the contrary,
    I fail to see what a complete wipe/re-install sequence would accomplish.

    > but hey ... most of you thought he was being attacked not doing the
    > attacking so I guess that is easily explained.


    Perhaps. It was really great of you to step up and point out the error
    so quickly. Oh wait, given that your first post on the topic was to
    "congratulate" the user for posting links to tools used to launch scans
    and/or attacks from his system, I think that might have been someone
    else ...

    --
    ----------------------------------------------------------------------
    Sylvain Robitaille syl@alcor.concordia.ca

    Network and Systems analyst Concordia University
    Instructional & Information Technology Montreal, Quebec, Canada
    ----------------------------------------------------------------------

  8. Re: Possible attack?

    Sylvain Robitaille wrote:
    > Prime wrote:
    >
    >> Are you prepared to publish all of the exploits, exploit analysis etc
    >> that you have on file ... what about a detailed look at all of the
    >> security measures you employ on your host(s) ... I think not.

    >
    > For what it's worth, most of the exploits I've examined were readily
    > available, and obtained via pointers posted to newsgroups or mailing
    > lists I subscribe to (with an intended audience of "the good guys").
    > Details of how my systems are secured aren't readily available, true,
    > but certainly there are outlines that are. I don't feel a need to hide
    > everything I do, though I'm not about to divulge exactly *how* I do it.


    Ok ... so there is some merit in obscurity.


    >> I've seen regular advice regarding running ssh on an obscure port to
    >> make it more difficult to find ... therefore obscurity = slightly
    >> better security.

    >
    > I disagree on that, and have expressed that the notion of moving any
    > service (ssh included) to a non-standard port (what, exactly, is an
    > "obscure port"? Nmap will find ssh at any port) is completely the wrong
    > way to do things. There is a lot of advice out there, intended to help
    > secure systems that is misguided at best.


    I agree. There are better ways of doing things.


    > Weak user passwords can be compromised at any port. Someone looking to
    > break into a system, especially manually, won't be slowed very much by
    > having to point his/her Ssh brute-force attack at port 22222 (for
    > example) rather than 22.


    Also agree. That was a point I made in another post ... the advice
    provided in this forum should have been centred around sound security
    practices including but limited to password strength and user scrutiny.


    >> My point also mentioned "Newbie skript kiddies" ... why make it easy
    >> for them ... make them earn their stripes.

    >
    > My point is that it's already easy for them. Why make it harder for
    > *us* to find the tools they're using than it is for them?


    I must be missing something here ...

    The OP posted a netstat log that most in this forum mis-read. Had it
    not been for your keen eye, the thread may well have gone off on a
    completely incorrect tangent. So, props to you for getting it right!


    >> I am surprised that no one has piped in earlier demanding that he
    >> unplug his hosts from the net, completely wipe the affected system and
    >> then re-install ...

    >
    > You and I agree that it doesn't appear, from the data that was posted
    > here, as though the system was compromised at any level higher than an
    > unprivileged user account. Unless the OP has evidence to the contrary,
    > I fail to see what a complete wipe/re-install sequence would accomplish.


    I wasn't suggesting that a complete wipe/re-install was called for ...
    in days gone by, many in this forum would have piped in and suggested
    that wiping the system was the only way to guarantee a clean system.

    I was surprised that wiping the system wasn't demanded given that many
    weighed in too quickly with equally unprofound advice.


    [snip]

    I've had enough of this thread now, we're getting nowhere ... again, we
    should agree to disagree or agree to accept that others may have
    different ways of doing things.

    Cheers

  9. Re: Possible attack?

    Prime wrote:

    >> I don't feel a need to hide everything I do, though I'm not about to
    >> divulge exactly *how* I do it.

    >
    > Ok ... so there is some merit in obscurity.


    Well, if you want to suggest that people not publishing their passwords
    is a form of obscurity, I suppose I heartily advocate for it, even. In
    the sense of "don't divulge details of commands run by an intruder on
    your system," though, I most certainly don't.

    > ...
    > I agree. ...
    > ...
    > Also agree. That was a point I made in another post ...
    > ...
    > I must be missing something here ...


    Perhaps I'm the one whose missing it, if it seems we're agreeing more
    than we've said (before your last post).

    > The OP posted a netstat log that most in this forum mis-read.


    Yes, but our disagreement occurred when you criticised the OP for also
    posting an unsanitized command-history from the intrusion on his/her
    system. I disagreed with your criticism.

    > I wasn't suggesting that a complete wipe/re-install was called for ...


    Ok, so we agree on that as well, then ...

    > I was surprised that wiping the system wasn't demanded given that many
    > weighed in too quickly with equally unprofound advice.


    I missed what may have been intended sarcasm, then.

    > I've had enough of this thread now, we're getting nowhere ...


    I don't think so: I think we've clarified points we do and don't agree
    on.

    --
    ----------------------------------------------------------------------
    Sylvain Robitaille syl@alcor.concordia.ca

    Network and Systems analyst Concordia University
    Instructional & Information Technology Montreal, Quebec, Canada
    ----------------------------------------------------------------------

  10. Re: Possible attack?

    On Mon, 22 Sep 2008, in the Usenet newsgroup comp.os.linux.security, in article
    , Sylvain Robitaille wrote:

    >Prime wrote:


    >> Are you prepared to publish all of the exploits, exploit analysis etc
    >> that you have on file ... what about a detailed look at all of the
    >> security measures you employ on your host(s) ... I think not.

    >
    >For what it's worth, most of the exploits I've examined were readily
    >available, and obtained via pointers posted to newsgroups or mailing
    >lists I subscribe to (with an intended audience of "the good guys").


    CERT? Bugtraq? Sans? Wazzat?

    >> I've seen regular advice regarding running ssh on an obscure port to
    >> make it more difficult to find ... therefore obscurity = slightly
    >> better security.

    >
    >I disagree on that, and have expressed that the notion of moving any
    >service (ssh included) to a non-standard port (what, exactly, is an
    >"obscure port"? Nmap will find ssh at any port) is completely the
    >wrong way to do things.


    1. Moving a service from a "well known port" to something else. The
    concept of well known ports goes back to the 1970s, and was meant to
    allow others to find specific services. If a specific service isn't
    meant to be offered to everyone, making it more difficult to find
    may be a valid decision (I'm not sure how many zombies and skript
    kiddiez do a full port-scan before "attacking"). It also may not be
    the optimum solution, especially if it's the only one applied..

    2. An "obscure port" is "not well known". In practice, it often means
    some port number above 1024, and not a "sekrit number" like 12345 or
    other numbers that appeal to the mindless.

    3. man nmap and look at the '-p ' option. Most skript
    kiddiez don't even know about the option, and thus accept the default
    (1-1024 plus those listed in the services file supplied with nmap -
    the file that comes with nmap-4.76 lists 3398 TCP ports above 1024).

    >There is a lot of advice out there, intended to help secure systems
    >that is misguided at best.


    Agreed

    >I have Ssh running on every system I manage, on TCP/22. I see lots
    >of evidence of attempted brute-force attacks against user passwords
    >on at least some of those systems.


    One of the reasons some get unhappy with such attempts is the waste
    of bandwidth. A simple solution to that problem is to configure the
    firewall to block access to the SSH server for addresses that will
    have no valid or imaginable reason to be trying such access. As of
    mid-month, there were 2708817080 IPv4 addresses in use on 88156
    networks in the world. I'm no longer amazed that people think
    they need to allow SSH access from every single one of those (and
    1586150216 others either unassigned or reserved by RFC3330) - after
    all, you KNOW they'll be leaping onto a plane in a few minutes and
    flying to Afghanistan, Armenia, Angola, Aruba, and the Aaland Islands
    (or similar), and simply don't have time to white-list the address
    ranges that might be used there.

    Another reason some get unhappy is that they must log every failed
    attempt - perhaps so they can click their tongues in disgust, and
    maybe turn over this information to the Internet Police. I have no
    sympathy for these either.

    >Weak user passwords can be compromised at any port.


    Of course

    >Someone looking to break into a system, especially manually, won't be
    >slowed very much by having to point his/her Ssh brute-force attack at
    >port 22222 (for example) rather than 22.


    They will be slowed if they must first _find_ the port. Something like
    port 22222 is _somewhat_ less easy to find ("22222" is in that nmap
    services file),

    [compton ~]$ ls -ld a* | cut -c37-41 | grep "[0-9]\{5\}" | column
    15588 02555 13004 31924 18104 15326 10940 40304 10458
    16266 13167 22820 34870 10943 18430 21195 10005
    [compton ~]$

    but ports 31924, 34870, or maybe 21195 might be a bit more obscure. A
    problem with this is that most users can't remember their own telephone
    number or postal delivery code, and expecting them to remember any port
    number is probably asking to much.

    Old guy

  11. Re: Possible attack?


    >One of the reasons some get unhappy with such attempts is the waste
    >of bandwidth. A simple solution to that problem is to configure the
    >firewall to block access to the SSH server for addresses that will
    >have no valid or imaginable reason to be trying such access. As of
    >mid-month, there were 2708817080 IPv4 addresses in use on 88156
    >networks in the world. I'm no longer amazed that people think
    >they need to allow SSH access from every single one of those (and
    >1586150216 others either unassigned or reserved by RFC3330) - after
    >all, you KNOW they'll be leaping onto a plane in a few minutes and
    >flying to Afghanistan, Armenia, Angola, Aruba, and the Aaland Islands
    >(or similar), and simply don't have time to white-list the address
    >ranges that might be used there.


    In a university setting with many faculty, yes, they'll be leaping on a
    plane in a few minutes to Afghanistan, Armenia, Angola, Aruba, and the
    Aaland Islands,(or similar). And trying to figure out waht the IP address
    range is that will be in use there is a serious task-- could take you
    staying at home weeks to discover it ( eg the faculty member might discover
    that an internet cafe is the onlyway to connect, or that the hotel-- what
    the hell is its ip address-- charges $40 an hour for internet connectivity.



    ....
    >but ports 31924, 34870, or maybe 21195 might be a bit more obscure. A
    >problem with this is that most users can't remember their own telephone
    >number or postal delivery code, and expecting them to remember any port
    >number is probably asking to much.


    Precisely.


  12. Re: Possible attack?

    Moe Trin wrote:

    > CERT? Bugtraq? Sans? Wazzat?


    .... and others, but Bugtraq is one I frequently get good information
    from. The usual websites also (most pointed to from the SecurityFocus
    website, so I won't try and get a list). I've spent less time on this
    type of thing in the past couple of years, so I can't point you to the
    "best" sources.

    > ... If a specific service isn't meant to be offered to everyone,
    > making it more difficult to find may be a valid decision ...


    Well, if a specific service isn't meant to be offered to everyone, one
    might argue that the first step in ensuring that, is that the service
    shouldn't be *visible* to everyone, or at least it shouldn't *respond*
    to everyone.

    > It also may not be the optimum solution, especially if it's the only
    > one applied..


    absolutely.

    > 2. An "obscure port" is "not well known".


    Well, most people I know (with IT knowledge) are aware of TCP ports from
    1 to 65535. They're pretty well-known, if not all by name. ;-)

    > 3. man nmap and look at the '-p ' option.


    Exactly.

    > Most skript kiddiez don't even know about the option, ...


    Counting on that, though, is in the same category as the misguided advice
    I was referring to in an earlier post.

    > A simple solution to that problem is to configure the firewall to
    > block access to the SSH server for addresses that will have no valid
    > or imaginable reason to be trying such access.


    Yes, that's certainly advisable, as one layer of security. More to the
    point, I generally advise configuring a firewall (in whatever form that
    might be) to permit access only from those addresses (or address ranges)
    where legitimate access is expected. As you no-doubt imagine, the
    reactions I get are frequently similar to those you get, but the
    approach works really well.

    > Another reason some get unhappy is that they must log every failed
    > attempt ....


    I normally advise folks to worry about the attempts that didn't fail.
    Those that failed are the result of your configuration working as it
    should ...

    >> Someone looking to break into a system, especially manually, won't be
    >> slowed very much ...

    >
    > They will be slowed if they must first _find_ the port.


    As quoted above, they "won't be slowed very much". In fact, in my
    opinion, they won't be slowed enough to offset the inconvenience to
    users who will then need to remember to send their Ssh clients to the
    non-standard port.

    > ("22222" is in that nmap services file),


    The actual port-number in my example wasn't the point ...

    > A problem with this is that most users can't remember their own
    > telephone number or postal delivery code, and expecting them to
    > remember any port number is probably asking to much.


    Well, after all, we're asking them to remember reusable passwords too,
    without using simple dictionary words! Some of us even insist that
    they not write them down on a sticky-note taped to their monitors (oh
    the nerve we have!)

    --
    ----------------------------------------------------------------------
    Sylvain Robitaille syl@alcor.concordia.ca

    Network and Systems analyst Concordia University
    Instructional & Information Technology Montreal, Quebec, Canada
    ----------------------------------------------------------------------

  13. Re: Possible attack?

    On Tue, 23 Sep 2008, in the Usenet newsgroup comp.os.linux.security, in article
    , Sylvain Robitaille wrote:

    >Moe Trin wrote:


    >> ... If a specific service isn't meant to be offered to everyone,
    >> making it more difficult to find may be a valid decision ...

    >
    >Well, if a specific service isn't meant to be offered to everyone, one
    >might argue that the first step in ensuring that, is that the service
    >shouldn't be *visible* to everyone, or at least it shouldn't *respond*
    >to everyone.


    I think that is the one that most smart people adopt. My home system
    under "normal" conditions accepts connections from a /22 and two /24s
    on the outside. In the somewhat rare situations when I'm traveling,
    I've taken to using a port-knocking scheme (where you first attempt
    to connect to an otherwise un-used port - the firewall notes the
    attempt, and unblocks access to the SSH server from "that" address for
    one minute). I still have to authenticate (an RSA key on a USB memory
    card) so the knocking isn't really security, but more "noise
    reduction".

    >Yes, that's certainly advisable, as one layer of security. More to
    >the point, I generally advise configuring a firewall (in whatever form
    >that might be) to permit access only from those addresses (or address
    >ranges) where legitimate access is expected. As you no-doubt imagine,
    >the reactions I get are frequently similar to those you get, but the
    >approach works really well.


    We're a research facility for the company, and have somewhat less of a
    "need" to log in from the outside world. This permits pretty
    restrictive limits on such access.

    >> Another reason some get unhappy is that they must log every failed
    >> attempt ....

    >
    >I normally advise folks to worry about the attempts that didn't fail.
    >Those that failed are the result of your configuration working as it
    >should ...


    Exactly. That's also why the USB dongle only provides part of the
    authentication - the users still need a password that gets hashed in
    to create the actual credentials.

    >> They will be slowed if they must first _find_ the port.

    >
    >As quoted above, they "won't be slowed very much". In fact, in my
    >opinion, they won't be slowed enough to offset the inconvenience to
    >users who will then need to remember to send their Ssh clients to the
    >non-standard port.


    It's amazing how much fits into those little USB dongles today. We
    are getting more concerned with 'homeland security' idiots than we used
    to be. There has always been the worry about having a laptop stolen
    at the security check-point, which is why filesystem encryption is more
    common, but now that may result in the laptop being detained while the
    CBP look for illegal files. See the stuff in news://comp.risks issues
    25-28 (12 Aug, 2008) and 25-14 (2 May, 2008) including the EFF URL.

    >> A problem with this is that most users can't remember their own
    >> telephone number or postal delivery code, and expecting them to
    >> remember any port number is probably asking to much.

    >
    >Well, after all, we're asking them to remember reusable passwords too,
    >without using simple dictionary words! Some of us even insist that
    >they not write them down on a sticky-note taped to their monitors (oh
    >the nerve we have!)


    The sticky-note on the monitor, or on the bottom of the keyboard (or
    mouse) had a fairly short life here - we got tagged in a government
    security audit many years ago, and there was hell to pay. We _try_ to
    help our users by having a regular hand-out that shows ways to create
    and remember more difficult passwords - the "n'th letter of the words
    of a phrase/song" seems to be tolerable, and a heck of a lot more
    secure than the phone number of the bookie, pizza-joint, or what-ever.

    Old guy

  14. Re: Possible attack?

    ibuprofin@painkiller.example.tld (Moe Trin) writes:


    >The sticky-note on the monitor, or on the bottom of the keyboard (or
    >mouse) had a fairly short life here - we got tagged in a government
    >security audit many years ago, and there was hell to pay. We _try_ to
    >help our users by having a regular hand-out that shows ways to create
    >and remember more difficult passwords - the "n'th letter of the words
    >of a phrase/song" seems to be tolerable, and a heck of a lot more
    >secure than the phone number of the bookie, pizza-joint, or what-ever.


    You might want to use my program wgen which generates "words" based on a
    dictionary. It takes the dictionary and calculates the occurance of the
    "trigrams-- combinations of three letters, including a double init to
    indicate the beginning of the word. It uses urandom to grab the next letter
    based on the probability of that letter being the last letter in a set of
    three as determined by teh dictionary. This produces words that are not
    words but are very similar in their structure to English words. It also
    puts out a "entropy" for the word (ie the number of bits of entropy for each
    word based on those trigrams-- it is a rough guide.

    People should grab longer words with higher bit numbers, or combine shorter
    words .
    Here is an example-- with max length of 10 characters

    ambly [17.1833]
    mainterial [24.9927]
    xeno [18.3541]
    rectinite [25.0441]
    anneau [23.2039]
    bismentram [32.0393]
    beworl-air [39.8553]
    gumfervivi [34.0005]
    prophy [16.0704]
    strusion [21.3945]
    unsonnersa [30.087]
    corrhaceab [26.3783]
    unaceae [17.1724]
    terregraem [37.0352]
    letason [29.3827]
    avolverra [33.715]
    subhensick [30.6531]
    coorsomide [37.5863]
    cosis [14.3989]
    airer [19.1535]


    Note occasionally a real word is generated.
    There is about 3 bits of entropy per letter-- some more, some less.
    But "airer anneau" would have an entropy of over 40. Throw in a few
    capitals or even punctuation, and you might get that up to 45 (but it is
    harder than you think to "throw in random punctuation"..
    (Note-- that entropy basically means that if the attacker used the same
    dictionary, that is a measure of how many times he would have to try to
    generate your password-- ie if the ranking is 35 it would take 2^35 = 10^10 tries.
    It is also better to use longer dictionaries (I have one with 400,000
    words) as it makes rarer combinations more likely. (By default it uses
    /usr/share/dict/words)

    If you use a text document as the dictionary, especially simple text, you are likely to get simply short
    words-- since the probabilities are coumputed from the whole document,
    with its repetitions of of words (a, the) biasing the results.

    http:www.theory.physics.ubc.ca/wgen/wgen.c or
    http:www.theory.physics.ubc.ca/wgen/wgen for the binary.


  15. Re: Possible attack?

    On 09/25/2008 12:03 PM, Unruh wrote:
    >
    >
    > If you use a text document as the dictionary, especially simple text, you are likely to get simply short
    > words-- since the probabilities are coumputed from the whole document,
    > with its repetitions of of words (a, the) biasing the results.
    >
    > http:www.theory.physics.ubc.ca/wgen/wgen.c or
    > http:www.theory.physics.ubc.ca/wgen/wgen for the binary.
    >


    wget http://www.theory.physics.ubc.ca/wgen/wgen.c
    --2008-09-25 12:12:41-- http://www.theory.physics.ubc.ca/wgen/wgen.c
    Resolving www.theory.physics.ubc.ca... 142.103.234.29
    Connecting to www.theory.physics.ubc.ca|142.103.234.29|:80... connected.
    HTTP request sent, awaiting response... 403 Forbidden
    2008-09-25 12:12:41 ERROR 403: Forbidden.

  16. Re: Possible attack?

    Unruh wrote:

    > You might want to use my program wgen which generates "words" based on
    > a dictionary. ...


    I like it, at least as a starting point for decent passwords. Thanks
    for passing that on.

    > People should grab longer words with higher bit numbers, or combine
    > shorter words . .... Throw in a few capitals or even punctuation, ...


    Agreed.

    --
    ----------------------------------------------------------------------
    Sylvain Robitaille syl@alcor.concordia.ca

    Network and Systems analyst Concordia University
    Instructional & Information Technology Montreal, Quebec, Canada
    ----------------------------------------------------------------------

  17. Re: Possible attack?

    Douglas O'Neal writes:

    >On 09/25/2008 12:03 PM, Unruh wrote:
    >>
    >>
    >> If you use a text document as the dictionary, especially simple text, you are likely to get simply short
    >> words-- since the probabilities are coumputed from the whole document,
    >> with its repetitions of of words (a, the) biasing the results.
    >>
    >> http:www.theory.physics.ubc.ca/wgen/wgen.c or
    >> http:www.theory.physics.ubc.ca/wgen/wgen for the binary.
    >>


    >wget http://www.theory.physics.ubc.ca/wgen/wgen.c
    >--2008-09-25 12:12:41-- http://www.theory.physics.ubc.ca/wgen/wgen.c
    >Resolving www.theory.physics.ubc.ca... 142.103.234.29
    >Connecting to www.theory.physics.ubc.ca|142.103.234.29|:80... connected.
    >HTTP request sent, awaiting response... 403 Forbidden
    >2008-09-25 12:12:41 ERROR 403: Forbidden.


    Oops. Corrected now.

  18. Re: Possible attack?

    Moe Trin wrote:

    > On Tue, 23 Sep 2008, in the Usenet newsgroup comp.os.linux.security,


    .....
    >
    > The sticky-note on the monitor, or on the bottom of the keyboard (or
    > mouse) had a fairly short life here - we got tagged in a government
    > security audit many years ago, and there was hell to pay. We _try_ to
    > help our users by having a regular hand-out that shows ways to create
    > and remember more difficult passwords - the "n'th letter of the words
    > of a phrase/song" seems to be tolerable, and a heck of a lot more
    > secure than the phone number of the bookie, pizza-joint, or what-ever.
    >
    > Old guy


    If you have people using a lot of different passwords each, or several,
    want them to remain unique, but be secure, then in an office
    environment, I always have complex passwords, but simply have the user
    keep them in a PGP encrypted file that they would use their one single
    complex, yet easily enough to remember, password for viewing. But, of
    course, there are always problems with trying to get an office or
    company full of people to remember passwords and store them safely.
    --
    Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
    Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
    and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
    Industry's most experienced staff! -- Web Hosting With Muscle!

  19. Re: Possible attack?

    Unruh wrote:

    > http:www.theory.physics.ubc.ca/wgen/wgen.c or


    Hrmmm.... not a complaint, but a suggestion for documentation:

    : alcor[syl] ~; make wgen
    cc wgen.c -o wgen
    /tmp/ccxv11ko.o: In function `main':
    wgen.c.text+0x8e7): undefined reference to `log'
    wgen.c.text+0xb35): undefined reference to `log'
    wgen.c.text+0xbd6): undefined reference to `log'
    wgen.c.text+0xc23): undefined reference to `log'
    wgen.c.text+0xc64): undefined reference to `log'
    /tmp/ccxv11ko.o:wgen.c.text+0xcb1): more undefined references to `log' follow
    collect2: ld returned 1 exit status
    make: *** [wgen] Error 1
    : alcor[syl] ~; cc -lm wgen.c -o wgen
    : alcor[syl] ~; ./wgen
    total trigrms= 4206391 raw ent= 2.119955e+06 tcount = 352846
    Max length=10 Number=20, Entropy3=9.760737 Entropy4=12.250720
    ...

    Again, thank you.

    --
    ----------------------------------------------------------------------
    Sylvain Robitaille syl@alcor.concordia.ca

    Network and Systems analyst Concordia University
    Instructional & Information Technology Montreal, Quebec, Canada
    ----------------------------------------------------------------------

  20. Re: Possible attack?

    Tim Greer wrote:
    > Moe Trin wrote:
    >
    >> On Tue, 23 Sep 2008, in the Usenet newsgroup comp.os.linux.security,

    >
    > ....
    >> The sticky-note on the monitor, or on the bottom of the keyboard (or
    >> mouse) had a fairly short life here - we got tagged in a government
    >> security audit many years ago, and there was hell to pay. We _try_ to
    >> help our users by having a regular hand-out that shows ways to create
    >> and remember more difficult passwords - the "n'th letter of the words
    >> of a phrase/song" seems to be tolerable, and a heck of a lot more
    >> secure than the phone number of the bookie, pizza-joint, or what-ever.
    >>
    >> Old guy

    >
    > If you have people using a lot of different passwords each, or several,
    > want them to remain unique, but be secure, then in an office
    > environment, I always have complex passwords, but simply have the user
    > keep them in a PGP encrypted file that they would use their one single
    > complex, yet easily enough to remember, password for viewing. But, of
    > course, there are always problems with trying to get an office or
    > company full of people to remember passwords and store them safely.


    Heh. I'm remembering a password based on 'The curious incident of the dog in
    the night-time', where the password owner was talking about the book, and
    didn't know that it's a famous Sherlock Holmes quote.

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast