method to authenticate devices

[ddaas]

Hi,

I found out with great astonishment that a worker in the firm where I work as admin came with his personal Notebook and introduced it in the network.
I am sure that this particular worker didn't want to do something harmful and didn't, but I am not sure about the others.

The LAN has 50 win clients with a Linux server (samba, sendmail, bind, ftp, httpd, dhcpd, etc). It’s the same broadcast domain for all.
The clients log in the samba domain (samba works as PDC) and use shares, email and other services which are available in every normal company.


Now I want foreign computers not to have access to the network or not without inform the admin. I want to authenticate the devices not only the users. Something like WEP or other wireless protocols do.

Does anyone know how can this be done?? Is there a special program which does that automatically and centralized? I was thinking about something like this: I get somehow a unique hash value for every legitimate host, and when it wants to communicate with the server (Linux) I check against that value.

At least a want the foreign hosts not to have access to the samba shares. I am satisfied if I am informed about that incident.

I would also like to stop the possibility of coping sensitive information from the samba shares on USB sticks (or to be informed of that).



Ideas ????


Any material/link/book about internal security of a network would be great appreciated.



ddaas

[bwkaz]

Did this happen over wireless? If so, the most secure way to prevent it from happening more is to replace the wireless with wires, which are inherently more secure because the information is only traveling along a specific path, not out over the air. ;)

If you want to authenticate devices on a wired network segment (e.g., if you have unused Ethernet ports throughout the building that people might use), then you'll want to look into switches that can do RADIUS authentication of the devices that hook into them. Most of those switches will probably cost quite a bit, though -- the average 8-port D-Link plastic box won't cut it. I'm not even sure our 3Com 72-port switch stacks at work (3 24-port switches in a stack) will do it.

Actually, with wireless, RADIUS is also the answer (preferably with EAP/TLS, using client certificates, because anything else (user passwords, MAC addresses) can be either guessed or impersonated). But IIUC, the original purpose of RADIUS was to authenticate devices at a switch, based on what port the device plugged into and based on information about the device (MAC address, etc.).

[drummerboy195]

You might also want to look into something along the lines of what most Universities do today. They tie an IP address to a MAC address, so 1) every machine always has the same IP, and 2) machines whose MAC isn't in the database are stuck on a subnet with limited capabilities. For example, here at RIT, when you first plug an unregistered computer into the network, you are assigned a 10.0.0.0/8 address, and there are only four places you can use that computer to communicate with, Windows Update, McAfee Update, Norton Update, and the new computer registration page. After you/ITS registers the MAC in the database, you are given a 129.21.0.0/16 address, and full access to everything. I would think something like this would allow you a great deal of control over what could be plugged into the network, and where those devices would be able to go. That said, MAC addresses are rather easy to clone, and so for a determined hacker/cracker, it really doesn't do much, but it would prevent people who don't take the time to fully consider the consequences of their actions from doing something idiotic.

[ddaas]

bwkaz,
As I knew RADIUS and TACACS+ are a solution to authenticate users not devices over a wireless network. Normally it is used in conjunction with EAP (Extensible Authentication Protocol) and it variations (Cisco LEAP, TLS-LEAP etc). The wireless devices are authenticated using WEP or better something else (TKIP - Temporary Key Integrity Protocol, BKR - Broadcast Key Rotation).
I didn’t know that this can be done at the switch for device authentication. This would be great for what I need. I am going to search for this subject.
I don't know if our switches support radius authentication but I hope the company wants to invest in security.

ddaas

[ddaas]

drummerboy195,
The solution with MACs sounds also good. I am interested mostly in not allowing communication with the server (Linux).

But does anyone know how can I combine cryptography/digital signature for anti - MAC poisoning ??? (the illegitimate MAC is easy to be replaced in the L2 Header with a valid MAC). I am thinking of digital signing the MAC so its identity can be verified. But I don’t how to implement this.


ddaas

[ddaas]

For bwkaz: my network is wired not wireless.

[bwkaz]

Originally posted by ddaas
As I knew RADIUS and TACACS+ are a solution to authenticate users not devices over a wireless network. Normally it is used in conjunction with EAP (Extensible Authentication Protocol) and it variations (Cisco LEAP, TLS-LEAP etc). EAP-TLS is the best, as far as I can tell.

CHAP and PAP are two possibilities -- they both authenticate based on a username/password. One allows very easy sniffing of the password, and the neither of them actually authenticates the server (so an attacker might be able to set up a rogue RADIUS server, and use it to get at passwords).

