Monday, October 10, 2011

ESXi Virtual Adapter in Promiscuous Mode

To install Firewalls, Port Sniffers, IDS, etc as guest virtual machines on an ESXi host which need network adapters working in promiscuous mode, it's not enough to put the virtual adapters in promiscuous mode, but you need as well to allow promiscuous mode on the vSwitch in which those virtual adapters are connected to.


To configure a portgroup or virtual switch to allow promiscuous mode:
  1. Log in to the ESX/ESXi host or vCenter Server using vSphere Client.
  2. Select the ESX/ESXi host in the inventory.
  3. Click the Configuration tab.
  4. In the Hardware section , click Networking.
  5. Click Properties of the virtual switch for which you want to enable promiscuous mode.
  6. Select the virtual switch or portgroup you wish to modify and click Edit.
  7. Click the Security tab.
  8. From the dropdown for Promiscuous Mode, select Accept.
HINTS: 
  • Software running inside a virtual machine may be able to monitor any and all traffic moving across a vSwitch if it is allowed to enter promiscuous mode. 
  • The setting on the portgroup overrides the virtual switch setting.
  • Placing the guest adapter in promiscuous mode causes it to detect all frames passed on the virtual switch that are allowed under the VLAN policy for the associated portgroup.

Sunday, October 9, 2011

Linux Brdige

Installing the software


The program you’re going to need is called brctl and is included in bridge-utils. Find it in Synaptic, or install it using this command:
aptitude install bridge-utils
This program will allow us to set up and use the bridge interface. The bridge interface appears as a new interface in ip link, much like eth0 or eth1. It doesn’t physically exist on your computer, but instead it is a virtual interface that just takes the packets from one physical interface, and transparently routes them to the other.


Setting up your Bridge


Manual bridge setup


First step to creating the bridge network is actually creating it. Issue this command to get the ball rolling and create the new interface.
brctl addbr br0
The name br0 is totally up to you, this is just an example name that I’ve chosen for the wiki article. Anyway, now that you have your bridge device, you have to add the interfaces that are gonna be bridged. You can cross-check the enumeration of your ethernet devices with (eth0, eth1, etc. is common):
ip addr show
Add both the interface with the second computer, and the interface that leads to the existing network. Do it with this command:
brctl addif br0 eth0 eth1
This will add the two interfaces eth0 and eth1 to bridge br0. Simple enough. There’s no distinction with how you add the bridges, or what order you do it, or any special commands you have to add to distinguish them. So don’t worry about that.


Well, now we have our bridges, so bring all the interfaces up, and you’ll be set!


Configuring bridging in /etc/network/interfaces


- To make your bridge a little more permanent, you’re gonna need to edit /etc/network/interfaces. Using our example names, make it look like this and you’re set (if you want to use DHCP):



 # This file describes the network interfaces available on your system
 # and how to activate them. For more information, see interfaces(5).

 # The loopback network interface
 auto lo br0
 iface lo inet loopback


 # Set up interfaces manually, avoiding conflicts with, e.g., network manager
 iface eth0 inet manual
 iface eth1 inet manual


 # Bridge setup
 iface br0 inet dhcp
 bridge_ports eth0 eth1


To bring up your bridge, you just have to issue  # ifup br0 and it’ll bring up the other necessary interfaces without anything in your interfaces file about the bridged interfaces.


- If you like static IP’s, then you can just add the static IP options under the br0 interface setup. Kinda like this:



 # This file describes the network interfaces available on your system
 # and how to activate them. For more information, see interfaces(5).

 # The loopback network interface
 auto lo br0
 iface lo inet loopback


 # Set up interfaces manually, avoiding conflicts with, e.g., network manager
 iface eth0 inet manual
 iface eth1 inet manual


 # Bridge setup
 iface br0 inet static
        bridge_ports eth0 eth1
        address 192.168.1.2
        broadcast 192.168.1.255
        netmask 255.255.255.0
        gateway 192.168.1.1


