Final year project ideas

Zbynek Houska zbynek.houska at gmail.com
Mon Sep 28 15:49:37 UTC 2009


On Mon, Sep 28, 2009 at 2:23 AM, Russell Coker <russell at coker.com.au> wrote:

> On Mon, 28 Sep 2009, Zbynek Houska <zbynek.houska at gmail.com> wrote:
> > write a few (new) policies for software of my choice.  I intend to use
> > honeypots running Fedora 11 as my base system. However, I'm not sure if
> > college class B network will produce conclusive results.
> >
> > Thus, I would appreciate support, guidance and comments from (seasoned)
> > SELinux gurus, developers and practitioners on this list in order to
> point
> > me in the right direction when it comes to sourcing literature, white
> > papers, research work other people might already have conducted and
> > overcoming pitfalls related to such testing environments.
>
> Firstly firewall all traffic from the system in question - other than that
> which is required for it to be vulnerable to the attacks you desire.  If
> you
> allow ICMP echo access then someone will try and ping-flood other systems.
> If you allow outbound TCP connections then your system may be used to
> compromise others.
>

I think I will be using private VLANs on the switch (aka switchport
protected / port protected on Cisco switches) which will limit that box to
be able to talk to the gateway only, hence making it impossible to
compromise other systems on same subnet. Firewall of some kind will have to
be used too as for example outgoing SMTP traffic from that box isn't
something I would like to see.

>
> Probably the best way to run honeypots is to use Xen or KVM to run virtual
> machines.  This means that you have lots of good options for monitoring the
> machines while they are attacked.  But don't assume that Xvn or KVM is
> flawless - IE don't have any sensitive data on the same physical machine.
>

Yes, I was thinking of exactly the same - using either KVM or UML - will
have to decide what way is the most feasible one.

>
> The purpose of a honeypot is to attract attack, running the latest versions
> of
> software is going to make it more difficult for attackers and partially
> defeats this goal.  Maybe running Fedora 10 (or earlier) with no updates
> would be a better option.  Of course you will probably want to back-port
> the
> latest SE Linux policy before you do this (which shouldn't be difficult).
>

Good point here, I didn't thought it through.

>
> It's been a while since anyone ran a SE Linux Play Machine on Fedora, I
> would
> be happy to offer detailed advice and some testing if you want to run one.
>

I wasn't even thinking about making 'play machine(s)' as I hoped to bring
some randomness into it by making it unannounced and hope for the best -
i.e. somebody trying to attack the box by scanning for running services.
But I have to admit, the way you proposed is more controllable and will
possibly yield more predictable results (rather than wait for a random
attack). Do you have much experience in setting up and running such boxes?
If so, would you mind shedding some light on the entire process, please?
However, I reckon I will need to announce a kind of 'hackathon'  (on this
list?) in order to achieve some results as I can't imagine to be impartial
if I do the attacks myself...

Regards,

Z.



> --
> russell at coker.com.au
> http://etbe.coker.com.au/          My Main Blog
> http://doc.coker.com.au/           My Documents Blog
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-selinux-list/attachments/20090928/b256b5cb/attachment.htm>


More information about the fedora-selinux-list mailing list