l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2001 Dec 30 17:06

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Attempted access -- I think
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Attempted access -- I think

On Thu, 14 Jun 2001, Cam Ellison wrote:

> Thanks for the help, Jeff.
> jdnewmil@dcn.davis.ca.us wrote:
> > 
> > On Wed, 13 Jun 2001, Cam Ellison wrote:
> > 
> <snip>
> > 
> > Looks like it.
> > 
> > > >
> > > >
> > > >   ------------------------------------------------------------------------
> > > >
> > > > Jun 13 16:44:28 treehouse kernel: Packet log: eth-in DENY eth1
> > > > PROTO=17 L=328 S=0x00 I=48460
> > > > F=0x0000 T=128 (#1)
> > 
> > This is a dhcp reply (bootp). In isolation, nothing to worry about, but
> > when you consider the source address is private, it starts to look kind of
> > weird...
> I agree.  I am running dhcp, of course, but the client, not the server. 
> Should I assume that someone has been messing around in my machine, and
> that the other host is trying to re-establish connection?

I don't think so. You haven't said anything about your network connection
arrangement... cable modem?  Some ISPs use private addresses for their
internal equipment, so in the widest possible picture it is possible that
the dhcp server is legitimate.  It could also be some newbie who installed
"everything" on a new Red Hat box, too.

It could be some cracker setting themself up to hand out dhcp leases so
they can intercept communications from dhcp clients in a
"man-in-the-middle" attack.  However, if you haven't been taking
precautions like ssh until now, I can't see what benefit that would offer
them over promiscously monitoring your traffic.

> > 
> > > > Jun 13 17:08:47 treehouse kernel: Packet log: eth-in DENY eth1
> > > > PROTO=17 L=44 S=0x00 I=27137
> > > > F=0x0000 T=128 (#1)
> > 
> > ... and this is an odd one... broadcast to 5005...  examine the output of
> > "netstat -ua" to see if treehouse would have responded to this, and use
> > "lsof -i :5005" to find out which process(es) is(are) handling that port.
> > 
> Nothing is using that port.  Netstat indicates the following processes:

These are service (port) names.  AFAIK netstat doesn't tell you process

> netbios-dgm
> netbios-ns

Eeek! exposed Samba? are you blocking all tcp/udp ports 137-139 yet?

> ntalk
> talk
> discard
> sunrpc

Almost certainly want to disable these... probably in /etc/inetd.conf

> I know I did not install talk deliberately, and assume it was installed
> by the distribution I use [Debian as repackaged by Libranet].  I cannot
> see that it would have anything to do with this, however -- or am I
> wrong in assuming that?

Don't run services you don't need.  It probably wasn't installed by a
cracker, but it could have been replaced with a trojan or just have latent
security bugs.

> I did not have lsof on the system, so had to download and install it.  I
> think we can assume it is clean.  It indicates that the only specific
> ports are 6000 and 7101.

lsof tells you which programs are servicing the ports.  6000 is usually
the X server, and 7101 is often an X font server.

> There are some other odd ports in the syslog entries: 1052, 3008, 3033,
> 3829.  None of these have any referents in /etc/services


1052 ddt (dynamic dns tools)
3008 midnight technologies
3033 pdb (protein data bank?)
3829 ?

I am not familiar with any of these myself.  Depending on context, they
could simply be random ports opened by client processes on your box for
which your firewall rules stopped the return packets.

> <snip>
> > 
> > The fact that these are not directed at your ip address in particular is a
> > little comforting, but someone is playing strange games.
> > 
> Clearly.  What I am still unclear about is whether this means someone is
> trying to get accesss to my system, or more importantly, has succeeded.
> What else whould I look at?

Unfortunately, an experienced cracker can cover their tracks pretty well.
The standard recommendation is to backup everything, disconnect from the
net, reinstall all binaries from trusted media, turn off all unnecessary
services, install a good firewall script, and then reconnect to the net.

Short of that you can install a firewall script (Seawall is pretty
good, or see freshmeat.net), use ps and/or lsof to identify what all of
the running processes on your machine are, comb through your logs, use
find to look for executables with odd permissions, and generally follow
the advice for hardening a Linux box (search with google) and pray.

Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.