Re: Uh-oh. Cracked allready. I think...

[Andrew Pritchard]

> >> 6346/tcp   filteredgnutella
> >
> >"filtered" means there's no reply coming back on thos ports - most likely 
> >your ISP is blocking those ports.
> 
> Yeah, they said that gnutella was "limited". 

Somewhat typical of ISPs - don't they realise that gnutella's port can be re-
configured? So now if you want to use gnutella, you know not to use the default 
port.
 
> >The fact they don't show up when you do a local scan confirms this.  These 
> >services aren't running on your machine.
> 
> So, what you're saying is that all this alarm is for no good reason...?

No - you should always been on your guard. Congrats for watching for odd 
behaviour. And you educated yourself at the same time - a bonus if you ask me.

> There has been no l337 h4X0rz trying to get into my box?

Probably not. Just because they haven't succeeded, doesn't mean they aren't 
trying. More likely they have gone off to find some poor[1] windows user to 
attack instead.

Andrew

[1] Have you seen how much they are charging for software these days? No? 
Neither have I - but I'm sure it's a lot.

"I do not agree with what you say,
but I will defend to the death your right to say it." 
Francois Marie Arouet Voltaire (1694-1778)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Uh-oh. Cracked allready. I think...

[Tim Haynes]

Kjetil Kjernsmo <[EMAIL PROTECTED]> writes:

> >The fact they don't show up when you do a local scan confirms this.
> >These services aren't running on your machine.
> 
> So, what you're saying is that all this alarm is for no good reason...?
> There has been no l337 h4X0rz trying to get into my box? Well, that
> would be really be good news! Of course, it will not make me stop reading
> about how to secure the box.

There is still an outside chance you have either
a) a tcp listener on only the external interface that's only started in
   response to an ICMP ping of specific content/length
and/or
b) some very dodgy (probably LKM-based) trojan that's either deflecting
   nmap and/or netstat calls and/or 

however, the chances of this are slimmer than I am paranoid.

I'd say you should be grateful to have got away lightly - kill listeners
you're not using, firewall it with iptables[0] and sort out your nIDS - the
chances are you'll soon find out if you're haemoraghing evil scans or
anything.

[0] I have a simple enough starter script floating around at
 if it helps at all -
no doubt others have their own approaches, but at least mine has no gui
requirements other than $EDITOR ;)

ATB,

~Tim
-- 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Uh-oh. Cracked allready. I think...

[Kjetil Kjernsmo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi!

Back after the weekend. I've done a bit of reading though.

On Fri, 24 May 2002, Reagan Blundell wrote:

>On Fri, May 24, 2002 at 02:23:38PM +0200, Kjetil Kjernsmo wrote:
>> 6346/tcp   filteredgnutella
>
>"filtered" means there's no reply coming back 
>on thos ports - most likely your ISP is blocking
>those ports.

Yeah, they said that gnutella was "limited". 

>The fact they don't show up when you do a
>local scan confirms this.  These services
>aren't running on your machine.

So, what you're saying is that all this alarm is for no good reason...?
There has been no l337 h4X0rz trying to get into my box?
Well, that would be really be good news! Of course, it will not make me
stop reading about how to secure the box. 

Best,

Kjetil
- -- 
Kjetil Kjernsmo
Recent astrophysics graduate  Problems worthy of attack
University of Oslo, NorwayProve their worth by hitting back
E-mail: [EMAIL PROTECTED]- Piet Hein
Homepage http://folk.uio.no/kjetikj/>
[EMAIL PROTECTED]OpenPGP KeyID: 6A6A0BBC

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (OSF1)
Comment: For info see http://www.gnupg.org

iD8DBQE88juklE/Gp2pqC7wRAlP2AJ9mZz8/YXCWvurdra8bewptWqvKmwCbBmHm
wBb2C4kIDfG1PQI6Ib8MwQE=
=yQx/
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Uh-oh. Cracked allready. I think...

[Andrew Pritchard]

> >> 6346/tcp   filteredgnutella
> >
> >"filtered" means there's no reply coming back on thos ports - most likely 
> >your ISP is blocking those ports.
> 
> Yeah, they said that gnutella was "limited". 

Somewhat typical of ISPs - don't they realise that gnutella's port can be re-
configured? So now if you want to use gnutella, you know not to use the default 
port.
 
> >The fact they don't show up when you do a local scan confirms this.  These 
> >services aren't running on your machine.
> 
> So, what you're saying is that all this alarm is for no good reason...?

No - you should always been on your guard. Congrats for watching for odd 
behaviour. And you educated yourself at the same time - a bonus if you ask me.

> There has been no l337 h4X0rz trying to get into my box?

Probably not. Just because they haven't succeeded, doesn't mean they aren't 
trying. More likely they have gone off to find some poor[1] windows user to 
attack instead.

Andrew

[1] Have you seen how much they are charging for software these days? No? 
Neither have I - but I'm sure it's a lot.

"I do not agree with what you say,
but I will defend to the death your right to say it." 
Francois Marie Arouet Voltaire (1694-1778)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Uh-oh. Cracked allready. I think...

[Tim Haynes]

Kjetil Kjernsmo <[EMAIL PROTECTED]> writes:

> >The fact they don't show up when you do a local scan confirms this.
> >These services aren't running on your machine.
> 
> So, what you're saying is that all this alarm is for no good reason...?
> There has been no l337 h4X0rz trying to get into my box? Well, that
> would be really be good news! Of course, it will not make me stop reading
> about how to secure the box.

There is still an outside chance you have either
a) a tcp listener on only the external interface that's only started in
   response to an ICMP ping of specific content/length
and/or
b) some very dodgy (probably LKM-based) trojan that's either deflecting
   nmap and/or netstat calls and/or 

however, the chances of this are slimmer than I am paranoid.

I'd say you should be grateful to have got away lightly - kill listeners
you're not using, firewall it with iptables[0] and sort out your nIDS - the
chances are you'll soon find out if you're haemoraghing evil scans or
anything.

[0] I have a simple enough starter script floating around at
 if it helps at all -
no doubt others have their own approaches, but at least mine has no gui
requirements other than $EDITOR ;)

ATB,

~Tim
-- 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Uh-oh. Cracked allready. I think...

[Kjetil Kjernsmo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi!

Back after the weekend. I've done a bit of reading though.

On Fri, 24 May 2002, Reagan Blundell wrote:

>On Fri, May 24, 2002 at 02:23:38PM +0200, Kjetil Kjernsmo wrote:
>> 6346/tcp   filteredgnutella
>
>"filtered" means there's no reply coming back 
>on thos ports - most likely your ISP is blocking
>those ports.

Yeah, they said that gnutella was "limited". 

>The fact they don't show up when you do a
>local scan confirms this.  These services
>aren't running on your machine.

So, what you're saying is that all this alarm is for no good reason...?
There has been no l337 h4X0rz trying to get into my box?
Well, that would be really be good news! Of course, it will not make me
stop reading about how to secure the box. 

Best,

Kjetil
- -- 
Kjetil Kjernsmo
Recent astrophysics graduate  Problems worthy of attack
University of Oslo, NorwayProve their worth by hitting back
E-mail: [EMAIL PROTECTED]- Piet Hein
Homepage http://folk.uio.no/kjetikj/>
[EMAIL PROTECTED]OpenPGP KeyID: 6A6A0BBC

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (OSF1)
Comment: For info see http://www.gnupg.org

iD8DBQE88juklE/Gp2pqC7wRAlP2AJ9mZz8/YXCWvurdra8bewptWqvKmwCbBmHm
wBb2C4kIDfG1PQI6Ib8MwQE=
=yQx/
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Uh-oh. Cracked allready. I think...

[synthespian]

Em Sex, 2002-05-24 às 04:00, Steve Meyer escreveu: 
> There is a good chance if you have been rooted, that the attacker installed 
> a rootkit to cover his tracks.  I saw a good rootkit detecter on  
> http://freshmeat.net/ .  Just do a search for it on there.
> 
> 
> >
>
HI- 

What you want, what he meant is the chkrootkit program. 
It's pretty straightforward in rootkit detection, particularly of the
"script kiddie" type. 
But then what 

Regs 
Henry


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Uh-oh. Cracked allready. I think...

[synthespian]

Em Sex, 2002-05-24 às 04:00, Steve Meyer escreveu: 
> There is a good chance if you have been rooted, that the attacker installed 
> a rootkit to cover his tracks.  I saw a good rootkit detecter on  
> http://freshmeat.net/ .  Just do a search for it on there.
> 
> 
> >
>
HI- 

What you want, what he meant is the chkrootkit program. 
It's pretty straightforward in rootkit detection, particularly of the
"script kiddie" type. 
But then what 

Regs 
Henry


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Uh-oh. Cracked allready. I think...

[Reagan Blundell]

On Fri, May 24, 2002 at 02:23:38PM +0200, Kjetil Kjernsmo wrote:
> 
> OK. This is what nmap says, launched from my workstation:
[snip]
> 137/tcpfilterednetbios-ns
> 138/tcpfilterednetbios-dgm
> 139/tcpfilterednetbios-ssn
[snip]
> 6346/tcp   filteredgnutella

"filtered" means there's no reply coming back 
on thos ports - most likely your ISP is blocking
those ports.

The fact they don't show up when you do a
local scan confirms this.  These services
aren't running on your machine.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Uh-oh. Cracked allready. I think...

[Tim Haynes]

Kjetil Kjernsmo <[EMAIL PROTECTED]> writes:

> On 24 May 2002, Tim Haynes wrote:
> 
> >Unfortunately, the only way to examine all the files on the disk/s is to
> >reboot the box off clean r/o media (read: rescue CD), mount them r/o,
> >and examine them by hand.
> 
> Yeah, I guess so.

In the absence of this, keeping an eye on what the box is doing is a close
second. 

> >> 53/tcp opendomain
> >
> >OK, what version of what are you running for this?
> 
> According to Nessus:
> "The remote bind version is : 9.2.0"
> But I guess this need not be accessible from the outside. I'm not running
> a name server myself (though I plan to some time...)

Well if you do, I'll recommend bind 9.2.x for the job unless there's a
better version out there by that time ;)

Last count of remote exploits: bind-8.x, lots. bind-9.x, none.

> >> 80/tcp openhttp
> >> 110/tcpopenpop-3
> >> 111/tcpopensunrpc
> >
> >Portmapper (111) is an absolute liability - I flatly refuse to run it on
> >any public-facing box, and it must *never* be externally visible.
> 
> *tears rolling* I would like to mount the three partitions where I keep
> my web pages over NFS, but my server and I will be on different networks.
> But OK I installed harden-servers.

