Saving Money with IOT Water Heater

About six months ago I installed an Energy Efficient water heater. This unit is what is known as a heat pump water heater. For those not familiar with refrigeration, this works by moving heat instead of creating heat. By contrast, traditional electric water heaters use resistance coils to heat the water. This new unit also has traditional coils that can be used for high demand or high temperature settings as well.

I guess by now everyone is wondering what this has to do with the topics we discussed at PacketU. To better understand the relationship, you can see that this Water Heater is also Connected to the Internet. The primary reasons I wanted to connect it to the Internet was to schedule the modes around my family’s usage patterns and control vacation mode from a mobile phone. When purchasing this unit I was quite skeptical and was concerned about transitioning from a simple conventional model to a mode that literally has moving parts. Continue reading

Posted in Uncategorized | Leave a comment

Firepower Indications of Compromise

Several days ago I wrote an article about Firepower Sinkhole rules. While I was confirming this in a lab, I temporarily created a custom DNS sinkhole rule. That rule classified requests for temp.packetu.com as Command and Control and returned an IP address of 1.1.1.1. What I later noticed is that this caused my laptop to be classified with an IOC.

Indications of Compromise (IOCs) can be thought of as reasons why Firepower Management Console believes a host cannot be trusted or is otherwise affected by malware. These can be found in multiple places in the UI. I find the Context Explorer to be a good middle ground for most SecOps team members and a good place to notice whether current IOC’s exist.

My network is rather simple and I only currently have one IOC. In any case, I can use the Context Explorer to launch the host information for the impacted host.

IOC Context Explorer

Once the Host Profile screen is launched, I can get a little more about information about the activity that causes Firepower to believe that this is a compromised host. Continue reading

Posted in Uncategorized | Tagged | 1 Comment

Understanding ‘transport output’ and ‘access-class’

Several years ago I wrote an article called The Elusive “access-class out” CommandMy primary goal was to help CCNA students understand both the behavior of and placement of this command. My friend Anthony Sequeira done a great job in the video that is also shown in my original post. Today, I want to share another command and expand on there behavior.

For all of the demonstrations in this article, the following topology will be used. The router named iosv-2 will be the primary focus and the only place changes will be made.

Topology

Understanding Telnet:SSH Client Restrictions

Backing up for a moment, there are a couple of messages that might be displayed when an IOS device blocks outbound telnet or ssh sessions from the current exec session. These are demonstrated with a quick configuration of an transport output and access-class restriction.

//the first error is unique depending on
//if ssh or telnet is being used
iosv-2(config)line con 0
iosv-2(config-line)#transport output none
iosv-2(config-line)#do telnet 192.168.0.3
% telnet connections not permitted from this terminal
iosv-2(config-line)#do ssh -l cisco 192.168.0.3
% ssh connections not permitted from this terminal

//now we can re-enable all the protocols
//and demonstrate the other error message
iosv-2(config-line)#transport input all
iosv-2(config-line)#access-list 1 deny 192.168.0.3
iosv-2(config)line con 0
iosv-2(config)#access-class 1 out
iosv-2(config-line)#do telnet 192.168.0.3
Trying 192.168.0.3 ...
% Connections to that host not permitted from this terminal

It is worth noting that in the second example, the error message is agnostic to the protocol being used (ssh or telnet). Continue reading

Posted in Uncategorized | Leave a comment

The New Strange Behavior for OSPF ‘Redistribute Subnets’

In older IOS Code, there was a specific requirement for redistributing OSPF Subnets. In almost every case, the keyword “subnets” had to be added to the redistribute command.

Older Code Example–

//notice the warning when 'subnets' is omitted
R1(config)#router ospf 1
R1(config-router)#redistribute eigrp 1
% Only classful networks will be redistributed

//and the configuration is stored exactly as it was typed
R1(config-router)#do show run | sec router
router ospf 1
 log-adjacency-changes
 redistribute eigrp 1

//we can change the behavior by adding 'subnets'
R1(config-router)#redistribute eigrp 1 subnets

//after adding, it is stored as one would expect
R1(config-router)#do show run | sec router
router ospf 1
 log-adjacency-changes
 redistribute eigrp 1 subnets

When I tested this in VIRL running 15.6(1S) running inside of IOS XE 3.17, the warning goes away. The question I had is whether it is still relevant or not.

Current Code Example–

//without the 'subnets' keyword
csr1000v-2(config)#router ospf 1
csr1000v-2(config-router)#redistribute eigrp 1
csr1000v-2(config-router)#do show run | sec router
router ospf 1
 redistribute eigrp 1

