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.
krypted January 27th, 2017
Posted In: Windows Server, Windows XP
netsh, script firewall rules, windows
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 krypted.com -f -l 1500
We should get an error:
Packet needs to be fragmented but DF set.
Now, let’s try
ping krypted.com -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
krypted September 17th, 2013
Posted In: Microsoft Exchange Server, Network Infrastructure, Windows Server
2008, 2012, change mtu size, jumbo frames, make mtu persistent, netsh, packet, ping -f -l, Windows Server
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.
krypted August 10th, 2010
Posted In: Windows Server
dnscmd, export, export settings, import, netsh, servername, Windows Server, zonename