Using Powershell to group by the Hard Disks Used Space from multiple Servers

Sometime, you may want to retrieve the Hard Disks Used Space from one or multiple Servers to build up a report (or something else!). In this case, the Drive ID does not really need to be shown as we want to group it up.

Here's what the Output looks like:

TotalCapacity TotalUsedSpace Server    
------------- -------------- ------    
571,7 Gb      228,3 Gb       SRV-SAPCS001
161,7 Gb      17,9 Gb        SRV-IIS001
109,7 Gb      15,4 Gb        SRV-IIS002

Here's the script:

 "srv-sapcs001.katalykt.lan", "srv-iis001.katalykt.lan", "srv-iis002.katalykt.lan" | 
    ForEach-Object {Get-WmiObject Win32_LogicalDisk -ComputerName $_ -Filter "Drivetype=3"} | 
        Select-Object SystemName, Size, @{Label = "Used Space";Expression = {$_.Size - $_.FreeSpace}} | 
            Group-Object SystemName | 
                ForEach-Object {
                    New-Object PSObject -Property @{
                        Server = $_.Group.SystemName[0]
                        TotalUsedSpace = ("{0:N1} Gb" -f (($_.Group."Used Space" | Measure-Object -Sum).Sum / 1Gb))
                        TotalCapacity = ("{0:N1} Gb" -f (($_.Group.Size | Measure-Object -Sum).Sum / 1Gb))
                    } 
                } 

Using Iptables to create a NAT/DMZ

Iptables is a powerful Firewall which can be used to create and maintain a simple or complex infrastructure.

In this case, we will be using the NAT feature of Iptables in order to make an Internal IIS Web Server communicate with a DMZ IIS Web Server.

Let's assume that we have a Web Service running on the IIS Web Server located in the DMZ that needs to be queried by the Internal Web Server by TCP/HTTP.

As our DMZ subnet is isolated, the Internal Web Server cannot communicate with the DMZ Web Server. This is where NAT comes handy.

As a result, if our Internal Web Server wants to communicate with the DMZ Web Server it will have to use the back-end Firewall's Internal interface eth0 which will translate the address to the DMZ via it's eth1 interface. In short, the NAT allows us to hide the DMZ Subnet which cannot be routed and which should remain in a controlled isolation.

Of course in this case, we will only be performing NAT for queries which come to our back-end Firewall on HTTP/TCP port 80.

So let's get started!

Enabling IPv4 Forwarding

The first thing is to ensure that IPv4 forwarding is enabled on our Firewall, the following command will output it's status (note that I'm using a Debian 8 Jessie in here):

sysctl net.ipv4.ip_forward

If it's already enabled, then everything's fine, otherwise you will have to either enable it on the fly (temporary) or make it persistent

Temporary change:

The temporary way is quite straightforward but will not survive a reboot

echo 1 > /proc/sys/net/ipv4/ip_forward

Persistent change:

On the other hand the persistent way requires the editing of the /etc/sysctl.conf file

 # Uncomment the next line to enable packet forwarding for IPv4

net.ipv4.ip_forward=1 

After changing that value we refresh our kernel with the new configuration file

sysctl -p /etc/sysctl.conf

Adding the NAT rule

The next step is to actually add the NAT rule to the back-end Iptables Firewall. This rule will need to be present in both PREROUTING and POSTROUTING chains.

 iptables -t nat -A PREROUTING -i eth0 -p tcp -d 10.10.10.200 --dport 80 -j DNAT --to-destination 192.168.200.200:80

iptables -t nat -A POSTROUTING -o eth1 -p tcp -s 10.10.10.210 --dport 80 -j SNAT --to-source 192.168.200.199 

Our PREROUTING rule will make sure that packets coming to our back-end Firewall eth0 interface (10.10.10.200) on port 80 (TCP/HTTP) will be translated toward the DMZ Web Server (192.168.200.200) on port 80

The POSTROUTING chain will alter the source of the outgoing package coming from the Internal Web Server (10.10.10.210) on port 80 and will substitute it's source with the back-end Firewall's eth1 IP (192.168.200.199)

This is it for the NAT rule, next we have to allow it.

Allowing the NAT rule

So we do have the NAT rule loaded on the Iptables but it will not work yet as long as we do not add it to the FORWARD chain (that is, of course, if your default policy is to drop all packets!)

 iptables -A FORWARD -p tcp -i eth0 -s 10.10.10.210 -d 192.168.200.200 -o eth1 --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT

iptables -A FORWARD -p tcp -i eth1 -s 192.168.200.200 -d 10.10.10.210 -o eth0 --sport 80 -m state --state ESTABLISHED -j ACCEPT 

The first FORWARD rule will allow new and established TCP/HTTP connections coming from the Internal Web Server to the DMZ Web Server while the second one will allow the reversed scenario but only with established connections.


That's about it, the NAT is now working exclusively between the Internal Web Server and the DMZ Web Server.