You might be better off with `rsync -e ssh' and passphraseless keys,
depending on exactly how immediate you want change notifications to
propogate. 

You should definitely consider the relationship between your servers in the
firewall design - at the very least I'd say portmap+nfs is permitted *IFF*
you firewall down to the two machines. But preferably, don't do it at all.

> >> 137/tcpfilterednetbios-ns
> >> 138/tcpfilterednetbios-dgm
> >> 139/tcpfilterednetbios-ssn
> >
> >You're running samba then?
> 
> No, it was installed in tasksel IIRC, I thought I removed it, but
> apparently not. I removed samba, but they didn't disappear, something
> more I have to do?

If you were running samba out of xinetd, you'll probably want to disable
the relevant services in /etc/xinetd.conf (and reload xinetd).

> >> 6346/tcp   filteredgnutella
> >
> >Hang around, it's "filtered"? That means it never replied to nmap but
> >there were other ports that did - the mixture of responses means nmap
> >"knows" this port is dropping responses.
> 
> It does? 

Yes. 

> >I think you have an anomaly, myself.
> 
> OK.

You might want to check for a firewall between your workstation and the
server in question dropping port 6346 specifically - in fact, if you really
want to be sure, run tcpdump on the server while you nmap it for
-p6345-6347 (a range crossing the port in question) and see if port 6346 is
scanned at all - if not, it's an outgoing firewall getting in your way :)

> >> Uh, don't think so. I installed snort, but didn't take the time to
> >> play with it. I thought that would do the job too... Can I get the
> >> required information from the snort install...?
> >
> >Nope, snort is for dynamic logs of dodgy packets going by. 
> 
> I see. 

... you can log the results into mysql and run _Acid_ against it, too. That
generates pretty-picture html overviews and stuff.

> >> What could be wrong about e.g.:
> >>ForwardX11 yes
> >
> >Erm, that's a little bit weird. 
> >
> > | StrictModes yes
> > | X11Forwarding yes
> > | X11DisplayOffset 10
> > | AllowTcpForwarding yes
> >
> >I think you're somehow using an old sshd_config with a proto2-enabled sshd.
> >Or a non-free ssh against openssh. Possibly.
> 
> Eh, Berend pointed out to me that I was making sshd read ssh_config...
> That could be it, but I have been messing a bit with it, so there could
> be more.

That would also explain it :8)

> >You should keep an eye the incoming/outgoing traffic, though; I thought
> >I saw a utility for analysing how many hosts/ports a box contacts over
> >time recently, which will help.
> 
> OK, I'll search.

Well if nothing else, you can use _iptraf_ in per-port summary mode :)

> >Set up snort and AIDE as a matter of urgency too
> 
> They're up. AIDE looked easy to configure, apt seemed to do that. 

Choose what hashes you maintain for which directory very carefully. I have
separate settings for:

=/boot$ Binlib
# Binaries
/bin Binlib
/sbin Binlib
/usr/bin Binlib
/usr/sbin Binlib
/usr/local/bin Binlib
/usr/local/sbin Binlib
/usr/games Binlib
# Libraries
/lib Binlib
/usr/lib Binlib
/usr/local/lib Binlib
# Log files
/var/log$ StaticDir
/var/log/aide/aide.log(.[0-9])?(.gz)? Databases
/var/log/aide/error.log(.[0-9])?(.gz)? Databases
/var/log/setuid.changes(.[0-9])?(.gz)? Databases
/var/log Logs
!/var/log/snort
# Devices
!/dev/pts
/dev Devices
# Other miscellaneous files
/var/run$ StaticDir
!/var/run

if it helps :)

> >and dns dangling around all over the place, nor will you be aware what's
> >going off if you don't start firewalling things properly and keep a

Re: Uh-oh. Cracked allready. I think...

[Kjetil Kjernsmo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 24 May 2002, Tim Haynes wrote:

>Unfortunately, the only way to examine all the files on the disk/s is to
>reboot the box off clean r/o media (read: rescue CD), mount them r/o, and
>examine them by hand.

Yeah, I guess so.

>You're highly unlikely to find something with trojanned binaries and/or a
>kernel module sitting there intercepting syscalls saying "we're not
>listening on port " and "oh look, an exec() call to ps, use ps.fake
>instead" - all 3 of which are possible these days.

Hehe.

>Nah, when you're root if the option completely isn't understood then you've
>got problems. (I mention this only because it was the first thing that gave
>a cracked box away to me.)

Good! :-)

>> OK. This is what nmap says, launched from my workstation:
>> Port   State   Service
>> 22/tcp openssh
>> 25/tcp opensmtp
>
>These are generally safe - especially in Testing.

Good.

>> 53/tcp opendomain
>
>OK, what version of what are you running for this?

According to Nessus:
"The remote bind version is : 9.2.0"
But I guess this need not be accessible from the outside. I'm not running
a name server myself (though I plan to some time...)

>> 80/tcp openhttp
>> 110/tcpopenpop-3
>> 111/tcpopensunrpc
>
>Portmapper (111) is an absolute liability - I flatly refuse to run it on
>any public-facing box, and it must *never* be externally visible.

*tears rolling* I would like to mount the three partitions where I keep my
web pages over NFS, but my server and I will be on different networks. But
OK I installed harden-servers.

>> 137/tcpfilterednetbios-ns
>> 138/tcpfilterednetbios-dgm
>> 139/tcpfilterednetbios-ssn
>
>You're running samba then?

No, it was installed in tasksel IIRC, I thought I removed it, but
apparently not. I removed samba, but they didn't disappear, something more
I have to do?

>> 6346/tcp   filteredgnutella
>
>Hang around, it's "filtered"? That means it never replied to nmap but there
>were other ports that did - the mixture of responses means nmap "knows"
>this port is dropping responses.

It does? 

>I think you have an anomaly, myself.

OK.

>> So, the suspicious gnutella port isn't in the latter. I don't know what
>> kdm is doing there, BTW. I unselected X and desktop in the initial
>> tasksel. There seems to have been installed some X stuff nevertheless,
>> but neither KDE nor kdm has ever been installed on this box.
>
>Ah, good you said that. It's not "kdm" necessarily, it's because it's the
>first port to which a non-privileged app may bind, >=1024. (See why the
>next one is 1025...)

I see. I also got a private response from Berend De Schouwer who explained
this. 

>I'd not worry about that lot myself. Unless I've missed something, it's not
>obviously different from the nmap results, is it?

Not that I can tell.

>> >Next, if you've got a socket listener or 6346 (IIRC, the most frequently
>> >used gnutella port), try telnetting into it and see what banner, if any,
>> >it presents.
>> 
>> Nope, nothing... 
>> pooh:~# telnet 217.77.32.186 6346
>> Trying 217.77.32.186...
>> telnet: Unable to connect to remote host: Connection refused
>> to be sure. 
>
>That's promising. 

Good.

>And it didn't turn up in netstat, just when you used a
>particular box to do the nmap?

Right.

>Does the port come and go over time at all?

Doesn't seem like it.

>> Yeah, I've done that several times. chkrootkit was described in "Securing
>> Debian", so I installed it before moving it, but only ran it just after I
>> saw the gnutella port. Nothing detected.
>
>OK. It's not a complete guarantee as it uses potentially-tainted tools, but
>it pushes the odds more in your favour.

Good.

>> >Do you have an original AIDE database from immediately after it was
>> >installed?
>> 
>> Uh, don't think so. I installed snort, but didn't take the time to play
>> with it. I thought that would do the job too... Can I get the required
>> information from the snort install...?
>
>Nope, snort is for dynamic logs of dodgy packets going by. 

I see. 

>AIDE is like
>tripwire - stores a database of crypto hashes for files in the filesystem,
>so you compare the database nightly and see what's changed of interest.

Yep, I installed it just after your last e-mail. Also installed
harden-environment. 

>> What could be wrong about e.g.:
>>ForwardX11 yes
>
>Erm, that's a little bit weird. 
>
> | StrictModes yes
> | X11Forwarding yes
> | X11DisplayOffset 10
> | AllowTcpForwarding yes
>
>I think you're somehow using an old sshd_config with a proto2-enabled sshd.
>Or a non-free ssh against openssh. Possibly.

Eh, Berend pointed out to me that I was making sshd read ssh_config...
That could be it, but I have been messing a bit with it, so there could be
more. 

>Good. OK, in that case, you might want to double-check a few others as
>well:
>
> | c29daf1d9fe836053e9f4f0a67a7a94e  /usr/sbin/chkroot

Re: Uh-oh. Cracked allready. I think...

[Tim Haynes]

Kjetil Kjernsmo <[EMAIL PROTECTED]> writes:

> Thanks for all the responses.
> 
> I realize it's pretty bold trying put a box on the net without having
> extensive admin experience beforehand. But I think I'm learning fast, and
> I hope I'll be able to do it without placing any burden on the rest of
> the net. That is, except for you guys... :-) Your help is greatly
> appreciated!

We do our best :)

> >Well if something's got on there that you don't remember installing, can
> >I have some of what you're taking? ;)
> 
> Hehe... I was so sure it would be at least one copy of Star Wars II,
> but no... ;-) There's nothing here... I've walked through the whole disk,
> and I can't find anything of any size that I don't know what is. Whatever
> it is, it has to be rather small...

Unfortunately, the only way to examine all the files on the disk/s is to
reboot the box off clean r/o media (read: rescue CD), mount them r/o, and
examine them by hand.

You're highly unlikely to find something with trojanned binaries and/or a
kernel module sitting there intercepting syscalls saying "we're not
listening on port " and "oh look, an exec() call to ps, use ps.fake
instead" - all 3 of which are possible these days.

> >It's at this point that you should start debugging what's really
> >listening on your box from what a scanner says you are. I suggest you
> >nmap yourself to see what ports you really have open, and compare
> >against
> >netstat -plant | grep LIST
> >(here's your first potential clue: if netstat complains about `-p', it's
> >been trojanned.)
> 
> It complained about -p when I wasn't root...

Nah, when you're root if the option completely isn't understood then you've
got problems. (I mention this only because it was the first thing that gave
a cracked box away to me.)

> OK. This is what nmap says, launched from my workstation:
> Port   State   Service
> 22/tcp openssh
> 25/tcp opensmtp

These are generally safe - especially in Testing.

> 53/tcp opendomain

OK, what version of what are you running for this?

> 80/tcp openhttp
> 110/tcpopenpop-3
> 111/tcpopensunrpc

Portmapper (111) is an absolute liability - I flatly refuse to run it on
any public-facing box, and it must *never* be externally visible.

> 137/tcpfilterednetbios-ns
> 138/tcpfilterednetbios-dgm
> 139/tcpfilterednetbios-ssn

You're running samba then?

> 6346/tcp   filteredgnutella

Hang around, it's "filtered"? That means it never replied to nmap but there
were other ports that did - the mixture of responses means nmap "knows"
this port is dropping responses.

I think you have an anomaly, myself.

