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
second.
> >> 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
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/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?
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
> >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 :)
~Tim
--
<http://spodzone.org.uk/>
--
To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: