Author: scottcschweitzer

Stratus and Solarflare for Capital Markets and Exchanges

scottcschweitzer HFT, networking ,

by David Whitney, Director of Global Financial Services, Stratus

The partnership of Stratus, the global standard for fault-tolerant hardware solutions, and Solarflare, the unchallenged leader in application network acceleration for financial services, at face value seems like an odd one. Stratus ‘always on’ server technology removes all single points of failure, which eliminates the need to write and maintain costly code to ensure high availability and fast failover scenarios.  Stratus and high performance are rarely been used in the same sentence.

Let’s go back further… Throughout the 1980’s and 90’s Stratus, and their proprietary VOSS operating system, globally dominated financial services from exchanges to investment banks. In those days, the priority for trading infrastructures was uptime which was provided by resilient hardware and software architectures. With the advent of electronic trading, the needs of today’s capital markets have shifted. High-Frequency Trading (HFT) has resulted in an explosion in transactional volumes. Driven by the requirements of one of the largest stock exchanges in the world, they realized that critical applications need to not only be highly available but also extremely focused on performance (low latency) and deterministic (zero jitter) behavior.

Stratus provides a solution that guarantees availability in mission-critical trading systems, without the costly overhead associated with today’s software-based High Availability (HA) solutions as well as the need for multiple physical servers. You could conceivably cut your server footprint in half by using a single Stratus server where before you’d need at least two physical servers. Stratus is also a “drop and go” solution. No custom code needs to be written, there is no concept of Stratus FT built customer applications. This isn’t just for Linux environments, Stratus also has hardened OS solutions for Windows and VMWare as well.

Solarflare brings low latency networking to the relationship with their custom Ethernet controller ASIC and Onload Linux Operating System Bypass communications stack. Normally network traffic arrives at the server’s network interface card (NIC) and is passed to the Operating System through the host CPU. This process involves copying the network data several times and switching the CPU’s context from kernel to user mode one or more times. All of these events take both time and CPU cycles. With over a decade of R&D, Solarflare has considerably shortened this path. Under Solarflare’s control applications often receive data in about 20% of the time it would typically take. The savings are measured in microseconds (millionths of a second), typically several or more. In trading speed often speed matters most, so a dollar value can be placed on this savings. Back in 2010, one trader valued the savings at $50,000/micro-second for each day of trading.

Both Stratus and Solarflare have worked together to dramatically reduce jitter to nearly zero. Jitter is caused by those seemingly inevitable events that distract a CPU core from its primary task of electronic trading. For example, the temperature of thermal sensor somewhere in the system may exceed a predetermined level and it raises a system interrupt. A CPU core is then assigned to handle that interrupt and determine which fan needs to be turned on or sped up. While this event, known as “Jitter”, sounds trivial the distraction to processes this interrupt and return to trading often results in a delay measured in the 100’s of microseconds. Imagine you’re trading strategy normally executes in 10s of microseconds, network latency adds 1-2 microseconds, and then all the sudden the system pauses your trading algorithm for 250 microseconds while it does some system housekeeping. By the time control is returned to your algorithm it’s possible that the value of what you’re trading has changed. Both Stratus and Solarflare have worked exceedingly hard to remove Jitter from the FT platform.

Going forward, Solarflare and Stratus will be adding Precision Time Protocol support to a new version of Onload for the Stratus FT Platform.

Black Hat 2016: NIC Packet Filtering

scottcschweitzer Security

Solarflare wants to talk with you at Black Hat in Las Vegas next month, and we’re raffling off a Wifi Pineapple to those who sign up for a meeting. What is a Wifi Pineapple you ask, perhaps one of the best tools available for diagnosing wireless security issues?

At Black Hat, Solarflare will be talking about their new line of SFN8xxx series adapters that support five-tuple packet filtering directly in hardware. The SFN8xxx series adapters support thousands of filters and an additional one thousand counters that can be applied to track filter usage. Along with filtering, we’ll be discussing the tamper-proof nature of this new line of adapters, and its capability to support over the wire firmware or filter table updates via an SSL/TLS link directly to the controller on the adapter.

To learn more or set up a meeting for Wednesday, August 3 or Thursday, August 4th at Black Hat please send an email to scollins@solarflare.com, and you’ll be automatically enrolled in our drawing for a Wifi Pineapple.

OCP & the Death of the OEM Mezz

scottcschweitzer OCP, Uncategorized