> So, the suspicious gnutella port isn't in the latter. I don't know what
> kdm is doing there, BTW. I unselected X and desktop in the initial
> tasksel. There seems to have been installed some X stuff nevertheless,
> but neither KDE nor kdm has ever been installed on this box.

Ah, good you said that. It's not "kdm" necessarily, it's because it's the
first port to which a non-privileged app may bind, >=1024. (See why the
next one is 1025...)

> So for netstat:
> pooh:~# netstat -plant | grep LIST
> tcp   0 0.0.0.0:10240.0.0.0:* LISTEN 209/rpc.statd
> tcp   0 0.0.0.0:10250.0.0.0:* LISTEN 236/rpc.mountd
> tcp   0 0.0.0.0:139 0.0.0.0:* LISTEN 218/inetd
> tcp   0 0.0.0.0:110 0.0.0.0:* LISTEN 218/inetd
> tcp   0 0.0.0.0:111 0.0.0.0:* LISTEN 123/portmap
> tcp   0 0.0.0.0:80  0.0.0.0:* LISTEN 6586/apache
> tcp   0 217.77.32.186:530.0.0.0:* LISTEN 194/named
> tcp   0 127.0.0.1:530.0.0.0:* LISTEN 194/named
> tcp   0 0.0.0.0:22  0.0.0.0:* LISTEN 285/sshd
> tcp   0 127.0.0.1:953   0.0.0.0:* LISTEN 201/lwresd
> tcp   0 0.0.0.0:25  0.0.0.0:* LISTEN 218/inetd
> 
> (slightly reformatted to fit better)

(reformatted better still ;)

I'd not worry about that lot myself. Unless I've missed something, it's not
obviously different from the nmap results, is it?

> >Next, if you've got a socket listener or 6346 (IIRC, the most frequently
> >used gnutella port), try telnetting into it and see what banner, if any,
> >it presents.
> 
> Nope, nothing... 
> pooh:~# telnet 217.77.32.186 6346
> Trying 217.77.32.186...
> telnet: Unable to connect to remote host: Connection refused
> to be sure. 

That's promising. And it didn't turn up in netstat, just when you used a
particular box to do the nmap?

Does the port come and go over time at all?

> >At some stage you should probably run _chkrootkit_ on the blighter, too.
> 
> Yeah, I've done that several times. chkrootkit was described in "Securing
> Debian", so I installed it before moving it, but only ran it just after I
> saw the gnutella port. Nothing detected.

OK. It's not a complete guarantee as it uses potentially-tainted tools, but
it pus

Re: Uh-oh. Cracked allready. I think...

[Reagan Blundell]

On Fri, May 24, 2002 at 02:23:38PM +0200, Kjetil Kjernsmo wrote:
> 
> OK. This is what nmap says, launched from my workstation:
[snip]
> 137/tcpfilterednetbios-ns
> 138/tcpfilterednetbios-dgm
> 139/tcpfilterednetbios-ssn
[snip]
> 6346/tcp   filteredgnutella

"filtered" means there's no reply coming back 
on thos ports - most likely your ISP is blocking
those ports.

The fact they don't show up when you do a
local scan confirms this.  These services
aren't running on your machine.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Uh-oh. Cracked allready. I think...

[Tim Haynes]

Kjetil Kjernsmo <[EMAIL PROTECTED]> writes:

> On 24 May 2002, Tim Haynes wrote:
> 
> >Unfortunately, the only way to examine all the files on the disk/s is to
> >reboot the box off clean r/o media (read: rescue CD), mount them r/o,
> >and examine them by hand.
> 
> Yeah, I guess so.

In the absence of this, keeping an eye on what the box is doing is a close
second. 

> >> 53/tcp opendomain
> >
> >OK, what version of what are you running for this?
> 
> According to Nessus:
> "The remote bind version is : 9.2.0"
> But I guess this need not be accessible from the outside. I'm not running
> a name server myself (though I plan to some time...)

Well if you do, I'll recommend bind 9.2.x for the job unless there's a
better version out there by that time ;)

Last count of remote exploits: bind-8.x, lots. bind-9.x, none.

> >> 80/tcp openhttp
> >> 110/tcpopenpop-3
> >> 111/tcpopensunrpc
> >
> >Portmapper (111) is an absolute liability - I flatly refuse to run it on
> >any public-facing box, and it must *never* be externally visible.
> 
> *tears rolling* I would like to mount the three partitions where I keep
> my web pages over NFS, but my server and I will be on different networks.
> But OK I installed harden-servers.

You might be better off with `rsync -e ssh' and passphraseless keys,
depending on exactly how immediate you want change notifications to
propogate. 

You should definitely consider the relationship between your servers in the
firewall design - at the very least I'd say portmap+nfs is permitted *IFF*
you firewall down to the two machines. But preferably, don't do it at all.

> >> 137/tcpfilterednetbios-ns
> >> 138/tcpfilterednetbios-dgm
> >> 139/tcpfilterednetbios-ssn
> >
> >You're running samba then?
> 
> No, it was installed in tasksel IIRC, I thought I removed it, but
> apparently not. I removed samba, but they didn't disappear, something
> more I have to do?

If you were running samba out of xinetd, you'll probably want to disable
the relevant services in /etc/xinetd.conf (and reload xinetd).

> >> 6346/tcp   filteredgnutella
> >
> >Hang around, it's "filtered"? That means it never replied to nmap but
> >there were other ports that did - the mixture of responses means nmap
> >"knows" this port is dropping responses.
> 
> It does? 

Yes. 

> >I think you have an anomaly, myself.
> 
> OK.

You might want to check for a firewall between your workstation and the
server in question dropping port 6346 specifically - in fact, if you really
want to be sure, run tcpdump on the server while you nmap it for
-p6345-6347 (a range crossing the port in question) and see if port 6346 is
scanned at all - if not, it's an outgoing firewall getting in your way :)

> >> Uh, don't think so. I installed snort, but didn't take the time to
> >> play with it. I thought that would do the job too... Can I get the
> >> required information from the snort install...?
> >
> >Nope, snort is for dynamic logs of dodgy packets going by. 
> 
> I see. 

... you can log the results into mysql and run _Acid_ against it, too. That
generates pretty-picture html overviews and stuff.

> >> What could be wrong about e.g.:
> >>ForwardX11 yes
> >
> >Erm, that's a little bit weird. 
> >
> > | StrictModes yes
> > | X11Forwarding yes
> > | X11DisplayOffset 10
> > | AllowTcpForwarding yes
> >
> >I think you're somehow using an old sshd_config with a proto2-enabled sshd.
> >Or a non-free ssh against openssh. Possibly.
> 
> Eh, Berend pointed out to me that I was making sshd read ssh_config...
> That could be it, but I have been messing a bit with it, so there could
> be more.

That would also explain it :8)

> >You should keep an eye the incoming/outgoing traffic, though; I thought
> >I saw a utility for analysing how many hosts/ports a box contacts over
> >time recently, which will help.
> 
> OK, I'll search.

Well if nothing else, you can use _iptraf_ in per-port summary mode :)

> >Set up snort and AIDE as a matter of urgency too
> 
> They're up. AIDE looked easy to configure, apt seemed to do that. 

Choose what hashes you maintain for which directory very carefully. I have
separate settings for:

=/boot$ Binlib
# Binaries
/bin Binlib
/sbin Binlib
/usr/bin Binlib
/usr/sbin Binlib
/usr/local/bin Binlib
/usr/local/sbin Binlib
/usr/games Binlib
# Libraries
/lib Binlib
/usr/lib Binlib
/usr/local/lib Binlib
# Log files
/var/log$ StaticDir
/var/log/aide/aide.log(.[0-9])?(.gz)? Databases
/var/log/aide/error.log(.[0-9])?(.gz)? Databases
/var/log/setuid.changes(.[0-9])?(.gz)? Databases
/var/log Logs
!/var/log/snort
# Devices
!/dev/pts
/dev Devices
# Other miscellaneous files
/var/run$ StaticDir
!/var/run

if it helps :)

> >and dns dangling around all over the place, nor will you be aware what's
> >going off if you don't start firewalling things properly and keep a

Re: Uh-oh. Cracked allready. I think...

[Kjetil Kjernsmo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Tim, dear all,

Thanks for all the responses.

I realize it's pretty bold trying put a box on the net without having
extensive admin experience beforehand. But I think I'm learning fast, and
I hope I'll be able to do it without placing any burden on the rest of the
net. That is, except for you guys... :-) Your help is greatly appreciated!

On 23 May 2002, Tim Haynes wrote:

>Kjetil Kjernsmo <[EMAIL PROTECTED]> writes:
>
>> To address this first: It is the gnutella server that causes alarm, so is
>> there anything I could have done that would install gnutella but escape
>> my attention? I certainly never did apt-get install gnutella (I tried
>> apt-get remove gnutella yesterday, with no effect). Is it likely that if
>> I don't know how it got there, has been installed by a cracker? I've
>> tried to telnet 217.77.32.186 6346 but get no connection.
>
>Well if something's got on there that you don't remember installing, can I
>have some of what you're taking? ;)

Hehe... I was so sure it would be at least one copy of Star Wars II,
but no... ;-) There's nothing here... I've walked through the whole disk,
and I can't find anything of any size that I don't know what is. Whatever
it is, it has to be rather small... 

>It's at this point that you should start debugging what's really listening
>on your box from what a scanner says you are. I suggest you nmap yourself
>to see what ports you really have open, and compare against
>netstat -plant | grep LIST
>(here's your first potential clue: if netstat complains about `-p', it's
>been trojanned.)

It complained about -p when I wasn't root...

OK. This is what nmap says, launched from my workstation:
Port   State   Service
22/tcp openssh
25/tcp opensmtp
53/tcp opendomain
80/tcp openhttp
110/tcpopenpop-3
111/tcpopensunrpc
137/tcpfilterednetbios-ns
138/tcpfilterednetbios-dgm
139/tcpfilterednetbios-ssn
1024/tcp   openkdm
1025/tcp   openlisten
6346/tcp   filteredgnutella

Whereas this is nmap from the machine itself:
[EMAIL PROTECTED]:~$ nmap pooh

Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )
Warning:  You are not root -- using TCP pingscan rather than ICMP
Interesting ports on pooh.kjernsmo.net (217.77.32.186):
(The 1545 ports scanned but not shown below are in state: closed)
Port   State   Service
22/tcp openssh
25/tcp opensmtp
53/tcp opendomain
80/tcp openhttp
110/tcpopenpop-3
111/tcpopensunrpc
139/tcpopennetbios-ssn
1024/tcp   openkdm
1025/tcp   openlisten

So, the suspicious gnutella port isn't in the latter. I don't know what
kdm is doing there, BTW. I unselected X and desktop in the initial
tasksel. There seems to have been installed some X stuff nevertheless, but
neither KDE nor kdm has ever been installed on this box. 

