bash_history set to zero length - Security

This is a discussion on bash_history set to zero length - Security ; And are there any reasons for the bash_history file to get set to zero - say for a broken ssh session - caused by a backup script logging in from a backup server over ssh using a key etc? I've ...

+ Reply to Thread
Results 1 to 18 of 18

Thread: bash_history set to zero length

  1. bash_history set to zero length

    And are there any reasons for the bash_history file to get set to zero - say
    for a broken ssh session - caused by a backup script logging in from a
    backup server over ssh using a key etc?

    I've had chkrootkit report the zero size file - but can find absolutely no
    other sign of a compromise.

    Thanks,

    Kevin

  2. Re: bash_history set to zero length

    Kevin Bailey wrote:

    > And are there any reasons for the bash_history file to get set to zero -
    > say for a broken ssh session - caused by a backup script logging in from
    > a backup server over ssh using a key etc?
    >
    > I've had chkrootkit report the zero size file - but can find absolutely
    > no other sign of a compromise.


    There would not seem to be any valid reason for the various /.bash_history
    files [all] to be zeroed. To be more thorough you could check them all -

    # ll /root/.bash_history

    # ll /home/[any_user_0]/.bash_history

    .... - etc.

    If you have set an IDS baseline (as [i.e.] tripwire or aide ...), (and
    stored on read-only media) you can check to see if your executable system
    files have been altered. If you have not done this, you have little or no
    reason to expect anything innocent. Please don't shoot the messenger, and
    sorry to say, but if you do not have an explanation immediately at hand,
    disconnect and rebuild from scratch or backup, as in last known secure
    backup. We all dread this, and I am sorry that this misfortune has come
    into your life.

    Good luck and best wishes. But please do disconnect. Thank you.

  3. Re: bash_history set to zero length

    responder wrote:

    > Kevin Bailey wrote:
    >
    >> And are there any reasons for the bash_history file to get set to zero -


    [...]

    > We all dread this, and I am sorry that this misfortune has come
    > into your life.


    [...]

    Thanks for your respect for your own security and everyone else's in
    protecting your own data and the secure integrity of everyone else's
    internet. Your posting host appears to be responding to traceroutes. It
    would not be doing that if it were disconnected. However, you may already
    have put up a new system. Or your posting host may be different than the
    system about which you were writing. I hope so.

    Your web site here is impressive and I wish you well:

    http://myweb.tiscali.co.uk/kbportal/

  4. Re: bash_history set to zero length

    responder wrote:

    > Kevin Bailey wrote:
    >
    >> And are there any reasons for the bash_history file to get set to zero -
    >> say for a broken ssh session - caused by a backup script logging in from
    >> a backup server over ssh using a key etc?
    >>
    >> I've had chkrootkit report the zero size file - but can find absolutely
    >> no other sign of a compromise.

    >
    > There would not seem to be any valid reason for the various /.bash_history
    > files [all] to be zeroed. To be more thorough you could check them all -
    >
    > # ll /root/.bash_history
    >
    > # ll /home/[any_user_0]/.bash_history
    >
    > ... - etc.
    >
    > If you have set an IDS baseline (as [i.e.] tripwire or aide ...), (and
    > stored on read-only media) you can check to see if your executable system
    > files have been altered. If you have not done this, you have little or no
    > reason to expect anything innocent. Please don't shoot the messenger, and
    > sorry to say, but if you do not have an explanation immediately at hand,
    > disconnect and rebuild from scratch or backup, as in last known secure
    > backup. We all dread this, and I am sorry that this misfortune has come
    > into your life.
    >
    > Good luck and best wishes. But please do disconnect. Thank you.


    aide is not reporting anything as having been changed. And nothing else is
    indicating an intrusion.

    BTW - it was only a single bash_history which was empty.

    Kevin

  5. Re: bash_history set to zero length

    responder wrote:

    > responder wrote:
    >
    >> Kevin Bailey wrote:
    >>
    >>> And are there any reasons for the bash_history file to get set to zero -

    >
    > [...]
    >
    >> We all dread this, and I am sorry that this misfortune has come
    >> into your life.

    >
    > [...]
    >
    > Thanks for your respect for your own security and everyone else's in
    > protecting your own data and the secure integrity of everyone else's
    > internet. Your posting host appears to be responding to traceroutes. It
    > would not be doing that if it were disconnected. However, you may already
    > have put up a new system. Or your posting host may be different than the
    > system about which you were writing. I hope so.


    The server is not the one I am posting from.

    Kevin

    >
    > Your web site here is impressive and I wish you well:
    >
    > http://myweb.tiscali.co.uk/kbportal/



  6. Re: bash_history set to zero length

    * Kevin Bailey
    | BTW - it was only a single bash_history which was empty.

    Do you know that it was non-empty any time prior?

    E.g., I had my *history files non-writable for some time, so they
    always were size 0.

    R'

  7. Re: bash_history set to zero length

    Ralf Fassel wrote:

    > * Kevin Bailey
    > | BTW - it was only a single bash_history which was empty.
    >
    > Do you know that it was non-empty any time prior?
    >
    > E.g., I had my *history files non-writable for some time, so they
    > always were size 0.
    >
    > R'



    Nope, but I've only just started using chkrootkit on all servers so I would
    not have received warnings about zero length bash_history files before.

    I will run a big nessus scan on the machine today to look for any unusual
    open ports. The logs are still not showing any sign of a compromise.

    Kevin



  8. Re: bash_history set to zero length


    Kevin Bailey wrote:

    > aide is not reporting anything as having been changed. And nothing else is
    > indicating an intrusion.
    >
    > BTW - it was only a single bash_history which was empty.


    It is possible that this is simply caused by the user in question never
    having logged in or the user's shell not being bash? Is it possible
    that the user in question simply zero'ed his/her own history file?


  9. Re: bash_history set to zero length

    Kevin Bailey wrote:

    > Ralf Fassel wrote:
    >
    >> * Kevin Bailey
    >> | BTW - it was only a single bash_history which was empty.
    >>
    >> Do you know that it was non-empty any time prior?
    >>
    >> E.g., I had my *history files non-writable for some time, so they always
    >> were size 0.
    >>
    >> R'

    >
    >
    > Nope, but I've only just started using chkrootkit on all servers so I
    > would not have received warnings about zero length bash_history files
    > before.
    >
    > I will run a big nessus scan on the machine today to look for any unusual
    > open ports. The logs are still not showing any sign of a compromise.


    Kevin, let us know what you found. We were all willing to try to help
    you. You should be willing to try to help us understand what happened.
    How else will we be able to help the next guy, or ourselves (let alone
    you), should this happen to us.

    We all will try to help some more, with more details. Was this user you?
    Was it a system user? Was it someone else? What was your 'big nessus
    scan'. Do we all need to be aware of something new?

    Please and thank you.

    Thanks.

  10. Re: bash_history set to zero length

    >
    > Kevin, let us know what you found. We were all willing to try to help
    > you. You should be willing to try to help us understand what happened.
    > How else will we be able to help the next guy, or ourselves (let alone
    > you), should this happen to us.
    >
    > We all will try to help some more, with more details. Was this user you?
    > Was it a system user? Was it someone else? What was your 'big nessus
    > scan'. Do we all need to be aware of something new?
    >



    I log in to the server over ssh to carry out various tasks for which I
    sometimes have to su to root.

    Only one other user has access via ssh - this is a delveloper who updates a
    website using winscp.

    The only thing that has shown up is the bash_history file was zero length
    one day when I su'd to root.

    There is no other sign of intrusion that I can see via aide or chkrootkit.
    Server is debian sarge and everything is up-to-date.

    I looked about and I had a few other sessions running on another workspace
    on my laptop and they had become disconnected when the network cable had
    become unplugged.

    Maybe one of these disconnects cause the bash_history to become lost?

    Cheers,

    Kevin


    > Please and thank you.
    >
    > Thanks.


  11. Re: bash_history set to zero length

    kevin bailey wrote:

    >> We all will try to help some more, with more details. Was this user
    >> you? Was it a system user? Was it someone else? What was your 'big
    >> nessus scan'. Do we all need to be aware of something new?


    > I log in to the server over ssh to carry out various tasks for which I
    > sometimes have to su to root.
    >
    > Only one other user has access via ssh - this is a delveloper who updates
    > a website using winscp.


    Generally, each user, including root, has his own .bash_history file in
    his own home directory. When you log in as a normal user, you will use
    that user's history. When you su to root, you will then use root's
    history. The session history is actually only in memory until the session
    is logged out. The existing history file on disk is not changed until
    then, when the session history is appended to what is already on disk.
    There are probably several easy ways to change that behavior if desired,
    but it would need to be an intentional change.

    The exception might be that your ssh connection is somehow not writing any
    history file, and so that user never had anything written to file. I
    can't tell you if that might be true, but it should be easy to check (and
    correct if necessary).

    So, for example, (normally) if you or anyone has ever logged on as
    that user, and then issued any command-line command (including su), and
    then logged out normally, then the session history will be written to disk
    and the file will not be zero length. And that's exactly why a zero
    length history is so "unusual". It is not difficult to determine if these
    rules do actually apply to your system and this user by logging on as (or
    su -ing to) this user and issue a command like ls, then log out and check
    the file length for that user's history again.

    There is (normally) no need to zero a history file, and no automatic
    provision to do so. What you have written suggests to me that you may not
    be entirely clear if it was due to your session or the other person's that
    the history length is zero.

    > The only thing that has shown up is the bash_history file was zero length
    > one day when I su'd to root.
    >
    > There is no other sign of intrusion that I can see via aide or chkrootkit.


    These are both generally well regarded and valuable tools. I might be
    wrong, but don't believe either is entirely infallible. Chrootkit looks
    for specific things that are (or have been) found on compromised systems
    (like zero-length history files). The fact that it doesn't find other
    signs (or any) is not evidence that there has _not_ been illicit activity
    or tampering. It is itself a shell script, subject to being edited or
    changed, and subject to system commands being trusted, and so is best run
    locally from a (live) CD.

    Aide depends on a baseline data and system commands. It is also best
    trusted when run locally using trusted, read only media.

    Unfortunately, what needs to be kept in mind is that if and when a system
    is compromised. nothing on that system can be trusted.

    > Server is debian sarge and everything is up-to-date.
    >
    > I looked about and I had a few other sessions running on another workspace
    > on my laptop and they had become disconnected when the network cable had
    > become unplugged.
    >
    > Maybe one of these disconnects cause the bash_history to become lost?


    Many things might happen as a result of unexpected or non-standard
    disconnections, etc. I would not expect plausible that zeroing a history
    file length would be one of them. You could check it on your system with
    a user that has a non-zero length history file to start with.

    I would like to be able to suggest a simple reason for this, but cannot
    outside of other possibilities already suggested. Until you find a
    plausible rationale, I think you should keep looking, at least.

    If you can populate a history file for this user, and cannot explain the
    zero length file you found, you have to seriously consider malicious
    activity. Hope you find the reason, and it is innocuous, but it doesn't
    sound that way yet.

    Good luck and please write back to tell us what you found.

  12. Re: bash_history set to zero length

    responder wrote:

    > kevin bailey wrote:
    >
    >>> We all will try to help some more, with more details. Was this user
    >>> you? Was it a system user? Was it someone else? What was your 'big
    >>> nessus scan'. Do we all need to be aware of something new?

    >
    >> I log in to the server over ssh to carry out various tasks for which I
    >> sometimes have to su to root.
    >>
    >> Only one other user has access via ssh - this is a delveloper who updates
    >> a website using winscp.

    >
    > Generally, each user, including root, has his own .bash_history file in
    > his own home directory. When you log in as a normal user, you will use
    > that user's history. When you su to root, you will then use root's
    > history. The session history is actually only in memory until the session
    > is logged out. The existing history file on disk is not changed until
    > then, when the session history is appended to what is already on disk.
    > There are probably several easy ways to change that behavior if desired,
    > but it would need to be an intentional change.
    >
    > The exception might be that your ssh connection is somehow not writing any
    > history file, and so that user never had anything written to file. I
    > can't tell you if that might be true, but it should be easy to check (and
    > correct if necessary).
    >
    > So, for example, (normally) if you or anyone has ever logged on as
    > that user, and then issued any command-line command (including su), and
    > then logged out normally, then the session history will be written to disk
    > and the file will not be zero length. And that's exactly why a zero
    > length history is so "unusual". It is not difficult to determine if these
    > rules do actually apply to your system and this user by logging on as (or
    > su -ing to) this user and issue a command like ls, then log out and check
    > the file length for that user's history again.
    >
    > There is (normally) no need to zero a history file, and no automatic
    > provision to do so. What you have written suggests to me that you may not
    > be entirely clear if it was due to your session or the other person's that
    > the history length is zero.
    >
    >> The only thing that has shown up is the bash_history file was zero length
    >> one day when I su'd to root.
    >>
    >> There is no other sign of intrusion that I can see via aide or
    >> chkrootkit.

    >
    > These are both generally well regarded and valuable tools. I might be
    > wrong, but don't believe either is entirely infallible. Chrootkit looks
    > for specific things that are (or have been) found on compromised systems
    > (like zero-length history files). The fact that it doesn't find other
    > signs (or any) is not evidence that there has _not_ been illicit activity
    > or tampering. It is itself a shell script, subject to being edited or
    > changed, and subject to system commands being trusted, and so is best run
    > locally from a (live) CD.
    >
    > Aide depends on a baseline data and system commands. It is also best
    > trusted when run locally using trusted, read only media.
    >
    > Unfortunately, what needs to be kept in mind is that if and when a system
    > is compromised. nothing on that system can be trusted.
    >
    >> Server is debian sarge and everything is up-to-date.
    >>
    >> I looked about and I had a few other sessions running on another
    >> workspace on my laptop and they had become disconnected when the network
    >> cable had become unplugged.
    >>
    >> Maybe one of these disconnects cause the bash_history to become lost?

    >
    > Many things might happen as a result of unexpected or non-standard
    > disconnections, etc. I would not expect plausible that zeroing a history
    > file length would be one of them. You could check it on your system with
    > a user that has a non-zero length history file to start with.
    >
    > I would like to be able to suggest a simple reason for this, but cannot
    > outside of other possibilities already suggested. Until you find a
    > plausible rationale, I think you should keep looking, at least.
    >
    > If you can populate a history file for this user, and cannot explain the
    > zero length file you found, you have to seriously consider malicious
    > activity. Hope you find the reason, and it is innocuous, but it doesn't
    > sound that way yet.
    >
    > Good luck and please write back to tell us what you found.



    Thanks for your detailed reply.

    Since I am the only user and the bash_history file is set up as is standard
    on Debian Sarge I agree that there is no normal reason that the
    bash_history file should be zero length when I log in.

    And you're right that chkrootkit could be altered and of course tripwire
    would be better than aide because the aide database is not on a read-only
    media - at least tripwire's database files are encrypted and signed.

    The machine was kept reasonably up-to-date with Debian stable. The only
    advisory I was a few days late with were the recent open-ssl ones.

    http://www.debian.org/security/2006/dsa-1174
    http://www.debian.org/security/2006/dsa-1173
    http://www.securityfocus.com/bid/19849

    and according to bugtrak there are no exploits based on this vulnerability
    yet.

    Nothing else is really showing at the moment.

    Thanks,

    Kevin

  13. Re: bash_history set to zero length

    kevin bailey wrote:

    > responder wrote:
    >
    >> kevin bailey wrote:
    >>
    >>>> We all will try to help some more, with more details. Was this user
    >>>> you? Was it a system user? Was it someone else? What was your 'big
    >>>> nessus scan'. Do we all need to be aware of something new?

    >>
    >>> I log in to the server over ssh to carry out various tasks for which I
    >>> sometimes have to su to root.
    >>>
    >>> Only one other user has access via ssh - this is a delveloper who
    >>> updates a website using winscp.

    >>
    >> Generally, each user, including root, has his own .bash_history file in
    >> his own home directory. When you log in as a normal user, you will use
    >> that user's history. When you su to root, you will then use root's
    >> history. The session history is actually only in memory until the
    >> session is logged out. The existing history file on disk is not changed
    >> until then, when the session history is appended to what is already on
    >> disk. There are probably several easy ways to change that behavior if
    >> desired, but it would need to be an intentional change.
    >>
    >> The exception might be that your ssh connection is somehow not writing
    >> any history file, and so that user never had anything written to file.
    >> I can't tell you if that might be true, but it should be easy to check
    >> (and correct if necessary).
    >>
    >> So, for example, (normally) if you or anyone has ever logged on as that
    >> user, and then issued any command-line command (including su), and then
    >> logged out normally, then the session history will be written to disk
    >> and the file will not be zero length. And that's exactly why a zero
    >> length history is so "unusual". It is not difficult to determine if
    >> these rules do actually apply to your system and this user by logging on
    >> as (or su -ing to) this user and issue a command like ls, then log out
    >> and check the file length for that user's history again.
    >>
    >> There is (normally) no need to zero a history file, and no automatic
    >> provision to do so. What you have written suggests to me that you may
    >> not be entirely clear if it was due to your session or the other
    >> person's that the history length is zero.
    >>
    >>> The only thing that has shown up is the bash_history file was zero
    >>> length one day when I su'd to root.
    >>>
    >>> There is no other sign of intrusion that I can see via aide or
    >>> chkrootkit.

    >>
    >> These are both generally well regarded and valuable tools. I might be
    >> wrong, but don't believe either is entirely infallible. Chrootkit looks
    >> for specific things that are (or have been) found on compromised systems
    >> (like zero-length history files). The fact that it doesn't find other
    >> signs (or any) is not evidence that there has _not_ been illicit
    >> activity or tampering. It is itself a shell script, subject to being
    >> edited or changed, and subject to system commands being trusted, and so
    >> is best run locally from a (live) CD.
    >>
    >> Aide depends on a baseline data and system commands. It is also best
    >> trusted when run locally using trusted, read only media.
    >>
    >> Unfortunately, what needs to be kept in mind is that if and when a
    >> system is compromised. nothing on that system can be trusted.
    >>
    >>> Server is debian sarge and everything is up-to-date.
    >>>
    >>> I looked about and I had a few other sessions running on another
    >>> workspace on my laptop and they had become disconnected when the
    >>> network cable had become unplugged.
    >>>
    >>> Maybe one of these disconnects cause the bash_history to become lost?

    >>
    >> Many things might happen as a result of unexpected or non-standard
    >> disconnections, etc. I would not expect plausible that zeroing a
    >> history file length would be one of them. You could check it on your
    >> system with a user that has a non-zero length history file to start
    >> with.
    >>
    >> I would like to be able to suggest a simple reason for this, but cannot
    >> outside of other possibilities already suggested. Until you find a
    >> plausible rationale, I think you should keep looking, at least.
    >>
    >> If you can populate a history file for this user, and cannot explain the
    >> zero length file you found, you have to seriously consider malicious
    >> activity. Hope you find the reason, and it is innocuous, but it doesn't
    >> sound that way yet.
    >>
    >> Good luck and please write back to tell us what you found.

    >
    >
    > Thanks for your detailed reply.
    >
    > Since I am the only user and the bash_history file is set up as is
    > standard on Debian Sarge I agree that there is no normal reason that the
    > bash_history file should be zero length when I log in.
    >
    > And you're right that chkrootkit could be altered and of course tripwire
    > would be better than aide because the aide database is not on a read-only
    > media - at least tripwire's database files are encrypted and signed.
    >
    > The machine was kept reasonably up-to-date with Debian stable. The only
    > advisory I was a few days late with were the recent open-ssl ones.
    >
    > http://www.debian.org/security/2006/dsa-1174
    > http://www.debian.org/security/2006/dsa-1173
    > http://www.securityfocus.com/bid/19849
    >
    > and according to bugtrak there are no exploits based on this vulnerability
    > yet.
    >
    > Nothing else is really showing at the moment.
    >
    > Thanks,
    >
    > Kevin


    Hello Kevin, - Thanks for writing back.

    I have a kind of "a thing" about compromised computers being left
    connected because I think it potentially presents a _very_ serious threat
    to all, including me and you, users of the public network. That also
    includes electric power utilities, (unfortunately!) defense nodes,
    (personal) financial databases, and every other internet connected aspect
    of our current lifestyles. Of course I would like to help with your
    current issue, but I also want to be sure and assured, as much as
    possible, that there are no compromised systems waiting to be called into
    play against us all in a civilized society. This is a very
    over-optimistic expectation, I know. But that does not prevent me from
    hoping for it and from working for it. So in that context let me talk to
    what you wrote.

    When you said (above)

    > Since I am the only user and the bash_history file is set up as is
    > standard on Debian Sarge I agree that there is no normal reason that the
    > bash_history file should be zero length when I log in.


    You seemingly contradicted what you wrote earlier, in message

    Message-ID:

    on

    Date: Thu, 21 Sep 2006 11:45:17 +0100

    when you wrote

    Only one other user has access via ssh - this is a delveloper who updates
    a website using winscp.

    I cannot make sense of this apparent contradiction, and so I cannot offer
    much more in the way of hopefully constructive advice. What I can say is
    to reiterate that if you don't know why your(?) .bash_history file was
    zeroed, then you still have a problem that should not be ignored. To
    ignore it would be a threat to you personally and to everyone else,
    connected or not.

    I know how these things could happen, and why there is reluctance to
    correct. Practice of good security means you are ready for a challenge,
    and have allocated the resources to respond. You should take your backup
    server into production now.

    I send you all good hopes and wishes. But please do not make us all
    suffer consequences because you are unprepared to disconnect and replace a
    compromised host.

    I read your links. It is not (so) important to me to know how a
    compromise happened or what your exact circumstances are. There are
    people reading here who know more than I do in many contexts, and who can
    help with specific questions. What I know is that a compromised system
    should be disconnected. Until you can clarify why the file was zeroed,
    you should consider yourself compromised. Unless you can do that now, the
    machine needs to be disconnected.

  14. Re: bash_history set to zero length

    * responder
    | I have a kind of "a thing" about compromised computers being left
    | connected because I think it potentially presents a _very_ serious
    | threat to all, including me and you, users of the public network.
    | That also includes electric power utilities, (unfortunately!)
    | defense nodes, (personal) financial databases, and every other
    | internet connected aspect of our current lifestyles.

    With the gazillions of compromised Windoze boxes currently out there,
    one more compromised Linux box won't make much of a difference. All
    of those potential targets hopefully have strong security measures in
    place which do not care whether the attacker is Windows or Linux.

    R'

  15. Re: bash_history set to zero length

    Ralf Fassel wrote:

    > * responder
    > | I have a kind of "a thing" about compromised computers being left
    > | connected because I think it potentially presents a _very_ serious
    > | threat to all, including me and you, users of the public network. That
    > | also includes electric power utilities, (unfortunately!) defense nodes,
    > | (personal) financial databases, and every other internet connected
    > | aspect of our current lifestyles.
    >
    > With the gazillions of compromised Windoze boxes currently out there, one
    > more compromised Linux box won't make much of a difference. All of those
    > potential targets hopefully have strong security measures in place which
    > do not care whether the attacker is Windows or Linux.


    A strong security plan includes recovery and restoration after a
    compromise, and that allows a compromised box to be promptly disconnected
    and replaced. It does little good to be able to detect a compromise if
    one is unable to respond promptly and correctly.

    The opinion you expressed is used as a rationalization by many who cannot
    or will not take security seriously. I sympathize with OP, but I don't
    think it is helpful to encourage or excuse this kind of behavior.

  16. Re: bash_history set to zero length

    * responder
    | The opinion you expressed is used as a rationalization by many who
    | cannot or will not take security seriously. I sympathize with OP,
    | but I don't think it is helpful to encourage or excuse this kind of
    | behavior.

    Don't leave a compromised box connected to the net. Take all measures
    to clean a box after it was compromised. I'm all for that.

    But. The 'very serious' in

    | I have a kind of "a thing" about compromised computers being left
    | connected because I think it potentially presents a _very_ serious
    | threat to all, including me and you, users of the public network.

    sounded to me like a compromised computer was something exceptional,
    something which does not happen everyday.

    While a compromised computer _should be_ something exceptional, it is
    quite common today, and therefore I would probably reduce the "_very_
    serious threat" to a mere "threat".

    I don't recommend leaving compromised computers compromised.
    R'

  17. Re: bash_history set to zero length

    Ralf Fassel wrote:

    > * responder
    > | The opinion you expressed is used as a rationalization by many who |
    > cannot or will not take security seriously. I sympathize with OP, but I
    > | don't think it is helpful to encourage or excuse this kind of
    > behavior.
    >
    > Don't leave a compromised box connected to the net. Take all measures
    > to clean a box after it was compromised. I'm all for that.


    Exactly. Agreed.

    > But. The 'very serious' in
    >
    > | I have a kind of "a thing" about compromised computers being left |
    > connected because I think it potentially presents a _very_ serious |
    > threat to all, including me and you, users of the public network.
    >
    > sounded to me like a compromised computer was something exceptional,
    > something which does not happen everyday.


    It certainly doesn't happen to me every day, week or year, thank you. If
    it happens to others more frequently then it is time for a security
    review, IMO.

    > While a compromised computer _should be_ something exceptional, it is
    > quite common today, and therefore I would probably reduce the "_very_
    > serious threat" to a mere "threat".


    When your identity is stolen, new credit cards are issued in your name and
    then not paid; when your (paper) mailbox is stuffed with red-tinted
    threatening form letters from collection agencies from debts you did not
    incur, please then do tell us again how it is not a "_very_" serious
    threat.

    When your electric power grid is interrupted because of, or just possibly
    with the "help" of some computer virus outbreak, please then do tell us
    again how it is not a "_very_" serious threat.

    Yes it surely is an everyday occurrence, particularly with the dominant
    microsoft os's. As I see it, the problem is not so much (just) that
    machines are compromised, as that they are then not cleaned. That is what
    your first comment seemed to me to advocate. That was not your intention
    judging from this message. From the first message either I needed to read
    more insightfully, or you needed to write more clearly. Whatever. On
    this topic, I am adamant.

    > I don't recommend leaving compromised computers compromised. R'


    Agreed.

    Thanks for writing.

  18. Re: bash_history set to zero length

    On Wed, 04 Oct 2006 06:14:37 -0400, responder wrote:
    > Ralf Fassel wrote:
    >> * responder


    >> But. The 'very serious' in
    >> | I have a kind of "a thing" about compromised computers being left |
    >> connected because I think it potentially presents a _very_ serious |
    >> threat to all, including me and you, users of the public network.
    >>
    >> sounded to me like a compromised computer was something exceptional,
    >> something which does not happen everyday.

    >
    > It certainly doesn't happen to me every day, week or year, thank you. If
    > it happens to others more frequently then it is time for a security
    > review, IMO.
    >
    >> While a compromised computer _should be_ something exceptional, it is
    >> quite common today, and therefore I would probably reduce the "_very_
    >> serious threat" to a mere "threat".

    >
    > When your identity is stolen [...]
    > please then do tell us again how it is not a "_very_" serious threat.


    I think the point is that any threat in an on-going situation with no end
    in site looses that "very serious" quality very quickly.

    Yes, it is a -very- serious threat that any of us could all get killed in a
    car accident.. even while sitting at our computers reading usenet, but
    since this a constant threat, with no end in site, and there is not a lot
    we can do about it (that we haven't already done)... it becomes a mere
    threat, and the "very serious" quality is lost. It would of course seem
    more serious to you at the time it happened to you.

    .... compare the threat against other ongoing threats and I'm sure you
    would agree eastern European financial crimes enabled by the Internet is
    more pressing than yet another compromised computer on the Internet ...
    and even if you did clean up THAT compromised computer, there are 10
    thousand more still connected... so you addressed 1/10,000th of the
    problem and so were almost wholly in-effective.

    Now if MicroSoft wanted to address this threat and had the ability to
    address the problem on a larger scale then they should take it -very-
    seriously... or if nobody took this threat seriously, it might become
    -very- serious... but even then, only for a while, then merely a serious
    threat as everyone grew accustomed to it.

+ Reply to Thread