still problem 'flooding' - BSD

This is a discussion on still problem 'flooding' - BSD ; Hi, I mentioned this a while back. Our ISP asked us to shut down our 5.5-RELEASE machine as it was the source of flooding. I checked the logs .. 0108.00:18:35.876 0108.00:21:07.562 96*** **** 51704 133** 88.XX.XXX.XX** 23*** 17* 0* 21719***** ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: still problem 'flooding'

  1. still problem 'flooding'

    Hi,
    I mentioned this a while back. Our ISP asked us to shut down our
    5.5-RELEASE machine as it was the source of flooding. I checked the
    logs ..

    0108.00:18:35.876 0108.00:21:07.562 96*** **** 51704
    133** 88.XX.XXX.XX** 23*** 17* 0* 21719***** 629851

    So it seems that there are repeated attempts to connect via telnet (port
    23?) from that box. Thing is, whilst there are two hundred or so
    accounts on that box, only two have shell access: me, and the IT guy.

    Any idea how to investigate this? I'll start by simply removing the
    telnet binary, but I need to know if someone has managed to get shell
    access ... whether he/she (if someone _has_ got in) has managed to crack
    root, etc ...

    --
    taglearc

  2. Re: still problem 'flooding'

    Begin
    On Mon, 07 Jul 2008 11:52:01 +0200, taglearc wrote:
    >
    > So it seems that there are repeated attempts to connect via telnet (port
    > 23?) from that box. Thing is, whilst there are two hundred or so
    > accounts on that box, only two have shell access: me, and the IT guy.
    >
    > Any idea how to investigate this?


    So how does your IT guy not know how to investigate this and why are you
    and not he posting here?


    > I'll start by simply removing the telnet binary, but I need to know
    > if someone has managed to get shell access ... whether he/she (if
    > someone _has_ got in) has managed to crack root, etc ...


    All one needs is the ability to run code that will open a connection to
    a remote host at remote port 23 -- no need for root. It may be anything
    from actual binaries to someone running a telnet servlet or (eg, php)
    script, a shell using telnet or nc or whatever other binary that will
    open a socket and lets you specify the target port, or whatnot.

    So, fire up the usual inspection tools and find out what process opens
    up those connections, who it belongs to, and find out what they're doing
    and how they're doing it exactly.

    This sort of thing would require someone knowledgeable on-site or at
    the very least with remote access. As stated your question contains Not
    Enough Information By Far to say anything more useful about it.

    ISTR you were told something along those lines previously, too.


    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    This message was originally posted on Usenet in plain text.
    Any other representation, additions, or changes do not have my
    consent and may be a violation of international copyright law.

  3. Re: still problem 'flooding'

    In article ,
    jpd wrote:

    > Begin
    > On Mon, 07 Jul 2008 11:52:01 +0200, taglearc wrote:
    > >
    > > So it seems that there are repeated attempts to connect via telnet (port
    > > 23?) from that box. Thing is, whilst there are two hundred or so
    > > accounts on that box, only two have shell access: me, and the IT guy.
    > >
    > > Any idea how to investigate this?

    >
    > So how does your IT guy not know how to investigate this and why are you
    > and not he posting here?
    >
    >
    > > I'll start by simply removing the telnet binary, but I need to know
    > > if someone has managed to get shell access ... whether he/she (if
    > > someone _has_ got in) has managed to crack root, etc ...

    >
    > All one needs is the ability to run code that will open a connection to
    > a remote host at remote port 23 -- no need for root. It may be anything
    > from actual binaries to someone running a telnet servlet or (eg, php)
    > script, a shell using telnet or nc or whatever other binary that will
    > open a socket and lets you specify the target port, or whatnot.
    >
    > So, fire up the usual inspection tools and find out what process opens
    > up those connections, who it belongs to, and find out what they're doing
    > and how they're doing it exactly.
    >
    > This sort of thing would require someone knowledgeable on-site or at
    > the very least with remote access. As stated your question contains Not
    > Enough Information By Far to say anything more useful about it.
    >
    > ISTR you were told something along those lines previously, too.


    I know, I know. ISTR the same degree of aggression the last time, too
    and I admit to still not understanding it. I installed this box a few
    years ago whilst teaching there. At the time, I'd been out of IT for =~
    five years, and had just enough knowledge to get it up and running. I
    no longer work there, and the bloke who does IT is MS and knows little
    about UNIX. Yeah, even less than me. :-|

    Anyway, it's a crappy little website, but is 'important' in that a lot
    of the students and former students have POP accounts with the name of
    the school in it.

    So ... could I ask, _please_ humour me, and give me some clues, like for
    example what are the 'usual inspection tools' ? And ...

    > find out what process opens
    > up those connections, who it belongs to, and find out what they're doing
    > and how they're doing it exactly.


    How? I don't need to be spoonfed (well, not much..). A man page would
    be sufficient to be going on with.

    Thanks.

    --
    taglearc

  4. Re: still problem 'flooding'

    Begin
    On Mon, 07 Jul 2008 12:10:36 +0200, taglearc wrote:
    >
    > I know, I know. ISTR the same degree of aggression the last time, too
    > and I admit to still not understanding it.


    No wonder, since I'm asking questions about technical and organisational
    details, perhaps pointedly and perhaps forcefully, but I'm not out to
    attack you personally. I rarely am.

    The bare fact is that you're Not Giving Enough Information To Work With.
    Before anyone can help you, you need to fix that. Yes, you, as nobody
    else can.

    Beyond that you need to understand that I am not here to hold your hand
    and pat you on your head and murmur sweet words of assurance into your
    ear. I don't know of many people in this group who even might.

    http://www.catb.org/~esr/faqs/smart-questions.html
    http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
    (and plenty more)

    Stealing a quote from another place:


    'Imagine' entering a medical conference, shouting "Hi Guyz",
    exposing your as^Hbdomen and crying "um ar... it hurts!! HELP ME!!"
    'Double-plus-ungood', huh?



    > I installed this box a few years ago whilst teaching there. At the
    > time, I'd been out of IT for =~ five years, and had just enough
    > knowledge to get it up and running. I no longer work there, and the
    > bloke who does IT is MS and knows little about UNIX. Yeah, even less
    > than me. :-|


    No wonder.

    The thing is, if you have an external breach of security on your hands,
    as opposed to, say, mere creative repurposing of some web-script by a
    legitimate user, you need to bring in some serious clue.

    Then again, you and the school have let the whole thing lapse for
    months, so despite your allegations it can't be that serious, or if it
    turns out to be, *someone* has been acting criminally irresponsible.

    This isn't me attacking you. This is pointing out the obvious.


    > Anyway, it's a crappy little website, but is 'important' in that a lot
    > of the students and former students have POP accounts with the name of
    > the school in it.


    If the school or perhaps their alumni club thinks it is important too, it
    would be up to them to provide the infrastructure to support this. An IT
    guy --even just a unix guy on a retainer-- for their servers in addition to
    just someone for hand-holding the desktop users would be a good start.


    Let me point another obvious thing then: You're asking complete
    strangers to help you with something you think important while making it
    extremely painful for them to come up with suggestions that stand any
    chance of being useful -- which would be the only reward.

    How is that for a carrot and stick approach?

    Your reaction of complaining about *my* attitude is just icing on the cake.


    > So ... could I ask, _please_ humour me, and give me some clues, like for
    > example what are the 'usual inspection tools' ? And ...


    *You* may have years of experience humouring backward students but you
    can't expect everybody else to jump at the opportunity to teach you from
    the simplest of basics over usenet for free. One requisite for giving
    you clues would be that you convince us you put in some effort yourself.


    >> find out what process opens
    >> up those connections, who it belongs to, and find out what they're doing
    >> and how they're doing it exactly.

    >
    > How? I don't need to be spoonfed (well, not much..). A man page would
    > be sufficient to be going on with.


    Your question implied that you would indeed need to be spoonfed well
    beyond a few pointers. You did indeed sound that clueless.

    In the time you've let lapse between questions you could've found out
    much yourself, basic things like `ps', `netstat', or an alternative like
    `lsof'. Have you even so much as looked at the handbook in the meantime?

    But if you have a real security breach, as you allegated but failed to
    provide more than a fractional indication for, a few free clues Just
    Will Not Cut It. It's too easy to miss vital clues of rootkits and
    other things an attacker may have gone out of their way for to hide, so
    someone who does have a good understanding of the system is called for.


    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    This message was originally posted on Usenet in plain text.
    Any other representation, additions, or changes do not have my
    consent and may be a violation of international copyright law.

  5. Re: still problem 'flooding'

    In article ,
    jpd wrote:

    { clip more aggressive ranting }

    Forget it, man.


    --
    taglearc

  6. Re: still problem 'flooding'

    taglearc wrote, On 07/07/08 07:22 AM:
    > In article ,
    > jpd wrote:
    >
    > { clip more aggressive ranting }
    >
    > Forget it, man.


    I think you need a thicker skin.

    'Cause he's right, you know. You're doing the equivalent of phoning the
    mechanic, saying "My car doesn't work - what's wrong with it?" And when
    teh mechanic asks you if any warning lights are one, if teh car is
    stalling or whatever you just respond "I dunno. My car doesn't work -
    what's wrong with it?"

  7. Re: still problem 'flooding'

    taglearc writes:

    > In article ,
    > jpd wrote:


    >> find out what process opens
    >> up those connections, who it belongs to, and find out what they're doing
    >> and how they're doing it exactly.

    >
    > How? I don't need to be spoonfed (well, not much..). A man page would
    > be sufficient to be going on with.


    tcpdump(1) and sockstat(1) are my usual starting places for
    identifying what starts particular connections...

    --
    Lowell Gilbert, embedded/networking software engineer
    http://be-well.ilk.org/~lowell/

  8. Re: still problem 'flooding'

    In article <44fxqlk697.fsf@be-well.ilk.org>,
    Lowell Gilbert wrote:

    > taglearc writes:
    >
    > > In article ,
    > > jpd wrote:

    >
    > >> find out what process opens
    > >> up those connections, who it belongs to, and find out what they're doing
    > >> and how they're doing it exactly.

    > >
    > > How? I don't need to be spoonfed (well, not much..). A man page would
    > > be sufficient to be going on with.

    >
    > tcpdump(1) and sockstat(1) are my usual starting places for
    > identifying what starts particular connections...


    Thank you.


    --
    taglearc

  9. Re: still problem 'flooding'

    1. If you suspect a compromise, perform all inspections from the
    console or serial connection, and NOT via a network.

    2. "lsof | grep TCP" will show all TCP connections
    open at the moment that command is issued. It is handy
    for narrowing down which processes may be doing
    improper things. If you don't have lsof already installed,
    you can get the appropriate binary for that OS release and load
    it on the system via memory stick, floppy, etc. I personally
    install lsof on every system minutes after the OS installed
    so that a compatible version is at hand.

    The tcpdump program which comes with the OS will also allow you
    to examine packets by odd activity. tcpdump -n -s 1536 -X tcp
    run as root will show you what is in all the TCP packets
    coming in and out. Add options to make it more specific and
    less noisy if you see things of interest.

    3. If you find anything improper, disconnect the network.
    No point letting whatever it is keep happening once you
    find it. Once disconnected, you can perform further
    analysis into programs that are running that should not
    be there or other alterations to the OS. CAUTION: the OS
    utilities may have been altered to display normal looking
    results and to wipe or filter log files, so booting from an
    installation CD and then looking at the filesystems on the
    hard disk may reveal a very modified system.

    4. If you find anything improper, assume all passwords are
    compromised. Be sure to change all of them on this
    and any other system you use AFTER YOU RE-INSTALL THE OS,
    as the attacker had access to the logs and knows which places
    you connect from, and so probably now knows other machines
    that might have the same passwords. If you accessed other
    systems via this one, assume the accounts and passwords
    of those systems have also become known to others.

    5. If you find anything improper, don't trust any setuid
    or setgid program/file on that system. Save your data files on
    backup media, and then wipe and re-install entire system from
    trusted media. Then reload your personal data files,
    but don't bring back any executables or privileged scripts
    from the backups. Remember that the system may have
    been compromised some time ago, so older backups may not
    be trustworthy either.

    6. If the system contained the personal data of others,
    such as e-mail addresses and other mailing-list type
    information, you may be required by organizational policy,
    or local or national statute to inform all of those
    persons of the potential compromise of their personal data.
    (Don't send the notifications from the compromised machine.)
    You may also be required or requested to make the uncleaned
    system available for analysis by law enforcement. Once
    they are done with it, then you can erase it and start fresh.


    Frank Durda IV - send mail to this address and remove the "LOSE":
    http://nemesis.lonestar.org
    "I have 14 words that would completely cure reckless commodity speculation:
    Make commodity gains Ordinary Income with no deductions for losses,
    and no margin trades." Pass this on to your elected representatives.
    Copyright 2008, ask before reprinting.


  10. Re: still problem 'flooding'

    In article ,
    Frank Durda IV wrote:

    > 1. If you suspect a compromise, perform all inspections from the
    > console or serial connection, and NOT via a network.


    { snip }

    Superb. Many, many thanks.


    --
    taglearc

+ Reply to Thread