So for netstat:
pooh:~# netstat -plant | grep LIST
tcp0  0 0.0.0.0:10240.0.0.0:* LISTEN 
209/rpc.statd
tcp0  0 0.0.0.0:10250.0.0.0:* LISTEN 
236/rpc.mountd
tcp0  0 0.0.0.0:139 0.0.0.0:* LISTEN 218/inetd
tcp0  0 0.0.0.0:110 0.0.0.0:* LISTEN 218/inetd
tcp0  0 0.0.0.0:111 0.0.0.0:* LISTEN 123/portmap
tcp0  0 0.0.0.0:80  0.0.0.0:* LISTEN 6586/apache
tcp0  0 217.77.32.186:530.0.0.0:* LISTEN 194/named
tcp0  0 127.0.0.1:530.0.0.0:* LISTEN 194/named
tcp0  0 0.0.0.0:22  0.0.0.0:* LISTEN 285/sshd
tcp0  0 127.0.0.1:953   0.0.0.0:* LISTEN 201/lwresd
tcp0  0 0.0.0.0:25  0.0.0.0:* LISTEN 218/inetd

(slightly reformatted to fit better)

>Next, if you've got a socket listener or 6346 (IIRC, the most frequently
>used gnutella port), try telnetting into it and see what banner, if any, it
>presents.

Nope, nothing... 
pooh:~# telnet 217.77.32.186 6346
Trying 217.77.32.186...
telnet: Unable to connect to remote host: Connection refused
to be sure. 

>At some stage you should probably run _chkrootkit_ on the blighter, too.

Yeah, I've done that several times. chkrootkit was described in "Securing
Debian", so I installed it before moving it, but only ran it just after I
saw the gnutella port. Nothing detected. 

>Do you have an original AIDE database from immediately after it was
>installed?

Uh, don't think so. I installed snort, but didn't take the time to play
with it. I thought that would do the job too... Can I get the required
information from the snort install...? 

>> I tried to set the suggested PermitRootLogin for ssh to no,
>> but ssh gave me some messsage that I thought meant it did't recognize it.
>
>That's 

Re: Uh-oh. Cracked allready. I think...

[Kjetil Kjernsmo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 24 May 2002, Tim Haynes wrote:

>Unfortunately, the only way to examine all the files on the disk/s is to
>reboot the box off clean r/o media (read: rescue CD), mount them r/o, and
>examine them by hand.

Yeah, I guess so.

>You're highly unlikely to find something with trojanned binaries and/or a
>kernel module sitting there intercepting syscalls saying "we're not
>listening on port " and "oh look, an exec() call to ps, use ps.fake
>instead" - all 3 of which are possible these days.

Hehe.

>Nah, when you're root if the option completely isn't understood then you've
>got problems. (I mention this only because it was the first thing that gave
>a cracked box away to me.)

Good! :-)

>> OK. This is what nmap says, launched from my workstation:
>> Port   State   Service
>> 22/tcp openssh
>> 25/tcp opensmtp
>
>These are generally safe - especially in Testing.

Good.

>> 53/tcp opendomain
>
>OK, what version of what are you running for this?

According to Nessus:
"The remote bind version is : 9.2.0"
But I guess this need not be accessible from the outside. I'm not running
a name server myself (though I plan to some time...)

>> 80/tcp openhttp
>> 110/tcpopenpop-3
>> 111/tcpopensunrpc
>
>Portmapper (111) is an absolute liability - I flatly refuse to run it on
>any public-facing box, and it must *never* be externally visible.

*tears rolling* I would like to mount the three partitions where I keep my
web pages over NFS, but my server and I will be on different networks. But
OK I installed harden-servers.

>> 137/tcpfilterednetbios-ns
>> 138/tcpfilterednetbios-dgm
>> 139/tcpfilterednetbios-ssn
>
>You're running samba then?

No, it was installed in tasksel IIRC, I thought I removed it, but
apparently not. I removed samba, but they didn't disappear, something more
I have to do?

>> 6346/tcp   filteredgnutella
>
>Hang around, it's "filtered"? That means it never replied to nmap but there
>were other ports that did - the mixture of responses means nmap "knows"
>this port is dropping responses.

It does? 

>I think you have an anomaly, myself.

OK.

>> So, the suspicious gnutella port isn't in the latter. I don't know what
>> kdm is doing there, BTW. I unselected X and desktop in the initial
>> tasksel. There seems to have been installed some X stuff nevertheless,
>> but neither KDE nor kdm has ever been installed on this box.
>
>Ah, good you said that. It's not "kdm" necessarily, it's because it's the
>first port to which a non-privileged app may bind, >=1024. (See why the
>next one is 1025...)

I see. I also got a private response from Berend De Schouwer who explained
this. 

>I'd not worry about that lot myself. Unless I've missed something, it's not
>obviously different from the nmap results, is it?

Not that I can tell.

>> >Next, if you've got a socket listener or 6346 (IIRC, the most frequently
>> >used gnutella port), try telnetting into it and see what banner, if any,
>> >it presents.
>> 
>> Nope, nothing... 
>> pooh:~# telnet 217.77.32.186 6346
>> Trying 217.77.32.186...
>> telnet: Unable to connect to remote host: Connection refused
>> to be sure. 
>
>That's promising. 

Good.

>And it didn't turn up in netstat, just when you used a
>particular box to do the nmap?

Right.

>Does the port come and go over time at all?

Doesn't seem like it.

>> Yeah, I've done that several times. chkrootkit was described in "Securing
>> Debian", so I installed it before moving it, but only ran it just after I
>> saw the gnutella port. Nothing detected.
>
>OK. It's not a complete guarantee as it uses potentially-tainted tools, but
>it pushes the odds more in your favour.

Good.

>> >Do you have an original AIDE database from immediately after it was
>> >installed?
>> 
>> Uh, don't think so. I installed snort, but didn't take the time to play
>> with it. I thought that would do the job too... Can I get the required
>> information from the snort install...?
>
>Nope, snort is for dynamic logs of dodgy packets going by. 

I see. 

>AIDE is like
>tripwire - stores a database of crypto hashes for files in the filesystem,
>so you compare the database nightly and see what's changed of interest.

Yep, I installed it just after your last e-mail. Also installed
harden-environment. 

>> What could be wrong about e.g.:
>>ForwardX11 yes
>
>Erm, that's a little bit weird. 
>
> | StrictModes yes
> | X11Forwarding yes
> | X11DisplayOffset 10
> | AllowTcpForwarding yes
>
>I think you're somehow using an old sshd_config with a proto2-enabled sshd.
>Or a non-free ssh against openssh. Possibly.

Eh, Berend pointed out to me that I was making sshd read ssh_config...
That could be it, but I have been messing a bit with it, so there could be
more. 

>Good. OK, in that case, you might want to double-check a few others as
>well:
>
> | c29daf1d9fe836053e9f4f0a67a7a94e  /usr/sbin/chkroo

Re: Uh-oh. Cracked allready. I think...

[Tim Haynes]

Kjetil Kjernsmo <[EMAIL PROTECTED]> writes:

> Thanks for all the responses.
> 
> I realize it's pretty bold trying put a box on the net without having
> extensive admin experience beforehand. But I think I'm learning fast, and
> I hope I'll be able to do it without placing any burden on the rest of
> the net. That is, except for you guys... :-) Your help is greatly
> appreciated!

We do our best :)

> >Well if something's got on there that you don't remember installing, can
> >I have some of what you're taking? ;)
> 
> Hehe... I was so sure it would be at least one copy of Star Wars II,
> but no... ;-) There's nothing here... I've walked through the whole disk,
> and I can't find anything of any size that I don't know what is. Whatever
> it is, it has to be rather small...

Unfortunately, the only way to examine all the files on the disk/s is to
reboot the box off clean r/o media (read: rescue CD), mount them r/o, and
examine them by hand.

You're highly unlikely to find something with trojanned binaries and/or a
kernel module sitting there intercepting syscalls saying "we're not
listening on port " and "oh look, an exec() call to ps, use ps.fake
instead" - all 3 of which are possible these days.

> >It's at this point that you should start debugging what's really
> >listening on your box from what a scanner says you are. I suggest you
> >nmap yourself to see what ports you really have open, and compare
> >against
> >netstat -plant | grep LIST
> >(here's your first potential clue: if netstat complains about `-p', it's
> >been trojanned.)
> 
> It complained about -p when I wasn't root...

Nah, when you're root if the option completely isn't understood then you've
got problems. (I mention this only because it was the first thing that gave
a cracked box away to me.)

> OK. This is what nmap says, launched from my workstation:
> Port   State   Service
> 22/tcp openssh
> 25/tcp opensmtp

These are generally safe - especially in Testing.

> 53/tcp opendomain

OK, what version of what are you running for this?

> 80/tcp openhttp
> 110/tcpopenpop-3
> 111/tcpopensunrpc

Portmapper (111) is an absolute liability - I flatly refuse to run it on
any public-facing box, and it must *never* be externally visible.

> 137/tcpfilterednetbios-ns
> 138/tcpfilterednetbios-dgm
> 139/tcpfilterednetbios-ssn

You're running samba then?

> 6346/tcp   filteredgnutella

Hang around, it's "filtered"? That means it never replied to nmap but there
were other ports that did - the mixture of responses means nmap "knows"
this port is dropping responses.

I think you have an anomaly, myself.

> So, the suspicious gnutella port isn't in the latter. I don't know what
> kdm is doing there, BTW. I unselected X and desktop in the initial
> tasksel. There seems to have been installed some X stuff nevertheless,
> but neither KDE nor kdm has ever been installed on this box.

Ah, good you said that. It's not "kdm" necessarily, it's because it's the
first port to which a non-privileged app may bind, >=1024. (See why the
next one is 1025...)

> So for netstat:
> pooh:~# netstat -plant | grep LIST
> tcp   0 0.0.0.0:10240.0.0.0:* LISTEN 209/rpc.statd
> tcp   0 0.0.0.0:10250.0.0.0:* LISTEN 236/rpc.mountd
> tcp   0 0.0.0.0:139 0.0.0.0:* LISTEN 218/inetd
> tcp   0 0.0.0.0:110 0.0.0.0:* LISTEN 218/inetd
> tcp   0 0.0.0.0:111 0.0.0.0:* LISTEN 123/portmap
> tcp   0 0.0.0.0:80  0.0.0.0:* LISTEN 6586/apache
> tcp   0 217.77.32.186:530.0.0.0:* LISTEN 194/named
> tcp   0 127.0.0.1:530.0.0.0:* LISTEN 194/named
> tcp   0 0.0.0.0:22  0.0.0.0:* LISTEN 285/sshd
> tcp   0 127.0.0.1:953   0.0.0.0:* LISTEN 201/lwresd
> tcp   0 0.0.0.0:25  0.0.0.0:* LISTEN 218/inetd
> 
> (slightly reformatted to fit better)