OCPSince the early days of personal computing, we’ve had expansion cards. The first Apple and Radio Shack TRS-80 micro-computers enabled hackers like me to buy a foundational system from the OEM then over time upgrade it with third-party peripherals. For example, my original TRS-80 Model III shipped with 4KB of RAM and a cassette tape drive (long-term data storage, don’t ask). Within a year I’d maxed the system out to 48KB of RAM (16KB per paycheck) and a pair of internal single sided, single density 5.25” floppy drives (90KB of storage per side). A year or so later the IBM PC debuted and transformed what was a hobby for most of us into a whole new market, personal computing (PC). For the better part of two decades IBM lead the PC market with an open standards approach, yeah they brought out MicroChannel Architecture (MCA) and PCNetwork, but we won’t hold that against them. Then in 2006 as the push towards denser server computing reached a head IBM introduced the BladeCenter H. A blade-based computing chassis with integrated internal switching. This created an interesting new twist in the market the OEM proprietary mezzanine  I/O card format (mezz), unique to IBM BladeCenter H.

At that time I was with another 10Gb Ethernet adapter company managing their IBM OEM relationship. To gain access to the new specification for the IBM BladeCenter H mezz card standard you had to license it from IBM. This required that your company pay IBM a license fee (a serious six-figure sum), or provide them with a very compelling business case for how your mezz card adapter would enable IBM to sell thousands more BladeCenter H systems. In 2006 we went the business case route, and in 2007 delivered a pair of mezz cards and a new 32-port BladeCenter H switch for the High-Performance Computing (HPC) market. All three of these products required a substantial amount of new engineering to create OEM specific products for a captive IBM customer base. Was it worth it, sure the connected revenue was easily well into the eight figures? Of course, IBM couldn’t be alone in having a unique mezz card design so soon HP and Dell debuted their blade products with their own unique mezz card specifications. Now having one, two or even three OEM mezz card formats to comply with isn’t that bad, but over the past decade nearly every OEMs from Dell through SuperMicro, and a bunch of smaller ones have introduced various unique mezz card formats.

Customers define markets, and huge customers can really redefine a market. Facebook is just such a customer. In 2011 Facebook openly shared their data center designs in an effort to reduce the industry’s power consumption. Learning from other tech giants Facebook spun off this effort into a 501c non-profit called the Open Compute Project Foundation (OCP) which quickly attracted rock star talent to its board like Andy Bechtolsheim (SUN & Arista Networks) and Jason Waxman (Intel). Then in April of last year Apple, Cisco, and Juniper joined the effort, and by then OCP had become an unstoppable force. Since then Lenovo and Google have hopped on the OCP wagon. So what does this have to do with mezz cards? Everything, OCP is all about an open system design with a very clear specification for a whole new mezz card architecture. Several of the big OEMs and many of the smaller ones have already adopted the OCP specification. In early 1Q17 servers sporting Intel’s Skylake Purley architecture will hit the racks, and we’ll see the significant majority of them supporting the new OCP mezz card format. I’ve been told by a number of OEMs that the trend is away from proprietary mezz card formats, and towards OCP. Hopefully, this will last for at least the next decade.

Beyond SDN: Micro-Segmentation, Macro-Segmentation or Application-Segmentation Part-2

scottcschweitzer Microsegmentation , , ,

Large publicly traded companies like Cisco, EMC (VMWare) and Arista Networks are deeply entrenched with their customers giving them a beachhead on which they can fairly easily launch new products. Since their brands, and value is well understood and established it’s often a matter of just showing up with a product that is good enough to win new business. By contrast, start-ups like Illumio and Tufin have to struggle to gain brand recognition and work exceptionally hard to secure each and every proof of concept (PoC) engagement. For a PoC to be considered successful these new startups have to demonstrate significant value to the entrenched players as they also need to overcome the institutional inertia behind every buying decision.  So how are Illumio or Tufin any different, and what value could they possibly deliver to justify even considering them? While both Illumio and Tufin are focused on making enterprises and the deployment of enterprise applications more secure, they each leverage a dramatically different approach. First, we’ll explore Tufin, then Illumio.

