This site uses cookies.
Some of these cookies are essential to the operation of the site,
while others help to improve your experience by providing insights into how the site is being used.
For more information, please see the ProZ.com privacy policy.
<b><i><font size +1>Translation services for your business!</b></i><font size -1> VAT ID 09245260154
Account type
Freelance translator and/or interpreter, Verified site user
Data security
This person has a SecurePRO™ card. Because this person is not a ProZ.com Plus subscriber, to view his or her SecurePRO™ card you must be a ProZ.com Business member or Plus subscriber.
English to Italian: Use a VPN for Wireless Security (PC Magazine article)
Source text - English Use a VPN for Wireless Security
Protect yourself from inherent AP risks
Picture a well-dressed woman standing in your company's lobby, chatting with your receptionist. Now imagine her laptop equipped with wireless sniffer software, sucking up all of your confidential documents and email messages. Or picture an enterprising young man who, just for kicks, has decided to set up on his laptop a rogue DHCP server, which diligently hands out invalid IP addresses to all of your desktop clients. With just a few thousand dollars worth of off-the-shelf computer hardware and software, an intruder can wreak havoc on your wireless network if you haven't taken the appropriate precautions to secure it properly. And after someone has gotten inside your network, you can't do much except unplug your wireless Access Point (AP) and clean up the damage.
Anyone can install wireless APs—even people outside your IT organization. If your organization is large, you might never know that some manager purchased a wireless AP from a discount store and hooked it into the network, just so his employees can wander around the office with their laptops. And this scenario might not even be happening in your building; it might be happening in a remote office, creating a gaping security hole in your organization's network. By nature, APs are a security problem—unless they're still in the box, wrapped in plastic and Styrofoam. However, by using your AP's security capabilities in conjunction with Microsoft Routing and Remote Access Service (RRAS), you can protect yourself from the inherent risks.
Wireless Security with Existing Equipment
You'll find many documents on the Internet about how to secure a wireless network by using nothing more than the equipment that your wireless manufacturer provides. Procedures for doing so vary from manufacturer to manufacturer, but a couple of common techniques are worth mentioning. Primarily, you should consider implementing both Wired Equivalent Privacy (WEP) and authorized media access control (MAC) lists, if your equipment offers these features.
WEP. Wireless networks' built-in encryption capabilities have been broken. Regardless of whether you use 40-bit WEP or 128-bit WEP, an intruder can decode the WEP key that you use for your network. As shocking as that revelation might be, even more shocking is the number of wireless networks that don't even use WEP. During a recent exercise in Washington, DC, I spent a mere 20 minutes worth of scanning for wireless networks and found more than 40 wireless APs, as Figure 1, page 60, shows—and hardly any of them were using encryption. Most people take the time to name their wireless network, simplifying even further the task of determining who's running an open network. I've obscured most of the network names in Figure 1, but 90 percent of the general public would recognize some of the names that I saw. (No, I didn't go past the White House.) If you don't plan to use WEP, you should at least avoid giving your network a descriptive name.
Although WEP has been broken, you can use it as a starting point for your network security to discourage people from attempting to enter your network. Some newer firmware revisions from wireless equipment manufacturers improve WEP security, making your WEP key much more difficult—if not impossible—to decode. So don't forget to upgrade the firmware on all your devices.
Authorized MAC lists. Some wireless APs let you build a table of authorized MAC addresses—the unique fingerprints of wireless NICs—into the AP. If an unauthorized wireless NIC attempts to associate with your wireless AP, the AP rejects it. This extra step takes a bit of effort because you'll need to manually add each card to the authorized MAC table. However, doing so adds an extra layer of security to your wireless implementation.
Security
Wireless networking's core deficiencies are in the areas of authentication and encryption. Wireless APs generally perform very little, if any, user authentication. If a user is within range of your AP and you're not using any type of security, he or she is connected to your network. WEP provides some value but has numerous inherent flaws. So here's a pop quiz: Which type of networking technology can authenticate users coming from an untrusted space and encrypt their communication so that someone listening can't intercept it? The answer is a VPN.
A VPN solves wireless networking's current deficiencies. Granted, getting connected becomes a bit more difficult for your users. But if you've already invested time in building a VPN infrastructure for your mobile users to access your organization's network, installing a VPN to authenticate wireless users is a relatively simple process.
Let's take a look at a fictional corporate network, before and after using a VPN to secure wireless connections. Figure 2 shows a network diagram of a typical wireless implementation, with the wireless AP behind the corporate firewall. Even after you spend tens of thousands of dollars on firewall equipment to keep untrusted connections out of the network, this type of implementation opens up a big hole within the trusted network space. Imagine a bank vault door at your front entrance but a rickety old screen door at your side entrance. Guess which point of entry an intruder will choose?
Figure 3 shows a secure method of implementing a wireless AP: behind a VPN server. This type of implementation provides high security for your wireless network implementation without adding significant overhead for your users. For extra protection, you might try moving the VPN server to sit in front of your firewall, but because APs are typically location-dependent, this approach won't work for everyone.
If you have more than one wireless AP in your organization, I recommend running them all into a common switch, then connecting the VPN server to the same switch. Then, your desktop users won't need to have multiple VPN dial-up connections configured on their desktops. They'll always be authenticating to the same VPN server no matter which wireless AP they've associated with.
VPN Server Setup
Ready to get started? Let's talk about the hardware you'll need to complete this project. First, you'll need a server to act as your VPN gateway device and control who gets into your trusted network. The machine doesn't need to be a super-powerful server. A high-end desktop might even suffice (depending on the number of wireless users you plan to support), although for such a crucial function, I prefer to use a low-end server-class device.
You need to install two NICs on the VPN gateway server, one for your untrusted wireless network and one for the trusted internal network. If you've implemented a VPN for Internet-based users, you'll be familiar with this process. Plug the wireless AP—and nothing else—directly into the untrusted network interface. Anyone associating with your wireless AP will be able to reach only your VPN server's untrusted interface and any client workstations associated with the AP. The VPN server becomes the gateway into your internal network, deciding who passes through and who gets rejected.
To communicate with your VPN server's untrusted interface, your wireless users must have an untrusted IP address assigned to them. If your wireless AP has DHCP server capabilities, you can configure the AP to hand out untrusted IP addresses to anyone who associates with it. (I recommend this approach.) If your wireless AP doesn't have DHCP server capabilities, you can install the DHCP service on your VPN server and configure it to hand out untrusted IP addresses only on the untrusted interface.
For example, let's assume that the untrusted network comprises the range of IP addresses from 172.16.30.0/24 (with a mask of 255.255.255.0) and that the wireless AP will freely hand out an IP address in this range to any device that asks for one. Also, assume that your VPN server's untrusted network interface has an IP address of 172.16.30.10.
For your internal network, assume that your organization has used the IP address range of 10.100.0.0/16 throughout the organization (with a mask of 255.255.0.0). For the network segment to which the VPN server is connected, assume that the IP addresses are in the 10.100.30.0/24 range and that the VPN server will have an IP address of 10.100.30.10 assigned to the trusted interface.
At this point, if you've inserted the VPN server between your wireless AP and the rest of your network, a wireless user can associate with your wireless AP—and that's about all. The next step is to configure the VPN server so that it can properly authenticate your users and permit authenticated users into your internal network.
To begin installing VPN capabilities on the server, select Start, Programs, Administrative Tools, Routing and Remote Access. When the Microsoft Management Console (MMC) Routing and Remote Access snap-in appears, right-click the server name in the left pane and select Configure and Enable Routing and Remote Access. Doing so will start the Routing and Remote Access Server Setup Wizard.
Microsoft has simplified the installation of a VPN server (compared with what Windows NT 4.0 involves), so walking through the wizard's screens is fairly easy. Let's take a look at each screen, starting with the Common Configurations screen, which Figure 4 shows. Choose to set up a VPN server by selecting Virtual private network (VPN) server. Click Next to proceed to the Remote Client Protocols screen, which Figure 5 shows. This screen is a bit puzzling—it doesn't serve much purpose. The wizard provides a list of protocols and asks you to ensure that all the protocols you need to support for your clients are installed on the server. If you select No, I need to add protocols, the wizard doesn't let you reconfigure your network settings. It simply quits. You also can't deselect protocols on this screen—for example, to disallow IPX over your VPN. So, if you have the correct protocols installed on your system, select Yes, all of the available protocols are on this list and click Next.
You typically implement VPNs with the Internet acting as the untrusted connection. Therefore, the next wizard screen, Internet Connection, which Figure 6 shows, asks which NIC points to your Internet connection. In this case, consider Internet to be synonymous with wireless and select the appropriate network interface. In this example, I've chosen the interface with the IP address 172.16.30.10, which is the address I defined for the connection to my untrusted (wireless) network. Click Next.
To let your wireless users communicate on your internal network, you'll need to give them an IP address within your internal network space. Some administrators like to use their primary DHCP server for this task—with or without the use of the DHCP relay agent—but I prefer to have my VPN server hand out addresses. Doing so simplifies troubleshooting should problems arise down the road.
If you want your VPN gateway server to allocate internal IP addresses to your wireless users, select From a specified range of addresses on the IP Address Assignment screen, which Figure 7 shows, then click Next. Selecting this option takes you to a wizard screen on which you can define ranges of addresses that your VPN server can hand out. Click New on that screen to access a dialog box in which you can add the appropriate IP address range to use, as Figure 8 shows. Click Next to go to the final wizard screen, which asks whether you want to use a Remote Authentication Dial-In User Service (RADIUS) server for authentication. Assuming you want to use your standard Active Directory (AD) or legacy NT domain database for authentication, answer No, I don't want to set this server up to do RADIUS now, then click Next. You've now finished your VPN server setup.
VPN Client Setup
To test your new VPN server implementation, you'll want to set up a wireless workstation or laptop and test each part of your connectivity—from the wireless AP to the VPN server on the untrusted side to your organization's trusted network.
If you boot your test station with the wireless NIC connected, you should associate with your AP. You can check your wireless manufacturer's drivers to see which AP you've associated with. Or, if you're using Windows XP, the OS should tell you which wireless AP you're connected to. Verify that your test workstation is receiving an untrusted TCP/IP address from either the DHCP service in your AP (if you've configured it to do so) or from your VPN server (if you installed DHCP).
If your test workstation has successfully obtained an untrusted IP address, you can ping the VPN server's untrusted interface by using the Ping command at a command prompt. Doing so verifies proper wireless connectivity from the workstation, through the wireless AP, and to the VPN server's untrusted interface. If you get a successful ping response, everything is working properly so far. If you don't get a ping response, troubleshoot the problem before going any further.
Now is the time to establish a VPN connection into your internal network. From the XP or Windows 2000 desktop, select Start, Settings, Network and Dial-up Connections, then double-click Add New Connection. Doing so launches the Network Connection Wizard, which prompts you for information about the connection you want to make. On the Network Connection Type screen, which Figure 9 shows, you specify a VPN connection by selecting Connect to a private network through the Internet. Click Next.
The next wizard screen prompts you for the DNS name or IP address of the VPN server you want to connect to. You probably won't have DNS name resolution available to a wireless user who hasn't been properly authenticated yet, so use the IP address of your VPN server's untrusted interface—172.16.30.10, in my example—and click Next.
The final two wizard screens are simple, asking whether you want to make this connection available only for yourself or for all users, and whether you want to share the connection with other users. Answer the questions appropriately for your situation.
Now, the fun begins. Start the DUN connection and provide an appropriate set of username and password credentials in the logon box. (The VPN server needs to verify that your user account has been granted dial-in access.) Your system establishes the VPN tunnel to your VPN server, which in turn authenticates you against the AD database or against the local accounts database. After you're properly authenticated, the VPN server allocates your test workstation a trusted IP address and starts routing your traffic to the internal network. You can verify this routing by running Ipconfig on your test workstation and checking the IP addresses that have been assigned. You should see one untrusted address and one trusted address.
Congratulations! You now have a fully functional VPN-protected wireless network that you can start rolling out to your end-user community.
Mobile Madness
You might wonder what happens to laptop users who move around the office and move from one AP to another. Because each AP gives out a specific scope of untrusted addresses, the untrusted IP address of a user who changes APs will also change. RRAS attempts to set up a secure VPN tunnel for communication with your user's device, so it won't be too keen on a device that suddenly changes its IP address. Therefore, the VPN tunnel will break. However, if you select the Redial if line is dropped option when you define your client VPN connection profile, you can be sure that Windows will try to reestablish the connection whenever it's lost.
Don't Just Plug It In
Wireless networks require particularly careful implementation. Because they're so easy to set up, the temptation is to simply plug them in and walk away. However, you should never connect a wireless AP to your network and leave it in its default configuration. If you do so, you might as well run some Ethernet cables out your office windows into the street, because you're effectively opening up your network to anyone within a few hundred feet of your office who has a wireless NIC.
Can you rest assured that your wireless data is secure within the type of implementation this article has described? I've spoken with some extremely security-conscious organizations—you know, the kind with armed guards who carry real guns and are trained to use them—and those organizations are using a VPN to protect their wireless networks. Of course, every situation is different, but if companies like that trust a VPN to secure their wireless communication, that's good enough for me.
Translation - Italian Usare una VPN per ottenere la sicurezza wireless
Ottenere una protezione dai rischi correlati all'uso degli AP.
Immaginatevi, nell'atrio della vostra azienda, una signora ben vestita che sta chiacchierando con la receptionist. Adesso immaginate che il suo laptop sia dotato di un software sniffer wireless, in grado di risucchiare tutti i vostri messaggi e-mail e i documenti riservati. Oppure immaginatevi un giovane intraprendente che, per puro divertimento, abbia deciso di installare sul suo laptop un server DHCP (Dynamic Host Configuration Protocol) fasullo, il quale diligentemente passa indirizzi IP non validi a tutti i vostri client desktop. Spendendo soltanto poche migliaia di dollari per l'acquisto di normale software e hardware per computer, un intruso può creare problemi enormi sulla vostra rete wireless se non avete preso le precauzioni appropriate per renderla sicura. Dopo che qualcuno sia riuscito a introdursi nella vostra rete, non resta molto da fare - se non scollegare il vostro AP (Access Point) wireless e fare il conto dei danni.
Chiunque può installare degli AP wireless - anche persone che si trovano al di fuori della vostra organizzazione IT. Se la vostra è una grande azienda, potreste non sapere nemmeno che qualche manager ha acquistato un AP wireless in un negozio a prezzi scontati e lo ha agganciato alla rete, semplicemente per consentire ai suoi sottoposti di spostarsi per l'ufficio con il laptop. Magari questo scenario potrebbe non accadere nemmeno nel vostro edificio; potrebbe accadere invece in un ufficio remoto, spalancando una falla nella sicurezza di rete della vostra azienda. Per loro natura, gli AP rappresentano un problema per la sicurezza - a meno che siano ancora nella loro confezione, ben avvolti da plastica e cellophane. In ogni caso, sfruttando le capacità di sicurezza del vostro AP congiuntamente al servizio Microsoft RRAS (Routing and Remote Access Service), è possibile proteggersi dai rischi correlati.
Sicurezza wireless con le attrezzature già esistenti
Su Internet si possono trovare molti documenti che spiegano come rendere sicura una rete wireless usando nient'altro che le attrezzature fornite dal vostro produttore di dispositivi wireless. Le procedure che permettono di ottenere questo risultato sono variabili da produttore a produttore, ma è opportuno citare un paio di tecniche comuni. In primo luogo, si dovrebbe valutare l'opportunità di implementare lo schema WEP (Wired Equivalent Privacy) e liste MAC (Media Access Control) autorizzate - sempre che le vostre attrezzature offrano queste funzionalità.
WEP. Le capacità di crittografia incorporate nelle reti wireless sono ormai state violate. Indipendentemente dal fatto che si utilizzi uno schema WEP a 40 o 128 bit, gli intrusi possono decodificare la chiave WEP che usate per la vostra rete. Questa rivelazione sarà forse sconvolgente, ma è ancora più sconvolgente il numero di reti wireless che addirittura non usa nemmeno il WEP. In un recente esperimento che abbiamo deciso di effettuare a Washington, abbiamo dedicato solo venti minuti alla scansione delle reti wireless e abbiamo individuato più di quaranta AP wireless, come indica la figura 1. Nessuno usava la crittografia. Oltre a ciò, la maggior parte della gente si prende il tempo necessario per assegnare un nome alla propria rete wireless, semplificando ancora di più il compito di stabilire a chi appartiene una data rete aperta. Nella figura 1 abbiamo oscurato la maggior parte dei nomi delle reti, ma il 90 per cento del pubblico generico potrà riconoscere alcuni dei nomi che abbiamo individuato (no, non siamo passati davanti alla Casa Bianca). Se non intendete usare il WEP, dovreste almeno evitare di assegnare un nome descrittivo alla vostra rete.
Anche se il WEP è stato violato, lo si può utilizzare come punto di partenza per la propria sicurezza, in modo da scoraggiare i potenziali intrusi dal tentare di introdursi nella rete. Alcune recenti revisioni del firmware che sono state introdotte dai produttori di dispositivi wireless consentono di migliorare la sicurezza WEP, rendendo la chiave WEP molto più difficile - se non impossibile - da decodificare. In conseguenza, non bisogna dimenticare di effettuare l'aggiornamento del firmware in tutti i dispositivi.
Liste MAC autorizzate. Alcuni AP wireless permettono di creare al proprio interno una tabella con indirizzi MAC autorizzati - ovvero le impronte digitali univoche delle schede NIC (Network Interface Card) wireless. Se una scheda NIC wireless non autorizzata dovesse cercare di associarsi all'AP wireless, quest'ultimo la rifiuterebbe. Questa fase aggiuntiva richiede un po' di lavoro, dal momento che bisogna aggiungere manualmente l'indirizzo di ogni scheda alla tabella con gli indirizzi MAC autorizzati. L'operazione consente tuttavia di aggiungere un ulteriore strato di sicurezza alla propria implementazione wireless.
Sicurezza
Le limitazioni centrali del networking wireless sono nell'area dell'autenticazione e della crittografia. In genere, gli AP wireless effettuano un'autenticazione molto blanda degli utenti - sempre che la effettuino. Se un utente è nel raggio d'azione dell'AP e la vostra azienda non usa nessun tipo di sicurezza, si ritroverà collegato alla vostra rete. Lo schema WEP offre qualche possibilità, ma è caratterizzato da numerosi difetti. Ecco allora un bel quiz: "Quale tipo di tecnologia di networking permette di autenticare gli utenti provenienti da uno spazio considerato non di fiducia e codificarne le comunicazioni in modo che qualcuno che sia in ascolto non possa intercettarle?". La risposta è: una VPN (Virtual Private Network).
L'uso di una VPN permette di eliminare gli attuali punti deboli del networking wireless. Certo: effettuare la connessione diventa un po' più difficile per gli utenti. In ogni caso, se avete già dedicato del tempo alla creazione di un'infrastruttura VPN per i vostri utenti mobili, al fine di consentire loro l'accesso alla rete dell'azienda, l'installazione di una VPN per autenticare gli utenti wireless sarà relativamente semplice.
Prendiamo in considerazione una rete aziendale fittizia, prima e dopo l'uso di una VPN per rendere sicure le connessioni wireless. La figura 2 mostra il diagramma di rete di una tipica implementazione wireless, con l'AP wireless dietro il firewall aziendale. Anche dopo aver speso decine di migliaia di dollari per l'acquisto di dispositivi firewall volti a mantenere fuori dalla rete le connessioni untrusted (non di fiducia), questo tipo di implementazione apre una grossa falla all'interno del vostro spazio di rete trusted (di fiducia). È un po' come aver installato una porta blindata da caveau bancario sull'ingresso principale, ma lasciare una traballante porta in legno sull'entrata di servizio. Provate a indovinare quale sarà il punto di ingresso scelto da un intruso?
La figura 3 indica un metodo sicuro per l'implementazione di un AP wireless: dietro un server VPN. Questo tipo di implementazione offre una sicurezza elevata alla rete wireless, senza aggiungere un sovraccarico significativo per gli utenti. Per ottenere un'ulteriore protezione, si potrebbe provare a spostare il server VPN per posizionarlo davanti al firewall; in ogni caso, dal momento che tipicamente gli AP sono dipendenti dalla posizione, questo approccio non potrà andare bene per tutti.
Se in azienda usate più di un AP wireless, vi consigliamo di collegarli tutti a uno switch comune, poi connettere al medesimo switch anche il server VPN. In questo caso, gli utenti desktop non avranno bisogno di aver configurato sui propri desktop molteplici connessioni dial-up VPN. Saranno sempre autenticati sul medesimo server VPN, indipendentemente dall'AP wireless al quale sono associati.
Configurazione del server VPN
Siete pronti per partire? Esaminiamo l'hardware di cui avete bisogno per completare questo progetto. In primo luogo ci vuole un server che dovrà agire da dispositivo gateway VPN e controllare chi può entrare nella vostra rete trusted. Questa macchina non dovrà necessariamente essere un server superpotente. Può andare bene anche un desktop di fascia alta (a seconda del numero di utenti wireless che intendete supportare); in ogni caso, per una funzione così cruciale, preferiamo usare un dispositivo di classe server di fascia bassa.
Si dovranno inoltre installare sul server gateway VPN due schede NIC: una per la rete wireless untrusted e l'altra per la rete interna trusted. Se avete implementato una VPN per gli utenti Internet, avrete già familiarità con questa procedura. Collegate l'AP wireless - e null'altro - direttamente all'interfaccia della rete untrusted. Chiunque si associ all'AP wireless potrà raggiungere soltanto l'interfaccia untrusted del server VPN e le eventuali workstation client associate all'AP. Il server VPN diventa il gateway alla rete interna, che decide chi può passare e chi invece verrà rifiutato.
Affinché possano comunicare con l'interfaccia untrusted del server VPN, agli utenti wireless deve venire assegnato un indirizzo IP untrusted. Se l'AP wireless offre le capacità di server DHCP, potrete configurarlo in modo da fornire indirizzi IP untrusted a chiunque sia associato all'AP stesso (consigliamo di seguire questo approccio). Se invece l'AP wireless non dispone delle capacità di server DHCP, potrete installare il servizio DHCP sul server VPN e configurarlo per fornire indirizzi IP untrusted unicamente all'interfaccia untrusted.
Per esempio, facciamo l'ipotesi che la rete untrusted comprenda la gamma di indirizzi IP 172.16.30.0/24 (con mask di 255.255.255.0) e che l'AP wireless possa fornire liberamente un indirizzo IP in questa gamma a qualsiasi dispositivo che chiede un indirizzo. Facciamo inoltre l'ipotesi che l'interfaccia di rete untrusted del server VPN usi l'indirizzo IP 172.16.30.10.
Per la rete interna, facciamo l'ipotesi che per tutta l'azienda venga usata la gamma di indirizzi IP 10.100.0.0/16 (con mask di 255.255.0.0). Per il segmento di rete al quale è connesso il server VPN, ipotizziamo che gli indirizzi IP appartengano alla gamma 10.100.30.0/24 e che il server VPN disponga dell'indirizzo IP 10.100.30.10 assegnato all'interfaccia trusted.
A questo punto, se il server VPN è stato inserito tra l'AP wireless e il resto della rete, un utente wireless potrà associarsi all'AP wireless - ed è tutto. La fase successiva consiste nella configurazione del server VPN, in modo che possa autenticare appropriatamente gli utenti e consentire a quelli autenticati di entrare nella rete interna.
Per cominciare l'installazione delle capacità VPN sul server, selezionare Start, Programs, Administrative Tools, Routing and Remote Access. Quando viene visualizzato lo snap-in MMC (Microsoft Management Console) Routing and Remote Access, fare un clic destro sul nome del server nel riquadro di sinistra e selezionare Configure and Enable Routing and Remote Access. Questa operazione lancia la procedura guidata Routing and Remote Access Server Setup.
Microsoft ha semplificato l'installazione di un server VPN (rispetto a quanto viene richiesto da Windows NT 4.0); in conseguenza, l'uso delle varie schermate di questa procedura guidata risulta piuttosto semplice. Diamo un'occhiata a ciascuna schermata, iniziando da quella chiamata Common Configurations che viene indicata dalla figura 4. Scegliere di configurare un server VPN, selezionando Virtual private network (VPN) server. Premere Next in modo da passare alla schermata Remote Client Protocols, indicata dalla figura 5. Questa schermata risulta un po' sconcertante, dal momento che non serve a molto. La procedura guidata fornisce una lista di protocolli e chiede di accertarsi che siano installati sul server tutti i protocolli che dovete supportare per i vostri client. Se selezionate No, I need to add protocols, la procedura guidata non consente di riconfigurare le impostazioni di rete. Semplicemente termina la propria esecuzione. Su questa schermata non è possibile nemmeno deselezionare i protocolli - per esempio, se desiderate disattivare l'IPX sulla vostra VPN. In conseguenza, se avete installato i protocolli corretti nel sistema, selezionate Yes, all of the available protocols are on this list e premete Next.
Di solito, le VPN vengono implementate con Internet che funge da connessione untrusted. In conseguenza, la schermata successiva della procedura guidata - Internet Connection, indicata dalla figura 6 - chiede quale scheda NIC punti alla vostra connessione Internet. Nel nostro caso, dobbiamo considerare Internet come sinonimo di wireless e selezionare l'interfaccia di rete appropriata. In questo esempio abbiamo scelto l'interfaccia con indirizzo IP 172.16.30.10, ovvero l'indirizzo che è stato definito per la connessione alla rete untrusted (wireless). Premere Next.
Al fine di consentire agli utenti wireless di comunicare sulla rete interna, si dovrà fornire loro un indirizzo IP entro lo spazio di rete interno. Alcuni amministratori preferiscono usare il server DHCP primario per questa operazione - con o senza l'uso del relay agent DHCP; noi invece preferiamo fare in modo che sia il server VPN a fornire gli indirizzi. Ciò semplifica la risoluzione degli eventuali problemi che potrebbero manifestarsi in seguito.
Se desiderate fare in modo che il server gateway VPN allochi gli indirizzi IP interni agli utenti wireless, selezionate From a specified range of addresses sulla schermata IP Address Assignment indicata dalla figura 7, poi premete Next. La scelta di questa opzione provoca la visualizzazione di una schermata in corrispondenza della quale è possibile definire la gamma degli indirizzi che possono essere forniti dal server VPN. Premere New su questa schermata, in modo da accedere a una finestra di dialogo nella quale è possibile aggiungere la gamma appropriata di indirizzi IP da utilizzare, come indica la figura 8. Premere Next per passare alla schermata finale della procedura guidata, che vi chiederà se desiderate usare un server RADIUS (Remote Authentication Dial-In User Service) per l'autenticazione. Nell'ipotesi che si desideri usare per l'autenticazione la propria Active Directory standard o un database di domini NT legacy, selezionare No, I don't want to set this server up to do RADIUS now, poi premere Next. A questo punto avete completatola configurazione del server VPN.
Configurazione del client VPN
Per sottoporre a test la nuova implementazione del server VPN, è opportuno configurare un laptop o una workstation wireless e sottoporre a test ogni porzione della connettività - dall'AP wireless fino al server VPN sul lato untrusted della rete trusted dell'azienda.
Se la macchina di test viene avviata con la scheda NIC wireless già collegata, dovreste associarvi automaticamente all'AP. Potete controllare i driver forniti dal vostro produttore wireless per vedere a quale AP siete associati. In alternativa, se usate Windows XP, il sistema operativo dovrebbe comunicarvi a quale AP wireless siete connessi. Controllate che la workstation di test riceva un indirizzo TCP/IP untrusted dal servizio DHCP nell'AP (se è stato configurato per questa operazione), oppure dal server VPN (se avete installato il protocollo DHCP).
Se la workstation di test ha ottenuto con successo un indirizzo IP untrusted, potete fare ping sull'interfaccia untrusted del server VPN usando il comando Ping in corrispondenza di un prompt dei comandi. Questa operazione permette di verificare l'appropriata connettività wireless dalla workstation, attraverso l'AP wireless e verso l'interfaccia untrusted del server VPN. Se si ottiene una risposta ping positiva, ciò significa che per il momento tutto funziona in modo appropriato. Se invece non si ottiene nessuna risposta ping, prima di procedere sarà necessario risolvere il problema.
Adesso è giunto il momento di instaurare una connessione VPN nella rete interna. Dal desktop di Windows XP o Windows 2000, selezionare Start, Settings, Network and Dial-up Connections, poi fare un doppio clic su Add New Connection. Questa operazione attiva la procedura guidata Network Connection Wizard, che chiede le informazioni sulla connessione che si desidera effettuare. In corrispondenza della schermata Network Connection Type, indicata dalla figura 9, è necessario specificare una connessione VPN selezionando Connect to a private network through the Internet. Premere Next.
La schermata successiva della procedura guidata chiede il nome DNS o l'indirizzo IP del server VPN al quale ci si desidera connettere. La risoluzione dei nomi DNS non sarà probabilmente disponibile per un utente wireless che non sia ancora stato autenticato appropriatamente; in conseguenza, usare l'indirizzo IP dell'interfaccia untrusted del server VPN - nel nostro esempio, 172.16.30.10 - e premere Next.
Le due schermate finali della procedura guidata sono piuttosto semplici e chiedono se si desidera rendere disponibile questa connessione soltanto a se stessi oppure a tutti gli utenti, e se si desidera condividere la connessione con altri utenti. Rispondete a queste domande in modo appropriato per la vostra situazione.
Adesso comincia il divertimento. Avviate la connessione DUN (Dial-Up Networking) e, nella finestra di logon, fornite una serie appropriata di credenziali con nome-utente e password (il server VPN dovrà verificare che al vostro account utente sia stato accordato l'accesso dial-in). Il sistema crea il tunnel VPN verso il server VPN, che a sua volta vi autentica nei confronti del database Active Directory o del database di account locale. Dopo aver effettuato correttamente l'autenticazione, il server VPN alloca un indirizzo IP trusted alla vostra workstation di test e comincia a instradare alla rete interna il vostro traffico. Potete verificare questo instradamento eseguendo Ipconfig sulla workstation di test e controllando gli indirizzi IP che sono stati assegnati. Dovreste vedere un indirizzo untrusted e un indirizzo trusted.
Congratulazioni! A questo punto avete una rete wireless completamente funzionale e protetta tramite VPN, che potete incominciare a rendere disponibile alla comunità degli utenti finali.
La mania del mobile
Magari vi state chiedendo che cosa succede agli utenti dei laptop che si spostano per l'ufficio passando da un AP all'altro. Dal momento che ciascun AP fornisce uno scope specifico di indirizzi untrusted, cambia anche l'indirizzo IP untrusted di un utente che cambia AP. Dal momento che il servizio RRAS cerca di creare un tunnel VPN sicuro per le comunicazioni con il dispositivo dell'utente, questo servizio non sarà troppo entusiasta di un dispositivo che improvvisamente cambia indirizzo IP. In conseguenza, il tunnel VPN verrà interrotto. Se però è stata selezionata l'opzione Redial if line is dropped nel momento in cui si ha definito il profilo di connessione VPN del client, si può star certi che Windows cercherà di instaurare nuovamente la connessione tutte le volte che dovesse cadere.
Non basta collegarsi
Le reti wireless hanno bisogno di un'implementazione particolarmente attenta. Dal momento che sono così facili da installare, la tentazione è quella di collegarsi semplicemente e cominciare a muoversi. In ogni caso, non si dovrebbe mai connettere un AP wireless alla rete e lasciarlo nella configurazione di default. Comportarsi così è un po' come calare dei cavi Ethernet fuori dalle finestre dell'ufficio fino al marciapiede, dal momento che state praticamente aprendo la vostra rete a chiunque sia nelle vicinanze dell'ufficio e disponga di una scheda NIC wireless.
Si può avere la certezza che i dati wireless sono sicuri usando il tipo di implementazione descritta da questo articolo? Abbiamo parlato con alcune aziende estremamente attente alla sicurezza - il tipo di aziende che usa guardie armate con pistole vere, e addestrate a usarle; tutte queste aziende usano una VPN per proteggere le proprie reti wireless. Ovviamente, ogni situazione è diversa dalle altre; se però aziende come queste accordano la propria fiducia a una VPN per rendere sicure le comunicazioni wireless, per noi è sufficiente.
English to Italian: Configuring Basic 802.11b Security (Windows & .NET Magazine article)
Source text - English Configuring Basic 802.11b Security
Once a novelty of tech-savvy users, 802.11b wireless devices have taken the residential scene by storm and have even found their way into many organizations—despite negative publicity about inherent security vulnerabilities. These devices have charmed users, who simply plug them in, dismissing—or not understanding—the concept of intrusion. The devices are cheap, offer decent performance, and are easy to set up. However, 802.11b devices can leave your network open to attack.
I don't recommend deploying bare-bones 802.11b devices directly into networks that contain sensitive data and demand tightly controlled access. However, given the popularity of these devices, every IT administrator needs to know the basic security principles behind every 802.11b device. You're probably also ready for a primer that shows you how to use Windows XP's Wireless Zero Configuration service—or third-party drivers, if necessary—to configure your wireless client.
Ease of Use
The 802.11b protocol, which uses the 2.4GHz frequency, provides service as fast as 11Mbps and offers rudimentary authentication and encryption mechanisms. (The 802.11a and 802.11g protocols provide service as fast as 54Mbps.) Unfortunately, out of the box, these devices are typically configured without built-in security mechanisms enabled. And with an Access Point (AP) and NIC price of less than $200 combined, the devices are painless for non-IT departments to purchase and plug into the corporate LAN. This plug-and-play approach is the reason for much of 802.11b's popularity. Many vendors offer the ability to simply plug in the AP, plug in the wireless NIC (USB or PC Card), insert the driver CD-ROM when prompted, and presto—you have an AP-based wireless network. In this article, I focus primarily on the prolific sub-$200 equipment that you'll probably find popping up in your network. (Many more robust—and expensive—solutions offer advanced security and management features that are better suited for an enterprise deployment.)
The 802.11b devices work in two modes: ad hoc and infrastructure. Ad hoc mode is a peer-to-peer mode in which computers with 802.11b wireless NICs can talk directly to one another. (Access is generally restricted to computers configured in ad hoc mode.) Infrastructure mode requires an AP, a network device that acts as a bridge between your wired LAN and your wireless users. In infrastructure mode, many users can use one AP. Also, with some models, you can overlap the coverage areas of multiple APs to create a mesh across your campus that users can roam. (Roaming across subnets is a tricky endeavor that less expensive devices don't generally support.)
Active Breach and Passive Listening
To understand 802.11b's weaknesses, think of your wireless network as a typical wired LAN. Imagine a potential intruder accessing your wireless network by simply plugging his or her computer into your Ethernet switch. This scenario is close to what you're permitting if you leave the basic security features of 802.11b disabled. An intruder's access to your network could be twofold: First, the intruder could access any system available to your wireless users on your LAN; second, the intruder could use your IP network to access the Internet.
An intruder doesn't need to physically breach your network to cause damage. He or she can passively listen to your wireless traffic and sniff corporate secrets (e.g., passwords). If you occupy a building with other tenants, those tenants could feasibly identify your network and set up a device to silently log all wireless traffic for later analysis. Such passive reconnaissance is impossible to detect electronically.
Authentication and Encryption
The 802.11b protocol provides basic authentication and encryption mechanisms, with which you can protect your wireless network against external threats. Authentication validates you as a legitimate wireless client before the AP permits access to the network. Encryption protects the data stream between the wireless adapter and the AP, preventing casual eavesdroppers from poaching your traffic. Both of these processes use a key or secret that the wireless user and the AP share. This shared secret can validate the user and encrypt the data. Widely available hacker programs can decipher these keys, so you need to rotate your keys regularly and frequently. Rotating keys involves changing the Wired Equivalent Privacy (WEP) key on every wireless client and each AP. Unfortunately, most 802.11b products (particularly the less expensive solutions) don't offer effective key management, and key rotation can be cumbersome. (For more secure alternatives to 802.11b's built-in security, see "Related Articles in Previous Issues.") The emerging 802.1x standard provides stronger port authentication through dynamic and session-based keys. For more information about 802.1x authentication, see the sidebar "A Glimpse at 802.1x Authentication."
Define Your SSID
To begin configuring basic 802.11b security, you first need to define your wireless network's service set identifier (SSID). The SSID, which is set on every wireless client and AP, defines the logical network for the group of wireless network devices that share that particular SSID. Be careful: Some vendors market the SSID as a type of security. A NETGEAR FAQ, for example, states that "the SSID is a common password unique to each wireless network," which might literally be true but not in the traditional sense of a password. NETGEAR's device broadcasts this SSID, which XP picks up as an available network, as Figure 1, page 70, shows. Obtaining the SSID is the first step toward gaining access to (or hacking into) a wireless network.
Many vendors use a default SSID for their devices, and I recommend that you set your SSID to a name that uniquely describes the deployment. (However, use discretion: Using the name Finance WLAN for a wireless LAN—WLAN—that serves the accounting department might draw unwanted attention.) If possible, disable your AP's broadcasting of your SSID. Check your AP's documentation to determine whether your AP will let you disable SSID broadcasting. Eavesdroppers will then have a tougher time finding your network.
The WEP Key
The WEP static network key is similar to IP Security's (IPSec's) preshared key—it's a shared secret between two wireless devices that want to communicate with each other (e.g., wireless client to AP). WEP uses a network key, 40 or 104 bits in length, for authentication and data encryption. Confusing matters, vendors might specify a 40-bit key as 64 bits in length or a 104-bit key as 128 bits. In each set, the systems are the same; the actual key lengths are 40 bits and 104 bits, respectively. The remaining 24 bits are for an initialization parameter that isn't user configurable.
Most systems support a hexadecimal network key, but some support an ASCII key—important to remember if you're mixing vendor products. You can store four keys in an 802.11b wireless device and set the key index to specify the active key. The key index also varies according to vendor: Some vendors prefer to number the key index 03, whereas others use 14.
The 802.11b standard specifies that the network key be installed on each network device independent of the wireless medium. Most vendors require the user to install the keys manually (or store them on the wireless device). Therefore, most users must type a key into their AP and type the same key into their wireless client. An example of a 128-bit WEP hex key is AB 02 1F 1A 93 2C DF FF 71 AB 29 F5 D9. (Encryption and decryption use the same key.) Inexpensive 802.11b systems don't offer a slick means of managing these keys. Imagine running around to your wireless users and typing in this key—and imagine changing it frequently! (Remember that regular and frequent key rotation is important to maintaining security in your basic 802.11b WLAN.)
I recommend using 128-bit encryption. If both your AP and wireless adapter support ASCII keys, consider them an alternative to the more difficult-to-remember hex keys. Also, consider devices that support automatic key management, although such devices are typically more expensive and often proprietary in nature.
Open System or Shared Key
Authentication is the process of validating a user or system before communication can occur; 802.11b connections support Open System and Shared Key authentication. Open System authentication, as its name implies, permits any wireless device to communicate with another wireless device.
Shared Key authentication uses the WEP network key to authenticate the client. The process is simple: The AP sends the wireless client a clear-text challenge; the client uses the network key to encrypt the challenge, then sends it back to the AP. If the client uses the wrong key, or no key, the AP denies access to the user. Although Shared Key authentication keeps unauthorized devices from associating with your AP, both the encrypted and unencrypted challenges are vulnerable to eavesdropping, which makes deciphering the WEP key easier. However, Shared Key authentication prevents random unauthorized users from connecting to your AP. So unless your AP supports a stronger (probably proprietary) authentication mechanism, and until we're all using 802.1x (or its future superior), I recommend that you use 802.11b's Shared Key authentication. However, you need to understand this weakness and remember to rotate your WEP keys frequently.
Set Up a Secure AP
Inexpensive APs that strictly adhere to the 802.11b feature set might offer 64-bit or 128-bit WEP and Shared Key or Open System authentication. (Some vendors might extend security features—for example, by limiting the media access control—MAC—address of specific authorized wireless NICs.)
AP configuration varies according to vendor, but you can count on following these basic steps:
Physically connect the AP to the LAN, and—if the AP supports direct cable management—connect the USB or serial cable to the management computer. Otherwise, you might use HTTP/HTTPS, Telnet, SNMP, or a vendor-specific network client to manage your AP. For maximum security, consider using a direct connection or a secure protocol (e.g., HTTPS, if your AP supports it) for managing your AP.
Load the AP management software onto the management computer. Run your management software and scan for the AP. If you have other APs on the network from the same vendor, you might also see them. (These APs are often denoted by their configured name, SSID, or MAC address.) Some vendors configure the AP's IP address to a default static address (e.g., 192.168.1.1), whereas others default to DHCP. So, to connect to it, you might need to change your management computer's IP address so that it's on the same subnet (e.g., 192.168.1.2) or be sure it can communicate with a DHCP server. After you successfully connect to the AP, follow the AP management software's documentation to change the AP's IP address to be on your LAN.
Because the AP is likely set with a common set of users and passwords, you need to change the default Administrator password and review any other default users who can manage the AP. (For example, some APs allow guest access for remote management.)
Select a descriptive word for your wireless network and set your SSID (or Extended SSID—ESSID—depending on the model of your AP) to this word. Every wireless client that wants to be a part of this logical network must use the same SSID. Figure 2 shows an AP setup screen in which the ESSID is set to Blackstatic.
Enable Shared Key authentication. Figure 3 shows the setup of an AP with Shared Key authentication enabled.
Enable WEP. Specify the hex network key. (Some AP models support ASCII keys in addition to hex keys.) Write down the network key; for static basic WEP implementations, you'll need to enter this key manually on every machine. The 802.11b standard supports four network keys, which are indexed. Some devices require you to enter the three other network keys (thereby defining all four). To specify the default (active) key, refer to your AP management software documentation for instructions about how to set the index to that key.
You've now completed basic security configuration for an 802.11b AP. Remember that some proprietary solutions add extra security features beyond the basic 802.11b specification, so be sure to check your vendor's documentation. Now, it's time to use Wireless Zero Configuration services or third-party drivers to configure the client. The steps to do so are similar. For the Wireless Zero Configuration example, I used an Intel 2011 wireless NIC. For the third-party driver example, I used an SMC SMC2632W wireless NIC. Both communicate with NET-GEAR's ME102 AP. These products are popular, inexpensive 802.11b solutions that you might see in home or workgroup implementations.
Wireless Zero Configuration Steps
Wireless Zero Configuration, which promises to centralize and sanitize wireless configuration in XP, is a service that's installed and started by default on all XP machines. When you install a wireless card that supports Wireless Zero Configuration, you don't need to install any third-party drivers. You need only to install the supported card (PC Card or USB) onto your computer, and Windows automatically installs the drivers and attempts to connect to an available AP. To use Wireless Zero Configuration to get up and running, follow these steps:
Insert the card into the computer. XP might prompt you to install drivers, although the Intel 2011 card didn't prompt me. In fact, after I plugged in this card, XP silently installed the necessary drivers. I viewed progress in XP pop-up balloons. The first balloon notified me that the new hardware was ready to use. The second balloon notified me that a new wireless network was available.
If you didn't configure your wireless AP for Shared Key authentication and WEP, XP automatically connects to your network. Remember that anyone else can just as easily attach to your network!
You can check the Microsoft Hardware Compatibility List (HCL) to ensure that your wireless device supports Wireless Zero Configuration—not all of them do. Devices that have proprietary features will likely require specific drivers. Another way to check for Wireless Zero Configuration support is to go ahead and install the card—if XP prompts you to install drivers, your card might not support Wireless Zero Configuration. After you install the card, open Network Connections and look for a Wireless Network Connection icon next to your adapter. Right-click the icon (or the icon of the NIC that you know is wireless), and click Properties. If your network connection adapter's Properties dialog box contains a new Wireless Networks tab, as Figure 4 shows, your card supports Wireless Zero Configuration. If it doesn't, you'll need to use the card's third-party drivers to manage it.
Connect to the network. Next to the system tray, you should see a balloon stating that a new wireless network is available. Click the balloon to access the Wireless Networks dialog box. In this dialog box, you can enter your network key, connect to your network, and perform advanced configuration. Because you've locked down the AP, you need to manually configure the client. To do so, in the Wireless Network dialog box, click Advanced, which takes you to the Wireless Network Connection Properties dialog box's Wireless Networks tab.
If you don't see the balloon next to the system tray, you can access the advanced-configuration options manually. Open Network Connections, right-click the wireless adapter, and click Properties. On the Wireless Networks tab, you'll see fields for your Available networks and Preferred networks. A preferred network is a wireless network that you can configure to automatically connect to in the future. If you've already configured your AP, you might see the SSID name under Available networks. (Many APs broadcast the SSID name, and Microsoft's Wireless Zero Configuration service uses it to help with configuration. These are two reasons you shouldn't rely on your SSID as a part of your security.)
Configure your network connection and configure 802.11b security. Under Preferred networks, select your network's SSID and click Properties. If you don't see any networks listed, click Add to access the Wireless Network Properties dialog box, which Figure 5 shows. Because basic 802.11b devices don't support automatic key management, you need to clear the The key is provided for me automatically check box. You can now configure the WEP network-key settings. Select both the Data encryption (WEP enabled) and Network Authentication (Shared mode) check boxes. (Shared mode is synonymous with Shared Key authentication.) Enter your WEP network key and specify its format, length, and index. The key index tells the system which of the four keys it should use. Click OK.
XP will now automatically find and connect to your wireless AP. Repeat this process for each of your wireless clients. (The 802.1x protocol will centralize and streamline much of this process, providing a higher level of authentication security and requiring less management.)
Third-Party Driver Steps
The steps for configuring a third-party driver are similar to those that comprise the Wireless Zero Configuration setup.
Insert the card into the computer and install its latest drivers. Some wire-less adapters install proprietary client-configuration software. Look in your system tray or Start menu for any adapter-specific utilities. You might also be able to access some of the configuration settings through the adapter's Properties sheet. In XP and Windows 2000, open Network Connections, right-click the wireless NIC's icon, and select Properties. Click Configure to configure the wireless adapter.
Maneuver to the dialog box that includes a tab on which you can enter the SSID. (The field might also be called ESSID or Network Name.) Enter the name with which you configured the AP. Figure 6 shows an example of an SMC card configured to connect to the Blackstatic SSID network.
Navigate to the tab on which you configure WEP settings. Enable WEP and specify the key length and the WEP key. Figure 7 shows the SMC's Encryption tab: Click OK and exit the dialog box.
No Choice
The 802.11b protocol provides built-in security mechanisms that organizations typically—and unfortunately—deploy in a disabled state. Particularly guilty are non-IT or nontechnical departments. You need to seek out any rogue 802.11b deployments and lasso them into alignment with your entire WLAN infrastructure. Even if you have a basic deployment, you must review the security requirements of your WLAN attached network, remembering that unauthorized access to the WLAN will likely permit trespass to the network to which it's connected. Most large organizations will want to add security measures to the basic 802.11b built-in security features, which alone are simply weak and subject to compromise. However, these fast, cheap devices are popular and will continue to sprout up everywhere. You need to understand how to properly configure your wireless devices for basic security—particularly in environments in which isolated networks or dedicated firewalls are impossible.
Translation - Italian Configurare una sicurezza 802.11b di base
Mentre qualche tempo fa erano di moda unicamente tra gli utenti più esperti dal punto di vista tecnico, adesso i dispositivi wireless 802.11b sono molto diffusi e hanno trovato la propria strada all'interno di molte organizzazioni - malgrado la pubblicità negativa sulle loro vulnerabilità dal punto di vista della sicurezza. Questi dispositivi sono particolarmente affascinanti per gli utenti, che semplicemente li collegano, trascurando - o non capendo - il concetto di intrusione. Questi dispositivi sono economici, offrono prestazioni decorose e sono facili da configurare. In ogni caso, i dispositivi 802.11b possono lasciare aperta la vostra rete nei confronti degli attacchi.
Vi sconsigliamo di implementare direttamente dei dispositivi di base 802.11b nelle reti che contengano dei dati delicati e richiedano un accesso strettamente controllato. Data la popolarità di questi dispositivi, tutti gli amministratori IT devono tuttavia conoscere i principi di sicurezza che stanno alla base di ogni dispositivo 802.11b. Probabilmente siete pronti anche per un articolo che spieghi come usare il servizio Wireless Zero Configuration di Windows XP - oppure dei driver di terze parti, se è necessario - al fine di configurare il client wireless.
Facilità d'uso
Il protocollo 802.11b, che usa la frequenza di 2,4 GHz, offre un servizio alla velocità massima di 11 Mbps accompagnato da rudimentali meccanismi di autenticazione e crittografia (i protocolli 802.11a e 802.11g offrono invece un servizio alla velocità massima di 54 Mbps). Purtroppo, nella configurazione standard, questi dispositivi vengono tipicamente configurati senza attivare i meccanismi di sicurezza incorporati. Con un prezzo combinato di AP (Access Point) e scheda NIC (Network Interface Card) inferiore a 200 dollari, per i dipartimenti non-IT è facile acquistare questi dispositivi e collegarli alla LAN aziendale. Questo approccio plug-and-play è la causa di buona parte della popolarità dello standard 802.11b. Molti produttori offrono la possibilità di collegare semplicemente l'AP, di inserire la scheda NIC wireless (USB o PC Card), di inserire il CD-ROM quando richiesto e - subito! - ecco una rete wireless basata su AP (molte soluzioni più robuste - e più costose - offrono una sicurezza più avanzata e funzionalità di gestione più adatte alle implementazioni di tipo enterprise).
I dispositivi 802.11b operano in due modalità: ad hoc e di infrastruttura. Quella ad hoc è una modalità peer-to-peer, dove i computer con schede NIC wireless 802.11b possono dialogare reciprocamente (l'accesso è di solito limitato ai computer configurati in modalità ad hoc). La modalità di infrastruttura richiede invece l'uso di un AP (Access Point): un dispositivo di rete che agisce da bridge tra la LAN cablata e gli utenti wireless. Nella modalità di infrastruttura, molti utenti possono usare un singolo AP. Inoltre, con alcuni modelli è possibile sovrapporre le aree di copertura di molteplici AP in modo da creare un reticolato che si estenda a tutta l'area aziendale, dove gli utenti si potranno muovere in roaming (il roaming attraverso le subnet è piuttosto complesso e non viene in genere supportato dai dispositivi meno costosi).
Violazioni attive e ascolto passivo
Per capire i punti deboli del protocollo 802.11b, bisogna pensare alla propria rete wireless come a una tipica LAN cablata. Si immagini un potenziale intruso che accede alla rete wireless collegando semplicemente il suo computer a uno dei vostri switch Ethernet. Questo scenario si avvicina a ciò che state rendendo possibile se lasciate disattivate le funzionalità di sicurezza di base del protocollo 802.11b. L'accesso dell'intruso alla vostra rete può essere duplice: in primo luogo, potrebbe accedere a qualsiasi sistema disponibile agli utenti wireless sulla rete; secondariamente, potrebbe usare la vostra rete IP per accedere a Internet.
Per creare danni, l'intruso non ha bisogno di violare fisicamente la rete: può ascoltare passivamente il traffico wireless e "sniffare" dei segreti aziendali (come le password). Se condividete l'edificio con altri inquilini, questi ultimi possono plausibilmente identificare la vostra rete e configurare un dispositivo che effettui silenziosamente il logging di tutto il traffico wireless, in modo da poterlo analizzare in un secondo tempo. È impossibile rilevare elettronicamente questa perlustrazione passiva.
Autenticazione e crittografia
Il protocollo 802.11b mette a disposizione dei meccanismi di base per autenticazione e crittografia, attraverso i quali è possibile proteggere la propria rete wireless dalle minacce esterne. L'autenticazione vi convalida come client wireless legittimo prima che l'AP consenta l'accesso alla rete. La crittografia protegge il flusso dei dati tra l'adattatore wireless e l'AP, impedendo che ascoltatori occasionali possano intercettare il vostro traffico. Entrambi questi processi usano una chiave o segreto che viene condiviso dall'utente wireless e dall'AP. Questo segreto condiviso può convalidare l'utente e crittografare i dati. Dal momento che alcuni programmi per hacker diffusamente disponibili permettono di decifrare queste chiavi, è opportuno ruotarle regolarmente e spesso. La rotazione delle chiavi coinvolge la modifica della chiave WEP (Wired Equivalent Privacy) su ogni client wireless e su ogni AP. Purtroppo, la maggior parte dei prodotti 802.11b (soprattutto le soluzioni meno costose) non offrono un'efficace gestione delle chiavi e la rotazione di queste ultime può risultare scomoda (per alcune alternative più sicure alla sicurezza incorporata del protocollo 802.11b, fare riferimento al riquadro intitolato "Articoli correlati pubblicati sui numeri precedenti"). Lo standard emergente 802.1x offre un'autenticazione più forte delle porte, attraverso chiavi dinamiche e basate sulla sessione. Per maggiori informazioni sull'autenticazione 802.1x, fare riferimento al riquadro intitolato "Un rapido sguardo all'autenticazione 802.1x".
Definire il proprio SSID
Per iniziare la configurazione della sicurezza 802.11b di base, per prima cosa bisogna definire l'identificatore SSID (Service Set Identifier) della propria rete wireless. Il SSID, che viene impostato su ogni client wireless e su ogni AP, definisce la rete logica per il gruppo di dispositivi di rete wireless che condividono quel particolare SSID. Bisogna tuttavia prestare una particolare attenzione: alcuni produttori commercializzano il SSID quale tipo di sicurezza. Una FAQ di NETGEAR, per esempio, afferma che "Il SSID è una password comune, univoca per ogni rete wireless" - cosa che letteralmente potrebbe essere anche vera, ma non nel senso tradizionale di password. Il dispositivo di NETGEAR trasmette questo SSID, che XP raccoglie come rete disponibile, nel modo indicato dalla figura 1. L'ottenimento del SSID rappresenta il primo passo verso la possibilità di ottenere l'accesso a una rete wireless (o di introdurvisi illegalmente).
Molti produttori usano un SSID di default per i loro dispositivi; raccomandiamo di impostare il proprio SSID su un nome che descriva l'implementazione in modo univoco (bisogna tuttavia usare una certa discrezione: l'uso del nome Finance WLAN per una WLAN - Wireless Local Area Network - che serve il dipartimento di contabilità potrebbe attirare un'attenzione indesiderata). Se possibile, disattivare il broadcasting del proprio SSID da parte dell'AP. Controllare la documentazione dell'AP in modo da verificare se il dispositivo consente di disattivare il broadcasting del SSID. In questo caso, gli ascoltatori indiscreti avranno delle difficoltà per trovare la vostra rete.
La chiave WEP
La chiave di rete statica WEP è simile alla chiave pre-condivisa del protocollo IPSec (Internet Protocol Security) - si tratta di un segreto condiviso tra due dispositivi wireless che desiderano comunicare reciprocamente (per esempio, il client wireless e l'AP). Lo schema WEP usa una chiave di rete, con lunghezza di 40 o 104 bit - per l'autenticazione e la crittografia dei dati. Per confondere ulteriormente la situazione, i produttori potrebbero specificare una chiave da 40 bit indicando una lunghezza di 64 bit, oppure una chiave da 104 bit indicando una lunghezza di 128 bit. In entrambi questi gruppi, i sistemi sono tutti uguali; le lunghezze effettive delle chiavi sono rispettivamente di 40 e 104 bit. I restanti 24 bit servono per un parametro di inizializzazione che non è configurabile dall'utente.
Mentre la maggior parte dei sistemi supporta una chiave di rete esadecimale, alcuni supportano una chiave ASCII - un fattore importante da tenere presente se si usano prodotti di diverse case produttrici. È possibile archiviare quattro chiavi in un dispositivo wireless 802.11b e impostare l'indice delle chiavi per specificare quella attiva. Anche l'indice delle chiavi varia a seconda del produttore: per l'indice, alcuni preferiscono usare la numerazione 0-3, mentre altri usano la numerazione 1-4.
Lo standard 802.11b specifica che la chiave di rete deve essere installata su ogni dispositivo, indipendentemente dal medium wireless. La maggior parte dei produttori richiede all'utente di installare manualmente le chiavi (o di archiviarle nel dispositivo wireless). In conseguenza, la maggior parte degli utenti deve digitare una chiave nell'AP e inserire la stessa chiave anche nel client wireless. Un esempio di chiave esadecimale WEP a 128 bit è AB 02 1F 1A 93 2C DF FF 71 AB 29 F5 D9 (la codifica e la decodifica usano la medesima chiave). I sistemi 802.11b poco costosi non offrono nessun mezzo comodo per gestire queste chiavi. Immaginate di dovervi recare presso tutti i vostri utenti wireless per inserire questa chiave - e immaginate di doverla cambiare spesso! Si ricordi infatti che una rotazione regolare e frequente delle chiavi è importante per mantenere la sicurezza nelle WLAN 802.11b di base.
Raccomandiamo di usare la crittografia a 128 bit. Se l'AP e l'adattatore wireless supportano entrambi le chiavi ASCII, consideratele come una valida alternativa alle chiavi esadecimali, che sono più difficili da ricordare. Inoltre, prendete in considerazione dei dispositivi che supportino la gestione automatica delle chiavi, anche se queste unità sono tipicamente più costose e spesso hanno una natura proprietaria.
Open System o Shared Key
L'autenticazione è il processo di convalida di un utente o un sistema prima che possano avvenire delle comunicazioni; le connessioni 802.11b supportano l'autenticazione Open System e l'autenticazione Shared Key. L'autenticazione Open System, come implica il nome, permette a qualsiasi dispositivo wireless di comunicare con un altro dispositivo wireless.
L'autenticazione Shared Key usa invece la chiave di rete WEP per autenticare il client. Il processo è semplice: l'AP invia al client wireless un challenge come testo in chiaro; il client usa la chiave di rete per crittografare il challenge e successivamente lo re-invia all'AP. Se il client usa la chiave sbagliata, o se non usa nessuna chiave, l'AP rifiuta l'accesso all'utente. Anche se l'autenticazione Shared Key impedisce ai dispositivi non autorizzati di associarsi al vostro AP, i challenge crittografati e non restano vulnerabili all'ascolto indiscreto - e ciò facilita la decifrazione della chiave WEP. In ogni caso, l'autenticazione Shared Key impedisce agli utenti casuali non autorizzati di connettersi al vostro AP. In conseguenza, a meno che quest'ultimo supporti un meccanismo di autenticazione più forte (e probabilmente proprietario) - e fino a quando non useremo tutti il protocollo 802.1x (o le sue future evoluzioni) - consigliamo di usare l'autenticazione Shared Key del protocollo 802.11b. In ogni caso, è indispensabile conoscerne i punti deboli e ricordare di ruotare frequentemente le chiavi WEP.
Configurare un AP sicuro
L'insieme delle funzionalità offerte dagli AP poco costosi e strettamente aderenti allo standard 802.11b potrebbe comprendere l'autenticazione Open System o Shared Key e lo schema WEP a 64 o 128 bit (alcuni produttori potrebbero estendere le funzionalità di sicurezza, per esempio, limitando l'indirizzo MAC - Media Access Control - delle schede NIC wireless specifiche autorizzate).
La configurazione degli AP varia a seconda del produttore, ma si può sempre contare sulle seguenti fasi di base:
1. Connettere fisicamente l'AP alla LAN; se l'AP supporta la gestione diretta dei cavi, connettere al computer di gestione il cavo USB o seriale. In caso contrario, per gestire l'AP si potrebbe usare un client HTTP/HTTPS, Telnet, SNMP (Simple Network Management Protocol), oppure un client di rete specifico al produttore. Al fine di ottenere la massima sicurezza, per la gestione dell'AP è opportuno considerare l'uso di una connessione diretta o di un protocollo sicuro (per esempio, l'HTTPS - se il vostro AP lo supporta).
2. Caricare il software di gestione dell'AP sul computer di gestione. Eseguirlo ed effettuare una scansione per individuare l'AP. Se nella rete vengono usati altri AP dello stesso produttore, potrete vederli elencati (questi AP vengono spesso denotati dal loro nome configurato, dal SSID, o dall'indirizzo MAC). Alcuni produttori configurano l'indirizzo IP dell'AP su un indirizzo statico di default (per esempio, 192.168.1.1), mentre altri usano come default il protocollo DHCP (Dynamic Host Configuration Protocol). In conseguenza, per connettersi, potrebbe essere necessario cambiare l'indirizzo IP del computer di gestione in modo che si trovi sulla stessa subnet (per esempio, 192.168.1.2), oppure accertarsi che possa comunicare con un server DHCP. Dopo aver connesso l'AP, seguire quanto indicato dalla documentazione del suo software di gestione per modificare il suo indirizzo IP in modo che appartenga alla vostra LAN.
3. Dal momento che probabilmente l'AP è configurato con un insieme comune di utenti e password, bisogna cambiare la password Administrator di default e controllare tutti gli altri eventuali utenti di default che possono gestire l'AP (per esempio, alcuni AP consentono l'accesso guest per la gestione remota).
4. Scegliere una parola restrittiva per la rete wireless e impostare su di essa il SSID (o l'ESSID - Extended Service Set Identifier - a seconda del modello del vostro AP). Ogni client wireless che vuole far parte di questa rete logica dovrà usare lo stesso SSID. La figura 2 mostra la schermata di setup di un AP dove l'ESSID è impostato su Blackstatic.
5. Attivare l'autenticazione Shared Key. La figura 3 mostra il setup di un AP con attivata l'autenticazione Shared Key.
6. Attivare lo schema WEP. Specificare la chiave di rete ed esadecimale (alcuni modelli di AP supportano anche chiavi ASCII, oltre a quelle esadecimali). Prendere nota della chiave di rete; per le implementazioni WEP statiche sarà necessario inserire manualmente questa chiave su ogni macchina. Lo standard 802.11b supporta quattro chiavi di rete, che sono indicizzate. Alcuni dispositivi richiedono l'inserimento anche delle altre tre chiavi di rete (definendole quindi tutte e quattro). Per specificare la chiave di default (attiva), fare riferimento alla documentazione del software di gestione dell'AP in modo da ottenere le istruzioni su come impostare l'indice su quella chiave.
A questo punto avete completato la configurazione di base della sicurezza per un AP 802.11b. Bisogna comunque tenere presente che alcune soluzioni proprietarie aggiungono ulteriori funzionalità di sicurezza, che vanno oltre la specifica 802.11b di base; in conseguenza, è sempre opportuno verificare la documentazione fornita dal produttore. Adesso è arrivato il momento di usare i servizi Wireless Zero Configuration, oppure i driver di terze parti, per configurare il client. Le fasi da seguire sono simili in entrambi i casi. Per l'esempio della Wireless Zero Configuration abbiamo usato una scheda NIC wireless Intel 2011. Per l'esempio con il driver di terze parti abbiamo usato invece una scheda NIC wireless SMC SMC2632W. Entrambe comunicano con l'AP ME102 di NET-GEAR. Questi prodotti sono soluzioni 802.11b particolarmente diffuse e poco costose, che si possono trovare nelle implementazioni home o workgroup.
Fasi relative a Wireless Zero Configuration
Wireless Zero Configuration, che promette di centralizzare e di rendere maggiormente accettabile la configurazione wireless in XP, è un servizio che viene installato e avviato per default su tutte le macchine XP. Quando si installa una scheda wireless che supporta la Wireless Zero Configuration, non è necessario installare nessun driver di terze parti. Basta installare semplicemente nel computer la scheda supportata (PC Card o USB); Windows installerà automaticamente i driver e cercherà di connettersi a un AP disponibile. Al fine di usare Wireless Zero Configuration per configurare una rete wireless, seguire queste fasi:
1. Inserire la scheda nel computer. XP potrebbe chiedervi di installare i driver - in ogni caso, la scheda Intel 2011 non ce l'ha chiesto. In effetti, dopo aver inserito questa scheda, XP ha installato "silenziosamente" tutti i driver necessari. Abbiamo potuto osservare i progressi dell'installazione nei "fumetti" pop-up visualizzati da XP. Il primo "fumetto" ha indicato che il nuovo hardware era pronto per l'uso. Il secondo ha indicato che era disponibile una nuova rete wireless. Se non avete configurato l'AP wireless per l'autenticazione Shared Key e lo schema WEP, XP si connette automaticamente alla rete. Bisogna tenere presente che chiunque altro può collegarsi alla rete in modo altrettanto facile! Potete controllare la lista HCL (Hardware Compatibility List) di Microsoft per verificare che il vostro dispositivo wireless supporti effettivamente lo schema Wireless Zero Configuration - non sempre è così. I dispositivi che offrono funzionalità proprietarie richiedono spesso l'uso di driver specifici. Un altro modo per verificare il supporto per Wireless Zero Configuration consiste nel proseguire e installare la scheda - se XP vi chiede di installare i driver, è probabile che la scheda non supporti la Wireless Zero Configuration. Dopo aver installato la scheda, aprire Network Connections e cercare l'icona Wireless Network Connection vicino al vostro adattatore. Fare un clic destro sull'icona (oppure sull'icona della scheda NIC che voi sapete già che è wireless) e fare clic su Properties. Se la finestra di dialogo Properties del vostro adattatore per la connessione di rete è dotata della nuova scheda Wireless Networks - come indicato dalla figura 4 - significa che la scheda supporta la Wireless Zero Configuration. In caso contrario, per gestire la scheda sarà necessario usare i suoi driver di terze parti.
2. Connettersi alla rete. Vicino alla barra di sistema dovrebbe esserci un fumetto che indica la disponibilità di una nuova rete wireless. Fare clic sul fumetto, in modo da accedere alla finestra di dialogo Wireless Networks. In questa finestra di dialogo è possibile inserire la chiave di rete, connettersi alla rete ed effettuare una configurazione avanzata. Dal momento che avete "chiuso a chiave" l'AP, sarà necessario configurare manualmente il client. Per compiere questa operazione, nella finestra di dialogo Wireless Network fare clic su Advanced; verrà visualizzata la scheda Wireless Networks della finestra di dialogo Wireless Network Connection Properties. Se non viene visualizzato il fumetto vicino alla barra di sistema, potete accedere manualmente alle opzioni di configurazione avanzata. Aprire Network Connections, fare un clic destro sull'adattatore wireless e fare clic su Properties. In corrispondenza della scheda Wireless Networks potrete vedere i campi etichettati con Available networks e Preferred networks. Una "preferred network" è una rete wireless che può essere configurata in modo da potervisi connettere automaticamente in futuro. Se avete già configurato l'AP, ne potete vedere il nome SSID sotto Available networks (molti AP effettuano il broadcast del nome SSID e il servizio Wireless Zero Configuration di Microsoft lo usa per facilitare la configurazione. Per questi due motivi, non ci si dovrebbe basare sul SSID per la propria sicurezza).
3. Configurare la connessione di rete e la sicurezza 802.11b. Sotto Preferred networks, selezionare il SSID della propria rete e fare clic su Properties. Se non viene elencata nessuna rete, fare clic su Add per accedere alla finestra di dialogo Wireless Network Properties indicata dalla figura 5. Dal momento che i dispositivi 802.11b di base non supportano la gestione automatica delle chiavi, bisogna togliere il segno di spunta dalla casella di controllo The key is provided for me automatically. A questo punto si possono configurare le impostazioni della chiave di rete WEP. Inserire il segno di spunta in entrambe le caselle di controllo Data encryption (WEP enabled) e Network Authentication (Shared mode) ("Shared mode" è sinonimo di "autenticazione Shared Key"). Inserire la chiave di rete WEP e specificare il formato, la lunghezza e l'indice. L'indice delle chiavi indica al sistema quale delle quattro chiavi bisogna usare. Fare clic su OK.
A questo punto XP troverà automaticamente l'AP wireless e vi si connetterà. Ripetere questa procedura per ognuno dei propri client wireless (il protocollo 802.1x provvederà a centralizzare e ottimizzare buona parte di questo processo, fornendo un livello più elevato di sicurezza dell'autenticazione e richiedendo una gestione meno onerosa).
Fasi per i driver di terze parti
Le fasi per la configurazione di un driver di terze parti sono simili a quelle per il setup della Wireless Zero Configuration.
1. Inserire la scheda nel computer e installare i suoi driver più recenti. Alcuni adattatori wireless installano del software proprietario per la configurazione del client. Cercate nella barra di sistema o nel menu Start la presenza di eventuali utility specifiche all'adattatore. In alcuni casi, potreste essere in grado di accedere ad alcune impostazioni di configurazione attraverso la finestra Properties dell'adattatore. In XP e Windows 2000, aprire Network Connections, fare un clic destro sull'icona della scheda NIC wireless e selezionare Properties. Fare clic su Configure per configurare all'adattatore wireless.
2. Aprire la finestra di dialogo che presenta una scheda dove si può inserire il SSID (questo campo potrebbe chiamarsi anche ESSID, oppure Network Name). Inserire il nome con il quale avete configurato l'AP. La figura 6 mostra un esempio di scheda SMC configurata per connettersi alla rete SSID Blackstatic.
3. Navigare fino alla scheda che permette di configurare le impostazioni WEP. Attivare lo schema WEP e specificare la lunghezza della chiave e la chiave WEP. La figura 7 mostra la scheda Encryption di SMC: fare clic su OK e uscire dalla finestra di dialogo.
Nessuna alternativa
Il protocollo 802.11b mette a disposizione dei meccanismi incorporati per la sicurezza, che tipicamente (purtroppo) le organizzazioni implementano senza attivarli. Sono colpevoli soprattutto i dipartimenti non-IT o non-tecnici. In questo caso, è indispensabile rilevare tutte le implementazioni 802.11b di questo tipo e metterle in linea con l'intera infrastruttura WLAN. Anche se avete un'implementazione soltanto di base, dovrete controllare i requisiti di sicurezza della rete connessa alla WLAN, ricordando che l'accesso non autorizzato alla WLAN può probabilmente consentire il passaggio alla rete alla quale la WLAN è connessa. Molte grandi organizzazioni desiderano aggiungere ulteriori misure di sicurezza, sommandole a quelle di base già incorporate dal protocollo 802.11b (che di per sé sono troppo deboli e soggette a violazioni).
In ogni caso, questi dispositivi veloci ed economici sono sempre più diffusi e continueranno a diffondersi ovunque. È indispensabile capire come configurare in modo appropriato i dispositivi wireless in modo da ottenere una sicurezza di base - soprattutto negli ambienti dove l'uso di reti isolate o di firewall dedicati risulta impossibile.
English to Italian: Turn a local computer script into an enterprise juggernaut (Windows & .NET Magazine article)
Source text - English Remote Administration with WMI
Turn a local computer script into an enterprise juggernaut
A trend seems to be growing in Redmond. Microsoft is taking administrative tools and command-line utilities once shackled to run on the local computer and transforming them into remote administration juggernauts. The catalyst behind the change is Windows Management Instrumentation (WMI), the underlying instrumentation on which the tools are built.
An often-overlooked fact about WMI is that from the beginning, Microsoft designed WMI to support remote administration scenarios. Any task that you can perform locally with a WMI-enabled tool, you can also perform remotely. To demonstrate WMI's remote administration agility, I want to walk you through several scenarios. First, I present a simple WMI script that performs an administrative task on the local computer. Next, I show you how to easily transform the script into a remote-savvy script. Finally, I show you how to run the script against all the computers on a remote IP subnet.
To get the most from this article, you need a basic knowledge of WMI and WMI scripting. If you need to build some skills, I encourage you to read Microsoft's "WMI Scripting Primer: Part 1" at http://msdn.microsoft.com/library/en-us/dnclinic/html/scripting06112002.asp.
Pick a Task, Any Task
The administrative task that I want to perform on the local computer is to check the Telnet service's Startup Type and Status. Now, before you say, "Please, not another services script," let me stress that the task is largely irrelevant. You can easily substitute this task with any of the hundreds of WMI scripts available at the Microsoft TechNet Script Center (http://www.microsoft.com/technet/scriptcenter). My objective is to show you how to take a common WMI script and scale it to service hundreds or thousands of remote computers.
Listing 1, page 54, shows the local version of the Telnet Server script, appropriately named TelnetCheck.vbs. The script begins by initializing the strComputer variable with a string that consists of a single dot, or period. In WMI scripting, the dot represents the local computer. Because this script runs on the local computer, I could have omitted the strComputer variable, but isolating the target computer variable (as Listing 1 shows) makes adapting the script to support remote computers easier.
The script uses VBScript's GetObject function to connect to the WMI service on the target computer. The string that the script passes to the GetObject function is a WMI connection string (aka a moniker) that consists of three components:
• the mandatory WMI prefix, "winmgmts:"
• security settings that tell WMI to impersonate the caller (i.e., use the security context of the person or process running the script to establish the connection)
• a WMI object path that comprises the target computer name and the WMI namespace to connect to on the target computer
GetObject returns a reference to the WMI scripting library's SWbemServices object, which represents an authenticated connection to WMI on a local or remote computer. To learn more about the WMI connection string, see "WMI Monikers," May 2001, http://www.winnetmag.com, InstantDoc 20401.
After the connection is established, Listing 1 calls the SWbemServices ExecQuery method to retrieve the instance of the Win32_Service class that represents the Telnet service. ExecQuery returns a reference to an SWbemObjectSet collection—another automation object in the WMI scripting library. If Telnet is installed on the target computer, ExecQuery returns a collection containing exactly one item, which is assigned to the reference variable named colServices. If Telnet isn't installed, ExecQuery returns an empty collection. The script uses the SWbemObjectSet Count property to determine whether Telnet is installed on the target computer. If the Count property is equal to 0, the WScript Echo method echoes to the console a message stating that Telnet isn't installed. Otherwise, the Echo method echoes the Telnet service's Startup Type (the Win32_Service StartMode property) and Status (the Win32_Service State property).
To run the script in Listing 1, open a command prompt and type the following (assuming you saved the script to a directory named C:\scripts):
C:\scripts>cscript telnetcheck.vbs
If Telnet is installed on the local computer, you should see a message similar to the following echoed to the console:
ATL-LAB-01,Disabled,Stopped
Go Remote
As you might guess, modifying Listing 1 to support remote computers is as simple as changing the value assigned to the strComputer variable to the name of any WMI-enabled computer in your domain. For example, to run the script against a remote computer named ATL-WEB-01, simply change
strComputer = "."
to
strComputer = "atl-web-01"
Of course, modifying the script each time you want to target a different remote computer isn't practical. A better solution would be to provide the remote computer name to the script as a command-line argument, as Listing 2 shows. The only difference between Listings 1 and 2 is that the line initializing strComputer in Listing 1 has been replaced with the code at callout A in Listing 2. The If...Then...Else statement at callout A checks for the presence of a command-line argument. If you pass an argument to the script, strComputer is initialized with the argument's value. Otherwise, strComputer is initialized with a dot, which represents the local computer. The remainder of Listing 2 is identical to Listing 1.
The following command demonstrates how to run Listing 2 against a remote computer named ATL-WEB-01:
C:\scripts>cscript
telnetcheck.vbs atl-web-01
The transparency of WMI remote access underscores one of WMI's most important features: Any task that you can perform locally, you can also perform remotely. WMI uses Distributed COM (DCOM), which uses remote procedure call (RPC) over a suitable network transport to access remote computers. Before you start feeling insecure about the ease with which WMI makes remote administration possible, let me point out that, by default, you must possess Administrator-equivalent credentials on the remote computer before you can use WMI to access it remotely. If you don't have such credentials and you try to run Listing 2 against a remote WMI-enabled computer, for example, GetObject will fail with a Permission denied error.
Here's a tip: To remote-enable the hundreds of WMI scripts available at the Script Center, simply replace the
strComputer = "."
line in the Microsoft script with the code at callout A in Listing 2. By doing so, you'll instantly create hundreds of scripts that can target remote computers; you simply need to specify the remote computer's name on the command line when you run the script.
Remotely Manage an Entire IP Subnet
You can use DNS-style names and IP addresses—in addition to NetBIOS names—
to identify remote computers. Suppose the computer named ATL-WEB-01 is assigned an IP address of 192.168.0.3 and resides in the atl.acme.com domain. Using the script that Listing 1 shows, you can use any of the following values to target the remote computer:
strComputer = "atl-web-01"
strComputer = "192.168.0.3"
strComputer = "atl-web-01.atl.acme.com"
WMI's recognition of DNS names and IP addresses opens the door for creative scripting solutions. The script in Listing 3, for example, demonstrates how to run a WMI script against an entire IP subnet.
Listing 3 begins by initializing the strIPSubnet variable with the network portion of the target subnet. (In my example, I use the private 192.168.0.0/24 class C network.) Next, the script creates a Windows Script Host (WSH) Shell object. The Shell object, which the variable objShell references, will call the Shell object's Exec method (I explain why in a moment). The script also enables VBScript's error-handling mechanism, On Error Resume Next, to trap the error that occurs if the script tries to connect to a non-WMI device or if the script tries to connect to a WMI-enabled computer without administrator credentials.
The real work begins with the For loop. During each loop iteration, the For loop increments a counter named strIPNode. The strIPNode counter represents the host portion of the target IP address. The first step inside the body of the For loop concatenates the current value of strIPNode with strIPSubnet and stores the resulting string in strComputer.
Next, the script uses the WSH Shell object's Exec method and the OS's ping.exe utility to ping the target computer. The reason I'm first pinging each computer has to do with the way WMI connections behave. Under typical conditions, WMI has a rather long connection timeout of 1 minute or longer. If a large number of computers in the target subnet are offline or unreachable, the script's performance suffers accordingly.
Suppose, for example, that half of the nodes in a typical class C subnet are unreachable. Without first running the Ping utility, the script will take several hours to run while WMI tries to connect to every IP address, only to time out on half of the addresses. If you have the script first ping each computer, you reduce the amount of time the script spends determining whether a computer is online and reachable.
I use the WSH Shell object's Exec method to run Ping. To control Ping's behavior, I reduce the number of echo requests that Ping sends to 2 (-n 2) and I set the reply timeout to 1000 milliseconds (-w 1000). By doing so, I reduce a 60-second or longer check (i.e., the WMI connection timeout) to a couple of seconds.
The Exec method returns a reference to a WshScriptExec object that the script can use to interact with and control the spawned process. I use the returned objScriptExec reference to capture Ping's output, which I then convert to lowercase and store in the strPingStdOut variable. Next, to determine whether Ping was successful, I use VBScript's InStr function to search for the substring "reply from" (followed by the target IP address) in Ping's output.
If Ping was successful, the code at callout A attempts to establish a WMI connection with the remote computer that the IP address stored in strComputer references. The GetObject call is identical to the GetObject call that you see in Listings 1 and 2.
Although I pinged the node to ensure that it's online, GetObject can fail if the node that the IP address in strComputer references isn't a WMI-enabled computer or if the security context under which the script is running doesn't have administrator access to the remote computer. The On Error Resume Next statement (enabled earlier) and the error-checking code immediately following the call to GetObject catch both errors.
The remainder of Listing 3's script—after the WMI connection is established—is identical to Listings 1 and 2. Following is a portion of the output that Listing 3 produces.
ATL-LAB-01: Disabled,Stopped
ATL-DC-01: Manual,Stopped
ATL-WEB-01: Disabled,Stopped
192.168.0.4: Permission denied
192.168.0.5: Telnet not installed.
192.168.0.6: Telnet not installed.
192.168.0.7: Host unreachable
If you're curious, the node with the IP address 192.168.0.4 is a Windows XP Home Edition computer, which doesn't permit remote WMI connections.
To run Listing 3 on a range of IP addresses in your network, you'll need to change the value assigned to strIPSubnet and the starting and ending values assigned to strIPNode in the For statement. You'll also need to ensure that you're running WSH 5.6, the version that introduced the Shell object's Exec method.
Put It to Work
You're probably wondering how you would adapt Listing 3 to run one of the WMI scripts in the Script Center. The good news is that the answer is simpler than you might think.
Suppose you want to remotely run the "Restart a Computer" script (which you'll find at http://www.microsoft.com/technet/scriptcenter/compmgmt/scrcm38.asp) against all the computers in a specified IP address range. You would follow these steps:
1. Replace the code at callout A in Listing 3 with the GetObject call in Microsoft's script:
2. Set objWMIService =
3. GetObject("winmgmts:" & _
4. "{impersonationLevel=impersonate," & _
5. "(Shutdown)}!\\" & strComputer & _
"\root\cimv2")
6. Replace the code at callout B in Listing 3 with the ExecQuery call in Microsoft's script:
7. Set colOperatingSystems = _
8. objWMIService.ExecQuery _
9. ("Select * from _
Win32_OperatingSystem")
10. Replace the code at callout C in Listing 3 with the For Each loop in Microsoft's script:
11. For Each objOperatingSystem in _
12. colOperatingSystems _
13. ObjOperatingSystem.Reboot()
Next
Listing 4 shows the final script. A word of caution before you unleash Listing 4 on your network: The script will also restart the computer running the script if the computer is assigned an IP address in the range of the target subnet. If such is the case, you can add an additional decision statement (If...Then...Else) inside the body of the main For loop to force the script to skip the local computer. To turn a local computer script into an enterprise juggernaut, you can apply the previous steps to most of the WMI scripts in the Script Center.
What About Security?
WMI security is robust. Although I don't have the space to delve into the nitty-gritty details of WMI security, I'll try to put any immediate concerns to rest and follow up with details in a subsequent article.
Whenever you use WMI, you pass through several security checkpoints. I've already mentioned the first: the WMI permissions checkpoint. WMI permissions are implemented at the namespace level (e.g., \root\cimv2) and checked when you establish a connection to WMI on a local or remote computer. You use the Microsoft Management Console (MMC) WMI Control snap-in to configure WMI permissions. By default, administrators are the only trustees granted the Remote Enable WMI permission.
The second checkpoint is DCOM security. The default DCOM setting for WMI is to impersonate the caller, which is the person or process running the script. The third and final checkpoint is the OS's security subsystem. The basic rule is that WMI doesn't provide access to anything you don't already have access to.
Finally, what about your Web browser? The good news is that all the WMI scripting objects (e.g., SWbemServices, SWbemObject) in the WMI scripting library are marked as unsafe for scripting. So, providing your users haven't lowered their Web browser's security settings, you're safe. However, if your users have lowered their browsers' security settings, you might consider implementing a system policy to manage your organization's security settings.
Listing 1
Listing 1: TelnetCheck.vbs
strComputer = "."
Set objWMIService = GetObject("winmgmts:{impersonationLevel=Impersonate}!\\" & _
strComputer & "\root\cimv2")
Set colServices = objWMIService.ExecQuery("SELECT * FROM Win32_Service " & _
"WHERE Name='tlntsvr'")
If colServices.Count = 0 Then
WScript.Echo strComputer & ",Telnet not installed."
Else
For Each objService In colServices
WScript.Echo objService.SystemName & "," & _
objService.StartMode & "," & _
objService.State
Next
End If
' BEGIN CALLOUT A
If WScript.Arguments.Count > 0 Then
strComputer = WScript.Arguments.Item(0)
Else
strComputer = "."
End If
' END CALLOUT A
Set objWMIService = GetObject("winmgmts:{impersonationLevel=Impersonate}!\\" & _
strComputer & "\root\cimv2")
Set colServices = objWMIService.ExecQuery("SELECT * FROM Win32_Service " & _
"WHERE Name='tlntsvr'")
If colServices.Count = 0 Then
WScript.Echo strComputer & ",Telnet not installed."
Else
For Each objService In colServices
WScript.Echo objService.SystemName & "," & _
objService.StartMode & "," & _
objService.State
Next
End If
Listing 3
Listing 3: Remote IP Subnet TelnetCheck.vbs
If InStr(strPingStdOut, "reply from " & strComputer) Then
' BEGIN CALLOUT A
Set objWMIService = GetObject("winmgmts:" & _
"{impersonationLevel=Impersonate}!\\" & _
strComputer & "\root\cimv2")
' BEGIN CALLOUT A
If Err.Number 0 Then
WScript.Echo strComputer & ": " & Err.Description
Err.Clear
Else
' BEGIN CALLOUT B
Set colServices = objWMIService.ExecQuery _
("SELECT * FROM Win32_Service WHERE Name='tlntsvr'")
' END CALLOUT B
' BEGIN CALLOUT C
If colServices.Count = 0 Then
WScript.Echo strComputer & ": Telnet not installed."
Else
For Each objService In colServices
WScript.Echo objService.SystemName & ": " & _
objService.StartMode & "," & _
objService.State
Next
End If
' END CALLOUT C
End If
Else
WScript.Echo strComputer & ": Host unreachable"
End If
Next
If InStr(strPingStdOut, "reply from " & strComputer) Then
Set objWMIService = GetObject("winmgmts:" & _
"{impersonationLevel=impersonate,(Shutdown)}!\\" & _
strComputer & "\root\cimv2")
If Err.Number 0 Then
WScript.Echo strComputer & ": " & Err.Description
Err.Clear
Else
Set colOperatingSystems = objWMIService.ExecQuery _
("SELECT * FROM Win32_OperatingSystem")
For Each objOperatingSystem in colOperatingSystems
objOperatingSystem.Reboot()
Next
End If
Else
WScript.Echo strComputer & ": Host unreachable"
End If
Next
Translation - Italian Amministrazione remota con WMI
Come trasformare lo script di un computer locale in un potente elemento per l'azienda
A Redmond sembra esserci un trend crescente. Microsoft prende le precedentemente trascurate utility a linea di comando e tool amministrativi da eseguire sul computer locale per trasformarli in potenti elementi di amministrazione remota. Il catalizzatore che sta dietro a questo cambiamento è WMI (Windows Management Instrumentation), la strumentazione sottostante sulla base della quale vengono costruiti questi tool.
Una particolarità spesso trascurata relativamente a WMI è costituita dal fatto che questa tecnologia è stata progettata fin dall'inizio da Microsoft al fine di supportare gli scenari di amministrazione remota. Qualsiasi operazione che si può effettuare localmente usando un tool WMI-enabled può essere effettuata anche in modo remoto. Al fine di dimostrare le capacità di amministrazione remota che caratterizzano WMI, in questo articolo prenderemo in considerazione alcuni scenari. Per prima cosa presenteremo un semplice script WMI che compie un'operazione amministrativa sul computer locale. Successivamente vedremo come trasformare con facilità questo script in modo che possa operare anche remotamente. Infine vedremo come eseguire lo script nei confronti di tutti i computer presenti in una subnet IP remota.
Per ottenere il meglio da questo articolo, i lettori dovrebbero avere una conoscenza almeno di base di WMI e dello scripting WMI. Se desiderate migliorare le vostre capacità in tal senso, vi consigliamo di leggere l'articolo Microsoft intitolato "WMI Scripting Primer: Part 1", disponibile all'indirizzo http://msdn.microsoft.com/library/en-us/dnclinic/html/scripting06112002.asp.
Scegliere un'operazione, una qualsiasi operazione
L'operazione amministrativa che intendiamo eseguire sul computer locale consiste nel controllare i valori Startup Type e Status del servizio Telnet. Prima che i lettori possano affermare "Per piacere, non un altro script sui servizi!", permetteteci di sottolineare che il tipo di operazione è in gran parte irrilevante. Si può facilmente sostituire questa operazione con uno qualsiasi delle centinaia di script WMI disponibili presso il Microsoft TechNet Script Center (http://www.microsoft.com/technet/scriptcenter). Il nostro obiettivo è quello di spiegare in che modo prendere un comune script WMI e adattarlo in modo che sia in grado di servire centinaia o migliaia di computer remoti.
Il listato 1 presenta la versione locale dello script Telnet Server, appropriatamente chiamato TelnetCheck.vbs. Lo script comincia inizializzando la variabile strComputer con una stringa che contiene un singolo punto. Nello scripting WMI, il punto rappresenta il computer locale. Dal momento che questo script viene eseguito sul computer locale, avremmo potuto omettere la variabile strComputer; in ogni caso, la decisione di isolare la variabile del computer di destinazione (come indica il listato 1) rende più facile adattare lo script al supporto dei computer remoti.
Lo script usa la funzione GetObject di VBScript per connettersi al servizio WMI sul computer di destinazione. La stringa che lo script passa alla funzione GetObject è una stringa (alias moniker) di connessione WMI, che consiste in tre componenti:
• il prefisso obbligatorio WMI, "winmgmts:"
• le impostazioni di sicurezza che indicano a WMI di impersonare il chiamante (ovvero di usare il contesto di sicurezza della persona o del processo che esegue lo script per instaurare la connessione)
• un percorso dell'oggetto WMI che comprende il nome del computer di destinazione e lo spazio di nomi WMI per connettersi al computer di destinazione
GetObject restituisce una referenza all'oggetto SWbemServices della libreria di scripting WMI, che rappresenta una connessione autenticata a WMI su un computer locale o remoto. Per ottenere ulteriori informazioni sulla stringa di connessione WMI, fare riferimento all'articolo intitolato "WMI Monikers", maggio 2001, http://www.winnetmag.com, InstantDoc 20401.
Dopo che la connessione è stata instaurata, il listato 1 chiama il metodo SWbemServices ExecQuery per recuperare l'istanza della classe Win32_Service che rappresenta il servizio Telnet. ExecQuery restituisce una referenza a una collezione SWbemObjectSet - un altro oggetto di automazione della libreria di scripting WMI.
Se sul computer di destinazione è installato Telnet, ExecQuery restituisce una collezione che contiene esattamente un elemento, il quale viene assegnato alla variabile di referenza chiamata colServices. Se invece Telnet non è installato, ExecQuery restituisce una collezione vuota. Lo script usa la proprietà Count dell'oggetto SWbemObjectSet per determinare se Telnet è installato o meno sul computer di destinazione. Se il valore della proprietà Count è uguale a 0, il metodo WScript Echo visualizza sulla consolle un messaggio che indica che Telnet non è installato. In caso contrario, il metodo Echo visualizza lo Startup Type (la proprietà Win32_Service StartMode) e lo Status (la proprietà Win32_Service State) del servizio Telnet.
Per eseguire lo script del listato 1, aprire un prompt dei comandi e digitare quanto segue (nell'ipotesi di aver salvato lo script in una directory chiamata C:\scripts):
C:\scripts>cscript telnetcheck.vbs
Se Telnet è installato sul computer locale, sulla consolle dovrebbe essere visualizzato un messaggio simile al seguente:
ATL-LAB-01,Disabled,Stopped
Passare a una configurazione remota
Come potreste aver già indovinato, modificare il listato 1 al fine di supportare i computer remoti è semplice come cambiare il valore assegnato alla variabile strComputer impostandolo sul nome di un qualsiasi computer WMI-enabled presente nel dominio. Per esempio, al fine di eseguire lo script nei confronti di un computer remoto chiamato ATL-WEB-01, è sufficiente cambiare semplicemente
strComputer = "."
in
strComputer = "atl-web-01"
Ovviamente, la necessità di modificare lo script tutte le volte che si desidera indirizzarsi a un computer remoto diverso non è affatto pratica. Una soluzione migliore potrebbe essere quella di fornire allo script il nome del computer remoto sotto forma di un argomento della linea di comando, come indica il listato 2. L'unica differenza tra il listato 1 e il listato 2 è rappresentata dal fatto che la linea che inizializza strComputer nel listato 1 è stata sostituita dal codice in corrispondenza del richiamo A nel listato 2. L'istruzione If...Then...Else in corrispondenza del richiamo A controlla la presenza di un argomento nella linea di comando. Se allo script viene passato un argomento, strComputer viene inizializzata con il valore di quell'argomento. In caso contrario, strComputer viene invece inizializzata con un punto, che rappresenta il computer locale. Il resto del listato 2 è identico al listato 1.
Il comando seguente dimostra come eseguire il listato 2 nei confronti di un computer remoto chiamato ATL-WEB-01:
C:\scripts>cscript
telnetcheck.vbs atl-web-01
La trasparenza dell'accesso remoto WMI sottolinea una delle caratteristiche più importanti di WMI: qualsiasi operazione che è possibile compiere localmente si può effettuare anche in modo remoto. WMI usa DCOM (Distributed Component Object Model), che a sua volta usa lo schema RPC (Remote Procedure Call) su un opportuno trasporto di rete per accedere ai computer remoti. Prima di iniziare ad avere qualche dubbio sulla facilità con cui WMI consente l'amministrazione remota, permetteteci di sottolineare che per default, prima di poter utilizzare WMI per accedere in modo remoto a un computer, è necessario possedere delle credenziali equivalenti ad Administrator su quella macchina. Se non si dispone di queste credenziali e si cerca di eseguire il listato 2 nei confronti di un computer WMI-enabled, per esempio, GetObject fallirà con un errore Permission denied.
Ecco un consiglio: per attivare il funzionamento remoto delle centinaia di script WMI disponibili presso lo Script Center, è sufficiente sostituire semplicemente la linea
strComputer = "."
nello script Microsoft con il codice in corrispondenza del richiamo A nel listato 2. Con questa operazione si ottengono istantaneamente centinaia di script che possono indirizzarsi ai computer remoti; basta specificare il nome del computer remoto sulla linea di comando quando si esegue lo script.
Gestire in modo remoto un'intera subnet IP
Per identificare i computer remoti è possibile usare gli indirizzi IP e i nomi in stile DNS - oltre ai nomi NetBIOS. Si supponga che al computer chiamato ATL-WEB-01 sia stato assegnato l'indirizzo IP 192.168.0.3 e che quel computer risieda nel dominio atl.acme.com. Usando lo script indicato dal listato 1, è possibile usare uno qualsiasi dei valori seguenti per indirizzarsi al computer remoto:
strComputer = "atl-web-01"
strComputer = "192.168.0.3"
strComputer = "atl-web-01.atl.acme.com"
La capacità di WMI di riconoscere gli indirizzi IP e i nomi DNS apre la strada alla possibilità di realizzare delle soluzioni di scripting creative. Lo script del listato 3, per esempio, dimostra in che modo eseguire uno script WMI nei confronti di un'intera subnet IP.
Il listato 3 comincia inizializzando la variabile strIPSubnet con la porzione di rete della subnet di destinazione (nel nostro esempio, usiamo la rete privata di classe C 192.168.0.0/24). Successivamente, lo script crea un oggetto Shell WSH (Windows Scripting Host). L'oggetto Shell, che viene referenziato dalla variabile objShell, chiamerà il metodo Exec dell'oggetto stesso (lo spiegheremo tra un momento). Lo script attiva inoltre il meccanismo di VBScript per la gestione degli errori, On Error Resume Next, in modo da intrappolare gli errori che vengono generati quando lo script cerca di connettersi a un dispositivo non-WMI, oppure quando lo script cerca di connettersi a un computer WMI-enabled senza disporre di credenziali amministrative.
Il vero lavoro inizia con il loop For. Nel corso di ogni iterazione, il loop For incrementa un contatore chiamato strIPNode. Quest'ultimo rappresenta la porzione host dell'indirizzo IP di destinazione. La prima operazione nel corpo del loop For concatena il valore corrente di strIPNode con strIPSubnet e archivia la stringa risultante in strComputer.
Successivamente, lo script usa il metodo Exec dell'oggetto WSH Shell e l'utility ping.exe del sistema operativo al fine di fare ping sul computer di destinazione. Il motivo per cui per prima cosa facciamo ping su ogni computer deriva dal modo in cui si comportano le connessioni WMI. Nelle condizioni tipiche, WMI presenta un timeout di connessione piuttosto lungo, pari ad almeno un minuto. Se nella subnet di destinazione molti i computer sono off-line o sono comunque irraggiungibili, le prestazioni dello script ne soffriranno proporzionalmente.
Si supponga, per esempio, che metà dei nodi in una tipica subnet classe C siano irraggiungibili. Se per prima cosa non viene eseguita l'utility Ping, l'esecuzione dello script richiederà varie ore mentre WMI cerca di connettersi a ciascun indirizzo IP, soltanto per andare timeout sulla metà degli indirizzi. Se invece lo script effettua per prima cosa un ping su ciascun computer, si riduce la quantità di tempo impiegata per determinare se un computer è on-line ed è raggiungibile.
Per eseguire Ping abbiamo usato il metodo Exec dell'oggetto WSH Shell. Al fine di controllare il comportamento di Ping, abbiamo ridotto a 2 (-n 2) il numero di richieste echo che Ping invia e abbiamo impostato il timeout di risposta su 1000 millisecondi (-w 1000). Grazie a questa operazione, abbiamo ridotto a un paio di secondi un controllo che richiedeva almeno 60 secondi (ovvero il timeout di connessione WMI).
Il metodo Exec restituisce una referenza a un oggetto WshScriptExec, che lo script può usare per interagire con il processo generato e per controllarlo. Abbiamo usato la referenza restituita objScriptExec per catturare l'output di Ping, che successivamente viene convertito in minuscolo e archiviato nella variabile strPingStdOut. Infine, per stabilire se Ping ha avuto successo, usiamo la funzione InStr di VBScript per ricercare la sottostringa "reply from" (seguita dall'indirizzo IP di destinazione) nell'output di Ping.
Se il Ping ha avuto successo, il codice in corrispondenza del richiamo A cerca di instaurare una connessione WMI con il computer remoto referenziato dall'indirizzo IP contenuto in strComputer. La chiamata a GetObject è identica a quella che si può vedere nel listato 1 e nel listato 2.
Anche se abbiamo fatto ping sul nodo per assicurarci che sia on-line, GetObject potrebbe fallire se il nodo referenziato dall'indirizzo IP in strComputer non è costituito da un computer WMI-enabled, oppure se il contesto di sicurezza sotto il quale viene eseguito lo script non dispone dell'accesso amministrativo al computer remoto. L'istruzione On Error Resume Next (attivata in precedenza) e il codice per il controllo degli errori immediatamente successivo alla chiamata a GetObject consentono di catturare entrambi gli errori.
La parte restante dello script nel listato 3 - dopo l'instaurazione della connessione WMI - è identica a quella del listato 1 e del listato 2. La seguente è una parte dell'output generato dal listato 3:
ATL-LAB-01: Disabled,Stopped
ATL-DC-01: Manual,Stopped
ATL-WEB-01: Disabled,Stopped
192.168.0.4: Permission denied
192.168.0.5: Telnet not installed.
192.168.0.6: Telnet not installed.
192.168.0.7: Host unreachable
Se avete la curiosità di saperlo, il nodo con indirizzo IP 192.168.0.4 è un computer Windows XP Home Edition, che non permette connessioni WMI remote.
Al fine di eseguire il listato 3 su una serie di indirizzi IP nella vostra rete, dovete modificare il valore assegnato a strIPSubnet e i valori iniziali e finali assegnati a strIPNode nell'istruzione For. È inoltre necessario verificare di usare WSH 5.6: la versione che ha introdotto il metodo Exec dell'oggetto Shell.
Al lavoro
Probabilmente state chiedendovi come sia possibile adattare il listato 3 per eseguire uno degli script WMI presenti nello Script Center. La buona notizia è che ciò è più semplice di quanto si potrebbe pensare.
Si supponga di voler avviare in modo remoto lo script "Restart a Computer" (che si può trovare all'indirizzo http://www.microsoft.com/technet/scriptcenter/compmgmt/scrcm38.asp) nei confronti di tutti i computer entro una gamma specificata di indirizzi IP. A questo fine è necessario seguire queste fasi:
1. Sostituire il codice in corrispondenza del richiamo A nel listato 3 con la chiamata a GetObject nello script di Microsoft:
Set objWMIService =
GetObject("winmgmts:" & _
"{impersonationLevel=impersonate," & _
"(Shutdown)}!\\" & strComputer & _
"\root\cimv2")
2. Sostituire il codice in corrispondenza del richiamo B nel listato 3 con la chiamata a ExecQuery nello script di Microsoft:
Set colOperatingSystems = _
objWMIService.ExecQuery _
("Select * from _
Win32_OperatingSystem")
3. Sostituire il codice in corrispondenza del richiamo C nel listato 3 con il loop For Each nello script di Microsoft:
For Each objOperatingSystem in _
colOperatingSystems _
ObjOperatingSystem.Reboot()
Next
Il listato 4 indica lo script finale. In ogni caso, è indispensabile procedere con cautela prima di utilizzare il listato 4 sulla propria rete: questo script, infatti, riavvia anche il computer che lo esegue se a quest'ultimo è stato assegnato un indirizzo IP appartenente alla gamma della subnet di destinazione. Se si verifica questa eventualità, si può aggiungere un'ulteriore istruzione decisionale (If...Then...Else) all'interno del corpo del loop For principale, in modo da forzare lo script a saltare il computer locale. Per trasformare lo script di un computer locale in una potenza a livello di intera azienda, potete applicare le fasi precedenti alla maggior parte degli script WMI offerti dalloScript Center.
Che dire della sicurezza?
La sicurezza WMI è piuttosto forte. In questo articolo non disponiamo dello spazio necessario per esaminare in dettaglio il funzionamento della sicurezza WMI, ma cercheremo comunque di eliminare le preoccupazioni più immediate facendo seguire i dettagli in un articolo successivo.
Tutte le volte che si usa WMI, vengono attraversati vari punti di controllo di sicurezza. Abbiamo già citato il primo: il punto di controllo dei permessi WMI. I permessi WMI vengono implementati a livello di spazio dei nomi (ovvero \root\cimv2) e vengono controllati quando si instaura una connessione con WMI su un computer locale o remoto. Per configurare il permessi WMI bisogna usare lo snap-in MMC (Microsoft Management Console) WMI Control. Per default, il permesso WMI Remote Enable viene accordato unicamente agli amministratori.
Il secondo punto di controllo è rappresentato dalla sicurezza DCOM. L'impostazione DCOM di default per WMI consiste nell'impersonare il chiamante, ovvero la persona o il processo che esegue lo script. Il terzo e ultimo punto di controllo è costituito dal sottosistema di sicurezza del sistema operativo. La regola di base è quella secondo cui WMI non fornisce l'accesso a qualcosa che non sia già accessibile.
Infine, che dire del browser Web? La buona notizia è che tutti gli oggetti di scripting WMI (per esempio, SWbemServices, SWbemObject) nella libreria di scripting WMI sono contrassegnati come insicuri per lo scripting. In conseguenza, se gli utenti non hanno ridotto le impostazioni di sicurezza del loro browser Web, si è al sicuro. Se invece gli utenti hanno ridotto le impostazioni di sicurezza del browser, si potrebbe valutare l'opportunità di implementare una politica di sistema al fine di gestire le impostazioni di sicurezza nell'azienda.
L'autore
Bob Wells ([email protected]) è MCSE (Microsoft Certified Systems Engineer), MCT (Microsoft Certified Trainer), oltre che Americas Technology Engineer presso la Operations Services Division di HP.
Listato 1: TelnetCheck.vbs
strComputer = "."
Set objWMIService = GetObject("winmgmts:{impersonationLevel=Impersonate}!\\" & _
strComputer & "\root\cimv2")
Set colServices = objWMIService.ExecQuery("SELECT * FROM Win32_Service " & _
"WHERE Name='tlntsvr'")
If colServices.Count = 0 Then
WScript.Echo strComputer & ",Telnet not installed."
Else
For Each objService In colServices
WScript.Echo objService.SystemName & "," & _
objService.StartMode & "," & _
objService.State
Next
End If
Listato 2: TelnetCheck.vbs per l'argomento remoto della linea di comando
' BEGIN CALLOUT A
If WScript.Arguments.Count > 0 Then
strComputer = WScript.Arguments.Item(0)
Else
strComputer = "."
End If
' END CALLOUT A
Set objWMIService = GetObject("winmgmts:{impersonationLevel=Impersonate}!\\" & _
strComputer & "\root\cimv2")
Set colServices = objWMIService.ExecQuery("SELECT * FROM Win32_Service " & _
"WHERE Name='tlntsvr'")
If colServices.Count = 0 Then
WScript.Echo strComputer & ",Telnet not installed."
Else
For Each objService In colServices
WScript.Echo objService.SystemName & "," & _
objService.StartMode & "," & _
objService.State
Next
End If
Listato 3: TelnetCheck.vbs per la subnet IP remota
If InStr(strPingStdOut, "reply from " & strComputer) Then
' BEGIN CALLOUT A
Set objWMIService = GetObject("winmgmts:" & _
"{impersonationLevel=Impersonate}!\\" & _
strComputer & "\root\cimv2")
' BEGIN CALLOUT A
If Err.Number 0 Then
WScript.Echo strComputer & ": " & Err.Description
Err.Clear
Else
' BEGIN CALLOUT B
Set colServices = objWMIService.ExecQuery _
("SELECT * FROM Win32_Service WHERE Name='tlntsvr'")
' END CALLOUT B
' BEGIN CALLOUT C
If colServices.Count = 0 Then
WScript.Echo strComputer & ": Telnet not installed."
Else
For Each objService In colServices
WScript.Echo objService.SystemName & ": " & _
objService.StartMode & "," & _
objService.State
Next
End If
' END CALLOUT C
End If
Else
WScript.Echo strComputer & ": Host unreachable"
End If
Next
If InStr(strPingStdOut, "reply from " & strComputer) Then
Set objWMIService = GetObject("winmgmts:" & _
"{impersonationLevel=impersonate,(Shutdown)}!\\" & _
strComputer & "\root\cimv2")
If Err.Number 0 Then
WScript.Echo strComputer & ": " & Err.Description
Err.Clear
Else
Set colOperatingSystems = objWMIService.ExecQuery _
("SELECT * FROM Win32_OperatingSystem")
For Each objOperatingSystem in colOperatingSystems
objOperatingSystem.Reboot()
Next
End If
Else
WScript.Echo strComputer & ": Host unreachable"
End If
Next
More
Less
Translation education
Master's degree
Experience
Years of experience: 40. Registered at ProZ.com: Mar 2002.
Microsoft Excel, Microsoft Word, Dragon Naturally Speaking, Emergency redundant data & fax connection, Other in-house developed software, Powerpoint, Trados Studio
Please allow me to introduce myself: I am not the usual 'one-size-fits-all' translator, as I work *exclusively* in my specialization fields: Information Technology, Computers, Hardware, Software, Networking, Consumer Electronics, Multimedia, Mobile devices, Audio/Video/Photo, Telecommunications, etc. - from English into Italian (my mother tongue).
You might want to give a look at my details below. I have built 24 years of experience in this kind of translation and - thanks to quality, speed and affordability of my services - have been able to win as direct clients all the major Italian Computer Publishing Houses, such as:
Mondadori Informatica (PC Professionale ), VNU Business Publications Italia (PC Magazine, Network News Italia, Computer Reseller News, Computer Idea), Duke Italia (Windows & .Net Magazine, Linux Journal, Internet World), Edizioni Master (Computer Bild Italia, AudioVideoFoto Bild Italia), PlayPress Publishing (Chip Magazine, Vista Magazine)
Another important direct client is Dell Computer Italy.
My background in engineering and as a technical journalist, coupled with so many years in translation, can make a real difference. Last but not least, I can use Trados and my rates are very competitive!
Education :
* Scientific High School, Collegio Santa Maria, Verbania, graded 60/60.
* College of Engineering, Politecnico di Milano, 25/30 ex.
Experience :1988-now In 1988 I founded Microwide, a company that provides translation services. In that position I have further improved my experience in the field of computer-related technical translation from English into Italian, being able to win as customers all the major Italian Publishing Houses in the IT industry.
1986-1988 While continuing as a consultant my activity of translator and journalist, I joined J.soft s.r.l. in Milan (a former publisher that became a nationwide exclusive software distributor for Lotus software and other IT products) as marketing manager. In that period I also wrote two computer books ("Il libro dei giochi per il Commodore 64" and "Lavoriamo con il Commodore 16"), published nationwide by Gruppo Editoriale Jackson.
1984-1986 Developing a previous hobby, I started my first job as editor for the computer magazines SuperVic, SuperCommodore 64, and PaperSoft, published by Gruppo Editoriale Jackson in Milan. In 1986 I graduated as a journalist (n. 55663, Milan). Afterwards, in the spare time I started a consulting activity as a translator from English into Italian, translating many articles published by those and other magazines. In the same period I translated a number of computer books for the same publisher.
Skills :
All the mainstream office tools (Windows 98/NT/2000/XP, MS-Office, databases, servers, Internet software, and much much more). I use a number of state-of-the-art computers systems (all Windows), a 24x7 Internet connection, voice recognition software, in-house developed software, and many other tools.
Current jobs :
I am translating on an on-going basis whole or part of the following Italian computer magazines: * Windows & .NET Magazine (Gruppo Editoriale Duke Italia) * Linux Journal (Gruppo Editoriale Duke Italia) * Internet World (Gruppo Editoriale Duke Italia) * PC Magazine (VNU Business Publications Italia) * Network News Italia (VNU Business Publications Italia) * Computer Reseller News (VNU Business Publications Italia) * Computer Idea (VNU Business Publications Italia) * Data Business (VNU Business Publications Italia) * CHIP Magazine (PlayPress Publications) * Computer Bild Italia (Edizioni Master) * AudioVideoFoto Bild Italia (Edizioni Master)
Among other jobs, I am translating on an on-going basis technical and marketing documentation for Dell Computer Italy.
Objective :
To start a collaboration as a consulting translator which utilizes my more than 20 years of translation experience, my experience in the IT industry, and my experience as a journalist.
I *don't* offer proofreading/editing services, but translation only!
Dynamic content (javascript) disabled in this profile. FAQ 
Expertise 
Portfolio 
CV/Resume (DOC)
