Frank Petrilli

Software Developer & Network Engineer

Author: Frank

PowerDNS AAAA Record DNSSEC validation failure

Recently, I ran into a problem with my PowerDNS server setup. When a user queried for a AAAA record against a zone that was DNSSEC-enabled and had only an A record for the subject of the query, the NOERROR negative response using an NSEC record from the PowerDNS authoritative server was validated by the PowerDNS recursor and other recursor software as “bogus”.

I was able to resolve this issue by enabling NSEC3 mode in PowerDNS using the ‘narrow’ flag to keep my SQL backend from requiring a zone rectify on every change.
The command to perform this was

sudo pdnsutil set-nsec3 <domain> '1 0 1 ab' narrow

If you’ve run into this issue, hopefully my post has helped you.

How-To: MPLS configuration from a service provider perspective | Part 3

Before beginning this blog post, make sure to read How-To: MPLS configuration from a service provider perspective | Part 2

Introduction

Sometimes enterprises want or need layer-2 connectivity between sites. By-and-large, we don’t want to run large layer-2 networks in the provider space. High-capacity links are expensive and there’s no reason to leave them in blocking state. Seeing xe-0/0/1.0 or even et-0/0/1.0 status: blocked by STP is disappointing to say the least. Using our MPLS and OSPF based backbone, we can make use of ECMP and keep these links alive and in use while retaining them for failover purposes.

VPLS & BGP

Using our MPLS and BGP-enabled network, we can create intelligent layer-2 bridges across the layer-3 network using MPLS as our transport protocol. To do this, we’ll use a protocol called VPLS. VPLS, or Virtual Private LAN Service is a way to create multipoint-to-multipoint layer-2 bridges across service provider MPLS backbones. BGP comes in handy here as a way to distribute information about how to connect into the VPLS service to each PE device.

Topology

I’ve left our layer-3 VPN intact for reference purposes and decided to place another device on our Access{1,3}’s ether3 link. In this case, we’ll use ether3 as the customer-facing interface and keep ether2 alive as a L3VPN CE-PE peering point.

Screen Shot 2016-08-25 at 12.28.05 PM

Bridges

In Mikrotik’s RouterOS, it’s necessary to create bridges which our customers and VPLS tunnel endpoints connect together inside. Let’s start by creating a bridge on each of Access{1,2}

# Create Bridge Customer2
/interface bridge add name=Customer2
# Add ether3 to that bridge
/interface bridge port add bridge=Customer2 interface=ether3

Now let’s add the a BGP-VPLS interface to that bridge. We need to choose a unique Route-Distinguisher for this link, for which I’ve chosen 65530:2. Further, we need unique Site-IDs for each PE we terminate on.

On Access1:

# Create BGP-VPLS Interface attached to Customer2 bridge with 65530:2 on Site-ID 1
/interface vpls bgp-vpls add bridge=Customer2 bridge-horizon=1 route-distinguisher=65530:2 import-route-targets=65530:2 export-route-targets=65530:2 site-id=1

On Access2:

# Create BGP-VPLS Interface attached to Customer2 bridge with 65530:2 on Site-ID 1
/interface vpls bgp-vpls add bridge=Customer2 bridge-horizon=1 route-distinguisher=65530:2 import-route-targets=65530:2 export-route-targets=65530:2 site-id=2

Let’s verify these were created. On Access1 or Access2, run the following:

# Display VPLS tunnels
/interface vpls print

The output should be as follows if run from Access1:

Flags: X - disabled, R - running, D - dynamic, B - bgp-signaled, C - cisco-bgp-signaled
0 RDB name="vpls1" mtu=1500 l2mtu=1500 mac-address=02:F2:EC:FA:B1:BB arp=enabled disable-running-check=no remote-peer=10.101.0.8 cisco-style=no cisco-style-id=0 advertised-l2mtu=1500 pw-type=raw-ethernet use-control-word=yes vpls=bgp-vpls1

This line indicates we have a Running, Dynamic, BGP-Signalled VPLS tunnel to the peer 10.101.0.8 (Access3’s loopback). At this point, our tunnel should be running! Let’s create some layer-2 based links on our Customer routers e.g. Cust2Site{1,2}

On Cust2Site1:

# Create IP Address on provider-facing interface
/ip address add interface=ether1 address=192.168.1.1/24

On Cust2Site2:

# Create IP Address on provider-facing interface
/ip address add interface=ether1 address=192.168.1.2/24

Now we should be able to talk with the other end of the connection just like there was a wire between them.

On Cust2Site1:

# Ping Cust2Site2
/ping 192.168.1.2 count=5

You should see responses as follows:

SEQ HOST SIZE TTL TIME STATUS
0 192.168.1.2 56 64 2ms
1 192.168.1.2 56 64 2ms
2 192.168.1.2 56 64 2ms
3 192.168.1.2 56 64 2ms
4 192.168.1.2 56 64 2ms
sent=5 received=5 packet-loss=0% min-rtt=2ms avg-rtt=2ms max-rtt=2ms

And just for fun, let’s verify this is true layer-2 communication by creating a PPPoE server on Cust2Site1 and scanning for it on Cust2Site2:

On Cust2Site1:

# Create PPPoE Server
/interface pppoe-server server add disabled=no interface=ether1 service-name=Cust2PPPoETest

On Cust2Site2:

# Scan for a PPPoE Server on the provider-facing interface
/interface pppoe-client scan interface=ether1 duration=10s

A successful connection will show output as follows:

SERVICE MAC-ADDRESS AC-NAME
Cust2PPPoETest 00:00:AB:F1:98:00 Cust2Site1

We now have a running layer-2 VPLS-based VPN signalled over BGP between the two endpoints. Adding another site for Cust2 is as simple as running the commands that were run on Access{1,2} with a different site-id.

How-To: MPLS configuration from a service provider perspective | Part 2

Before beginning this blog post, make sure to read How-To: MPLS configuration from a service provider perspective | Part 1

Introduction

So after part 1 we have a running MPLS network. Congratulations! It may not seem any different from the OSPF-enabled routed networks you may have experience with before with what we’ve done so far, but now that we have MPLS running, we can make use of its content-agnostic design to transport some more interesting traffic via our topology.

Continue reading

How-To: MPLS configuration from a service provider perspective | Part 1

I often get questions on MPLS use cases and network designs; when we have such accelerated forwarding in modern-day network equipment with massive, rapid TCAM or general-purpose memory in the case of modern virtualized networks, why do we want label-based forwarding?

The Case for MPLS

While forwarding on labels is at its core a more simplistic way to forward data and should be faster, the fact remains that modern hardware sees no or minimal performance increase from moving to an MPLS network. We then must have a better reason for MPLS forwarding.

Though MPLS is a somewhat “old” in its basis (RFC3031, 2001), the modern use case for a transport protocol with no opinion on what is inside has its strengths. For example, in 2016, MPLS-designed networks allow transport of IPv6 over legacy IPv4-enabled cores without any configuration change outside of edge devices. Further, modern protocols make use of MPLS to get their job done, such as MPLS-TE, which allows for reservation of path’s resources (a blog post to come later about that), L3VPNs which allow customers to have simple connectivity between sites, and VPLS which allows for layer 2 connectivity to traverse a purely layer-3 provider backbone.

The Topology

With a little introduction done, let’s begin on making a basic MPLS network in GNS3; I’ll begin with Mikrotik RouterOS as my platform today, and release my versions with Cisco and Juniper configurations soon.

We’ll start with a simplified provider backbone model:

Screen Shot 2016-08-24 at 1.06.32 PM
Continue reading

Cipher-suite 0 IPMI

Information

Recently, Supermicro and a number of other companies have come under fire due to the inherent vulnerabilities in their IPMI implementation. In this article, I’ll be exploring the results of the vulnerability, and the ways in which this can be exploited, as well as some important mitigation strategies.

What is cipher-suite 0?

Cipher-suite 0 is a pseudo-cipher suite used in IPMI implementations which simply ignores authentication and allows full access without valid credentials.

This allows a remote attacker to exploit the BMC IPMI interface present in many rackmount servers to gain remote console access to the hardware and a shell on the embedded controller.

Exploitation

How do we exploit it?

Those familiar with IPMI will be experienced with the ipmitool command, used to locally or remotely control the IPMI controller from Linux.

To use ipmitool with cipher-suite 0, simply pass the -C 0 flag to the command. For example:

# ipmitool -I lanplus -C 0 -H 10.0.0.2 -U ADMIN -P password user list

Let’s break down what this command does:
ipmitool
The command used to control IPMI interfaces
-I lanplus
To specify IPMI v2 protocol
-C 0
Cipher-suite 0, the subject of this article
-H 10.0.0.2
Remote host to run the command against
-U ADMIN
Username: Use a valid username from the table below.
-P password
Password: Arbitrary, since it’s ignored anyway.
user list
The command we wish to run. In this case, return a list of users.

This command will complete without issue despite not knowing the actual password.

Default usernames and passwords:

Vendor Username Password
Dell root Calvin
IBM USERID PASSW0RD
Supermicro ADMIN ADMIN
Oracle root changeme
Fujitsu admin admin
Asus admin admin

Mitigation:

Using ipmitool, we’re able to disable cipher-suite 0. Run the following command on the local machine, or modify the flags to run it remotely:
ipmitool -I open raw 0xC 0x1 1 0x18 0 0x40 0x44 0x44 0x44 0x44 0x44 0x44 0x4

This should disable cipher-suite 0, effectively mitigating the flaw. Further, make sure you keep IPMI interfaces off public IP addresses, or addresses accessible to people who don’t need them. If you run an IDS, make sure it has cipher-suite 0 in its signature database.

OpenVZ container locale errors

Certain Debian-based OpenVZ container templates have no default locale set, which results in this error with certain tasks which require a locale to be set:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = “en_US.UTF-8”
are supported and installed on your system.
perl: warning: Falling back to the standard locale (“C”).
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

To fix this, run these Two commands:
locale-gen en_US en_US.UTF-8
dpkg-reconfigure locales

© 2019 Frank Petrilli

Theme by Anders NorenUp ↑