Tufin has a feature called the Interactive Topology Map, which enables them to traverse your entire physical network, including your use of hybrid clouds to craft a complete map of your infrastructure. This enables them to quickly display on a single pane of glass how everything in your enterprise is connected. They then offer visual path analysis from which you can explore your security and firewall policies across your network. Furthermore, you can use a sophisticated discovery mechanism by which you select two systems, and it explores the path between them and displays all the security policies that might impact data flows between these two systems. In actual practice, as you define an application within Tufin you can leverage this sophisticated discovery or manually define the source, destination, and service. Tufin will then show you the status of the connection, at which point you can drill down to see what if any components in your infrastructure require a change request. They then have a six-step change ticket workflow: Request, Business Approval, Risk Identification, Risk Review, Technical Design, and Auto Verification. To date they appear to support the following vendors: Cisco, Check Point, Palo Alto Networks, Fortinet, Juniper, F5, Intel Security, VMWare NSX, Amazon Web Services, Microsoft Azure, and OpenStack.

By contrast, Illumio takes a much different approach, it designs security from the inside out with no dependencies on infrastructure. They attach an agent to each enterprise application as it is launched. This attached agent then watches over every network flow into and out of the application and records exactly what the application requires to be effective. From this, it computes a security policy for that application that can then be enforced every time that application is launched. It can then adapt to workflow changes, and it also has the capability to encrypt all data flowing between systems. While their videos and data sheets don’t specifically say this it sounds as though they’ve placed a shim into the network OS stack hosting the application so that they can then record all the network traffic flow characteristics, that’s likely how they support on the fly encryption between nodes. They do call out that they use IPTables, so it is possible that their code is an extension of this pre-existing security platform. Clearly, though they are just above the adapter, and Jimmy Ray confirms this in one of his awesome videos that Illumio is based on an “adapter security platform” view. Illumio then provides an enterprise management application to gather the flow data from all these agents to craft, and manage its view of the network.

So while Tufin looks into your network from the outside and enumerates what it finds, Illumio looks from the application out. Both are impressive and yield interesting perspectives worthy of evaluating. Moving forward both are tuned to delivery Application-Segmentation, it will be interesting to see how the market evaluates each, both had strong presences at RSA2016, but it will ultimately be revenue from customers that determines success.

Beyond SDN: Micro-Segmentation, Macro-Segmentation or Application-Segmentation Part-1

scottcschweitzer Microsegmentation

Software Defined Networking (SDN) originally came out of work done to extend the functionality of the Java software framework as early as 1995. In 1998 a number of the key people from Sun Microsystems and Javasoft left to found WebSprocket the first commercial implementation of SDN. Two years later Gartner had recognized SDN as an emerging market and created a new category to track commercial efforts engaged in this space. Now some 15+ years later we have cyber warfare, espionage, and financially motived hackers constantly questing for the chewy center that is our enterprise data. While SDN has addressed some of the deficiencies found in the perimeter only systems, it’s still not comprehensive enough. Some have proposed, and possibly even implemented, setting up zero-trust zones for key enterprise servers where the default policy for access to these systems is “Deny All”. Then as applications are added to a server, specific access controls are added to the switch port of that server to enable the new functionality. The problem with this approach is that it can quickly become very tedious to craft and daunting to maintain. This still leaves several problems.

The smallest practical unit on which security can be applied is the IP address, while a switch can have different policies for each Virtual Machine’s (VM) unique IP address the switch itself will never see VM to VM traffic within the same server. Using switch Access Control Lists (ACL) to enforce security policies at the application and server port layers can quickly tax a switches Content Addressable Memory (CAM). Finally, we have maintenance, can you quickly resolve why a given switch or firewall has a specific security policy or rule? Most organization are incapable of knowing the origin of every single rule as often there is no centralized, cross-vendor, auditable database that exists.

To address some of these issues VMWare and Cisco crafted a new approach they named Micro-Segmentation which defines a new overlay framework where a software management layer takes control of both the hypervisor’s virtual soft switch and the enterprise switching fabric providing a single management perspective. VMWare branded this NSX, and it offers three major advantages: management to the virtualized Network Interface Card (NIC), automated deployment of the security policy with the VM, extending the management framework to include legacy switching. Including legacy, switching isn’t just for compliance, but it’s to address all the issues around deployment across the entire enterprise. Cisco calls this Application Centric Infrastructure (ACI).

Not wanting to be left out of the post-SDN ecosystem Arista Networks added to this by crafting a Macro-Segmentation view. Rather than using an overlay framework instantiated as a series of services woven into hypervisor they are leveraging existing firewall services in both software and hardware. These firewalls can then be easily stood up or reconfigured between servers by leveraging existing software & hardware from well-established firewall vendors like Fortinet and Palo Alto Networks. Actually weaving together a management layer that includes switching and firewalls is much more coherent.

The best solution though resides somewhere between Micro-Segmentation and Macro-Segmentation, and some have called it Application-segmentation. Because in the end, all we really care about is the security of the applications we deploy on our infrastructures. So while VMWare, Cisco & Arista have taken a sort of bottom-up approach, a new breed of network security orchestration applications from companies like Illumio and Tuffin have entered the fray taking a top-down, an Application-Segmentation approach to the same problem. More on this to come in Part-2 of Beyond SDN.

Popular Cyber Security & Networking Acronyms

scottcschweitzer networking, Security

Thanks in part to IBM, no field uses acronyms like computer science. Recently I was asked to pick up product management responsibility for an evolving new line of cybersecurity products. To be relevant one needs to be current with the trendy lingo, as such here are some of the must-know acronyms. So if you’re a budding cyber security student, or hacker in training see how many of these you know off the top of your head. Note, every one of these has been checked, and the full expansion of the acronym links to the appropriate Wikipedia page.  Good luck, and enjoy.

ACL – Access Control List
AES – Advanced Encryption Standard
APT – Advanced Persistent Threat
ARP – Address Resolution Protocol
AV – AntiVirus
BGP – Border Gateway Protocol
BIND – Berkley Internet Name Domain
CAL – Client Access License
CERT – Computer Emergency Response Team
CMDB – Configuration Management Database
CRC – Cyclic Redundancy Check
CVE – Common Vulnerabilities and Exposures
DES – Data Encryption Standard
DLP – Data Loss Prevention
DNS – Domain Name System, although Service is also common
EAP – Extensible Authentication Protocol
EGP – Exterior Gateway Protocol
EMM – Enterprise Mobility Management
HIPS – Host-based Intrusion Prevention System, Wikipedia doesn’t have a unique listing for this one.
IPS – Intrusion Prevention System
IPsec – Internet Protocol Security
IDS – Intrusion Detection System
L2F – Layer-2 Forwarding protocol
L2TP – Layer-2 Tunneling Protocol
LDAP – Lightweight Directory Access Protocol
MAC – Media Access Control, as in MAC address
MAC – Mandatory Access Control
NAC – Network Access Control
NAT – Network Address Translation
NGFW – Next-Generation Firewall
NIST – National Institute of Standards and Technology
OSI – Open Systems Interconnection
OSPF – Open Shortest Path First
PAP – Password Authentication Protocol
PFS – Public-key Forward Secrecy
PGP – Pretty Good Privacy
PKI – Public Key Infrastructure
PPP – Point to Point Protocol
PPTP – Point to Point Tunneling Protocol
RARP – Reverse Address Resolution Protocol
RIP – Routing Information Protocol
RSA – Rivest-Shamir-Adleman
SCAP – Security Content Automation Protocol
SDN – Software Defined Networking
SIEM – Security Information Event Management
SNMP – Simple Network Management Protocol
SSH – Secure Shell
SSL – Secure Sockets Layer
TLS – Transport Layer Security
URI – Uniform Resource Identifier
VPN – Virtual Private Network
WAP – Wireless Application Protocol
WEP – Wired Equivalent Privacy

If it’s not on this list that doesn’t mean it’s not important, just that I’ve not yet stumbled across it, or Wikipedia doesn’t recognize it as an industry term but is likely a vendor-initiated one.

Why Netflow, What is it, and Why it’s Important to Security

scottcschweitzer networking

Many of us have been working in technology so long that we’ve become jaded, and readily dismiss what appears as new, yet minor advancements. Back in the 1990s, we were focused on the emergence of the web server, web site creation, and the DOTCOM boom. We barely took notice when Cisco released a router utilizing a new technique called Netflow. It quickly flopped as a method of routing, and gave way to Express Forwarding, but as is often the case it didn’t die. The new IPFIX standard is essentially Netflow v10 since it followed Netflow v9. Regardless, why has a technology that failed so early on, gone through nine subsequent major version releases? Primarily because network administrators wanted to know how their infrastructure was being utilized. Netflow morphed into a network accounting mechanism. The real benefit though has come in the past five or so years as it has risen in importance as solutions to mitigate advanced persistent threats (APT) have become critical. Packet capture is fine, but the volume of data retained can be crushing, often all you need is the intelligence captured in a Netflow record. So what are Netflows and why are they important?