Source Link: http://wiki.debian.org/BridgeNetworkConnections

Cisco NTP Client Configuration

Display the system clock

Use the show clock command in EXEC mode, enter:

show clock
OR
show clock detail
The last example will show the clock source (such as NTP) and the current summer time setting etc.

Set the system clock manually

To set the time use the following 24 hour time format:
clock set 20:30:13 July 2009
The syntax is as follows:

clock set hh:mm:ss day month year
OR
clock set hh:mm:ss month day year

Set the system clock via NTP server

The more recent versions of IOS (version 10+) support NTP version 4.
To make your router synchronize with a ClockWatch NTP server with the IP address of 192.168.1.1, use the IOS commands:

Router> enable
password: *********
Router# config t
Router(config)# ntp server 192.168.1.1
Router(config)# exit
Router# wr mem

The NTP server command forms a server association with the ClockWatch server. The Cisco router then goes through the process of validating the ClockWatch server. This may be immediate or take several minutes. You can confirm it has been synchronized by showing the NTP associations:

Router>show ntp associations

address ref clock st when poll reach delay offset disp
*~192.168.1.1 .CLKW. 1 35 64 377 23.9 -0.45 1.2

The star (*) displayed next to the configured (~) peer indicates the router is synchronized with ClockWatch. A pound sign (#)  indicates that the router isn't syncing with ClockWatch even though NTP request and response packets are being exchanged. In this case, check the output of the show ntp associations detail command or enable the NTP debugs to see why the clocks aren't syncing. 

One possible reason for the failure to sync is that the NTP client's clock differs by more than 4000 seconds from ClockWatch's clock. On Cisco routers, a time difference of greater than 4000 seconds is considered out of range, and prevents the router from syncing to the server. This doesn't apply when you first configure an NTP peer on a Cisco router or at a reload. In this case, the NTP client's (the Cisco router's) clock is changed to match the NTP server's clock, no matter how large the difference.

Tips:

- Check that ClockWatch Server has been synchronized to an external timeserver within the last 24 hours. This is a NTP server qualification requirement of the Cisco NTP client implementation.

- ClockWatch does not support authentication. Turn off authentication by issuing the IOS configuration command no ntp authentication. Authentication is normally turned on in IOS version 12.4 and above.

- You can manually change the client's clock (using the clock set command) to within a few minutes of the ClockWatch Server's clock to facilitate the synchronization.

- Make sure you check the time zone of the client's clock; local time is displayed, but time values in NTP messages are stored in UTC (GMT).

Source Links:

Friday, October 7, 2011

NAT Router on Linux

1- Enable Packet forwarding for IPv4 via /etc/sysctl.conf, by uncommenting the following line:
net.ipv4.ip_forward=1
2- Add the following lines to the bottom of /etc/rc.local:
/sbin/iptables -P FORWARD ACCEPT
/sbin/iptables --table nat -A POSTROUTING -o eth0 -j MASQUERADE
Taking into consideration that eth0 is the interface connected to the internet.

Thursday, October 6, 2011

NTP Server & Client

Network Time Protocol allows distributed devices to synchronize timestamps, which is critical to effective log analysis because it allows audit personnel to establish accurate event sequences across multiple devices.

Installing NTP Server or Client on Debain linux is never easier:
apt-get install ntp
That's it, just edit the configuration file /etc/ntp.conf for both client and server.

Configuring NTP Server

- Use two to three servers for good accuracy. It's better to choose NTP servers near you in your country or your continent.
server 0.europe.pool.ntp.org
server 1.europe.pool.ntp.org
server 2.europe.pool.ntp.org
server 3.europe.pool.ntp.org
- If the server is going to provide time for other devices (PCs, Servers, Security and Network devices), you can define the networks that are allowed to synchronize with the NTP server.
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
- Restart NTP for these settings to take effect using the following command:
/etc/init.d/ntp restart
-To check if the NTP server is synchronized with NTP servers in the configuration file, use the following command:
ntpq -p
- Hint: Public Internet Time Servers
  • pool.ntp.org - This points to a random worldwide time server.
  • europe.pool.ntp.org - This points to a random European time server.
  • uk.pool.ntp.org - This points to a random United Kingdom based time server.


Configuring NTP Client

If you have linux machines to synchronize with the server, apply the following:

- Add your NTP server in the configuration file /etc/ntp.conf.
server 192.168.1.1
while 192.168.1.1 is your NTP server

- Restart the NTP service for settings to take effect:
/etc/init.d/ntp restart

Tuesday, October 4, 2011

How can I disable/enable the "Administrative Share" creation in Windows NT/2000/XP/2003?

Every Windows NT/W2K/XP/2003 machine automatically creates a share for each drive on the system. These shares are hidden, but available with full control to domain administrators. The drive letter, followed by the $ sign is the name, and it is shared from the root. When trying to attain a highly secure network, you may wish to address this potential security issue by disabling these shares, or at least restricting their permissions to specific users or services. 

The default-hidden shares are:
  • C$ D$ E$ - Root of each partition. For a Windows NT workstation/W2K/2003/XP Professional computer only members of the Administrators or Backup Operators group can connect to these shared folders. For a Windows NT Server/W2K Server computer, members of the Server Operators group can also connect to these shared folders.
  • ADMIN$ - %SYSTEMROOT% This share is used by the system during any remote administration of a computer. The path of this resource is always the path to the W2K/NT system root (the directory in which W2K/NT is installed usually C:\Winnt and in XP it's C:\Windows).
  • FAX$ - On W2K Server, this used by fax clients in the process of sending a fax. The shared folder temporarily caches files and accesses cover pages stored on the server.
  • IPC$ - Temporary connections between servers using named pipes essential for communication between programs. It is used during remote administration of a computer and when viewing a computer's shared resources. This share can be very dangerous and can be used to extract large amounts of information about your network, even by an anonymous account.
  • NetLogon - This share is used by the Net Logon service of a W2K, 2003 and NT Server computer while processing domain logon requests, and by Pre-W2K computers when running logon scripts.
  • PRINT$ - %SYSTEMROOT%\SYSTEM32\SPOOL\DRIVERS Used during remote administration of printers.
It is possible to simply remove the share from Server Manager (in NT) or Shared Folders (in W2K/XP/2003) but the problem with this method is that the shares will automatically be recreated when the machine reboots.
You can disable the automatic administrative share creation via Group Policy, but this is a much simpler way:
In order to disable these shares permanently, a registry edit will be necessary.

Servers

For NT 4.0/W2K/Windows Server 2003s, the change is:
Hive: HKEY_LOCAL_MACHINE Key: SYSTEM\CurrentControlSet\Services\LanManServer\Parameters Name: AutoShareServer Data Type: REG_DWORD Value: 0
Idiot proof note: If you can't find the value in the registry under the exact location (i.e. it does not exist) - please right click in the right pane of the window and create it.
Note: A reboot is necessary for this to take effect.

Workstations

For NT 4.0 Workstation/W2K Pro/XP Pro, the change is:
Hive: HKEY_LOCAL_MACHINE Key: SYSTEM\CurrentControlSet\Services\LanManServer\Parameters Name: AutoShareWks Data Type: REG_DWORD Value: 0
A double idiot proof note: If you can't find the value in the registry under the exact location (i.e. it does not exist) - please right click in the right pane of the window and create it.
Note: Again, a reboot is necessary for this to take effect. If you want the administrative shares to be re-created, you can change the value back to 1.
Note: Some applications depend on the presence of these shares. If things stop working you'll know to re-enable the shares.
Security note: Unfortunately this registry hack does NOT stop the IPC$ share and this is a share that is often used by hackers to enumerate systems before attack since it can yield a wealth of information about your system names, your user names, and more. If your ACL permissions are not correct or you haven't disabled anonymous user access or you haven't disabled the guest account then this port can lead to total system compromise within minutes!

Source link: http://www.petri.co.il/disable_administrative_shares.htm

How to enable PAE on Windows 2008 Server 32bit?

Steps are:
  1. Click Start- All Programs-Accesories-Commando Prompt - "Right Click-Run as administrator".
  2. "Bcdedit /set PAE forceenable".
  3. Restart Server.

ESXi "Setting the number of cores per CPU"


Some operating system SKUs are hard-limited to run on a fixed number of CPUs. For example, Windows Server 2003 Standard Edition is limited to run on up to 4 CPUs. If you install this operating system on an 8-socket physical box, it runs on only 4 of the CPUs. The operating system takes advantage of multi-core CPUs so if your CPUs are dual core, Windows Server 2003 SE runs on up to 8 cores, and if you have quad-core CPUs, it runs on up to 16 cores, and so on.
Virtual CPUs (vCPU) in VMware virtual machines appear to the operating system as single core CPUs. So, just like in the example above, if you create a virtual machine with 8 vCPUs (which you can do with vSphere) the operating system sees 8 single core CPUs. If the operating system is Windows 2003 SE (limited to 4 CPUs) it only runs on 4 vCPUs.
Note: Remember that 1 vCPU maps onto a physical core not a physical CPU, so the virtual machine is actually getting to run on 4 cores.
Considering that 1 vCPU is equal to 1 CPU is an assumption for the sake of simplification, since vCPUs are scheduled on logical CPUs which are hardware execution contexts. These tasks can take a while in the case of a single core CPU, CPUs that have only 1 thread per core, or could be just a thread in the case of a CPU that has hyperthreading.
Consider this scenario:
In the physical world you can run Windows 2003 SE on up to 8 cores (using a 2-socket quad-core box) but in a virtual machine they can only run on 4 cores because VMware tells the operating system that each CPU has only 1 core per socket.
VMware now has a setting which provides you control over the number of cores per CPU in a virtual machine.
This new setting, which you can add to the virtual machine configuration (.vmx) file, lets you set the number of cores per virtual socket in the virtual machine.
To implement this feature:
  1. Power off the virtual machine.
  2. Right-click on the virtual machine and click Edit Settings.
  3. Click Hardware and select CPUs.
  4. Choose the number of virtual processors.
  5. Click the Options tab.
  6. Click General, in the Advanced options section.
  7. Click Configuration Parameters.
  8. Include cpuid.coresPerSocket in the Name column.
  9. Enter a value (try 2, 4, or 8) in the Value column.Note: Ensure that the number of vCPUs is divisible by the number of  cpuid.coresPerSocket in the virtual machine. That is, when you divide the number of vCPUs by the number of cpuid.coresPerSocket, it must return an integer value. For example, if your virtual machine is created with 8 vCPUs, coresPerSocket can only be 1, 2, 4, or 8.

    The virtual machine now appears to the operating system as having multi-core CPUs with the number of cores per CPU given by the value that you provided in step 9.
  10. Click OK.
  11. Power on the virtual machine.
For example:
Create an 8 vCPU virtual machine and set cpuid.coresPerSocket = 2Window Server 2003 SE running in this virtual machine now uses all 8 vCPUs. Under the covers, Windows sees 4 dual-core CPUs. The virtual machine is actually running on 8 physical cores.
Note:
  • To be able to assign more than 4 vCPUs or if the processor supports more than 6 core(s) per processor, you have to assign an Enterprise Plus license, which supports up to 8 vCPUs and 12 core(s) per processor.
  • Only values of 1, 2, 4, 8 for the cpuid.coresPerSocket are supported for the multi-core vCPU feature in ESX 4.x.
  • In ESX 4.0, if multi-core vCPU is used, hot-plug vCPU is not permitted, even if it is available in the UI.
  • Only HV 7 virtual machines support the multi-core vCPU feature.
Important: When using cpuid.coresPerSocket, you should always ensure that you are in compliance with the requirements of your operating system EULA (Regarding the number of physical CPUs on which the operating system is actually running).