[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Kjetil Kjernsmo <kjetil.kjernsmo@astro.uio.no> 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

> >> 53/tcp     open        domain
> >
> >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     open        http
> >> 110/tcp    open        pop-3
> >> 111/tcp    open        sunrpc
> >
> >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

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/tcp    filtered    netbios-ns
> >> 138/tcp    filtered    netbios-dgm
> >> 139/tcp    filtered    netbios-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   filtered    gnutella
> >
> >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.

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
    # Devices
    /dev Devices
    # Other miscellaneous files
    /var/run$ StaticDir

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
> >close eye on your IDS.
> I'll read up on IPtables.

Definitely. <http://netfilter.samba.org/> is one possible starting point;
I'd also recommend <http://www.linuxsecurity.com/> and search the latter
for the comp.os.linux.security FAQ.

> BTW, I just off the phone with my host. They said that as long as I'm on
> the case and take it seriously, they're cool. Besides, the Gnutella port
> is somewhat limited, so it is limited what kind of damage intruders can
> do through that port.

They sound like sensible folks to me :)


To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: