On 28 May 2006 at 11:39, Bernie Cosell wrote:
> There's a *HUGE* difference between not having services running and
> having the ports *closed*. Closing ports mean that you *cannot* open a
> connection from an application and *NO* application can post a LISTEN.
Actually going back through my notes, no services were started and the
firewall only allowed localhost connections.
> Just shutting down services doesn't close any ports, it just doesn't run
> the 'usual' servers on them. Apps can still connect out [e.g., a zombie
> connecting to its IRC-channel master to pick up more malware and/or
That assumes the zombie bot is installed already, if you do a clean
installation offline, patch from cd and don't allow any services to start up
AND the firewall is set to block all in/outbound traffic, you are golden.
This is NO different than any other os or firewall.
> attack instructions] and in most cases, apps can simply post LISTENs [and
> so be sitting there waiting to be told to do something].
If they can't communicate in or outbound, that's irrelevant, if the bot can
do a local priveledge escalation, that's a different issue.
> BTW: I'm pushing on this because I was teaching a class using Unix and it
> was imperative that I set up a "sandbox" for the students to give them
> the ability to do a LOT of fooling around but not hurt the server (or the
> LAN or the Internet). It was *remarkably* difficult [e.g., protecting a
> Unix system from a user doing:
The BSD's have the Jail system which has been around for years, you can give
the user root access to his/her own area without concern that they'll be able
to get out of the jail.
> #!/usr/bin/perl
> while (1)
> { fork(); }
> or filling a filesystem, or ... But I managed that... but the one thing
Then there is SELinux from our fine friends at the NSA which gives even more
fine grained control.
http://www.nsa.gov/selinux/
Another useful tool is Sudo plus there are lots of other ACL based user
control apps around, both userspace and kernel based. Heck you could even do
virtual machines ala Vmware and Userspace Linux.
> I couldn't figure out how to do was to prevent the students from writing
> little net-apps that connected out and [potentially] screwed up the
> school's LAN [if not causing more widespread troubles] or that ran
> servers, etc. [this in the days before iptables were available [at least
> on the distro we were using]... and even now, I think that using ipchains
> to control this kind of thing is tricky, at best]. I'd *LOVE* to hear
It's not, set default policy to deny all, don't add any more rules, you're
done. As I said above this is no different than setting up an enterprise
firewall/router, deny all traffic, explicitly allow the traffic you want.
The Generic class of IPFilters on Unix, specifcally BSD's and Linux have been
able to do this for at LEAST 10 years, can't speak to the other commercial
unices as I've not used them.
> that there's some easy/elegant way to control a program's/user's access
> to sockets and the Internet...
Between IPtables and SELinux, you're pretty much covered, assuming of course
that no one finds an exploit for the 2 packages above, or Jail under BSD.
--
Harondel J. Sibble
Sibble Computer Consulting
Creating solutions for the small business and home computer user.
[EMAIL PROTECTED] (use pgp keyid 0x3AD5C11D) http://www.pdscc.com
(604) 739-3709 (voice/fax) (604) 686-2253 (pager)
--
----------------------------------------
WIN-HOME Archives: http://PEACH.EASE.LSOFT.COM/archives/WIN-HOME.html
Contact the List Owner about anything: [EMAIL PROTECTED]
Official Win-Home List Members Profiles Page
http://www.besteffort.com/winhome/Profiles.html