PEAP (one of Microsoft's EAP implementations) creates some kind of encrypted tunnel, which authenticates the server, but not the client. Then it uses either CHAP or PAP to authenticate the client (which is done as above, with a username and password). Passwords can be guessed or sniffed (they can only be sniffed if the PEAP tunnel is weakly encrypted, though I don't know for sure if that's the case).

LEAP is a Cisco proprietary protocol, and I think it has some weaknesses (though I don't know for sure). I believe it's password based, though I don't know for sure on that either.

EAP-TTLS is similar to PEAP -- it's a TLS connection that tunnels another authentication type through it. The client is not authenticated at the TLS channel level, so security is (again) dependent on whatever authentication is tunneled through it. At least sniffing is hard (due to the TLS tunnel), but passwords can still be guessed.

EAP-TLS is the only one that requires client certificates (which are the only thing that -- at least with today's computing power -- can't be either guessed or sniffed). They can still be stolen if the user's machine is compromised, but two out of three isn't bad.

The wireless devices are authenticated using WEP or better something else (TKIP - Temporary Key Integrity Protocol, BKR - Broadcast Key Rotation). Well... no, they're not.

All the encryption schemes you just listed are not for authenticating clients. They are ONLY for encrypting traffic. I have sometimes heard people say that WEP authenticates clients (because only clients that know the encryption key can connect), but it should not be relied on for that. TKIP and BKR require a key source (either a RADIUS server, or Pre-Shared-Key mode, which is more or less the same as WEP). Either the RADIUS server or knowledge of the pre-shared key would be what does the "authentication" in that case. (Preferably RADIUS).

There is also AES (an optional part of WPA, and required for WPA2, aka 802.11i) for encryption, which suffers none of the problems of WEP or TKIP. (Yes, TKIP has problems. That's what happens when you take a stream cipher, in the form of RC4, and use it in a block mode, for individual packets. AES is at least a block cipher in the first place. It's one of those "use the right tool for the right job" things.)

I didn’t know that this can be done at the switch for device authentication. RADIUS can be done at a switch, but AFAIK WEP, WPA, AES, etc. (encryption), cannot.

I've seen references to Cisco, certain 3Com, and (a very few) Netgear switches supporting RADIUS. I'm sure there are others.

Originally posted by ddaas
But does anyone know how can I combine cryptography/digital signature for anti - MAC poisoning ??? (the illegitimate MAC is easy to be replaced in the L2 Header with a valid MAC). I am thinking of digital signing the MAC so its identity can be verified. But I don’t how to implement this. You'd have to change the Ethernet (802.3) specification.

802.3 defines two things. First, it defines how Ethernet devices are supposed to talk to each other, at the electrical signal level (this includes values like the maximum cable length, maximum signalling rate, how packets are put onto the wire, etc.).

Second, it defines the packet structure itself. Part of this packet structure is the MAC address of the source and destination Ethernet devices. There is nothing in this packet format for a cryptographic signature of the addresses, and the vast majority of network cards probably aren't powerful enough to compute a good signature even if it did exist (this is why RC4 was used for WEP and TKIP -- wireless devices weren't powerful enough for better encryption).

You're going to have to do something that only partially relies on the MAC address (if it relies on it at all -- EAP-TLS, my favorite, does not).

[ddaas]

bwkaz,
You are right! WEP encrypts data. It doesn’t authenticate clients nor devices (also most Cisco APs have WEP as an optional authentication methods - the authentication data is encrypted using wep keys which are 4 and are preconfigured - but this is something optional not the purpose of wep). WEP encrypts only payload not headers.

About using MACs to authenticate devices: I didn't think of using cryptography al the OSI L2 (DataLink layer). I would need to modify Ethernet and 802.11 :)

I was thinking of using cryptography in conjunction with MAC at the main Linux server at the application layer. I was thinking to use iptables (or onother firewall) and to allow communication with my Linux server only from legitimate clients.

What do you think?


ddaas

[bwkaz]

Originally posted by ddaas
About using MACs to authenticate devices: I didn't think of using cryptography al the OSI L2 (DataLink layer). I would need to modify Ethernet and 802.11 :) Right, and that's why I was saying that was going to be really hard. :)

I was thinking of using cryptography in conjunction with MAC at the main Linux server at the application layer. Ah, OK.

To do this, you might be able to use IPSec and/or a VPN type of setup. The server would only allow VPN or IPSec sessions to be negotiated with known clients. ("Known" would be based on anything -- I think you can set up VPN credentials with certificates, though I'm not sure. I'm pretty sure you can do it with username/password pairs.)

Most preferable would probably be setting up a VPN that uses IPSec for its encryption, since you won't need to NAT encrypted packets. (You can NAT packets after decrypting them, that's no big deal. But IIRC IPSec puts a digital signature on the source and destination IP addresses, so you can't NAT IPSec packets, because doing so would change the source IP.)

But you'd have to find somebody more experienced with VPNs and/or IPSec to set that up. I'm sure Linux can do it (we have a VPN box at work running Red Hat plus a few patches, which connects us to the offices at corporate), I just don't know enough about how it works.

[ddaas]

Thanks,

I start looking for information/documentation about what you've said.


ddaas