On 5/23/07, Ryan McLean <ryanm@accelrys.com> wrote:
> On 5/23/07, Plaul, Markus <Markus.Plaul@vng.de> wrote:
> >> Hi guys,
> >>
> >>
> >>
> >> im about write a project about pxe. How it works etc but im stucking at
> >> the security thing. Well pxe has this menu password feature using
> SHA-1,
> >> but since sha-1 is hacked, i cant stick with it saying sha-1 is safe
> >> ..etc. What else could i add when it comes to network boot, pxe and
> >> security besides BIS? I would really appricate some ideas or help. Thx
> >> in advance
> >>
> >>
> >>
> >> _______________________________________________
> >> SYSLINUX mailing list
> >> Submissions to SYSLINUX@zytor.com
> >> Unsubscribe or set options at:
> >> http://www.zytor.com/mailman/listinfo/syslinux
> >> Please do not send private replies to mailing list traffic.
> >>
> >>
>
> >SHA1 may be hacked, but you have to ask yourself just how important
> >this is. Are you expecting outside hackers getting into your LAN
> >(perhaps with wireless?) If so, some things such as access controls
> >and network encryption are a must anyway for your own safety
> >(encryption is a must, but my favorite option is the access control
> >list where you can set it such that only certain MAC addresses are
> >ever allowed to connect. Most wireless routers have this option, but
> >I should add here that PXELinux also has the ability to do this to
> >some extent as well.) If not, I have to wonder how many legitimate
> >users are going to be employing SHA1 encryption breaker tools just to
> >get past your password. In a more normal work environment, most users
> >simply balk at the sight of a password, try a few basics, and give up
> >if they fail rather than employing password hacking methods. Are you
> >providing some sort of direct access to something highly sensitive?
> >If so, it may be more advisable to limit that access further than just
> >by password.
>
> I think what is relevent is that SHA-1 is "secure enough", at the end of
> the day the password is stored in plain text in the configuration file.
>
> The point of encryption is not so much to prevent things from being
> decrypted as much as it is to delay it until the information is useless.
> For example if you change your password every 6 months and have a decent
> IT password policy then this a) make decrypting the password harder (in
> the case of brute force and guessing) and b) limits damage as the password
> is changed frequently.
>
Good advice. Not only is it harder to crack one that changes
frequently, but any sucessful crack is useful for a shorter period of
time.
> Although Nazo mentions filtering by mac address as added security this is
> even less secure than using a password as most routers and a good few NICs
> allow their MAC addresses to be change (this mainly came about due to ISPs
> locking the connection to their own Hardware's MAC, which could be
> expensive to change). Yes using both together is more secure but still far
> from totally secure.
Nothing short of an absolute firewall with no security flaws set to
block ALL incoming and ALL outgoing ports is absolutely secure.
Sometimes all you can do is combine the best things that work for you.
However, I must point out that just because MAC addresses can be
changed does not make MAC filtering insecure. They must know WHAT to
change to. Perhaps you can get this through sniffing if the traffic
is unencrypted, but it can't be THAT easy to get it (meaning that your
average employee isn't going to be doing this probably at the very
least.) If one does not know what MAC addresses are valid, then it's
a 12 digit long hexadecimal code, which means it's not exactly
something you can just guess at.
>
> If you use (windows) RIS instead of TFTP you can have an additional layer
> of security as the RIS server will only server people who can logon via
> Active Directory, there is a tutorial in the wiki on how to do this.
>
> >If all else fails, there's safety in obscurity. Make people manually
> >type out the full command line to get to whatever you wish to password
> >protect. If it's complex enough, chances are that only those who know
> >exactly what to type can get in...
>
> Sorry but bullshit! There is no such thing as security through obscurity
> and and anyone who says there is, is talking absolute tripe!
>
> Regards,
>
I'm not sure why you feel that way, but "security through obscurity"
isn't some theological concept or theoretical but untested idea. It's
simple logic. It works under this basic premise: if a potential
hacker does not know that there is something to hack, then chances are
they aren't going to do it. Take for example one of the most
extremist ways of handling this, port knocking. The firewall simply
drops all traffic until certain ports are "knocked at" in a certain
order. All other traffic is simply dropped as if there is no computer
there at all. To a potential hacker, this may be crackable, but if
they don't know a computer is there, they don't expend the time and
effort needed to crack it. Since there may not even be a computer
there at all, they usually just move on to a system that does respond
to what they are looking to crack. The fact is, if they set their
mind to it, a good hacker is probably going to get in if you set them
a challenge, but if they don't know there is something to get in to
they may never even try.
Really it's just simple logic that there is security in obscurity.
Just as gravity exists whether you believe in it or not (even if we
may not yet fully understand its nature) no amount of denying it will
make it go away. Now I'm not saying that "security through obscurity"
is the answer to everything, just that it is a potential concept to
explore a question of security comes up. In this particular case,
there are some holes in the idea I had, which is why I only barely
mentioned it and mentioned it last. Actually, I must point out that
all good firewalls follow the security through obscurity concept to
some extent already by dropping unsolicited traffic and detecting port
scans such that a potential hacker may think there is no system there
at all. Mind you, they still allow solicited or seemingly solicited
traffict through, so it's obviously not perfect, but my point is that
they already rely on such a concept to increase security somewhat.
Who today still wants one of those old cheap firewalls that would
simply refuse unsolicited traffic, waving a big red flag to any
scanners?
The biggest problem with my idea here, if it's just a simple matter of
a kernel and initial ramdrive, then anyone can look on the simple-FTP
server (which doesn't have much by way of access controls) and see the
filenames of each. Only if something more complex must be entered on
the command line will it work -- something they can't just see by a
simple file list. In perhaps the best example, one might modify the
inital ramdrive's startup scripts to look for a password on that
command line, then produce a misleading error if it is not correct
(say a complaint about some hardware problem for example -- something
that might just look like a standard problem with an old outdated
kernel or something.) You could even set it up to store and compare
that password with a more complex hash than SHA1 because you are in
control of what is done once control has been passed from PXELinux to
the kernel. While it's possible to disect even that, a person would
have to think that there is a reason to examine it up closely before
they will do so and even then there is at least some small possibility
that they could just accidentally pass right by the modified section
if it looked harmless enough at first glance.
It's not perfect, but like with trying to open a hole on a dam, the
moment you open one, however small, you stand the risk of it widening.
Unfortunately, in the case of security, a small hole must be opened,
so no solution will ever be 100% perfect probably.
_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux Please do not send private replies to mailing list traffic.