So, your server is receiving unwanted network traffic.
You'd normally add a new iptables rule and block the troublemaker. But this time, the source comes from a network set with an IPv6 address.
Who This Post is For
This post covers the absolute basics of dealing with IPv6 addresses. It delivers the bare-bones summary I had hoped to find when I searched for how to block IPv6 traffic.
If you want detailed information, the IPv6 Wikipedia Page is a good place to start.
But you don't want that, do you.
You want to:
- understand the syntax of an IPv6 address;
- learn how to specify an IPv6 address range; and
- see how to write an iptables rule that blocks an IPv6 address range.
At least I did. And now I know!
And, in a few minutes, you're going to know as well.
The Basics of IPv6
IPv6 syntax is similar to traditional IPv4.
Hexadecimal values are listed in order of network detail, with each four-byte group delimited by ":".
An address you'll often see is: 2001:db8::
That's not a special value; it's just a standard subnet chosen for IPv6 documentation. Think of it as the www.example.com of IPv6, or the equivalent of the 192.168.0.1 you might use for an IPv4 document.
We'll be using that 2001:db8:: subnet in the examples outlined here.
"But," you might ask, "isn't that example address a bit short for IPv6?"
Nope! The address is just written in IPv6 short form.
IPv6 Short Form
The IPv6 address 2001:db8:: can be fully written as:
Leading 0s can be omitted. So, we can write a snipped equivalent of the above with:
Snipping further, ranges of 0s can be indicated with a double colon "::", like so:
We can also snip out 0s in the middle of an address. For example, this address:
can be written as:
The IBM documentation page at https://www.ibm.com/docs/en/i/7.4?topic=concepts-ipv6-address-formats does an excellent job of describing IPv6 syntax.
I recommend reading that page before continuing (it's very short -- it'll take you two minutes) to make sure you understand IPv6 syntax.
How to Specify an IPv6 Subnet
We now know how to write out one of the 340,282,366,920,938,463,463,374,607,431,768,211,456 possible IPv6 addresses.
Yeah, there are a lot. And we'll have to block many nefarious IPv6 subnets in the years to come.
IPv6 subnets are identified through the address's four-byte groups. So, just as we can write:
to indicate all IPv4 addresses from 192.168.0.0 to 192.168.0.255, we can write:
to indicate all IPv6 addresses from 2001:0db8:0000:0000:0000:0000:0000:0000 to 2001:0db8:ffff:ffff:ffff:ffff:ffff:ffff
Similarly, the notation:
would indicate all IPv6 addresses from 2001:0db8:4567:0000:0000:0000:0000:0000 to 2001:0db8:4567:ffff:ffff:ffff:ffff:ffff
If you're wondering what /32 and /48 mean, this page about IPv6 subnetting does a fantastic job of explaining values for IPv6 slash "/" notation.
I recommend reading that page before continuing (again, it's very short -- you'll be done in minutes) to make sure you understand how IPv6 subnets are written.
Want to Test What You've Learned?
Of course you do!
This IPv6 Subnet Calculator will accept an entered IPv6 subnet and show the range of addresses it covers.
A few experiments there will confirm you've caught the basics.
How to Block an IPv6 Subnet
Now that we know how to specify an IPv6 subnet, how do we go about blocking it?
Why, using ip6tables, of course!
I'm assuming here that you're familiar with how to use the iptables tool to block unwanted IPv4 network traffic. If iptables is new to you, you'll find Linode's iptables tutorial a helpful guide to get started with the basics.
Using iptables, we could block traffic from the IPv4 address range 192.168.0.0 to 192.168.0.255 with the command:
iptables -A INPUT -s 192.168.0.0/24 -j DROP
In the same way, we can block all traffic from an IPv6 subnet using ip6tables.
Using our range example above, the IPv6 address range 2001:0db8:0000:0000:0000:0000:0000:0000 to 2001:0db8:ffff:ffff:ffff:ffff:ffff:ffff can be blocked using the ip6tables command:
ip6tables -A INPUT -s 2001:0db8::/32 -j DROP
Similarly, a more precise targeting of the IPv6 address range 2001:0db8:4567:0000:0000:0000:0000:0000 to 2001:0db8:4567:ffff:ffff:ffff:ffff:ffff can be blocked with:
ip6tables -A INPUT -s 2001:0db8:4567::/48 -j DROP
You can specify your subnet of choice using the examples covered above.
And That's It!
You're good to go.
You're armed and ready to block any IPv6 traffic dispatched to hassle your servers.
(Special thanks to demu.red's post about IPv6 range blocking at https://demu.red/blog/2016/09/blocking-ipv6-ranges-with-iptables/. That gave me a good starting point for figuring out the basics.)
These old papers and abstracts came up in conversation, and I thought I'd surface them here from Google Scholar for easy blog reference.
The contents are decades old, but lunar matters are much the same. The major difference these days is that the ‘non-renewable resource' of scientific ignorance has diminished a bit.
So we've got that going for us, which is nice.
This list is in chronological order, and nowhere near complete. Three full lunar/asteroidal development papers for the Journal of the British Interplanetary Society seem to be tucked elsewhere, and there is a ridiculously extensive collection of presentations made through the years that are very slightly bending a shelf to my right.
If you'd like copies, just ask over a coffee or pint.
Commercial activities resulting from a lunar base - Charles D. O'Dale (1994)
British Interplanetary Society, Journal (ISSN 0007-094X)
vol. 47, no. 12, p. 549-554
Policy Considerations for Lunar Development - Charles D. O'Dale (1995)
Thirty Second Space Congress, Paper Session II-C (1995)
The International Lunar Base as a Foundation for Commercial Industry - Charles D. O'Dale (2000)
Proceedings of the Fourth International Conference on Exploration and Utilisation of the Moon: ICEUM 4
Public and Private Sector Coordination for Effective Lunar Resource Use - Charles D. O'Dale (2005)
Proceedings of the International Lunar Conference, 2005
Lessons from Earth: Experiences Which can Guide Lunar and Asteroidal Development - Charles D. O'Dale (2004)
Space Resources Roundtable VI
Using Secondary Objectives to Guide the Development of Lunar Industry - Charles D. O'Dale (2005)
Lunar Exploration Analysis Group (LEAG) (2005)
Windows Notepad is a simple workhorse text editor. It's nothing fancy. It just gives the bare basics, with a clean session each time it's opened.
At least it did.
In 2019, Microsoft decided to have Windows 10 Notepad remember its last used settings. That change isn't a big deal for most people, but when I open Notepad I'm not looking to tweak settings before getting to work. I just want to open Notepad, enter a snippet to find with 'ctrl-f', hit 'enter', and confirm the text is present (or not) before moving on. But now, I have to step out of my workflow to first confirm text search is clear, set its direction, and then perform my search.
Again, not a big deal for most people. But if you are as annoyed by that change as I am, you understand why it's a pain.
It would be fantastic if Microsoft provided a 'do not remember last settings' option in Windows 10 Notepad along with that extra functionality to remember find settings, but they didn't. So, now we have to work a little magic with the registry editor to fix that and get Windows 10 Notepad to start with a clean session each time it is opened.
Like it used to.
The changes made here use the Windows registry edit tool.
If you are already familiar with the registry editor, you know how to tweak registry settings and are aware of how dangerous those changes can be.
If you are not familiar with the Windows registry editor, please familiarize yourself with the ins-and-outs of that tool and back up your full windows registry before proceeding.
These instructions have been left deliberately vague and may be confusing to anyone not familiar with the Windows 10 registry editor. If these instructions are not perfectly clear to you, please take a bit of time to familiarize yourself with your Windows registry editor.
Disclaimer and Warning:
Changes made in your Windows registry editor can destroy your computer. That is not an exaggeration. Be certain you have a full registry backup and know what you are doing before proceeding with any windows registry edits.
To Prevent Windows 10 Notepad From Saving Its Find Settings:
First, perform a search in Windows 10 Notepad to place your settings in your preferred default search direction ("Direction (*) Down", right?) then close Notepad.
Next, open your editor to the branch:
Select the key:
and clear its contents.
At this point, you have Windows 10 Notepad set to its traditional defaults. Now, we are going to lock those defaults in place:
Click the registry branch:
then right-click on that item and choose the "Permissions..." pop-up menu item. The "Permissions for Notepad" dialog box will be opened, with its "Security" tab displayed.
In the displayed list of "Group or user names:", select the user account you would like to fix Notepad for (that will almost always be the user account you have signed in with). With that user account selected, toggle on the "Deny" checkboxes for the "Full Control" and "Read" permissions (the "Allow" checkbox items are read-only and cannot be changed; setting those items to "Deny" will serve to disable them).
With "Deny" toggled on, click "Apply".
A security dialog will appear, warning that you are going to deny a permissions entry (yes, that is exactly what we are wanting to do). Click the "Yes" button on that warning dialog to apply your change, then click "Ok" on the "Permissions for Notepad" dialog to close that box.
You're done. You can now close your registry editor and go about your business, with Notepad now clearing its find preferences after every session.
What a pain.
Microsoft, please don't mess with Notepad. If I want a text editor with text editor functionality, I'll use one. Windows 10 Notepad is a notepad for quick scratch notes and text reference, please keep it that way.
Update - August 8th, 2021
Some day soon, web browsers will block self-signed certificates from securing WebSockets.
Although the instructions on this page will still work for creating a self-signed certificate, I would recommend jumping right to using a certificate signed by a registered authority, rather than risk web browser security headaches when developing Java WebSockets with a self-signed cert.
So, here's the situation you're facing:
You have a Java-based server program running on a Windows computer. The computer is not a web server -- it's just a regular Windows machine -- and you want to secure its WebSocket with a self-signed SSL certificate.
Maybe you're wanting to connect in to that Java server program through an HTTPS web page. Maybe you're wanting a bit of extra security for occasional connections over the public internet. Maybe (like me) you need an SSL certificate to allow a bit of HTTPS testing in-house on a few isolated Windows PCs. Regardless, you have a Java jar running on a Windows computer, that Java jar creates a TCP WebSocket, and you want to secure that WebSocket with a self-signed SSL certificate.
What to do?
Setting a Network Name
Before starting, you will want to have a network name by which your Windows computer is known. That can be handled by either having a proper DNS name for your computer or, in a pinch, you can edit the hosts file to direct a name to the IP address of that computer. That hosts file edit is the quick hack we'll run through here.
Your hosts file can be found on your Windows computer at:
to edit that file, open up Notepad in Administrator mode (admin rights will be needed to save your changes) and add an entry for the IP address of interest.
For example, if you wanted to reference a computer at the local IP address of 192.168.0.3 with the DNS name mytestserver, adding the following line for that in your hosts file would direct that name to the computer:
# Copyright (c) 1993-2009 Microsoft Corp. # # This is a sample HOSTS file used by Microsoft TCP/IP for Windows. # # This file contains the mappings of IP addresses to host names. Each # entry should be kept on an individual line. The IP address should # be placed in the first column followed by the corresponding host name. # The IP address and the host name should be separated by at least one # space. # # Additionally, comments (such as these) may be inserted on individual # lines or following the machine name denoted by a '#' symbol. # # For example: # # 126.96.36.199 rhino.acme.com # source server # 188.8.131.52 x.acme.com # x client host # localhost name resolution is handled within DNS itself. # 127.0.0.1 localhost # ::1 localhost 192.168.0.3 mytestserver
After making that entry, a ping test from your MS DOS command prompt to that mytestserver DNS name should show you a reply from your identified IP address (if not, check that you've chosen the correct IP address for your hosts entry -- a ping will bounce off a computer running at that address).
The rest of this example assumes use of the mytestserver DNS name we hacked up in the hosts file above. For all of the following examples, where you see 'mytestserver' in a listed command, substitute in your own Windows computer's DNS name instead.
Creating a Self-Signed SSL Certificate on Windows
Now to the root of things: Creating a self-signed SSL certificate on the Windows computer itself. That can be done using the Windows Powershell utility running in Administrator mode.
The easiest way to start your Powershell is to open your Cortana search (keyboard shortcut: windows-key S), enter 'powershell' in the search prompt, and then right-click and select 'Run as administrator' on the Windows Powershell desktop app which appears in your search results.
The New-SelfSignedCertificate Windows Powershell command will create a self-signed SSL certificate and add it to your Windows certificates list.
For example, this Windows Powershell command (which is broken out on multiple lines here for clarity, but which must be entered in your Powershell on one line):
New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -DnsName "mytestserver" -FriendlyName "MyLocalTestCert" -NotAfter (Get-Date).AddYears(25)
Would create a new self-signed certificate for the example DNS name we're using of "mytestserver" and provide it with a human-readable name of "MyLocalTestCert". You should use your own computer's DNS name and the certificate name you would like as appropriate. That certificate would have a lifetime of 25 years (something you could safely forget about for purposes of your testing) and is ready to add to the trusted root certification authorities.
Your Windows Powershell window can be closed now -- we're done with that tool.
Making a Self-Signed SSL Certificate Trusted
With the self-signed SSL certificate created, we can now access it in the Windows Manage Computer Certificates utility. As with Windows Powershell, the easiest way to access that tool on Windows 10 is to bring up Cortana search, enter 'certificate' in the search box, and select the 'manage computer certificates' option from the list of search results.
With your Windows Certificates Manager open, open the folder branch:
"Certificates - Local Computer -> Personal -> Certificates"
You will see the MyLocalTestCert certificate you created listed in that folder.
Now, we'll want to copy that certificate to the list of trusted certificates. That can be done with a simple copy-and-paste of your certificate from the certificates manager folder:
"Certificates - Local Computer -> Personal -> Certificates"
to the folder:
"Certificates - Local Computer -> Trusted Root Certification Authorities -> Certificates"
That serves to register your created SSL certificate as one which your Windows computer will trust for SSL socket creation.
Creating a Java-Ready SSL Certificate
At this point, we have a self-signed SSL certificate created and registered as trusted on Windows. So, how do we create a Java-ready keystore?
The solution for that is the Java keytool utility, which should already be available on your computer thanks to your Java development. But before we can use the keytool, we need to export a copy of the self-signed certificate we've created.
Returning to the Windows Certificates Manager, select the certificate you imported into your Trusted Root Certification Authorities and right-click the cert to select "All Tasks -> Export...". From there, it's just a matter of following the certificate export Wizard.
In the certificate export wizard, you will want to export the private key (that key will be used in your Java keystore), use the Export File Format of "Personal Information Exchange PKCS #12 (.PFX)" and for the file export options, you will want to choose:
- Include all certificates in the certification path if possible
- Enable certificate privacy
Be sure to make note of the password you choose for your certificate -- you will be using that password later.
With your certificate data exported to file (we're using the filename myexportedcert.pfx for the example that follows), you're ready to create your Java keystore.
To provide a simple staging area for the creation of your keystore, create a temporary directory on your hard drive (say, d:\temp_work\ ) and copy your exported myexportedcert.pfx file to that directory.
With your myexportedcert.pfx file in place, open an MS DOS prompt window, change the path to your temporary directory and enter (on a single line) the keytool command:
keytool -importkeystore -srckeystore myexportedcert.pfx -srcstoretype pkcs12 -destkeystore myKeystore.jks -deststoretype JKS
and then follow the on-screen prompts to enter the password you used for the creation of your certificate.
Once all prompts have been finished, you will find a new file, myKeystore.jks, in your temporary directory. That myKeystore.jks file provides all of the detail you require to load and use your self-signed SSL certificate to secure your Java program's WebSocket.
Using Your Self-Signed SSL Certificate on Other Computers
What we'll be wanting to do next is allow your self-signed SSL certificate to be used from other computers.
Since your SSL certificate is self-signed, it will not be recognized outside of your server computer (having copied your certificate to your "Trusted Root Certificate Authorities" provided all of the authorization you needed for that system), but you can export your certificate to different computers to allow use of the self-signed SSL certificate elsewhere.
The exported certificate file in this case will not contain your private certificate information and will be safe to pass around to other computers for your testing. To create it, open up your Windows Certificates Manager, select the self-signed SSL certificate you placed in your Trusted Root Certification Authorities earlier, and right-click the certificate to open up your certificate export wizard.
This time, you will not want to export the private key for the certificate, and you will select the export file format of "DER encoded binary X.509 (.CER)". Once you have completed the certificate export wizard and have exported a new .cer file, that file can be added to the trusted keys of any other computer you would like to access your SSL socket from.
To import your .cer file on another Windows computer, just open the Windows Certificates Manager on your other computer, open the folder:
"Certificates - Local Computer -> Trusted Root Certification Authorities -> Certificates"
and import your created .cer file. From there, you will be able to connect to your test computer's SSL socket.
Don't forget: If you do not have a DNS name specified for the computer hosting your Java SSL socket server program, you will need to add an entry to that computer's hosts file so that it will recognize the hostname tied to your SSL certificate (for example, the mytestserver DNS name we used earlier in our quick hosts file hack).
That's it! You have created a self-signed SSL certificate which can be used to secure a Java TCP socket for testing, and you can now access that certificate from whichever computer you would find helpful.
This is a rather niche case for SSL certificates and, for a permanent solution, you will want to purchase a certificate signed by an external certificate authority rather than work with a self-signed cert on your systems. But these particular steps were helpful for my own testing, and I hope the details outlined here will help save time in your own troubleshooting and development.