Tiny Deathstars of Foulness

Here ya’ go!

netsh advfirewall firewall add rule name=”KryptedWebhook” dir=in protocol=tcp localport=8443 profile=private remoteip=any action=allow

Wait, what’s that?!?! Let’s break down the options I used here:

  • advfirewall: Yup, it’s the new firewall.
  • firewall: Yup, it’s a firewall.
  • add: I’m adding a new rule. I also could have used delete along with the rule name and removed one. Or show to see one. Or set to augment one.
  • rule: It’s all about rules. Each rule allows for a port and/or an action.
  • name: Every rule needs a unique name. Namespace conflicts will result in errors. If programmatically creating rules, I’ve found it undesirable to use a counter and instead moved to using GUIDs and a hash table.
  • dir: The direction traffic is flowing. In is for incoming traffic or out would be to block outgoing traffic.
  • protocol: Use the protocol, typically tcp or ump, but if pings, might be one of the icmps.
  • localport: The port that is being used (there’s also a remoteport operator for reflections).
  • profile: I mostly use profile of private.
  • remoteip: Set to any but could be set to a given IP for increased security (yes, I know people can spoof these – so your version of the word might be different.
  • action: I used allow, but could have been block (which denies traffic) or bypass.

For further security, I might add a security operator, to allow for an authentication string. You can

You might also need to allow traffic for a given app. To do so, let’s add a rule that does so, the only option for which not mentioned above is program, which is the path to the binary we’re allowing:

netsh advfirewall firewall add rule name="My Application" dir=in action=allow program="C:\kryptedscripts\kryptedcompiledwebapp.exe" enable=yes

To then see the rules and validate that your rules were indeed installed, use:

netsh advfirewall firewall show rule name=all

The reason I call this quick and dirty is that I’m really only covering a small subset of options. Additionally, it would be a bit more modern to do this via powershell using New-NetFirewallRule or one of the many, many other commandlets, such as Copy-NetFirewallRule, Enable-NetFirewallRule, Disable-NetFirewallRule, Get-NetFirewallAddressFilter, Get-NetFirewallApplicationFilter, Get-NetFirewallInterfaceFilter, Get-NetFirewallInterfaceTypeFilter, Get-NetFirewallPortFilter, Get-NetFirewallRule, Get-NetFirewallSecurityFilter, New-NetFirewallRule, Open-NetGPO (cause you can configure the firewall through a GPO), Remove-NetFirewallRule, Rename-NetFirewallRule, Save-NetGPO, Set-NetFirewallRule, Set-NetFirewallSetting, and Show-NetFirewallRule.

January 27th, 2017

Posted In: Windows Server, Windows XP

Tags: , ,

When we transfer certain amounts of data in a packet we might cause that packet to fragment. The less fragmentations without requiring a collision or a re-send of a packet, the more efficient network traffic can be. The MTU defines the packet size. Different types of data or network links respond differently. To change the MTU on a Windows Server we’re going to use the netsh command. First, we’re going to use ping to ping a host on our network, using -f and then -l which allows us to define the MTU size. In this case we’re going to use 1500:

ping -f -l 1500

We should get an error:

Packet needs to be fragmented but DF set.

Now, let’s try

ping -f -l 1464

Now, let’s look at the interfaces along with what the current MTU is on each:

netsh interface ipv4 show interfaces

Then, let’s make the mtu 1464 persistently using the Idx number of the interface to change from the above command in quotes:

netsh interface ipv4 set subinterface "10" mtu=1464 store=persistent

September 17th, 2013

Posted In: Microsoft Exchange Server, Network Infrastructure, Windows Server

Tags: , , , , , , , ,

The netsh command can be used to manage network interfaces, control routing and one of the lesser-used features that I’ve seen are to import and export service settings with Windows Servers. This can be especially helpful if you need to normalize data for import into another Windows server or to be normalized for use with another server platform. To export your DHCP information, from a command prompt in Windows you would run the netsh command along with the service you are exporting settings for (WINS, DHCP, etc). After the service identifier you would indicate the action being performed (ie – import or export in this context), followed by a file to dump the data to and finally the subset of the data (we’ll use all for convenience sake and throw the data into an easily locatable place on the root of the C Drive, which you obviously need access to for the copy):

netsh dhcp server export C:dhcpsettings.txt all

Now that you have exported the data, you can copy it to your other Windows Server box and import using the exact same command (assuming the file lives in the same place) but swapping out your export for an import:

netsh dhcp server import C:dhcpsettings.txt all

DNS is a different beast given that there is a special dnscmd command for managing that service. To export your DNS information:

dnscmd ServerName /enumrecords zonename @ /type A /detail > c:mydnssettings.txt

Or in CSV:

dnscmd /enumrecords zonename @ /Type A /additional > c:mydnssettings.csv

One of the most used services for Windows servers though, is as a filer. File shares are stored in a registry key at HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLanmanServerShares. You can browse here using regedt32 and then export the key. You would then use the Import option in the File menu (Windows 2003 uses Import whereas previous versions use Restore).

Note: Restoring this data will nuke and pave your existing shares on the box you’re running it on and in most cases you will need to restart appropriate services and/or the box to see the new settings.

August 10th, 2010

Posted In: Windows Server

Tags: , , , , , , ,