A Sender Policy Framework (SPF) record is a type of Domain Name Service (DNS) TXT record that identifies which mail servers are permitted to send an email on behalf of your domain. The purpose of an SPF record is to detect and prevent spammers from sending messages with forged From addresses on your domain.
Sender Policy Framework (SPF) is a method of fighting spam. As more time passes, this protocol will be used as one of the standard methods of fighting spam on the Internet. An SPF record is a TXT record that is part of a domain’s DNS zone file. The TXT record specifies a list of authorized hostnames/IP addresses that mail can originate from for a given domain name. Once this entry is placed within the DNS zone, no further configuration is necessary to take advantage of servers that incorporate SPF checking into their anti-spam systems. This SPF record is added the same way as a regular A, MX, or CNAME record.
Collect all IP addresses that are used to send email
The Sender Policy Framework (SPF) gives the ability to authenticate your email and to specify which IP addresses are allowed to send an email on behalf of the specific domain.
In order to successfully implement SPF, you first need to identify which mail servers are used to send an email for your domain. These mail servers can be any sending organization, you should think of your Email Service Provider, Office mail server and any other third-party mail servers that may be used to send an email for you.
ike-scan is a command-line tool for discovering, fingerprinting and testing IPsec VPN systems. It constructs and sends IKE Phase-1 packets to the specified hosts, and displays any responses that are received.
ike-scan does two things:
Discovery: Determine which hosts are running IKE. This is done by displaying those hosts which respond to the IKE requests sent by ike-scan.
Fingerprinting: Determine which IKE implementation the hosts are using. There are several ways to do this: (a) Backoff fingerprinting – recording the times of the IKE response packets from the target hosts and comparing the observed retransmission backoff pattern against known patterns; (b) vendor id fingerprinting – matching the vendor-specific vendor IDs against known vendor ID patterns; and (c) proprietary notify message codes.
# ike-scan x.x.x.x
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
22.214.171.124 Main Mode Handshake returned HDR=(CKY-R=e6e1202cb8c44f2d) SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration=28800) VID=4a131c81070358455c5728f20e95452f (RFC 3947 NAT-T) VID=7d9419a65310ca6f2c179d9215529d56 (draft-ietf-ipsec-nat-t-ike-03) VID=90cb80913ebb696e086381b5ec427b1f (draft-ietf-ipsec-nat-t-ike-02\n) VID=cd60464335df21f87cfdb2fc68b6a448 (draft-ietf-ipsec-nat-t-ike-02) VID=4485152d18b6bbcd0be8a8469579ddcc (draft-ietf-ipsec-nat-t-ike-00) VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)
Ending ike-scan 1.9: 1 hosts scanned in 0.512 seconds (1.95 hosts/sec). 1 returned handshake; 0 returned notify
Iptables is used to set up, maintain, and inspect the tables of IP packet filter rules in the Linux kernel. Several different tables may be defined. Each table contains a number of built-in chains and may also contain user-defined chains.
Each chain is a list of rules which can match a set of packets. Each rule specifies what to do with a packet that matches. This is called a ‘target’, which may be a jump to a user-defined chain in the same table.
The filter table: This is the default and perhaps the most widely used table. It is used to make decisions about whether a packet should be allowed to reach its destination.
Themangle table: This table allows you to alter packet headers in various ways, such as changing TTL values.
Thenat table: This table allows you to route packets to different hosts on NAT (Network Address Translation) networks by changing the source and destination addresses of packets. It is often used to allow access to services that can’t be accessed directly because they’re on a NAT network.
Theraw table: iptables is a stateful firewall, which means that packets are inspected with respect to their “state”. (For example, a packet could be part of a new connection, or it could be part of an existing connection.) The raw table allows you to work with packets before the kernel starts tracking its state. In addition, you can also exempt certain packets from the state-tracking machinery.
The PREROUTING chain: Rules in this chain apply to packets as they just arrive on the network interface. This chain is present in the nat, mangle and raw tables.
The INPUT chain: Rules in this chain apply to packets just before they’re given to a local process. This chain is present in the mangle and filter tables.
The OUTPUT chain: The rules here apply to packets just after they’ve been produced by a process. This chain is present in the raw, mangle, nat and filter tables.
The FORWARD chain: The rules here apply to any packets that are routed through the current host. This chain is only present in the mangle and filter tables.
The POSTROUTING chain: The rules in this chain apply to packets as they just leave the network interface. This chain is present in the nat and mangle tables.
ACCEPT: This causes iptables to accept the packet.
DROP: iptables drops the packet. To anyone trying to connect to your system, it would appear like the system didn’t even exist.
REJECT: iptables “rejects” the packet. It sends a “connection reset” packet in case of TCP, or a “destination host unreachable” packet in case of UDP or ICMP.
The connection tracking module – conntrack
NEW: This state represents the very first packet of a connection.
ESTABLISHED: This state is used for packets that are part of an existing connection.
RELATED: This state is used for connections that are related to another ESTABLISHEDconnection.
INVALID: This state means the packet doesn’t have a proper state. This may be due to several reasons, such as the system running out of memory or due to some types of ICMP traffic.
UNTRACKED: Any packets exempted from connection tracking in the raw table with the NOTRACK target end up in this state.
DNAT: This is a virtual state used to represent packets whose destination address was changed by rules in the nat table.
SNAT: Like DNAT, this state represents packets whose source address was changed.
Changes in this new architecture will allow for: dramatic file system performance increases, and full system call compatibility, meaning you can run more Linux apps in WSL 2 such as Docker.
WSL 2 is a new version of the architecture that powers the Windows Subsystem for Linux to run ELF64 Linux binaries on Windows. This new architecture changes how these Linux binaries interact with Windows and your computer’s hardware, but still provides the same user experience as in WSL 1 (the current widely available version). Individual Linux distros can be run either as a WSL 1 distro, or as a WSL 2 distro, can be upgraded or downgraded at any time, and you can run WSL 1 and WSL 2 distros side by side. WSL 2 uses an entirely new architecture that uses a real Linux kernel.
Microsoft will be shipping a Linux kernel with Windows
Yes, you did just read that heading correctly! We will be shipping a real Linux kernel with Windows that will make full system call compatibility possible. This isn’t the first time Microsoft has shipped a Linux kernel, as we have already shipped one in 2018 when we announced Azure Sphere. However, this will be the first time a Linux kernel as shipped with Windows, which is a true testament to how much Microsoft loves Linux!
This kernel has been specially tuned for WSL 2. It has been optimized for size and performance to give an amazing Linux experience on Windows. We will service this Linux kernel through Windows updates, which means you will get the latest security fixes and kernel improvements without needing to manage it yourself.
Lastly, of course, this Linux kernel will be fully open source! When we release WSL 2 we will have the full configuration available online on Github, so you can see how it works and builds it yourself. If you’d like to read more about this kernel you can check out this blog post written by the team that built it.
A quick explanation of the architectural changes in WSL 2
WSL 2 uses the latest and greatest in virtualization technology to run its Linux kernel inside of a lightweight utility virtual machine (VM). However, WSL 2 will NOT be a traditional VM experience. When you think of a VM, you probably think of something that is slow to boot up, exists in a very isolated environment, consumes lots of computer resources and requires your time to manage it. WSL 2 does not have these attributes. It will still give the remarkable benefits of WSL 1: High levels of integration between Windows and Linux, extremely fast boot times, small resource footprint, and best of all will require no VM configuration or management.
How much faster is WSL 2?
File intensive operations like git clone, npm install, apt update, apt upgrade, and more will all be noticeably faster. The actual speed increase will depend on which app you’re running and how it is interacting with the file system. Initial tests that we’ve run have WSL 2 running up to 20x faster compared to WSL 1 when unpacking a gzipped tarball, and around 2-5x faster when using git clone, npm install and CMake on various projects. We’re looking forward to seeing speed comparisons from the community when we release!
Full System Call Compatibility
Linux binaries use system calls to perform many functions such as accessing files, requesting memory, creating processes, and more. In WSL 1 we created a translation layer that interprets many of these system calls and allows them to work on the Windows NT kernel. However, it’s challenging to implement all of these system calls, resulting in some apps being unable to run in WSL 1. Now that WSL 2 includes its own Linux kernel it has full system call compatibility. This introduces a whole new set of apps that you can run inside of WSL. Some exciting examples are the Linux version of Docker, as well as FUSE!
Using WSL 2 means you can also get the most recent improvements to the Linux kernel much faster than in WSL 1, as we can simply update the WSL 2 kernel rather than needing to reimplement the changes ourselves.
WSL 2 will be a much more powerful platform for you to run your Linux apps on and will empower you to do more with a Linux environment on Windows.