Showing posts with label Security. Show all posts
Showing posts with label Security. Show all posts

Thursday, October 22, 2020

Security Field Day 4 - Cisco Security Update - Tetration all the things

This time around Security Field Day 4 was all about Cisco Tetration. It seems they are focusing on how to solve security policy creation and management via big data and machine learning.

Rob Tappenden did the overview of Tetration, giving the background about why the product is around and why it is important. The goal is securing application workloads across on-premises Data Centers, Campus ang Cloud. It ingests IP data and is able to make policy enforcement decisions based on that data set, which is collected and analyzed over time. Tetration is doing data correlation and pattern matching to help define policies and also to determine if an application is currently matching an existing policy already defined.


Here is Rob's video:



Tim Garner then walked through the details around the policy process and operations of how Tetration does what it does. It was an interesting demo to watch, mainly because I have not had the chance to be hands on with Tetration at all myself. You can learn a lot about how a product functions by watching others use it. Tetration leverages both an agent and also flow data. The combination is likely the approach many with take as it gives the most complete view of the network. The demo had systems running in AWS with the agent installed, therefore exposing all the IP and network connectivity. The agent is able to do policy enforcement based off what you publish through Tetration and it is possible to run a simulation of your policy to see the impact prior to deploying it.





Here is Tim's video:


Then a more developer focused presentation was given by Remi Philippe, walking through a standard CI/CD workflow using Github and Jenkins to show how a developer would integrate and use/interact with Tetration. It was useful to see, but I am skeptical how many companies have operational team that are adopting Tetration and teaming with their developers in this way. I'm sure they are out there, but I am guessing that the majority of application developers are for more interesting in APM solutions like AppDynamics (owned by Cisco), New Relic, DataDog or Dynatrace than accommodating the operations team around Tetration. Because APM is code integrated and has an agent, I am doubting the desire of the app teams to run multiple agents on a host. The moment something goes wrong in an environment, the first thing that is turned off is security policy, firewalls and anything that might prevent the application to talk on the wire to each other. If that fixes it, then that agent or process isn't turned back on again.

Here is Remi's video:


I believe, over the long term, Tetration has to be integrated with AppDynamics and ThousandEyes (owned by Cisco) and have a single agent able to provide data to all those services. It also needs to support third party APMs because not all teams chose the same tooling and Cisco needs to open up there ecosystem to support that. I'm not sure that Tetration really isn't just the big data part (with a security angle) that all the APM providers already include as part of their product and that Cisco, over the long haul with have to reposition the produce around that story. I am speculating that it is a feature of a bigger product family over time. Only time will tell.

I will update the post when the video becomes available but you should be able to find them here when they post. You can also check out some of the other delegate's thoughts on the presentation such as Michael Davis, go check out his thoughts.

- Ed

In a spirit of fairness (and also because it is legally required by the FTC), I am posting this Disclosure Statement. It is intended to alert readers to funding or gifts that might influence my writing. My participation in Tech Field Day events was voluntary and I was invited to participate in XFD4. Tech Field Day is hosted by Gestalt IT and my hotel, transportation, food and beverage was/is paid for by Gestalt IT for the duration of the event if travel was involved. In addition, sometimes small swag gifts were/are provided by some of the sponsors of the event to delegates. It should be noted that there was/is no requirement to produce content about the sponsors and any content produced does not require review or editing by Gestalt IT or the sponsors of the event.

Tuesday, October 20, 2020

Security Field Day 4 - A quick virtual hit of security

It has been awhile since I paid close attention to what is going on in the security space so I am excited to catch a few sessions with the Tech Field Day team for their Security Field Day 4 event happening tomorrow, Oct 21 virtually. You can catch everything live tomorrow and ask questions via twitter, just use the hashtag #XFD4 and cc: @techfieldday so those who are participating can ask your question live to the presenters.

Looks like the day will be with Cisco, and I think they need to impress, there are a lot of security companies out there with fantastic brands and products, this is a tough market. I hope they bring out the ThousandEyes team to talk about integration with AppDynamics to elevate Application level security and end to end monitoring and telemetry. I guess we will see what they have to say shortly!

Join me - you can hit the main website at https://techfieldday.com/ to watch live, it is 11-12 and 1-3pm PDT.

- Ed

In a spirit of fairness (and also because it is legally required by the FTC), I am posting this Disclosure Statement. It is intended to alert readers to funding or gifts that might influence my writing. My participation in Tech Field Day events was voluntary and I was invited to participate in XFD4. Tech Field Day is hosted by Gestalt IT and my hotel, transportation, food and beverage was/is paid for by Gestalt IT for the duration of the event if travel was involved. In addition, sometimes small swag gifts were/are provided by some of the sponsors of the event to delegates. It should be noted that there was/is no requirement to produce content about the sponsors and any content produced does not require review or editing by Gestalt IT or the sponsors of the event.

Tuesday, February 02, 2010

How to prevent ipv6 tunneling across firewalls and routers

Perhaps it is a company policy or someone on your IT team feels it is important to block IPv6 tunneling across your network to 6to4 relays or Teredo relay servers or perhaps you only want internal folks using your delegated IPv6 address block. Do you have any options available to you to block this sort of traffic?

As it seems with all things tech related the answer is, it depends on what you want to do. Both 6to4 and ISATAP utilize IPv4 protocol 41 to tunnel their traffic. Therefore, it is easy enough to block IPv6 protocol 41 from traversing internally (which would stop ISATAP and 6to4) or at the edge firewall (which would stop 6to4 but might not stop ISATAP.) On Cisco IOS it might look like this on an internal router or switch:
access-list 100 deny 41 any any
access-list 100 permit any any (or whatever traffic you DO want to permit)