//with the 'subnets' keyword
csr1000v-2(config-router)#redistribute eigrp 1 subnets
csr1000v-2(config-router)#do show run | sec router
router ospf 1
 redistribute eigrp 1 subnets

I initially spent some time experimenting with this and thought that ‘subnets‘ had completely lost its relevance. However, the keyword kept popping up on its own. What I finally discovered is that IOS adds it later in in some cases. Take a close look at this strange behavior. Continue reading

Posted in Uncategorized | 3 Comments

Firepower Threat Defense — DNS Sinkholing

A few days ago I wrote an article that described Firepower DNS Policies. One item that probably warrants a little more discussion is DNS Sinkholing. Although the title of this article indicates Firepower Threat Defense, this will also work with Firepower and Firepower Services.

For this article, I would like to first share some of the challenges around getting security intelligence visibility from DNS requests. A typical enterprise environment will have an internal DNS server. So even though we know we can return “Domain Not Found” with an FTD DNS policy, that might not give us the visibility necessary to remediate a problem.

So if the host in the diagram below makes a DNS request for bad.site.com, what happens? Basically that request is sent to the DNS Resolver. The DNS Resolver will look to the Root Hints and eventually get the request to an Internet based DNS server that has the appropriate domain ownership. The problem with this is that the only request seen by the Firewall (FTD in our example) is the one made by the DNS Resolver. The problem here is that there is no way the Firewall can tell which host needs to be scrubbed by the SecOps team.

DNS Sinkholing

Sinkholing can solve this problem. As a DNS Reply for a known malicious request passes through FTD, it can replace the server address with one of the administrator’s choosing. This simply needs to be an address that will cause the clients to send the traffic through the Firewall. This does two things. Similar to the other DNS actions, it drastically decreases the likelihood that the host pc will connect to the malicious host on the Internet. It also allows FTD to see the subsequent connection attempts to the modified address found in the DNS Reply. Continue reading

Posted in Uncategorized | Tagged | 2 Comments

Testing the EIGRP Feasibility Condition (FC)

Last night I was going through some CCIE Routing and Switching VOD’s and found a statement I found interesting. Beyond the fact that I thought the content was far below the expert level (which is fine because a refresher or level-set is typically helpful), I believed it to be incorrect. The statement that was made is as follows:

“A neighbor meets the feasibility condition if the reported distance by the neighbor is the same as or smaller than the feasible distance of the router”

So what are my issues with this statement? First, I thought “feasible distance of the router” is ambiguous and could be assumed to be the advertised distance or the reported distance which is basically the feasible distance of the neighboring router. However, that was not my main problem with the statement. My main concern with this statement is that I have always learned that the feasibility condition is only met if the reported distance (RD) is strictly less than the feasible distance of the local route. So I set out to determine if I had a correct understanding or if the Feasibility Condition (FC) could really be met with a RD equal to the FD.

To test my theory, I built out a simple topology with a 1.1.1.0/24 network in two different places. The second instance of 1.1.1.0/24 is one more hop away and should work out perfectly to demonstrate this from the perspective of csr1000v-1. This should create an RD through csr1000v-2 that is equal to the local FD of csr1000v-1 for the network represented on the L1 interfaces. I also simplified the topology by removing the link between the two intermediary routers and only included transit links and the 1.1.1.0/24 in the EIGRP topology.

Screen Shot 2016-07-04 at 9.45.49 PM

EIGRP Topology from csr1000v-1

Continue reading

Posted in Uncategorized | Leave a comment

Understanding Firepower DNS Policies

One cool feature added with Firepower version 6 is probably best described as DNS-based Security Intelligence, Inspection and Sinkholing. The thought is pretty simple. If a host issues a DNS request for a host that is known to be malicious, that response is manipulated. The manipulated response can be host not found, an alternative IP address or no response at all. This allows an administrator to provide another layer of protection by preventing hosts ready access to the IP addresses of known malicious hosts.

So the first question that might come to mind is how are hosts on the Internet classified as bad. The short answer is that Talos maintains lists of known bad fully qualified domain names (fqdn). These are actually categorized and delivered into the Firepower solution as a feed. Each of the following category can be selected into one or multiple DNS Rules.

DNS Feeds and ListsDNS Rule with Categories

  • DNS Attackers
  • DNS Bogons
  • DNS Bots
  • DNS CnC
  • DNS Dga
  • DNS Exploitkit
  • DNS Malware
  • DNS Open_proxy
  • DNS Open_relay
  • DNS Phishing
  • DNS Response
  • DNS Spam
  • DNS Suspicious
  • DNS Tor_exit_node

Continue reading

Posted in Uncategorized | Tagged | 2 Comments