(reformatted better still ;)

I'd not worry about that lot myself. Unless I've missed something, it's not
obviously different from the nmap results, is it?

> >Next, if you've got a socket listener or 6346 (IIRC, the most frequently
> >used gnutella port), try telnetting into it and see what banner, if any,
> >it presents.
> 
> Nope, nothing... 
> pooh:~# telnet 217.77.32.186 6346
> Trying 217.77.32.186...
> telnet: Unable to connect to remote host: Connection refused
> to be sure. 

That's promising. And it didn't turn up in netstat, just when you used a
particular box to do the nmap?

Does the port come and go over time at all?

> >At some stage you should probably run _chkrootkit_ on the blighter, too.
> 
> Yeah, I've done that several times. chkrootkit was described in "Securing
> Debian", so I installed it before moving it, but only ran it just after I
> saw the gnutella port. Nothing detected.

OK. It's not a complete guarantee as it uses potentially-tainted tools, but
it pu

Re: Uh-oh. Cracked allready. I think...

[Kjetil Kjernsmo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Tim, dear all,

Thanks for all the responses.

I realize it's pretty bold trying put a box on the net without having
extensive admin experience beforehand. But I think I'm learning fast, and
I hope I'll be able to do it without placing any burden on the rest of the
net. That is, except for you guys... :-) Your help is greatly appreciated!

On 23 May 2002, Tim Haynes wrote:

>Kjetil Kjernsmo <[EMAIL PROTECTED]> writes:
>
>> To address this first: It is the gnutella server that causes alarm, so is
>> there anything I could have done that would install gnutella but escape
>> my attention? I certainly never did apt-get install gnutella (I tried
>> apt-get remove gnutella yesterday, with no effect). Is it likely that if
>> I don't know how it got there, has been installed by a cracker? I've
>> tried to telnet 217.77.32.186 6346 but get no connection.
>
>Well if something's got on there that you don't remember installing, can I
>have some of what you're taking? ;)

Hehe... I was so sure it would be at least one copy of Star Wars II,
but no... ;-) There's nothing here... I've walked through the whole disk,
and I can't find anything of any size that I don't know what is. Whatever
it is, it has to be rather small... 

>It's at this point that you should start debugging what's really listening
>on your box from what a scanner says you are. I suggest you nmap yourself
>to see what ports you really have open, and compare against
>netstat -plant | grep LIST
>(here's your first potential clue: if netstat complains about `-p', it's
>been trojanned.)

It complained about -p when I wasn't root...

OK. This is what nmap says, launched from my workstation:
Port   State   Service
22/tcp openssh
25/tcp opensmtp
53/tcp opendomain
80/tcp openhttp
110/tcpopenpop-3
111/tcpopensunrpc
137/tcpfilterednetbios-ns
138/tcpfilterednetbios-dgm
139/tcpfilterednetbios-ssn
1024/tcp   openkdm
1025/tcp   openlisten
6346/tcp   filteredgnutella

Whereas this is nmap from the machine itself:
kjetil@pooh:~$ nmap pooh

Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )
Warning:  You are not root -- using TCP pingscan rather than ICMP
Interesting ports on pooh.kjernsmo.net (217.77.32.186):
(The 1545 ports scanned but not shown below are in state: closed)
Port   State   Service
22/tcp openssh
25/tcp opensmtp
53/tcp opendomain
80/tcp openhttp
110/tcpopenpop-3
111/tcpopensunrpc
139/tcpopennetbios-ssn
1024/tcp   openkdm
1025/tcp   openlisten

So, the suspicious gnutella port isn't in the latter. I don't know what
kdm is doing there, BTW. I unselected X and desktop in the initial
tasksel. There seems to have been installed some X stuff nevertheless, but
neither KDE nor kdm has ever been installed on this box. 

So for netstat:
pooh:~# netstat -plant | grep LIST
tcp0  0 0.0.0.0:10240.0.0.0:* LISTEN 209/rpc.statd
tcp0  0 0.0.0.0:10250.0.0.0:* LISTEN 236/rpc.mountd
tcp0  0 0.0.0.0:139 0.0.0.0:* LISTEN 218/inetd
tcp0  0 0.0.0.0:110 0.0.0.0:* LISTEN 218/inetd
tcp0  0 0.0.0.0:111 0.0.0.0:* LISTEN 123/portmap
tcp0  0 0.0.0.0:80  0.0.0.0:* LISTEN 6586/apache
tcp0  0 217.77.32.186:530.0.0.0:* LISTEN 194/named
tcp0  0 127.0.0.1:530.0.0.0:* LISTEN 194/named
tcp0  0 0.0.0.0:22  0.0.0.0:* LISTEN 285/sshd
tcp0  0 127.0.0.1:953   0.0.0.0:* LISTEN 201/lwresd
tcp0  0 0.0.0.0:25  0.0.0.0:* LISTEN 218/inetd

(slightly reformatted to fit better)

>Next, if you've got a socket listener or 6346 (IIRC, the most frequently
>used gnutella port), try telnetting into it and see what banner, if any, it
>presents.

Nope, nothing... 
pooh:~# telnet 217.77.32.186 6346
Trying 217.77.32.186...
telnet: Unable to connect to remote host: Connection refused
to be sure. 

>At some stage you should probably run _chkrootkit_ on the blighter, too.

Yeah, I've done that several times. chkrootkit was described in "Securing
Debian", so I installed it before moving it, but only ran it just after I
saw the gnutella port. Nothing detected. 

>Do you have an original AIDE database from immediately after it was
>installed?

Uh, don't think so. I installed snort, but didn't take the time to play
with it. I thought that would do the job too... Can I get the required
information from the snort install...? 

>> I tried to set the suggested PermitRootLogin for ssh to no,
>> but ssh gave me some messsage that I thought meant it did't recognize it.
>
>That's weird. 

Re: Uh-oh. Cracked allready. I think...

[Steve Meyer]

There is a good chance if you have been rooted, that the attacker installed 
a rootkit to cover his tracks.  I saw a good rootkit detecter on  
http://freshmeat.net/ .  Just do a search for it on there.




From: Tim Haynes <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: Kjetil Kjernsmo <[EMAIL PROTECTED]>
CC: debian-security@lists.debian.org
Subject: Re: Uh-oh. Cracked allready. I think...
Date: 23 May 2002 17:11:26 +0100
MIME-Version: 1.0
Received: from murphy.debian.org ([65.125.64.134]) by hotmail.com with 
Microsoft SMTPSVC(5.0.2195.4905); Thu, 23 May 2002 09:58:49 -0700

Received: (qmail 17912 invoked by uid 38); 23 May 2002 16:11:56 -
Received: (qmail 17654 invoked from network); 23 May 2002 16:11:41 -
Received: from potato.vegetable.org.uk (195.149.39.120)  by 
murphy.debian.org with SMTP; 23 May 2002 16:11:41 -
Received: from piglet by potato.vegetable.org.uk with local (Exim 3.35 #1 
(Debian))id 17AvBW-oa-00; Thu, 23 May 2002 17:11:26 +0100

X-Envelope-Sender: [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Lines: 78
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
X-Spam-Status: No, hits=-2.0 required=4.7 tests=IN_REP_TO version=2.01
Resent-Message-ID: <[EMAIL PROTECTED]>
Resent-From: debian-security@lists.debian.org
X-Mailing-List:  archive/latest/7361
X-Loop: debian-security@lists.debian.org
List-Post: <mailto:debian-security@lists.debian.org>
List-Help: <mailto:[EMAIL PROTECTED]>
List-Subscribe: 
<mailto:[EMAIL PROTECTED]>
List-Unsubscribe: 
<mailto:[EMAIL PROTECTED]>

Precedence: list
Resent-Sender: [EMAIL PROTECTED]
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 23 May 2002 16:58:49.0697 (UTC) 
FILETIME=[1C308510:01C2027B]


Kjetil Kjernsmo <[EMAIL PROTECTED]> writes:

> To address this first: It is the gnutella server that causes alarm, so 
is

> there anything I could have done that would install gnutella but escape
> my attention? I certainly never did apt-get install gnutella (I tried
> apt-get remove gnutella yesterday, with no effect). Is it likely that if
> I don't know how it got there, has been installed by a cracker? I've
> tried to telnet 217.77.32.186 6346 but get no connection.

Well if something's got on there that you don't remember installing, can I
have some of what you're taking? ;)

It's at this point that you should start debugging what's really listening
on your box from what a scanner says you are. I suggest you nmap yourself
to see what ports you really have open, and compare against
netstat -plant | grep LIST
(here's your first potential clue: if netstat complains about `-p', it's
been trojanned.)

Next, if you've got a socket listener or 6346 (IIRC, the most frequently
used gnutella port), try telnetting into it and see what banner, if any, it
presents.

At some stage you should probably run _chkrootkit_ on the blighter, too.

Do you have an original AIDE database from immediately after it was
installed?

> I tried to set the suggested PermitRootLogin for ssh to no,
> but ssh gave me some messsage that I thought meant it did't recognize 
it.


That's weird. Try running an sshd from a terminal, to read /etc/ssh/*, and
see if you get any syntax errors there.