In simple terms, a Netflow is a record of a connection between two systems during a period of time. Essentially a path of collected digital foot prints showing every detail of the connection between two systems. Netflow records, in fact, are so trusted that they are admissible in court as evidence. So what is a Netflow record? While Netflow v9 or IPFIX, the formalized standard derived from it, is the latest these are both pretty complex to digest this early on so we’ll look at the most commonly used version Netflow v5. There are two parts to a Netflow v5 event, the flow header, and the flow record. The flow header contains mainly time stamp information specific to the record when the record was generated down to the nanosecond, as well as some basic info about what generated the record. The record is where the real data lives. It contains the source and destination IP addresses, next hop router address, SNMP interface data, number of packets in the flow, the total number of Layer 3 bytes in the flow, TCP/UDP source and destination ports, protocol type, service type, and a series of flags. Records are generated when a flow is finished, or periodically for persistent flows. Whatever is exporting the flow can be configured to generate records periodically for open flows. A flow is considered finished when a TCP session termination is received or if the flow exceeds a predetermined age since the last packet in the flow was received. So what can these flow records be used for?

Have you ever watched a crime drama, and seen the police pull the suspect’s vehicle E-ZPass toll records or onboard GPS history. They are looking at real world flow data to determine if the suspect could have been on the scene of the crime at the time it occurred. In the cyber world Netflow, data would be the equivalent. It will tell you when an attacker connected with your system, how they connected, and how much data they stole. It will not tell you what specifically they stole, but knowing the time, how it was taken, and how much was stolen is often enough of a clue to enable you to explore other system specific records or logs to determine exactly what was taken. Looking at patterns of Net flows in near-real time (remember when net flow records are created) is a new technique for catching attackers before they can make off with your enterprise’s crown jewels.

Netflow data can we used for a great many things from balancing loads across a cloud application or infrastructure to tracking cyber crime or cyber warfare in near-real time. So how might you use Netflow to look for a cyber attack? One method is to employ the dark space within your companies Internet and internal corporate address space to setup decoy systems. The decoys could be simple stand-alone RaspberryPi systems configured to run Apache, Nginx, Memcached, MySQL, etc… and loaded with useless dummy data. These systems should typically see NO traffic because they serve no purpose to your employees or customers. Mark my words though, once they exist they will soon be discovered and interrogated. By monitoring the Netflows into these systems you can then use that source data as the key to search all the flows into all your production systems and desktops. Also, you could pro-actively use the data from these systems to strengthen both your perimeter and endpoint defenses.

Another method would be to look for Netflow patterns within your enterprise that are indicative of a cyber attack. All of the common penetration testing tools can be profiled in such a way as to yield a unique pattern of Netflows that they generate into a system they are preparing to attack. Often these tools work like a common home burglar doing reconnaissance before a job.  If you can catch the burglar during his recon effort you can thwart his attack. Netflows provide you this data.

Cisco’s Approach to 25Gbps: Why It Matters

scottcschweitzer networking

By John Ciarlone, Hummingbird Networks

Currently, there is something of a gap in network speeds.  More of a gulf, really.  For larger businesses looking to invest in high-speed networking, the major choices at the moment are either 10Gbps… or 100Gbps.  There is, obviously, a vast difference in price and implementation difficulty between these speeds, especially as 100Gbps is currently aimed only at the largest of enterprises and service-based providers.

So for larger enterprises whose needs were growing beyond what 10Gbps could offer, the options were limited.  Bundling services and hardware allows for speeds up to 40Gbps, but that involves significant redundancies and increased cabling requirements, reducing its cost-effectiveness.

However, a new collation has arisen, promoting 25Gbps chipsets, which can also be doubled to 50Gbps.  The 25 Gigabit Ethernet Consortium began in 2014 with Google, Microsoft, and Broadcom seeking new and better upgrade paths for their operations and their clients, and has quickly picked up steam.  With the new announcement that Cisco has joined in, along with Arista and Dell, 25Gbps seems to be a standard worth discussing.

25Gbps:  Your New Upgrade Path?
Cisco’s decision to join into the 25 Gigabit consortium signals that its time may have truly come, especially given Cisco’s new emphasis on software-defined networking (SDN) and SD-WAN.  25Gb speeds give virtualized software-based systems plenty of room to breathe, and the option to move up to 50Gb creates an obvious upgrade path from 10Gbps.