In addition, to this step you can blackhole the IPv4 route to 192.88.99.1 which is the IPv4 anycast address used for the 6to4 IPv4 relay. On Cisco IOS you could do:
ip route 192.88.99.1 255.255.255.255 null0

Teredo clients can be blocked in a simple method because by design it utilizes UDP over IPv4 to establish and build it's NAT traversal tunnel traffic. Simply blocking outbound UDP traffic solves the problem but certainly breaks a lot of other functions for end client machines.

If you are running a Microsoft Windows AD configuration with clients belonging to the domain you can poison the Teredo entry that is used by default on a Microsoft client machine. All Microsoft clients from Windows XP on up make use of the dns name teredo.ipv6.microsoft.com to resolve if they can utilize Teredo to build out an IPv6 connection. This likely isn't the best method but it can be effective and some might say required because from Windows Vista on up Teredo is enabled by default but is inactive. This means if an application gets installed that wants to make use of Teredo it activates the Teredo client and attempts to use it.

You can also use a GPO to change the registry keys to keep Teredo off. You can push firewall changes to the Windows clients (Vista and Windows 7) that would block Teredo or you could turn off IPv6 which would solve the problem also. Microsoft has documentation on all of those options, you can start looking here, here or here to find out more.

So, in those cases where you actually need to turn off IPv6 tunneling technologies there are options available. The next question is do you really want to block these technologies?
- Ed

Friday, January 29, 2010

Recommended rfc networks to consider as filters

There are many ways to help protect your network from attack, one of the simpilist and most effective is actually to filter incoming and outgoing traffic from your network. An excellent place to start is to utilize the rfc's to define IPv4 addresses that are not or never will be in use on the public Internet and not allowing that traffic inbound. In the same vein, you can use the same information to limit what is allowed to leave your network, such as only IPv4 addresses that are legitimately routable on the public Internet.

This is not a new or unique solution but it is more commonly done at the service provider and larger enterprise level because those type of operations pay attention to the rfc's but also because they recieve much higher traffic loads on average traditionally. I believe that this technique is still useful for much smaller operations to use and is relatively simple to set up and maintain.

Here is a short list of rfc's to put in your firewall or edge router of addresses you should not be seeing from the Internet and ones that you should consider filtering out before sending traffic out to the Internet.

network RFC 1112
description - Host Extensions for IP Multicasting - in RFC 1700 also
240.0.0.0 240.0.0.0

network RFC 1700
description - assigned numbers - multicast, current, host, and reserved
224.0.0.0 240.0.0.0
240.0.0.0 240.0.0.0
0.0.0.0 255.0.0.0
127.0.0.0 255.0.0.0

network RFC 1797
description - Class A Subnet Experiment - may get reallocated - use the bogon list instead
39.0.0.0 255.0.0.0

network RFC 1918
description - reserved private IPv4 addresses
10.0.0.0 255.0.0.0
172.16.0.0 255.240.0.0
192.168.0.0 255.255.0.0

network RFC 2544
description - Benchmarking Methodology for Network Interconnect Devices
198.18.0.0 255.254.0.0

network RFC 3068
description - IPv4 reserved 6to4 IPv6 gateway services
192.88.99.0 255.255.255.0

network RFC 3171
description - IANA Guidelines for IPv4 Multicast Address Assignments
224.0.0.0 224.0.0.0 (covers 224.0.0.0 through 255.255.255.255)

network RFC 3927
description - Dynamic Configuration of IPv4 Link-Local Addresses - in 5735 above
169.254.0.0 255.255.0.0

network RFC 5735 (update of RFC 3330)
description - this rfc really collects all the other rfc with special use (reserved and limited IPv4 blocks) in a single doc, these is only a partial listing
192.0.2.0 255.255.255.0
169.254.0.0 255.255.0.0
224.0.0.0 224.0.0.0
14.0.0.0 255.0.0.0 (may be reallocated - use the bogon list instead just in case)

network RFC 5736
description - IPv4 Special Purpose Address Registry
192.0.0.0 255.255.255.0

network RFC 5737
description - reserved for test net
198.51.100.0 255.255.255.0
203.0.113.0 255.255.255.0

Here are some reference URL's to get you started to determine what you should apply for your needs.
Wikipedia
IANA
Team CYMRU

In addition to using IP address list filters there are other protections you can take at the edge. You should consider putting more aggressive ICMP filters in and also filter specific IP protocol numbers from coming in or going out. I'll post more about that another time.
- Ed

Thursday, January 21, 2010

Imperva Releases Detailed Analysis of 32 Million Breached Consumer Passwords

Seems that password security is still a huge issue for enterprises and for consumers. The recent analysis report from Imperva is a little scary and enlightening at the same time. Granted this is analysis of consumer grade passwords for a website but it still offers insight into how people go about using and generating passwords.

Some fascinating items from the reports findings of the most common passwords:
  1. 123456
  2. 12345
  3. 123456789
  4. Password
  5. iloveyou
  6. princess
  7. rockyou
  8. 1234567
  9. 12345678
  10. abc123
I think given that the website was rockyou.com we can safely remove that one from the list. What you are left with are passwords that you should be eliminating as acceptable within your environment. In addition, the graphs show in the report that only 3.81% of users used special characters in their passwords. They also state "Nearly 50% of users used names, slang words, dictionary words or trivial passwords (consecutive digits, adjacent keyboard keys, and so on)."

Gets you thinking that OTP + pin or smartcards might be the only real way to enforce true high quality password security for consumers or enterprises.
- Ed