Here's another idea:

 | zsh/scr, potato  5:03PM piglet % md5sum /var/cache/apt/archives/*ssh*
 | /usr/sbin/sshd
 | 0c1ef2fb11aa02a3b6af95157038e71b  ssh_1%3a3.0.2p1-9_i386.deb
 | a68ece0b46d2f42b655d0bf6434c317a  /usr/sbin/sshd

> I complied in IPtables in the kernel, but I haven't read up
> on how to use it. I have also installed some of the harden packages.

> Last night, I thought my system was running quite well, though I had
> noticed gnutella running. I figured it was time to run nessus, so I did.
> It seems to report many holes, some holes that I guess would be
> exploitable. I put the report on  http://www.astro.uio.no/~kjetikj/tmp/pooh-nessus-2002-22-05.html >

Bear in mind two things:

a) Debian apply patches in stable as/when required, we don't follow
   upstream version#s regardlessly

b) testing is a strange halfway-house between stable and unstable; you can
   expect a security fix to make it into Unstable pretty soon (as it 
tracks

   upstream versions) but it'll be at least a fortnight after that it hits
   Testing.

That said, you probably want to check the Changelog(.Debian.gz) for ssh -
I'd be surprised if the patches required hadn't made it down into Testing.

> If it has been cracked, what should I do? I could run up to my hosts and
> have them turn it off, I guess. But then what? I have really no clue 
what

> happened, and while I could turn off some more services, it seems like
> the biggest security problems are with ssh and

Re: Uh-oh. Cracked allready. I think...

[Steve Meyer]

There is a good chance if you have been rooted, that the attacker installed 
a rootkit to cover his tracks.  I saw a good rootkit detecter on  
http://freshmeat.net/ .  Just do a search for it on there.


>From: Tim Haynes <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: Kjetil Kjernsmo <[EMAIL PROTECTED]>
>CC: [EMAIL PROTECTED]
>Subject: Re: Uh-oh. Cracked allready. I think...
>Date: 23 May 2002 17:11:26 +0100
>MIME-Version: 1.0
>Received: from murphy.debian.org ([65.125.64.134]) by hotmail.com with 
>Microsoft SMTPSVC(5.0.2195.4905); Thu, 23 May 2002 09:58:49 -0700
>Received: (qmail 17912 invoked by uid 38); 23 May 2002 16:11:56 -
>Received: (qmail 17654 invoked from network); 23 May 2002 16:11:41 -
>Received: from potato.vegetable.org.uk (195.149.39.120)  by 
>murphy.debian.org with SMTP; 23 May 2002 16:11:41 -
>Received: from piglet by potato.vegetable.org.uk with local (Exim 3.35 #1 
>(Debian))id 17AvBW-oa-00; Thu, 23 May 2002 17:11:26 +0100
>X-Envelope-Sender: [EMAIL PROTECTED]
>Sender: [EMAIL PROTECTED]
>References: <Pine.OSF.3.96.1020523151454.501518E-10@alnair>
>In-Reply-To: <Pine.OSF.3.96.1020523151454.501518E-10@alnair>
>Message-ID: <[EMAIL PROTECTED]>
>Lines: 78
>User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
>X-Spam-Status: No, hits=-2.0 required=4.7 tests=IN_REP_TO version=2.01
>Resent-Message-ID: 
>Resent-From: [EMAIL PROTECTED]
>X-Mailing-List: <[EMAIL PROTECTED]> archive/latest/7361
>X-Loop: [EMAIL PROTECTED]
>List-Post: <mailto:[EMAIL PROTECTED]>
>List-Help: <mailto:[EMAIL PROTECTED]?subject=help>
>List-Subscribe: 
><mailto:[EMAIL PROTECTED]?subject=subscribe>
>List-Unsubscribe: 
><mailto:[EMAIL PROTECTED]?subject=unsubscribe>
>Precedence: list
>Resent-Sender: [EMAIL PROTECTED]
>Return-Path: [EMAIL PROTECTED]
>X-OriginalArrivalTime: 23 May 2002 16:58:49.0697 (UTC) 
>FILETIME=[1C308510:01C2027B]
>
>Kjetil Kjernsmo <[EMAIL PROTECTED]> writes:
>
> > To address this first: It is the gnutella server that causes alarm, so 
>is
> > there anything I could have done that would install gnutella but escape
> > my attention? I certainly never did apt-get install gnutella (I tried
> > apt-get remove gnutella yesterday, with no effect). Is it likely that if
> > I don't know how it got there, has been installed by a cracker? I've
> > tried to telnet 217.77.32.186 6346 but get no connection.
>
>Well if something's got on there that you don't remember installing, can I
>have some of what you're taking? ;)
>
>It's at this point that you should start debugging what's really listening
>on your box from what a scanner says you are. I suggest you nmap yourself
>to see what ports you really have open, and compare against
> netstat -plant | grep LIST
>(here's your first potential clue: if netstat complains about `-p', it's
>been trojanned.)
>
>Next, if you've got a socket listener or 6346 (IIRC, the most frequently
>used gnutella port), try telnetting into it and see what banner, if any, it
>presents.
>
>At some stage you should probably run _chkrootkit_ on the blighter, too.
>
>Do you have an original AIDE database from immediately after it was
>installed?
>
> > I tried to set the suggested PermitRootLogin for ssh to no,
> > but ssh gave me some messsage that I thought meant it did't recognize 
>it.
>
>That's weird. Try running an sshd from a terminal, to read /etc/ssh/*, and
>see if you get any syntax errors there.
>
>Here's another idea:
>
>  | zsh/scr, potato  5:03PM piglet % md5sum /var/cache/apt/archives/*ssh*
>  | /usr/sbin/sshd
>  | 0c1ef2fb11aa02a3b6af95157038e71b  ssh_1%3a3.0.2p1-9_i386.deb
>  | a68ece0b46d2f42b655d0bf6434c317a  /usr/sbin/sshd
>
> > I complied in IPtables in the kernel, but I haven't read up
> > on how to use it. I have also installed some of the harden packages.
>
> > Last night, I thought my system was running quite well, though I had
> > noticed gnutella running. I figured it was time to run nessus, so I did.
> > It seems to report many holes, some holes that I guess would be
> > exploitable. I put the report on  > http://www.astro.uio.no/~kjetikj/tmp/pooh-nessus-2002-22-05.html >
>
>Bear in mind two things:
>
>a) Debian apply patches in stable as/when required, we don't follow
>upstream version#s regardlessly
>
>b) testing is a strange halfway-house between stable and unstable; you can
>expect a security fix to make it into Unstable pretty soon (as it 
>tracks
>upstream versions) but it'll be at least a fortnight aft

Re: Uh-oh. Cracked allready. I think...

[Noah L. Meyerhans]

On Thu, May 23, 2002 at 01:39:25PM -0400, Hubert Chan wrote:
> Security patches go into stable first.  Sid/unstable is generally
> upgraded pretty promptly too.  They're working on a system (AFAIK) to
> allow security patches to be fast tracked into testing.

Not to be fast tracked in to testing.  To be fast tracked in to woody,
which will soon be stable.  Packages going in to testing still need to
go through the requisite test period.  They can be uploaded with a
higher priority, which will (in theory) get them in to testing sooner,
but not if a critical bug is filed against the new version or something
that keeps it out.  It's conceivable that testing won't get the security
fix at all until it approaches release time.  In reality, the community
wouldn't let that happen, but I don't recommend relying on that for a
critical system.

noah

-- 
 ___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html 


pgpUmpoEUjSqj.pgp
Description: PGP signature

Re: Uh-oh. Cracked allready. I think...

[Hubert Chan]

> "John" == John  <[EMAIL PROTECTED]> writes:

John> Woody ahh woody. It's always been told to me (by someone who's
John> even on this list and on the debian security team) that 'Potato'
John> should be the only thing that's really trusted ("trusted") for
John> security in Debian.  It's supposed to get security updates
John> first. Arguments of the debian release system aside, that's the
John> general plan of debian it seems. You shouldn't have used woody for
John> a remote box.

Security patches go into stable first.  Sid/unstable is generally
upgraded pretty promptly too.  They're working on a system (AFAIK) to
allow security patches to be fast tracked into testing.

[...]

>> -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (OSF1) Comment:
>> For info see http://www.gnupg.org
>> iD8DBQE87QV/lE/Gp2pqC7wRAnOwAKClkxaNInxG+/59Z+67CmyY6vzJyQCgmHl5
>> dXGHMoenwxKHE2bQZQWI308= =VSU4 -END PGP SIGNATURE-

John> Oh, and you'll want to revoke your PGP key if it was on this box,
John> as you can't trust your PGP keys anymore either.

Unless it was password protected.  (With a secure password.)

-- 
Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.


pgpqQswD7LTpW.pgp
Description: PGP signature

Re: Uh-oh. Cracked allready. I think...

[John]

Unfortunately, this reply will be a lot of 'should haves'. There's not
much you can do after the fact. 

On Thu, May 23, 2002 at 05:06:23PM +0200, Kjetil Kjernsmo wrote:
> -BEGIN PGP SIGNED MESSAGE-
--snip--
> The story is that I installed Woody on three boxes, two workstations, and
> a server, starting at the beginning of may, using my old University
> network and installing most of it from network. I read most of "Securing
> Debian Manual". I disregarded most of the stuff that had to do with people
> having physical access to the box, that shouldn't represent a threat. I
> disabled everything that had to do with cleartext passwords. I must admit
> that I left fingerd, and that I export some NFS-things. 

Woody ahh woody. It's always been told to me (by someone who's even
on this list and on the debian security team) that 'Potato' should be
the only thing that's really trusted ("trusted") for security in Debian.
It's supposed to get security updates first. Arguments of the debian
release system aside, that's the general plan of debian it seems. You
shouldn't have used woody for a remote box. 

> 
> Last night, I thought my system was running quite well, though I had
> noticed gnutella running. I figured it was time to run nessus, so I did. 
> It seems to report many holes, some holes that I guess would be
> exploitable. I put the report on 
> http://www.astro.uio.no/~kjetikj/tmp/pooh-nessus-2002-22-05.html >
> 

Great. And how does this compare to the baseline nessus you ran before
you made the box totally public? Or didn't you run it to start with? 

> If it has been cracked, what should I do? I could run up to my hosts and
> have them turn it off, I guess. But then what? I have really no clue what
> happened, and while I could turn off some more services, it seems like the
> biggest security problems are with ssh and smtp, that is, OpenSSH and
> Exim, so would a clean reinstall help a lot? 

Try installing chkrootkit. I'm not sure if it's apt-getable. If it
isn't, install it from source. And even then, if you think it's been
cracked, it probably was. However, talk to all your users and see what
they say. I assume this is a 'friends access' type box. How well do you
know all these friends? Have you met them all IRL? 

If your box has been cracked, the only real solution is to reinstall it.
Have your host shut it off and ship it back, or go get it. Don't leave
it online. It will become a place where the crackers invite friends to
do things and a jumping off point for attacks to other networks. And you
might be held responsible by your provider. 


Test for root kits, if yes, reinstall it. Don't trust it until you do. 

> Unfortunately, I can't report a break-in to the police. The computer crime
> police here in Norway has a political agenda I despice, and I don't want
> to give them any legitimacy. 

Well, there's not much most police will do about this. Most police don't
know enough about this. (Some do! And nothing against them please, but
most police just ship out all computer crime to overloaded state crime
labs). 

> Recent astrophysics graduate  Problems worthy of attack
> University of Oslo, NorwayProve their worth by hitting back
> E-mail: [EMAIL PROTECTED]- Piet Hein
> Homepage http://folk.uio.no/kjetikj/>
> [EMAIL PROTECTED]OpenPGP KeyID: 6A6A0BBC

Hey, debian security ain't rocket science, but a rocket science degree
can't hurt  :) 

> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.0.6 (OSF1)
> Comment: For info see http://www.gnupg.org
> iD8DBQE87QV/lE/Gp2pqC7wRAnOwAKClkxaNInxG+/59Z+67CmyY6vzJyQCgmHl5
> dXGHMoenwxKHE2bQZQWI308=
> =VSU4
> -END PGP SIGNATURE-

Oh, and you'll want to revoke your PGP key if it was on this box, as you
can't trust your PGP keys anymore either. If you go around with this
same key and your private key was on a hacked box, that's bad. 


Best of luck.


j


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Uh-oh. Cracked allready. I think...

[Tim Haynes]

Kjetil Kjernsmo <[EMAIL PROTECTED]> writes:

> To address this first: It is the gnutella server that causes alarm, so is
> there anything I could have done that would install gnutella but escape
> my attention? I certainly never did apt-get install gnutella (I tried
> apt-get remove gnutella yesterday, with no effect). Is it likely that if
> I don't know how it got there, has been installed by a cracker? I've
> tried to telnet 217.77.32.186 6346 but get no connection.

Well if something's got on there that you don't remember installing, can I
have some of what you're taking? ;)

It's at this point that you should start debugging what's really listening
on your box from what a scanner says you are. I suggest you nmap yourself
to see what ports you really have open, and compare against
netstat -plant | grep LIST
(here's your first potential clue: if netstat complains about `-p', it's
been trojanned.)

Next, if you've got a socket listener or 6346 (IIRC, the most frequently
used gnutella port), try telnetting into it and see what banner, if any, it
presents.

At some stage you should probably run _chkrootkit_ on the blighter, too.

Do you have an original AIDE database from immediately after it was
installed?

> I tried to set the suggested PermitRootLogin for ssh to no,
> but ssh gave me some messsage that I thought meant it did't recognize it.

That's weird. Try running an sshd from a terminal, to read /etc/ssh/*, and
see if you get any syntax errors there.

Here's another idea:

 | zsh/scr, potato  5:03PM piglet % md5sum /var/cache/apt/archives/*ssh*
 | /usr/sbin/sshd
 | 0c1ef2fb11aa02a3b6af95157038e71b  ssh_1%3a3.0.2p1-9_i386.deb
 | a68ece0b46d2f42b655d0bf6434c317a  /usr/sbin/sshd

> I complied in IPtables in the kernel, but I haven't read up
> on how to use it. I have also installed some of the harden packages.
 
> Last night, I thought my system was running quite well, though I had
> noticed gnutella running. I figured it was time to run nessus, so I did.
> It seems to report many holes, some holes that I guess would be
> exploitable. I put the report on  http://www.astro.uio.no/~kjetikj/tmp/pooh-nessus-2002-22-05.html >

Bear in mind two things:

a) Debian apply patches in stable as/when required, we don't follow
   upstream version#s regardlessly

b) testing is a strange halfway-house between stable and unstable; you can
   expect a security fix to make it into Unstable pretty soon (as it tracks
   upstream versions) but it'll be at least a fortnight after that it hits
   Testing.

That said, you probably want to check the Changelog(.Debian.gz) for ssh -
I'd be surprised if the patches required hadn't made it down into Testing.

> If it has been cracked, what should I do? I could run up to my hosts and
> have them turn it off, I guess. But then what? I have really no clue what
> happened, and while I could turn off some more services, it seems like
> the biggest security problems are with ssh and smtp, that is, OpenSSH and
> Exim, so would a clean reinstall help a lot?

.

First assess whether you really have been breached; if you have, you *must*
reformat, reinstall, update all packages, firewall, install an IDS (aide)
and nIDS (snort) - but take a forensic last-minute backup before you do.

~Tim
-- 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: Uh-oh. Cracked allready. I think...

[James]

What to do?

If you really are cracked, wipe the system and start fresh, with recent
copies of ssh and exim.

If I had to make a bet between what is listed, I'd say it was ssh
exploited, because those have been floating around for quite a while.

- James

> -Original Message-
> From: Kjetil Kjernsmo [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, May 23, 2002 11:06 AM
> To: debian-security@lists.debian.org
> Subject: Uh-oh. Cracked allready. I think...
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Dear all,
> 
> Please accept my apologies for not lurking. I got my first 
> own server box in server-hosting last week, and I thought I 
> configured it well, but it appears to be cracked allready. 
> :-( Well, I'm a real newbie, and so I'm having a steep learning curve.
> 
> At least I can't remember installing gnutella on it, yet, 
> nmap says it runs there... So I'm seeking advice. 
> 
> To address this first: It is the gnutella server that causes 
> alarm, so is there anything I could have done that would 
> install gnutella but escape my attention? I certainly never 
> did apt-get install gnutella (I tried apt-get remove gnutella 
> yesterday, with no effect). Is it likely that if I don't know 
> how it got there, has been installed by a cracker? I've tried 
> to telnet 217.77.32.186 6346 but get no connection.
> 
> The story is that I installed Woody on three boxes, two 
> workstations, and a server, starting at the beginning of may, 
> using my old University network and installing most of it 
> from network. I read most of "Securing Debian Manual". I 
> disregarded most of the stuff that had to do with people 
> having physical access to the box, that shouldn't represent a 
> threat. I disabled everything that had to do with cleartext 
> passwords. I must admit that I left fingerd, and that I 
> export some NFS-things. 
> 
> I have shadow passwords and MD5 passwords. I also have inetd. 
> I didn't really understand that much of the PAM stuff, but 
> there aren't going to be many users on this system, and all 
> users will be able to perform the same tasks. I tried to set 
> the suggested PermitRootLogin for ssh to no, but ssh gave me 
> some messsage that I thought meant it did't recognize it. 
> Besides, updating stuff would be hard so I have sshed to the 
> root account many times. I complied in IPtables in the 
> kernel, but I haven't read up on how to use it. I have also 
> installed some of the harden packages. 
> 
> Last night, I thought my system was running quite well, 
> though I had noticed gnutella running. I figured it was time 
> to run nessus, so I did. 
> It seems to report many holes, some holes that I guess would 
> be exploitable. I put the report on 
>  http://www.astro.uio.no/~kjetikj/tmp/pooh-nessus-2002-22-05.ht
ml >

I first made sure these ~/.qpopper-options wouldn't be read, so that's
taken care of. There are lots of complaints about OpenSSH there, and the
SMTP server (Exim). So, what to do about these things...?

If it has been cracked, what should I do? I could run up to my hosts and
have them turn it off, I guess. But then what? I have really no clue
what happened, and while I could turn off some more services, it seems
like the biggest security problems are with ssh and smtp, that is,
OpenSSH and Exim, so would a clean reinstall help a lot? 

Unfortunately, I can't report a break-in to the police. The computer
crime police here in Norway has a political agenda I despice, and I
don't want to give them any legitimacy. 

Best,

Kjetil
- -- 
Kjetil Kjernsmo
Recent astrophysics graduate  Problems worthy of attack
University of Oslo, NorwayProve their worth by hitting back
E-mail: [EMAIL PROTECTED]- Piet Hein
Homepage http://folk.uio.no/kjetikj/>
[EMAIL PROTECTED]OpenPGP KeyID: 6A6A0BBC




-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (OSF1)
Comment: For info see http://www.gnupg.org

iD8DBQE87QV/lE/Gp2pqC7wRAnOwAKClkxaNInxG+/59Z+67CmyY6vzJyQCgmHl5
dXGHMoenwxKHE2bQZQWI308=
=VSU4
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Uh-oh. Cracked allready. I think...

[Michal Melewski]

Hello
First, and I think most ipmortant thing would be to upgrade all
mission-critical applications you are using. For sure you have to upgrade
OpenSSH nad Exim. (run apt-setup, then apt-get update followed by apt-get
upgrade). 
Second think would be to block all unwanted connection by iptables (man
iptables could be helpfull ;) )
Securing your host is long subject... I'm not able to cover it in one e-mail
(sure no one can :) )

ps. You don't have to ssh on a root account, simply ssh on a normal account
and then invoke 'su' to get root privilages.

-- 
Michael "carstein" Melewski  |  "One day, he said, in a taped segment   
[EMAIL PROTECTED]|   that suggested chemical interrogation,
mobile: 502 545 913  |   everything had gone gray."
gpg: carstein.c.pl/carstein.txt  |   -- Corto , 'Neuromancer'


pgpM9JLAWi0QG.pgp
Description: PGP signature

Re: Uh-oh. Cracked allready. I think...

[Noah L. Meyerhans]

On Thu, May 23, 2002 at 01:39:25PM -0400, Hubert Chan wrote:
> Security patches go into stable first.  Sid/unstable is generally
> upgraded pretty promptly too.  They're working on a system (AFAIK) to
> allow security patches to be fast tracked into testing.

Not to be fast tracked in to testing.  To be fast tracked in to woody,
which will soon be stable.  Packages going in to testing still need to
go through the requisite test period.  They can be uploaded with a
higher priority, which will (in theory) get them in to testing sooner,
but not if a critical bug is filed against the new version or something
that keeps it out.  It's conceivable that testing won't get the security
fix at all until it approaches release time.  In reality, the community
wouldn't let that happen, but I don't recommend relying on that for a
critical system.

noah

-- 
 ___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html 



msg06823/pgp0.pgp
Description: PGP signature

Re: Uh-oh. Cracked allready. I think...

[Hubert Chan]

> "John" == John  <[EMAIL PROTECTED]> writes:

John> Woody ahh woody. It's always been told to me (by someone who's
John> even on this list and on the debian security team) that 'Potato'
John> should be the only thing that's really trusted ("trusted") for
John> security in Debian.  It's supposed to get security updates
John> first. Arguments of the debian release system aside, that's the
John> general plan of debian it seems. You shouldn't have used woody for
John> a remote box.

Security patches go into stable first.  Sid/unstable is generally
upgraded pretty promptly too.  They're working on a system (AFAIK) to
allow security patches to be fast tracked into testing.

[...]

>> -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (OSF1) Comment:
>> For info see http://www.gnupg.org
>> iD8DBQE87QV/lE/Gp2pqC7wRAnOwAKClkxaNInxG+/59Z+67CmyY6vzJyQCgmHl5
>> dXGHMoenwxKHE2bQZQWI308= =VSU4 -END PGP SIGNATURE-

John> Oh, and you'll want to revoke your PGP key if it was on this box,
John> as you can't trust your PGP keys anymore either.

Unless it was password protected.  (With a secure password.)

-- 
Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.



msg06822/pgp0.pgp
Description: PGP signature

Re: Uh-oh. Cracked allready. I think...

[John]

Unfortunately, this reply will be a lot of 'should haves'. There's not
much you can do after the fact. 

On Thu, May 23, 2002 at 05:06:23PM +0200, Kjetil Kjernsmo wrote:
> -BEGIN PGP SIGNED MESSAGE-
--snip--
> The story is that I installed Woody on three boxes, two workstations, and
> a server, starting at the beginning of may, using my old University
> network and installing most of it from network. I read most of "Securing
> Debian Manual". I disregarded most of the stuff that had to do with people
> having physical access to the box, that shouldn't represent a threat. I
> disabled everything that had to do with cleartext passwords. I must admit
> that I left fingerd, and that I export some NFS-things. 

Woody ahh woody. It's always been told to me (by someone who's even
on this list and on the debian security team) that 'Potato' should be
the only thing that's really trusted ("trusted") for security in Debian.
It's supposed to get security updates first. Arguments of the debian
release system aside, that's the general plan of debian it seems. You
shouldn't have used woody for a remote box. 

> 
> Last night, I thought my system was running quite well, though I had
> noticed gnutella running. I figured it was time to run nessus, so I did. 
> It seems to report many holes, some holes that I guess would be
> exploitable. I put the report on 
> http://www.astro.uio.no/~kjetikj/tmp/pooh-nessus-2002-22-05.html >
> 

Great. And how does this compare to the baseline nessus you ran before
you made the box totally public? Or didn't you run it to start with? 

> If it has been cracked, what should I do? I could run up to my hosts and
> have them turn it off, I guess. But then what? I have really no clue what
> happened, and while I could turn off some more services, it seems like the
> biggest security problems are with ssh and smtp, that is, OpenSSH and
> Exim, so would a clean reinstall help a lot? 

Try installing chkrootkit. I'm not sure if it's apt-getable. If it
isn't, install it from source. And even then, if you think it's been
cracked, it probably was. However, talk to all your users and see what
they say. I assume this is a 'friends access' type box. How well do you
know all these friends? Have you met them all IRL? 

If your box has been cracked, the only real solution is to reinstall it.
Have your host shut it off and ship it back, or go get it. Don't leave
it online. It will become a place where the crackers invite friends to
do things and a jumping off point for attacks to other networks. And you
might be held responsible by your provider. 


Test for root kits, if yes, reinstall it. Don't trust it until you do. 

> Unfortunately, I can't report a break-in to the police. The computer crime
> police here in Norway has a political agenda I despice, and I don't want
> to give them any legitimacy. 

Well, there's not much most police will do about this. Most police don't
know enough about this. (Some do! And nothing against them please, but
most police just ship out all computer crime to overloaded state crime
labs). 

> Recent astrophysics graduate  Problems worthy of attack
> University of Oslo, NorwayProve their worth by hitting back
> E-mail: [EMAIL PROTECTED]- Piet Hein
> Homepage http://folk.uio.no/kjetikj/>
> [EMAIL PROTECTED]OpenPGP KeyID: 6A6A0BBC

Hey, debian security ain't rocket science, but a rocket science degree
can't hurt  :) 

> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.0.6 (OSF1)
> Comment: For info see http://www.gnupg.org
> iD8DBQE87QV/lE/Gp2pqC7wRAnOwAKClkxaNInxG+/59Z+67CmyY6vzJyQCgmHl5
> dXGHMoenwxKHE2bQZQWI308=
> =VSU4
> -END PGP SIGNATURE-

Oh, and you'll want to revoke your PGP key if it was on this box, as you
can't trust your PGP keys anymore either. If you go around with this
same key and your private key was on a hacked box, that's bad. 


Best of luck.


j


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Uh-oh. Cracked allready. I think...

[Tim Haynes]

Kjetil Kjernsmo <[EMAIL PROTECTED]> writes:

> To address this first: It is the gnutella server that causes alarm, so is
> there anything I could have done that would install gnutella but escape
> my attention? I certainly never did apt-get install gnutella (I tried
> apt-get remove gnutella yesterday, with no effect). Is it likely that if
> I don't know how it got there, has been installed by a cracker? I've
> tried to telnet 217.77.32.186 6346 but get no connection.

Well if something's got on there that you don't remember installing, can I
have some of what you're taking? ;)

It's at this point that you should start debugging what's really listening
on your box from what a scanner says you are. I suggest you nmap yourself
to see what ports you really have open, and compare against
netstat -plant | grep LIST
(here's your first potential clue: if netstat complains about `-p', it's
been trojanned.)

Next, if you've got a socket listener or 6346 (IIRC, the most frequently
used gnutella port), try telnetting into it and see what banner, if any, it
presents.

At some stage you should probably run _chkrootkit_ on the blighter, too.

Do you have an original AIDE database from immediately after it was
installed?

> I tried to set the suggested PermitRootLogin for ssh to no,
> but ssh gave me some messsage that I thought meant it did't recognize it.

That's weird. Try running an sshd from a terminal, to read /etc/ssh/*, and
see if you get any syntax errors there.

Here's another idea:

 | zsh/scr, potato  5:03PM piglet % md5sum /var/cache/apt/archives/*ssh*
 | /usr/sbin/sshd
 | 0c1ef2fb11aa02a3b6af95157038e71b  ssh_1%3a3.0.2p1-9_i386.deb
 | a68ece0b46d2f42b655d0bf6434c317a  /usr/sbin/sshd

> I complied in IPtables in the kernel, but I haven't read up
> on how to use it. I have also installed some of the harden packages.
 
> Last night, I thought my system was running quite well, though I had
> noticed gnutella running. I figured it was time to run nessus, so I did.
> It seems to report many holes, some holes that I guess would be
> exploitable. I put the report on  http://www.astro.uio.no/~kjetikj/tmp/pooh-nessus-2002-22-05.html >

Bear in mind two things:

a) Debian apply patches in stable as/when required, we don't follow
   upstream version#s regardlessly

b) testing is a strange halfway-house between stable and unstable; you can
   expect a security fix to make it into Unstable pretty soon (as it tracks
   upstream versions) but it'll be at least a fortnight after that it hits
   Testing.

That said, you probably want to check the Changelog(.Debian.gz) for ssh -
I'd be surprised if the patches required hadn't made it down into Testing.

> If it has been cracked, what should I do? I could run up to my hosts and
> have them turn it off, I guess. But then what? I have really no clue what
> happened, and while I could turn off some more services, it seems like
> the biggest security problems are with ssh and smtp, that is, OpenSSH and
> Exim, so would a clean reinstall help a lot?

.

First assess whether you really have been breached; if you have, you *must*
reformat, reinstall, update all packages, firewall, install an IDS (aide)
and nIDS (snort) - but take a forensic last-minute backup before you do.

~Tim
-- 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: Uh-oh. Cracked allready. I think...

[James]

What to do?

If you really are cracked, wipe the system and start fresh, with recent
copies of ssh and exim.

If I had to make a bet between what is listed, I'd say it was ssh
exploited, because those have been floating around for quite a while.

- James

> -Original Message-
> From: Kjetil Kjernsmo [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, May 23, 2002 11:06 AM
> To: [EMAIL PROTECTED]
> Subject: Uh-oh. Cracked allready. I think...
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Dear all,
> 
> Please accept my apologies for not lurking. I got my first 
> own server box in server-hosting last week, and I thought I 
> configured it well, but it appears to be cracked allready. 
> :-( Well, I'm a real newbie, and so I'm having a steep learning curve.
> 
> At least I can't remember installing gnutella on it, yet, 
> nmap says it runs there... So I'm seeking advice. 
> 
> To address this first: It is the gnutella server that causes 
> alarm, so is there anything I could have done that would 
> install gnutella but escape my attention? I certainly never 
> did apt-get install gnutella (I tried apt-get remove gnutella 
> yesterday, with no effect). Is it likely that if I don't know 
> how it got there, has been installed by a cracker? I've tried 
> to telnet 217.77.32.186 6346 but get no connection.
> 
> The story is that I installed Woody on three boxes, two 
> workstations, and a server, starting at the beginning of may, 
> using my old University network and installing most of it 
> from network. I read most of "Securing Debian Manual". I 
> disregarded most of the stuff that had to do with people 
> having physical access to the box, that shouldn't represent a 
> threat. I disabled everything that had to do with cleartext 
> passwords. I must admit that I left fingerd, and that I 
> export some NFS-things. 
> 
> I have shadow passwords and MD5 passwords. I also have inetd. 
> I didn't really understand that much of the PAM stuff, but 
> there aren't going to be many users on this system, and all 
> users will be able to perform the same tasks. I tried to set 
> the suggested PermitRootLogin for ssh to no, but ssh gave me 
> some messsage that I thought meant it did't recognize it. 
> Besides, updating stuff would be hard so I have sshed to the 
> root account many times. I complied in IPtables in the 
> kernel, but I haven't read up on how to use it. I have also 
> installed some of the harden packages. 
> 
> Last night, I thought my system was running quite well, 
> though I had noticed gnutella running. I figured it was time 
> to run nessus, so I did. 
> It seems to report many holes, some holes that I guess would 
> be exploitable. I put the report on 
>  http://www.astro.uio.no/~kjetikj/tmp/pooh-nessus-2002-22-05.ht
ml >

I first made sure these ~/.qpopper-options wouldn't be read, so that's
taken care of. There are lots of complaints about OpenSSH there, and the
SMTP server (Exim). So, what to do about these things...?

If it has been cracked, what should I do? I could run up to my hosts and
have them turn it off, I guess. But then what? I have really no clue
what happened, and while I could turn off some more services, it seems
like the biggest security problems are with ssh and smtp, that is,
OpenSSH and Exim, so would a clean reinstall help a lot? 

Unfortunately, I can't report a break-in to the police. The computer
crime police here in Norway has a political agenda I despice, and I
don't want to give them any legitimacy. 

Best,

Kjetil
- -- 
Kjetil Kjernsmo
Recent astrophysics graduate  Problems worthy of attack
University of Oslo, NorwayProve their worth by hitting back
E-mail: [EMAIL PROTECTED]- Piet Hein
Homepage http://folk.uio.no/kjetikj/>
[EMAIL PROTECTED]OpenPGP KeyID: 6A6A0BBC




-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (OSF1)
Comment: For info see http://www.gnupg.org

iD8DBQE87QV/lE/Gp2pqC7wRAnOwAKClkxaNInxG+/59Z+67CmyY6vzJyQCgmHl5
dXGHMoenwxKHE2bQZQWI308=
=VSU4
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Uh-oh. Cracked allready. I think...

[Michal Melewski]

Hello
First, and I think most ipmortant thing would be to upgrade all
mission-critical applications you are using. For sure you have to upgrade
OpenSSH nad Exim. (run apt-setup, then apt-get update followed by apt-get
upgrade). 
Second think would be to block all unwanted connection by iptables (man
iptables could be helpfull ;) )
Securing your host is long subject... I'm not able to cover it in one e-mail
(sure no one can :) )

ps. You don't have to ssh on a root account, simply ssh on a normal account
and then invoke 'su' to get root privilages.

-- 
Michael "carstein" Melewski  |  "One day, he said, in a taped segment   
[EMAIL PROTECTED] |   that suggested chemical interrogation,
mobile: 502 545 913  |   everything had gone gray."
gpg: carstein.c.pl/carstein.txt  |   -- Corto , 'Neuromancer'



msg06818/pgp0.pgp
Description: PGP signature