This is largely thanks to the new Broadcom Tomahawk chipset, which is designed specifically for SDN systems at 25, 50, or 100Gbpsspeeds.  It’s capable of up to 3.2Tbps in switching capacity, bringing 25Gbps speeds to every lane.  It can reduce cabling requirements by up to 75%, as compared to 40Gbps connections.

In fact, 100Gbps connections are simply four 25Gbps streams working in parallel, so splitting them into separate connections is an obvious choice.  This single chipset allows for a simple upgrade path up to current top-grade speeds, without burdening operations that don’t have a need for 100Gbps yet.

By embracing Tomahawk, Cisco and Dell are creating networking opportunities appropriate for a wide range of large-scale operations.

Coming Soon To Equipment Near You
Is it time to invest?  Well, not quite.  25G just began rolling out at the end of 2015, with only around 2,500 units sold in the last quarter of the year.  However, based on the widespread demand for networks in this speed range, analysts are estimating it could account for up to 10% of ports shipped worldwide by 2019.

Plus, of course, data demands are only going to grow in the years to come.  4K video is already here, and 8K isn’t far behind, with both consumers and businesses alike quickly adopting ultra high-resolution videos.   Likewise, demand in the consumer sector for video games with 4K+ graphics and robust multiplayer capabilities will be putting additional strain on service providers attempting to keep data flowing smoothly with minimum lag.
Even if there doesn’t seem to be much demand for 25Gbps now, that demand will undoubtedly be there soon enough.

In the meantime, if you’re one of those organizations on that borderline where 10Gbps is too slow, 40Gbps is too obfuscated, and100Gbps is simply too much, please consider contacting Hummingbird Networks.  We can discuss whether you’re ready to become one of the early adopters of this hot new standard.

40GbE Performance Tuning Suggestions

scottcschweitzer networking
A customer recently requested some 40GbE performance tuning advice, and this is what we shared with them.

Solarflare provides some initial tuning advice in our “Solarflare Server Adapter User’s Guide” Section 3.24 “Performance Tuning on Linux”.  The User Guide can be downloaded from https://support.solarflare.com/ -> Downloads as part number SF-103837-CD. This is frankly the best place to start. 

The biggest gain for throughput will come from reducing the CPU load when transferring data and this done in two ways. The first is to reduce the number of packets being sent/received by increasing the size of the MTU for the interface. This does require all the network devices to be configured so as to support this larger size, it will automatically negotiate down if necessary. You can set the larger size using the following command, where is the interface name:

# ifconfig mtu 9000

We support up to 9216 with our adapters but the 9000 value is the most commonly used by network equipment.
The second improvement can be done by increasing the number of packets processed each time the system processor is interrupted. This is done using ‘ethtool’ to increase the interrupt moderation time and will increase latency but reduce CPU utilization. You can do this with the following command:

# ethtool -C rx-usecs 100

The default value is 60 (or 56 on more recent firmware versions) and values up to 200 may be used. The benefits from going beyond this value experience diminishing returns.
With this second method, we also recommend disabling interrupt moderation where the kernel will tune the value used to somewhere between 1 and the value specified. In theory, this can be useful if you are doing a mixture of large and some small, latency sensitive transfers but the algorithm isn’t great and can get stuck at either end of the range. To disable this, you can use the following command:

# ethtool -C adaptive-rx off

This can be combined with the previous ‘ethtool’ command into a single one if desired:

                # ethtool -C <if_name adaptive-rx off rx-usecs 100

These two changes should give increased throughput, most probably limited by the CPU processing capability of the incoming packets. It should be noted that if you use multiple streams for TCP or different hosts for UDP/TCP you can get better performance because the processing will be done by more cores.
— Richard Drinkwater, Solarflare

Solarflare at DataConnectors Charlotte NC

scottcschweitzer Uncategorized

You can never know too much about Cyber Security. Later this month Data Connectors is hosting a Tech Security event on Thursday, January 21st at the Sheraton Charlotte Airport Hotel, and we’d like to offer you a free VIP Pass!

Solarflare will be at this event showing our latest in 10Gb and 40Gb Ethernet server adapters along with discussing how servers can defend themselves against a DDoS attack through our hardened kernel driver which provides SYN cookie, white/black listing by port and address as well as rate limiting. To learn more please stop by.