Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: syslinux: users

PXE and Security Issues

 

 

syslinux users RSS feed   Index | Next | Previous | View Threaded


Markus.Plaul at vng

May 23, 2007, 1:31 AM

Post #1 of 9 (1477 views)
Permalink
PXE and Security Issues

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 [at] zytor
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.


nazosan at gmail

May 23, 2007, 1:49 AM

Post #2 of 9 (1396 views)
Permalink
Re: PXE and Security Issues [In reply to]

On 5/23/07, Plaul, Markus <Markus.Plaul [at] vng> 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 [at] zytor
> 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.

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...

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX [at] zytor
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.


ryanm at accelrys

May 23, 2007, 2:25 AM

Post #3 of 9 (1390 views)
Permalink
Re: PXE and Security Issues [In reply to]

On 5/23/07, Plaul, Markus <Markus.Plaul [at] vng> 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 [at] zytor
>> 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.

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.

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,


Ryan McLean
_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX [at] zytor
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.


nazosan at gmail

May 23, 2007, 7:19 PM

Post #4 of 9 (1391 views)
Permalink
Re: PXE and Security Issues [In reply to]

On 5/23/07, Ryan McLean <ryanm [at] accelrys> wrote:
> On 5/23/07, Plaul, Markus <Markus.Plaul [at] vng> 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 [at] zytor
> >> 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 [at] zytor
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.


linux at comjet

May 23, 2007, 8:11 PM

Post #5 of 9 (1399 views)
Permalink
Re: PXE and Security Issues [In reply to]

I know this isn't the "philosophy of security" mailing list, but here's my 2
cents. ALL security is through obscurity. On average, it would take a fast
computer longer than the age of the universe to guess a 2048-bit key.
However, it is not impossible that you could guess the right key on the first
try. Same goes for all passwords, keys, filenames, etc....anything that
someone might need to get into a system...it's secure because it's obscure,
and ONLY because it's obscure!

Larry

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX [at] zytor
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.


hpa at zytor

May 23, 2007, 8:35 PM

Post #6 of 9 (1393 views)
Permalink
Re: PXE and Security Issues [In reply to]

Larry Howe wrote:
> I know this isn't the "philosophy of security" mailing list, but here's my 2
> cents. ALL security is through obscurity. On average, it would take a fast
> computer longer than the age of the universe to guess a 2048-bit key.
> However, it is not impossible that you could guess the right key on the first
> try. Same goes for all passwords, keys, filenames, etc....anything that
> someone might need to get into a system...it's secure because it's obscure,
> and ONLY because it's obscure!

That's a shared secret, which is different than "security through
obscurity."

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX [at] zytor
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.


ryanm at accelrys

May 24, 2007, 1:53 AM

Post #7 of 9 (1394 views)
Permalink
Re: PXE and Security Issues [In reply to]

>I know this isn't the "philosophy of security" mailing list, but here's
my 2
>cents. ALL security is through obscurity. On average, it would take a
fast
>computer longer than the age of the universe to guess a 2048-bit key.
>However, it is not impossible that you could guess the right key on the
first
>try. Same goes for all passwords, keys, filenames, etc....anything that
>someone might need to get into a system...it's secure because it's
obscure,
>and ONLY because it's obscure!
>
>Larry

As HPA said..

Security through obscurity applies to things like, instead of ssh on port
22 you put it on port 2222.
Anouther reason i am against security through obscurity is that for every
port you remap you have to remember it / note it down or when you try to
trouble shoot you are in for a very difficult time.

>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.

Why pay for a Firewall just pull out the LAN cable.. :)

>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.

Actually any decent packet sniffer can pull the MAC address from the
packets, as far as i am aware even encrypted packets leave the IP & MAC
unencrypted, Esp in the case of wireless (try kismet).

>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 main reason they drop the unsolicited packets is to prevent a DoS
attack. If they inspected every packet it would be simple to overload them
and render the users connection useless. Which can be just as rewarding
(if used for extortion) as successfully gaining root on an internal
machine.

>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

Couldn't agree with you more.

>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?

Again a decent portscanner will still tell you which ports are available,
(try nmap with different setting combinations).
You can assertain if a computer is present by watching the network traffic
(wireshark).

>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.

As to the original disscussion, the problem here is that were are
discussing a tftp server so the following sequence of events happens
(generally).

Computer joins network and broadcasts for address
DHCP server responds with IP lease & address of tftp server (so now we
know that they both exist)
Comptuer "talks" to tftp server
tftp responds..

So basically though packet sniffing for certain packets we get the
addresses of the client and the tftp server.
>From there we filter all our traffic for these 2 only.
And the packets will contain all the info such as passwords etc

Obv thats a very much simplified attack but it show how easy it is to
initate. I would point out while I haven't looked at the SHA-1 crack i am
assuming that t works on the same principle as the WEP crack (gathering
enough packets to preform a bruteforce based on the packets encryption
pattern) To gather enough packets from a tftp transaction would be alot
more time consuming to the point of being almost a waste of time.

>Unfortunately, in the case of security, a small hole must be opened,
>so no solution will ever be 100% perfect probably.

Agreeed.
Unfortunatly there is no such thing as totally secure, just a combination
of "secure enough" and damage limitation.
Even an off network pc in a locked room can be hacked.. you just need to
break into the room first.. :) and it wouldn't be useful. So we trade
security off against usefulness.


Regards,


Ryan McLean
Systems Administrator
Email: ryanm [at] accelrys
Tel: +44 1223 228632
Ext: 8632
_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX [at] zytor
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.


hpa at zytor

May 24, 2007, 2:19 AM

Post #8 of 9 (1392 views)
Permalink
Re: PXE and Security Issues [In reply to]

Plaul, Markus 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
>

Last I heard SHA-1 was still more secure than MD5 was uncracked, but
maybe there are updates.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX [at] zytor
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.


cristi.mitrana at gmail

May 24, 2007, 3:16 AM

Post #9 of 9 (1395 views)
Permalink
Re: PXE and Security Issues [In reply to]

On 5/24/07, H. Peter Anvin <hpa [at] zytor> wrote:
> Plaul, Markus 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
> >
>
> Last I heard SHA-1 was still more secure than MD5 was uncracked, but
> maybe there are updates.
>

SHA-1 'hacked' is a big word, AFAIK for both MD5 and SHA-1 there are
some 'classes' of bit patterns that can be used to obtain the same
hash by craftfully appending them into 2 different strings
(collisions). Obtaining the cleartext from a hashed string by
bruteforce is still not feasible.
Before a more secure hash algo is to be found people could use
sha-256 and higher, for which the collision attacks are too expensive
to be realy a threat.

--
mitu

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX [at] zytor
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

syslinux users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.