[syslinux] problem with PXElinux and security of local LAN

Harald_Jensas at Dell.com Harald_Jensas at Dell.com
Tue Dec 20 01:05:00 PST 2005


Hi,

Could you not just use menu and set passwords?

MENU PASSWD passwd

	(Only valid after a LABEL statement.)
	Sets a password on this menu entry.  "passwd" can be either a
	cleartext password or a SHA-1 encrypted password; use the
	included Perl script "sha1pass" to encrypt passwords.
	(Obviously, if you don't encrypt your passwords they will not
	be very secure at all.)

	If you are using passwords, you want to make sure you also use
	the settings "NOESCAPE 1", "PROMPT 0", and either set
	"ALLOWOPTIONS 0" or use a master password (see below.)

	If passwd is an empty string, this menu entry can only be
	unlocked with the master password.


MENU MASTER PASSWD passwd

	Sets a master password.  This password can be used to boot any
	menu entry, and is required for the [Tab] and [Esc] keys to
	work.

Normally, the user can press [Tab] to edit the menu entry, and [Esc]
to return to the SYSLINUX command line.  However, if the configuration
file specifies ALLOWOPTIONS 0, these keys will be disabled, and if
MENU MASTER PASSWD is set, they require the master password.

--------

Another idea:

Use "MAC adresses filtering". You can configure your DHCP server to give the "filename" and "next-server" arguments only to known NICs?


Menu with passwords, and "MAC address filtering" would be quite secure? No?



Regards
Harald Jensås



-----Original Message-----
From: syslinux-bounces at zytor.com [mailto:syslinux-bounces at zytor.com] On Behalf Of Jason Keltz
Sent: den 19 december 2005 22:32
To: Murali Krishnan Ganapathy
Cc: syslinux at zytor.com
Subject: Re: [syslinux] problem with PXElinux and security of local LAN

Hi Murali,
I like the challenge response idea a lot, but even the other idea is good..  I just don't know how to implement either :(

jas.

Murali Krishnan Ganapathy wrote:
> Any kind of security protocol, will require some exchange of 
> information between the local client and the purported DHCP server, 
> which can be verified by both parties. Since this verification needs 
> to be done prior to booting into a kernel, you will have use COMBOOT 
> like stuff to implement the verification.
> 
> More detail of what I had in mind
> 
> (1) Local machine boots into SYSLINUX and runs COMBOOT code stored on 
> local machine
> (2) Local machine asks for DHCP server
> (3) Server S responds
> (4) Local machine asks S for the value of string X (can be implemented 
> as an option-string in DHCP configuration)
> (5) Local machine encrypts "MAGIC STRING" with key Current Date and 
> checks if it equals string X
> (6) If so, trust S and PXE boot from S (using the DHCP server S -- 
> identified by its MAC Address say)
> 
> Yes. Implementing something like this would require a cron job on the 
> server which changes the value of X on a daily basis (or more 
> frequently if you are more paranoid). If this is not done, the bad guy 
> can just intercept the value of X sent by the DHCP server to a client 
> and then mimic the behavior of the DHCP server in the future without 
> knowing the "MAGIC STRING".
> 
> Alternatively, if you dont like the idea of changing the configuration 
> on a regular basis, you should change the protocol to a challenge 
> response protocol, i.e. the local client generates and sends a string 
> to the server which then encrypts it using the MAGIC STRING as key and 
> sends back the result. But this cannot be acheived within the DHCP 
> framework, so the COMBOOT code will be a lot more complicated.
> 
> I guess the question you need to ask is if you want to secure your 
> setup against a casual bad guy or a person determined to hack into 
> your system. If it is the latter, you will need to implement more 
> robust measures, which unfortunately would require more complex work.
> 
> - Murali
> 
> Jason Keltz wrote:
> 
>> That solution sounds interesting albeit a bit complex for me to 
>> implement.   I'm not sure that I quite understand 3.  If the comboot 
>> code asks for a DHCP value, and that value is sent across the wire 
>> encrypted, that seems to require adjusting that code on the DHCP 
>> configuration on a regular basis as well...  further, I also wonder 
>> if it would be possible for a machine to insert itself between step 3 
>> and 4... but definately food for thought.
>>
>> Jason.
>>
>> Murali Krishnan Ganapathy wrote:
>>
>>> Here is an ideal solution. I dont know how much of this is really 
>>> possible.
>>>
>>> (1) Set your BIOS to boot from the local hard disk.
>>> (2) Use SYSLINUX as your boot loader and run a COMBOOT code (stored 
>>> in your hard disk)
>>> (3) The COMBOOT Code figures out Who the DHCP server it is talking 
>>> to, and has some kind of check.
>>> (4) If check works out, then chain boot your PXE ROM
>>>
>>> First this is essentially security by obscurity, i.e. in step (3), I 
>>> am assuming that the DHCP server sends an additional string X 
>>> (actually COMBOOT code asks the DHCP server for X). There is some 
>>> magic string hard wired into the COMBOOT code, which gets encrypted 
>>> using the current date as the key. If the encrypted string is X then 
>>> you can trust the DHCP server.
>>> If the bad guy finds out the magic string (which is never sent over 
>>> the network), then there is no security left.
>>>
>>> It would be cool if this can be implemented. One real life situation 
>>> where SYSLINUX on HDD beats other boot loaders.
>>>
>>> - Murali
>>>
>>> Jason Keltz wrote:
>>>
>>>> Hi.
>>>>
>>>> I want to use PXELinux to build a dynamic boot menu for a computer 
>>>> lab.  Sometimes, the machines need to be in Linux mode/Windows 
>>>> mode/allow the option of Linux/Windows.  I configured this all fine 
>>>> with PXELinux.  My problem is really one of security.  Someone can 
>>>> plug in a laptop with a DHCP server, and tftp server and fake a lab 
>>>> machine to boot into any mode they desire, or even worse, they 
>>>> could configure the local machine to boot Linux in single user 
>>>> mode, and hence allow access to root, local ssh keys, etc.  I can't 
>>>> really think of any easy way how to solve this problem since there 
>>>> is no way to authenticate the PXELinux instance that is loading or the
>>>> configuration files.   Any ideas?  A locally configured grub could 
>>>> do the same thing, of course, but using pxelinux, I can change the 
>>>> configuration of machines that are off so that when they come back 
>>>> on, they are in the mode that I desire.
>>>>
>>>> :(
>>>>
>>>> Jason.
>>>>
>>>> _______________________________________________
>>>> SYSLINUX mailing list
>>>> Submissions to SYSLINUX at zytor.com
>>>> Unsubscribe or set options at:
>>>> http://www.zytor.com/mailman/listinfo/syslinux
>>>> Please do not send private replies to mailing list traffic.
>>>>
>>>>
>>>
>>
>>
> 

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





More information about the Syslinux mailing list