Meraki MX – URL Filtering

Over the past few days, I’ve spent quite a bit of time looking at some of the advanced capabilities of modern Cisco Firewalls. My most recent testing was done with the Meraki MX 60 cloud managed Firewall product. What I have to say is this is the easiest to configure content filter I’ve ever seen. So I just wanted to take a moment and share what that looks like.Meraki MX Menu

As with all Meraki products, the MX is completely cloud managed. So to manage the device, and administrator must access the Meraki Dashboard. Once authenticated, it is simply necessary to choose Security Appliance then Content Filtering from the menu on the right.

Once on the content filtering page, the policy is self explanatory. The top section is for categories that should be blocked. While the box appears to be a free form entry field, clicking anywhere in the area presents a list of categories to choose from. The bottom section allows for manual whitelisting and blacklisting. To get a better idea on how the match is performed and the format requirements of the block criteria, the “Learn how URL blocking works” link may be selected. Continue reading

Posted in Uncategorized | 1 Comment

Be Careful with TCP Syslog and the ASA

I wanted to take just a moment to share a little gotcha that could take you by surprise. To demonstrate, I have a simple topology with an ASA in the middle. I am inspecting ICMP so ping traffic is stateful and flows properly.

TCP Syslog
To confirm connectivity,  I can ping from csr1000v-2 from csr1000v-1

csr1000v-1#ping 10.0.0.10 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/6/16 ms

Now for the ASA change that can catch an administrator off guard Continue reading

Posted in Uncategorized | 2 Comments

Manual URL Filtering in Firepower

A few days ago, someone asked me the following two questions–

  1. Is a URL filtering license required to manually filter sites in Firepower?
  2. Are wildcards supported as filtering criteria?

The short answer to the first question is simply no. There is no requirement for a term-based URL filtering license to do manual filtering. The URL license enables filtering AND logging based on web categories and risks levels. If this license is not installed and attached to a Firepower device, any policy containing those elements cannot be deployed. However, URL filtering rules that contain only manual URLs can be applied and do function properly.

The visual below is directly from the URL tab in an Access Control Policy Rule.

Selected URLs

The second question requires a slightly longer answer. With URL filtering, Firepower considers the protocol, fqdn, path and filename. For example, the following is a URL for the article I wrote last Thursday. Continue reading

Posted in Uncategorized | Tagged | 1 Comment

Accessing ASA CLI in Firepower Threat Defence

I’ve recently loaded Firepower Threat Defense on an ASA5525 for my home Internet firewall. For those unfamiliar with FTD, it is basically a combination of critical ASA features and all of the Cisco Firepower features in a single image and execution space. So unlike Firepower Services, which runs separately inside the same ASA sheet metal,  FTD takes over the hardware. Once the image installed onto the hardware, the firewall is attached to and managed by a Firepower Management Console.

For those that still want to (or need to) get under the covers to understand the underpinnings or do some troubleshooting of the ASA features, it is still possible to access the familiar CLI. The process first requires an ssh connection to the management IP of the FTD instance, then access expert mode and enter the lina_cli command.

MacBook:~ paulste$ ssh [email protected]
Password:
Last login: Thu Jun 23 18:16:43 2016 from 192.168.1.48

Copyright 2004-2016, Cisco and/or its affiliates. All rights reserved.
Cisco is a registered trademark of Cisco Systems, Inc.
All other trademarks are property of their respective owners.

Cisco Fire Linux OS v6.0.1 (build 37)
Cisco ASA5525-X Threat Defense v6.0.1 (build 1213)

//go into expert mode
> expert

//enter sudo lina_cli -- my su password was the admin pw I set during installation
[email protected]:~$ sudo lina_cli
Password:


Attaching to ASA console ... Press 'Ctrl+a then d' to detach.
Type help or '?' for a list of available commands.

//enable password was blank for me
firepower> en
Password:
firepower#

Now the typical ASA show commands are avaialble. For example–

show run dhcpd (yes, you can actually make your FTD device a DHCP server) Continue reading

Posted in Security, Technology | Tagged | 8 Comments

Simple ASA to IOS VPN

Occasionally you just need a cheat sheet to configure something up. This is meant to be exactly that, a quick configuration of lan to lan IPSec between an ASA and IOS based router.

Topology

Host (for testing)

! /// Host is simply here to emulate a
! /// client on one end of the network
!
hostname Host
!
interface GigabitEthernet0/1
 description to iosv-1
 ip address 192.168.1.2 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 192.168.1.1

iosv-1 (IOS IPSec Endpoint)

Continue reading

Posted in Uncategorized | 1 Comment