Security updates have been issued by CentOS (httpd and thunderbird), Debian (nss), Fedora (git), openSUSE (krb5, libvirt, samba, and thunderbird), Oracle (httpd and thunderbird), Red Hat (httpd, rh-mysql57-mysql, and thunderbird), Scientific Linux (httpd and thunderbird), and Ubuntu (ceph).
Security updates have been issued by CentOS (kernel and postgresql), Debian (botan1.10, curl, dnsmasq, libxfont, nautilus, qemu, qemu-kvm, sam2p, and tor), Fedora (dnsmasq, libmspack, and samba), Gentoo (file, icu, libpcre2, munin, ocaml, pacemaker, postgresql, rubygems, and sudo), Mageia (clamav, dnsmasq, flightgear, libidn, and x11-server), openSUSE (libvirt), Oracle (kernel), SUSE (portus), and Ubuntu (poppler).
Security updates have been issued by Arch Linux (weechat), Debian (debsecan, git, ruby1.8, ruby1.9.1, rubygems, and weechat), Fedora (kernel, libbson, and oniguruma), Gentoo (tiff), openSUSE (tor), Oracle (augeas, samba, and samba4), Red Hat (kernel), and Scientific Linux (kernel).
Security updates have been issued by Debian (bzr, clamav, libgd2, libraw, samba, and tomcat7), Fedora (drupal7-views, gnome-shell, httpd, krb5, libmspack, LibRaw, mingw-LibRaw, mpg123, pkgconf, python-jwt, and samba), Gentoo (adobe-flash, chromium, cvs, exim, mercurial, oracle-jdk-bin, php, postfix, and tcpdump), openSUSE (Chromium and libraw), Red Hat (chromium-browser), and Slackware (libxml2 and python).
The Samba 4.7.0 release is out. New features include whole DB read locks
(a reliability improvement), active directory with Kerberos support,
detailed audit trails for authentication and authorization activities, a
multi-process LDAP server, better read-only domain controller support, and
more. See the release
notes for details.
Security updates have been issued by CentOS (augeas, samba, and samba4), Debian (apache2, bluez, emacs23, and newsbeuter), Fedora (kernel and mingw-LibRaw), openSUSE (apache2 and libzip), Oracle (kernel), SUSE (kernel, spice, and xen), and Ubuntu (emacs24, emacs25, and samba).
Security updates have been issued by Arch Linux (tomcat7), Debian (kernel and perl), Fedora (libwmf and mpg123), Mageia (bluez, ffmpeg, gstreamer0.10-plugins-good, gstreamer1.0-plugins-good, libwmf, tomcat, and tor), openSUSE (emacs, fossil, freexl, php5, and xen), Red Hat (augeas, rh-mysql56-mysql, samba, and samba4), Scientific Linux (augeas, samba, and samba4), Slackware (samba), SUSE (emacs and kernel), and Ubuntu (qemu).
Security updates have been issued by Debian (enigmail, gnupg, libgd2, libidn, libidn2-0, mercurial, and strongswan), Fedora (gd, libidn2, mbedtls, mingw-openjpeg2, openjpeg2, and xen), Mageia (apache-commons-email, botan, iceape, poppler, rt/perl-Encode, samba, and wireshark), and openSUSE (expat, freerdp, git, libzypp, and php7).
Security updates have been issued by Debian (connman, faad2, gnupg, imagemagick, libdbd-mysql-perl, mercurial, and php5), openSUSE (postgresql93 and samba and resource-agents), Oracle (poppler), Scientific Linux (poppler), SUSE (firefox and php7), and Ubuntu (pyjwt).
Post Syndicated from Cameron Worrell original https://aws.amazon.com/blogs/security/how-to-configure-an-ldaps-endpoint-for-simple-ad/
Simple AD, which is powered by Samba 4, supports basic Active Directory (AD) authentication features such as users, groups, and the ability to join domains. Simple AD also includes an integrated Lightweight Directory Access Protocol (LDAP) server. LDAP is a standard application protocol for the access and management of directory information. You can use the BIND operation from Simple AD to authenticate LDAP client sessions. This makes LDAP a common choice for centralized authentication and authorization for services such as Secure Shell (SSH), client-based virtual private networks (VPNs), and many other applications. Authentication, the process of confirming the identity of a principal, typically involves the transmission of highly sensitive information such as user names and passwords. To protect this information in transit over untrusted networks, companies often require encryption as part of their information security strategy.
In this blog post, we show you how to configure an LDAPS (LDAP over SSL/TLS) encrypted endpoint for Simple AD so that you can extend Simple AD over untrusted networks. Our solution uses Elastic Load Balancing (ELB) to send decrypted LDAP traffic to HAProxy running on Amazon EC2, which then sends the traffic to Simple AD. ELB offers integrated certificate management, SSL/TLS termination, and the ability to use a scalable EC2 backend to process decrypted traffic. ELB also tightly integrates with Amazon Route 53, enabling you to use a custom domain for the LDAPS endpoint. The solution needs the intermediate HAProxy layer because ELB can direct traffic only to EC2 instances. To simplify testing and deployment, we have provided an AWS CloudFormation template to provision the ELB and HAProxy layers.
This post assumes that you have an understanding of concepts such as Amazon Virtual Private Cloud (VPC) and its components, including subnets, routing, Internet and network address translation (NAT) gateways, DNS, and security groups. You should also be familiar with launching EC2 instances and logging in to them with SSH. If needed, you should familiarize yourself with these concepts and review the solution overview and prerequisites in the next section before proceeding with the deployment.
Note: This solution is intended for use by clients requiring an LDAPS endpoint only. If your requirements extend beyond this, you should consider accessing the Simple AD servers directly or by using AWS Directory Service for Microsoft AD.
The following diagram and description illustrates and explains the Simple AD LDAPS environment. The CloudFormation template creates the items designated by the bracket (internal ELB load balancer and two HAProxy nodes configured in an Auto Scaling group).
Here is how the solution works, as shown in the preceding numbered diagram:
- The LDAP client sends an LDAPS request to ELB on TCP port 636.
- ELB terminates the SSL/TLS session and decrypts the traffic using a certificate. ELB sends the decrypted LDAP traffic to the EC2 instances running HAProxy on TCP port 389.
- The HAProxy servers forward the LDAP request to the Simple AD servers listening on TCP port 389 in a fixed Auto Scaling group configuration.
- The Simple AD servers send an LDAP response through the HAProxy layer to ELB. ELB encrypts the response and sends it to the client.
Note: Amazon VPC prevents a third party from intercepting traffic within the VPC. Because of this, the VPC protects the decrypted traffic between ELB and HAProxy and between HAProxy and Simple AD. The ELB encryption provides an additional layer of security for client connections and protects traffic coming from hosts outside the VPC.
- Our approach requires an Amazon VPC with two public and two private subnets. The previous diagram illustrates the environment’s VPC requirements. If you do not yet have these components in place, follow these guidelines for setting up a sample environment:
- Identify a region that supports Simple AD, ELB, and NAT gateways. The NAT gateways are used with an Internet gateway to allow the HAProxy instances to access the internet to perform their required configuration. You also need to identify the two Availability Zones in that region for use by Simple AD. You will supply these Availability Zones as parameters to the CloudFormation template later in this process.
- Create or choose an Amazon VPC in the region you chose. In order to use Route 53 to resolve the LDAPS endpoint, make sure you enable DNS support within your VPC. Create an Internet gateway and attach it to the VPC, which will be used by the NAT gateways to access the internet.
- Create a route table with a default route to the Internet gateway. Create two NAT gateways, one per Availability Zone in your public subnets to provide additional resiliency across the Availability Zones. Together, the routing table, the NAT gateways, and the Internet gateway enable the HAProxy instances to access the internet.
- Create two private routing tables, one per Availability Zone. Create two private subnets, one per Availability Zone. The dual routing tables and subnets allow for a higher level of redundancy. Add each subnet to the routing table in the same Availability Zone. Add a default route in each routing table to the NAT gateway in the same Availability Zone. The Simple AD servers use subnets that you create.
- The LDAP service requires a DNS domain that resolves within your VPC and from your LDAP clients. If you do not have an existing DNS domain, follow the steps to create a private hosted zone and associate it with your VPC. To avoid encryption protocol errors, you must ensure that the DNS domain name is consistent across your Route 53 zone and in the SSL/TLS certificate (see Step 2 in the “Solution deployment” section).
- Make sure you have completed the Simple AD Prerequisites.
- We will use a self-signed certificate for ELB to perform SSL/TLS decryption. You can use a certificate issued by your preferred certificate authority or a certificate issued by AWS Certificate Manager (ACM).
Note: To prevent unauthorized connections directly to your Simple AD servers, you can modify the Simple AD security group on port 389 to block traffic from locations outside of the Simple AD VPC. You can find the security group in the EC2 console by creating a search filter for your Simple AD directory ID. It is also important to allow the Simple AD servers to communicate with each other as shown on Simple AD Prerequisites.
This solution includes five main parts:
- Create a Simple AD directory.
- Create a certificate.
- Create the ELB and HAProxy layers by using the supplied CloudFormation template.
- Create a Route 53 record.
- Test LDAPS access using an Amazon Linux client.
1. Create a Simple AD directory
With the prerequisites completed, you will create a Simple AD directory in your private VPC subnets:
- In the Directory Service console navigation pane, choose Directories and then choose Set up directory.
- Choose Simple AD.
- Provide the following information:
- Directory DNS – The fully qualified domain name (FQDN) of the directory, such as corp.example.com. You will use the FQDN as part of the testing procedure.
- NetBIOS name – The short name for the directory, such as CORP.
- Administrator password – The password for the directory administrator. The directory creation process creates an administrator account with the user name Administrator and this password. Do not lose this password because it is nonrecoverable. You also need this password for testing LDAPS access in a later step.
- Description – An optional description for the directory.
- Directory Size – The size of the directory.
- Provide the following information in the VPC Details section, and then choose Next Step:
- VPC – Specify the VPC in which to install the directory.
- Subnets – Choose two private subnets for the directory servers. The two subnets must be in different Availability Zones. Make a note of the VPC and subnet IDs for use as CloudFormation input parameters. In the following example, the Availability Zones are us-east-1a and us-east-1c.
- Review the directory information and make any necessary changes. When the information is correct, choose Create Simple AD.
It takes several minutes to create the directory. From the AWS Directory Service console , refresh the screen periodically and wait until the directory Status value changes to Active before continuing. Choose your Simple AD directory and note the two IP addresses in the DNS address section. You will enter them when you run the CloudFormation template later.
Note: Full administration of your Simple AD implementation is out of scope for this blog post. See the documentation to add users, groups, or instances to your directory. Also see the previous blog post, How to Manage Identities in Simple AD Directories.
2. Create a certificate
In the previous step, you created the Simple AD directory. Next, you will generate a self-signed SSL/TLS certificate using OpenSSL. You will use the certificate with ELB to secure the LDAPS endpoint. OpenSSL is a standard, open source library that supports a wide range of cryptographic functions, including the creation and signing of x509 certificates. You then import the certificate into ACM that is integrated with ELB.
- You must have a system with OpenSSL installed to complete this step. If you do not have OpenSSL, you can install it on Amazon Linux by running the command, sudo yum install openssl. If you do not have access to an Amazon Linux instance you can create one with SSH access enabled to proceed with this step. Run the command, openssl version, at the command line to see if you already have OpenSSL installed.
- Create a private key using the command, openssl genrsa command.
- Generate a certificate signing request (CSR) using the openssl req command. Provide the requested information for each field. The Common Name is the FQDN for your LDAPS endpoint (for example, ldap.corp.example.com). The Common Name must use the domain name you will later register in Route 53. You will encounter certificate errors if the names do not match.
- Use the openssl x509 command to sign the certificate. The following example uses the private key from the previous step (privatekey.pem) and the signing request (server.csr) to create a public certificate named server.crt that is valid for 365 days. This certificate must be updated within 365 days to avoid disruption of LDAPS functionality.
- You should see three files: privatekey.pem, server.crt, and server.csr.
Restrict access to the private key.
Keep the private key and public certificate for later use. You can discard the signing request because you are using a self-signed certificate and not using a Certificate Authority. Always store the private key in a secure location and avoid adding it to your source code.
- In the ACM console, choose Import a certificate.
- Using your favorite Linux text editor, paste the contents of your server.crt file in the Certificate body box.
- Using your favorite Linux text editor, paste the contents of your privatekey.pem file in the Certificate private key box. For a self-signed certificate, you can leave the Certificate chain box blank.
- Choose Review and import. Confirm the information and choose Import.
3. Create the ELB and HAProxy layers by using the supplied CloudFormation template
Now that you have created your Simple AD directory and SSL/TLS certificate, you are ready to use the CloudFormation template to create the ELB and HAProxy layers.
- Load the supplied CloudFormation template to deploy an internal ELB and two HAProxy EC2 instances into a fixed Auto Scaling group. After you load the template, provide the following input parameters. Note: You can find the parameters relating to your Simple AD from the directory details page by choosing your Simple AD in the Directory Service console.
|Input parameter||Input parameter description|
|HAProxyInstanceSize||The EC2 instance size for HAProxy servers. The default size is t2.micro and can scale up for large Simple AD environments.|
|MyKeyPair||The SSH key pair for EC2 instances. If you do not have an existing key pair, you must create one.|
|VPCId||The target VPC for this solution. Must be in the VPC where you deployed Simple AD and is available in your Simple AD directory details page.|
|SubnetId1||The Simple AD primary subnet. This information is available in your Simple AD directory details page.|
|SubnetId2||The Simple AD secondary subnet. This information is available in your Simple AD directory details page.|
|MyTrustedNetwork||Trusted network Classless Inter-Domain Routing (CIDR) to allow connections to the LDAPS endpoint. For example, use the VPC CIDR to allow clients in the VPC to connect.|
|SimpleADPriIP||The primary Simple AD Server IP. This information is available in your Simple AD directory details page.|
|SimpleADSecIP||The secondary Simple AD Server IP. This information is available in your Simple AD directory details page.|
|LDAPSCertificateARN||The Amazon Resource Name (ARN) for the SSL certificate. This information is available in the ACM console.|
- Enter the input parameters and choose Next.
- On the Options page, accept the defaults and choose Next.
- On the Review page, confirm the details and choose Create. The stack will be created in approximately 5 minutes.
4. Create a Route 53 record
The next step is to create a Route 53 record in your private hosted zone so that clients can resolve your LDAPS endpoint.
- If you do not have an existing DNS domain for use with LDAP, create a private hosted zone and associate it with your VPC. The hosted zone name should be consistent with your Simple AD (for example, corp.example.com).
- When the CloudFormation stack is in CREATE_COMPLETE status, locate the value of the LDAPSURL on the Outputs tab of the stack. Copy this value for use in the next step.
- On the Route 53 console, choose Hosted Zones and then choose the zone you used for the Common Name box for your self-signed certificate. Choose Create Record Set and enter the following information:
- Name – The label of the record (such as ldap).
- Type – Leave as A – IPv4 address.
- Alias – Choose Yes.
- Alias Target – Paste the value of the LDAPSURL on the Outputs tab of the stack.
- Leave the defaults for Routing Policy and Evaluate Target Health, and choose Create.
5. Test LDAPS access using an Amazon Linux client
At this point, you have configured your LDAPS endpoint and now you can test it from an Amazon Linux client.
- Create an Amazon Linux instance with SSH access enabled to test the solution. Launch the instance into one of the public subnets in your VPC. Make sure the IP assigned to the instance is in the trusted IP range you specified in the CloudFormation parameter MyTrustedNetwork in Step 3.b.
- SSH into the instance and complete the following steps to verify access.
- Install the openldap-clients package and any required dependencies:
sudo yum install -y openldap-clients.
- Add the server.crt file to the /etc/openldap/certs/ directory so that the LDAPS client will trust your SSL/TLS certificate. You can copy the file using Secure Copy (SCP) or create it using a text editor.
- Edit the /etc/openldap/ldap.conf file and define the environment variables BASE, URI, and TLS_CACERT.
- The value for BASE should match the configuration of the Simple AD directory name.
- The value for URI should match your DNS alias.
- The value for TLS_CACERT is the path to your public certificate.
- Install the openldap-clients package and any required dependencies:
Here is an example of the contents of the file.
To test the solution, query the directory through the LDAPS endpoint, as shown in the following command. Replace corp.example.com with your domain name and use the Administrator password that you configured with the Simple AD directory
You should see a response similar to the following response, which provides the directory information in LDAP Data Interchange Format (LDIF) for the administrator distinguished name (DN) from your Simple AD LDAP server.
You can now use the LDAPS endpoint for directory operations and authentication within your environment. If you would like to learn more about how to interact with your LDAPS endpoint within a Linux environment, here are a few resources to get started:
- Using ldapsearch to locate and retrieve directory entries
- Using ldapmodify to make changes to directory entries
- Managing access with the System Security Services Daemon (SSSD) – SSSD can be used within a Linux environment to authenticate LDAP sessions.
If you receive an error such as the following error when issuing the ldapsearch command, there are a few things you can do to help identify issues.
- You might be able to obtain additional error details by adding the -d1 debug flag to the ldapsearch command in the previous section.
- Verify that the parameters in ldap.conf match your configured LDAPS URI endpoint and that all parameters can be resolved by DNS. You can use the following dig command, substituting your configured endpoint DNS name.
- Confirm that the client instance from which you are connecting is in the CIDR range of the CloudFormation parameter, MyTrustedNetwork.
- Confirm that the path to your public SSL/TLS certificate configured in ldap.conf as TLS_CAERT is correct. You configured this in Step 5.b.3. You can check your SSL/TLS connection with the command, substituting your configured endpoint DNS name for the string after –connect.
- Verify that your HAProxy instances have the status InService in the EC2 console: Choose Load Balancers under Load Balancing in the navigation pane, highlight your LDAPS load balancer, and then choose the Instances
You can use ELB and HAProxy to provide an LDAPS endpoint for Simple AD and transport sensitive authentication information over untrusted networks. You can explore using LDAPS to authenticate SSH users or integrate with other software solutions that support LDAP authentication. This solution’s CloudFormation template is available on GitHub.
If you have comments about this post, submit them in the “Comments” section below. If you have questions about or issues implementing this solution, start a new thread on the Directory Service forum.
– Cameron and Jeff
Security updates have been issued by Debian (extplorer and libraw), Fedora (mingw-libsoup, python-tablib, ruby, and subversion), Mageia (avidemux, clamav, nasm, php-pear-CAS, and shutter), Oracle (xmlsec1), Red Hat (openssl tomcat), Scientific Linux (authconfig, bash, curl, evince, firefox, freeradius, gdm gnome-session, ghostscript, git, glibc, gnutls, groovy, GStreamer, gtk-vnc, httpd, java-1.7.0-openjdk, kernel, libreoffice, libsoup, libtasn1, log4j, mariadb, mercurial, NetworkManager, openldap, openssh, pidgin, pki-core, postgresql, python, qemu-kvm, samba, spice, subversion, tcpdump, tigervnc fltk, tomcat, X.org, and xmlsec1), SUSE (git), and Ubuntu (augeas, cvs, and texlive-base).
Security updates have been issued by Mageia (atril, mpg123, perl-SOAP-Lite, and virtualbox), openSUSE (kernel and libzypp, zypper), Oracle (authconfig, bash, curl, gdm and gnome-session, ghostscript, git, glibc, gnutls, gtk-vnc, kernel, libreoffice, libtasn1, mariadb, openldap, openssh, pidgin, postgresql, python, qemu-kvm, samba, tcpdump, tigervnc and fltk, and tomcat), Red Hat (kernel, kernel-rt, openstack-neutron, and qemu-kvm), and SUSE (puppet and tcmu-runner).
Security updates have been issued by Debian (varnish), Fedora (gcc, gcc-python-plugin, libtool, mingw-c-ares, and php-PHPMailer), Red Hat (bash, curl, evince, freeradius, gdm and gnome-session, ghostscript, git, glibc, golang, GStreamer, gtk-vnc, kernel, kernel-rt, libtasn1, mariadb, openldap, openssh, pidgin, postgresql, python, qemu-kvm, qemu-kvm-rhev, samba, tigervnc and fltk, tomcat, and X.org X11 libraries), Slackware (gnupg), and Ubuntu (apache2, lxc, and webkit2gtk).
Security updates have been issued by Debian (freerdp and ghostscript), Fedora (freerdp, jackson-databind, moodle, remmina, and runc), Red Hat (authconfig, devtoolset-4-jackson-databind, gnutls, libreoffice, NetworkManager and libnl3, pki-core, rh-eclipse46-jackson-databind, samba, and tcpdump), and Ubuntu (apache2, bash, imagemagick, openjdk-8, and rabbitmq-server).
Post Syndicated from Robert Graham original http://blog.erratasec.com/2017/07/slowloris-all-things.html
At DEFCON, some researchers are going to announce a Slowloris-type exploit for SMB — SMBloris. I thought I’d write up some comments.
The original Slowloris from several years creates a ton of connections to a web server, but only sends partial headers. The server allocates a large amount of memory to handle the requests, expecting to free that memory soon when the requests are completed. But the requests are never completed, so the memory remains tied up indefinitely. Moreover, this also consumes a lot of CPU resources — every time Slowloris dribbles a few more bytes on the TCP connection is forces the CPU to walk through a lot of data structures to handle those bytes.
The thing about Slowloris is that it’s not specific to HTTP. It’s a principle that affects pretty much every service that listens on the Internet. For example, on Linux servers running NFS, you can exploit the RPC fragmentation feature in order to force the server to allocate all the memory in a box waiting for fragments that never arrive.
SMBloris does the same thing for SMB. It’s an easy attack to carry out in general, the only question is how much resources are required on the attacker’s side. That’s probably what this talk is about, causing the maximum consequences on the server with minimal resources on the attacker’s machine, thus allowing a Raspberry Pi to tie up all the resources on even the largest enterprise server.
According to the ThreatPost article, the attack was created looking at the NSA ETERNALBLUE exploit. That exploit works by causing the server to allocate memory chunks from fragmented requests. How to build a Slowloris exploit from this is then straightforward — just continue executing the first part of the ETERNALBLUE exploit, with larger chunks. I say “straightforward”, but of course, the researchers have probably discovered some additional clever tricks.
Samba, the SMB rewrite for non-Windows systems, probably falls victim to related problems. Maybe not this particular attack that affects Windows, but almost certainly something else. If not SMB, then the DCE-RPC service on top of it.
Microsoft has said they aren’t going to fix the SMBloris bug, and for good reason: it might be unfixable. Sure, there’s probably some kludge that fixes this specific script, but would still leave the system vulnerable to slight variations. The same reasoning applies to other services — Slowloris is an inherent problem in all Internet services and is not something easily addressed without re-writing the service from the ground up to specifically deal with the problem.
The best answer to Slowloris is the “langsec” discipline, which counsels us to separate “parsing” input from “processing” it. Most services combine the two, partially processing partial input. This should be changed to fully validate input consuming the least resources possible, before processing it. In other words, services should have a light-weight front-end that consumes the least resources possible, waiting for the request to complete, before it then forwards the request to the rest of the system.
Security updates have been issued by Debian (catdoc, gsoap, and libtasn1-3), Fedora (GraphicsMagick, java-1.8.0-openjdk, krb5, librsvg2, nodejs, phpldapadmin, rubygem-rack-cors, and yara), Mageia (irssi), openSUSE (rubygem-puppet), Red Hat (kernel), Slackware (tcpdump), and Ubuntu (imagemagick, linux, linux-raspi2, linux-snapdragon, linux-lts-xenial, mysql-5.5, samba, and xorg-server, xorg-server-hwe-16.04, xorg-server-lts-xenial).
Security updates have been issued by Arch Linux (apache, evince, and mosquitto), Debian (apache2, evince, heimdal, and knot), Fedora (c-ares, cacti, evince, GraphicsMagick, httpd, jabberd, libgcrypt, openvas-cli, openvas-gsa, openvas-libraries, openvas-manager, openvas-scanner, poppler, qt5-qtwebengine, qt5-qtwebkit, spatialite-tools, and sqlite), openSUSE (gnutls, ncurses, qemu, and xorg-x11-server), Slackware (mariadb and samba), SUSE (cryptctl), and Ubuntu (heimdal and samba).