Iptables is a Linux-based firewall utility that allows system administrators to configure rules and filters for network traffic. It works by examining each packet that passes through the system and making decisions based on rules defined by the administrator.

In the context of iptables, tables are organizational units that contain chains and rules. There are five built-in tables in iptables:

1. filter – This is the default table and is used for packet filtering.
2. nat – This table is used for network address translation (NAT).
3. mangle – This table is used for specialized packet alteration.
4. raw – This table is used for configuring exemptions from connection tracking in combination with the NOTRACK target.
5. security – This table is used for Mandatory Access Control (MAC) networking rules.

In iptables, a chain is a sequence of rules that are applied to each packet passing through a particular table. Each table contains several built-in chains, and these chains can also have user-defined chains.

Each table contains several built-in chains and can also have user-defined chains. The chains contain rules that are used to determine what happens to packets as they pass through the firewall.

The name “chain” comes from the way that iptables processes packets. When a packet arrives at the firewall, it is first matched against the rules in the PREROUTING chain. If the packet matches a rule in that chain, it is processed according to the action specified in the rule. If the packet is not matched by any rules in the PREROUTING chain, it is then passed to the INPUT chain, where it is again matched against each rule.

This process continues through the FORWARD, OUTPUT, and POSTROUTING chains until the packet is either accepted, rejected, or dropped. Because each chain is a sequence of rules that are processed in order, it is called a “chain.”

In iptables, there are five types of chains. Not all of the five chains are present in all the tables. The PREROUTING, INPUT, and FORWARD chains are present in the “filter” and “raw” tables. The OUTPUT and POSTROUTING chains are present in the “filter”, “nat”, and “mangle” tables.

The “security” table, which is used for Mandatory Access Control (MAC) networking rules, does not have the PREROUTING, POSTROUTING, or OUTPUT chains. Instead, it has inbound and outbound chains for each network interface.

Each of these chains has a default policy that can be set to either ACCEPT, DROP, or REJECT. ACCEPT means that the packet is allowed through, DROP means that the packet is silently discarded, and REJECT means that the packet is discarded and the sender is notified.

System administrators can create custom rules that match specific criteria, such as the source or destination IP address, the protocol used, or the port number.

“mangle” is a table that is used to alter or mark packets in various ways. The mangle table provides a way to modify packet headers in ways that other tables cannot, such as changing the Time To Live (TTL) value or the Type of Service (TOS) field.

Remote Desktop Protocol (RDP) has its own vulnerabilities and needs to be appropriately secured.

https://mmishou.wordpress.com/2010/04/13/passive-dns-mining-from-pcap-with-dpkt-python/

Ransomware-spreading hackers sneak in through RDP

https://www.n00py.io/2018/08/bypassing-duo-two-factor-authentication-fail-open/

I was struck by the large number of vendors offering visibility as a key selling point. Into various types of network traffic. Network monitors, industrial network gateways, SSL inspection, traffic in VM farms, between containers, and on mobile.

More expected are the vendors offering reduced visibility – via encryption, TPMs, Secure Enclaves, mobile remote desktop, one way links, encrypted storage in the cloud etc. The variety of these solutions is also remarkable.

Neil Degrasse’s closing talk was so different yet strangely related to these topics, the universe slowly making itself visible to us through light from distant places, with insights from physicists and mathematics building up to the experiments that recently confirmed gravitational waves – making the invisible, visible. . This tenuous connection between security and physics left me misty eyed. What an amazing time to be living in.

Software Defined Networking seeks to centralize control of a large network. The abstractions around computer networking evolved from the connecting nodes via switches, to applications that run on top with the OSI model, to the controllers that manage the network. The controller abstraction was relatively weak – this had been the domain of telcos and ISPs, and as the networks of software intensive companies like Google approached the size of telco networks, they moved to reinvent the controller stack.  Traffic engineering and security which were done in disparate regions were attempted to be centralized in order to better achieve economies of scale. Google adopted openflow for this, developed by Nicira, which was soon after acquired by VMWare; Cisco internal discussions concluded that such a centralization wave would reduce Cisco revenues in half, so they spun out Insieme networks for SDN capabilities and quickly acquired it back. This has morphed into the APIC offering.

The centralization wave is a bit at odds with the security and resilience of networks because of their inherent distributed and heterogenous nature. Distributed systems provide availability, part of the security CIA triad, and for many systems availability trumps security. The centralized controllers would become attractive targets for compromise. This is despite the intention of SDN, as envisioned by Nicira founder M. Casado, to have security as its cornerstone as described here. Casado’s problem statement is interesting: “We don’t have a ubiquitous and horizontal security layer that provides both context and isolation. Where do we normally put security controls? We put it in one of two places. We might put it in the physical infrastructure, which is great because you have isolation. If I have ACLs [access control lists] or a firewall or an IDS [intrusion detection system], I put it in a separate box and I put it away from the applications so that the attack surface is pretty small and it’s totally isolated… you have isolation, but you have no context. ..  Another place we put security is in the end host, an application or operating system. This suffers from the opposite problem. You have all the context that you need — applications, users, the data being accessed — but you have absolutely no isolation.” The centralization imperative comes from the need to isolate and minimize the trusted computing base.

In the short term, there may be some advantage to be gained by complexity reduction through centralized administration, but the recommendation of dumb switches that respond to a tightly controlled central brain, go against the tenets of compartmentalization of risk and if such networks are put into practice widely they can result in failures that are catastrophic instead of isolated.

What the goal should be is a distributed system which is also responsive.

Cgroups limit how much you can do. Namespaces limit how much you can see.

Linux containers are based on cgroups and namespaces and can be privileged or unprivileged. A privileged container is one without the “User Namespace” implying it has direct visibility into all users of the underlying host. The User Namespace allows remapping the user identities in the container so even if the process thinks it is running as root, it is not.

Using cgroups to limit fork bombs from Jessie’s talk:

$ sudo su
# echo 2 > /sys/fs/cgroup/pids/parent/pids.max
# echo $$ > /sys/fs/cgroup/pids/parent/cgroups.procs  // put current pid
# cat /sys/fs/cgroup/pids/parent/pids.current
2
# (echo "foobar" | cat )
bash: for retry: No child processes

Link to the 122 page paper on linux containers security here.  Includes this quote on linux kernel attacks.

“Kernel vulnerabilities can take various forms, from information leaks and Denial of Service (DoS) risks to privilege escalation and arbitrary code execution. Of the roughly 400 Linux system calls, a number have contained privilege escalation vulnerabilities, as recently as of 2016 with keyctl(2). Over the years this included, but is not limited to: futex(2), vmsplice(2), mremap(2), unmap(2), do_brk(2), splice(2), and modify_ldt(2). In addition to system calls, old or obscure networking code including but not limited
to SCTP, IPX, ATM, AppleTalk, X.25, DECNet, CANBUS, Econet and NETLINK has contributed to a great number of privilege escalation vulnerabilities through various use cases or socket options. Finally, the “perf” subsystem, used for performance monitoring, has historically contained a number of issues, such as perf_swevent_init (CVE-2013-2094).”

Which makes the case for seccomp, as containers both privileged and unprivileged can lead to bad things –

““Containers will always (by design) share the same kernel as the host. Therefore, any vulnerabilities in the kernel interface, unless the container is forbidden the use of that interface (i.e. using seccomp)”- LXC Security Documentation by Serge Hallyn, Canonical”

The paper has several links on restricting access, including grsecurity, SELinux, App Armor and firejail. A brief comparison of the first three is here. SELinux has a powerful access control mechanism – it attaches labels to all files, processes and objects; however it is complex and often people end up making things too permissive, instead of taking advantage of available controls.  AppArmor works by labeling  files by pathname and applying policies to the pathname – it is recommended with SUSE/OpenSUSE, not CentOS.  Grsecurity policies are described here, its ACLs support process–based resource restrictions, including memory/cpu/files open, etc.

A recent talk discussed ethics for autonomous vehicles, as an optimization problem. There can be several imperatives for an AV which are all “correct”, yet be in conflict for an autonomous vehicle which relies on hard coded logic.

For example: Follow Traffic safety rules. Stick to the lane. Avoid obstacles. Save most human lives. Save passengers.

How can a vehicle prioritize these ? Instead of a case by case design, the proposal is to cast it in an ethics framework based on optimization of various ideals and constraints with weighted coefficients. Then test the outcomes.

The optimization equation looks to minimize ( path_tracking + steering + traffic_laws ) subject to constraints ( avoid_obstacles ). The equations produce different behaviour when the coefficients are changed.

Another consideration is the Vehicle intent: is it fully in control or can the human override it. This affects the software assumptions and system design.

The talk was presented by Sarah Thornton, PhD. Stanford. A related discussion on safety is  here : Who gets the blame when driverless cars crash ?.

Somewhat related is the idea of computer vision itself operating correctly. There can be adversarial inputs as discussed in the paper Intriguing properties of neural networks which discusses blind spots. Generative Adversarial Models are a way to improve the generalization capabilities of a network by pitting generative against discriminative models. The European Conference on Computer Vision starts today: http://www.eccv2016.org/main-conference/

 

ISO 26262 is a standard for Automotive Electric/Electronic Systems safety, that is adopted by car manufacturers. Its V shape consists of two legs, the first comprising definition, analysis, design, architectural design, development and implementation. The second leg consists of verification and validation of the software, starting from unit tests to functional tests, safety tests and system-wide tests. Model based design is used to reduce the complexity. These models are now fairly complex. Model based design is the one of the value adds that Mentor Graphics automotive kit provides is help with achieving compliance with this standard.

ISO 26262 is derived from its parent, the IEC 61508 standard, which is titled Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems. This parent standard has variants for safety of automotive, railway, nuclear, manufacturing processes (refineries, petrochemical, chemical, pharmaceutical, pulp and paper, and power) and machinery related electrical control systems. An associated, upcoming standard is the SAE J2980.

An excellent talk today by MIT fellow Ricardo Dematos discussed more comprehensive approaches to automotive safety. This is building up from his work with safety research at MIT, AWS IoT and our SyncBrake entry for V2V safety at TechCrunch Disrupt 2015.

Oracle MICROS Point of Sale systems are again reported to be attacked. The support site of MICROS was infected by malware which was able to access usernames and passwords and send them to a remote server. This remote server was identified as one previously known to be used by ‘Carbanak’, a cybercrime group.

ZDNet reports that in the last year, dozens of machines at Starwood and Hilton hotels were impacted by malware, with the aim of poaching payment and card data, which can be used or sold on to the highest bidder. The attack on MICROS systems may be behind these.

An advisory by VISA here, discusses two previous malware threats attacking POS systems, Carbanak and MalumPOS.

This report by Symantec describes POS attacks as multi-stage attacks, with threats and mitigation strategies.

In August 2014, Department of Homeland Security had issued an advisory for ‘Backoff’ a POS malware, which affected a large number of systems in retailers including Target, PF Chang’s, Neiman Marcus, Michaels, Sally Beauty Supply and Goodwill Industries International.  PF Chang had a cyber insurance policy which covered direct damages, but not claims filed by Mastercard/Bank of America for credit card fraud reimbursements and reissuance via a “PCI DSS assessment”.

These trends are interesting for a few reasons. First, the recurrent attack are reason to accelerate the move to EMVs. Second, it gives rise to new architectures for payments. Third it draws attention to Blockchain technologies.

Verifone has a Secure Commerce Architecture which sends the payment data directly from the terminal system which receives the card, to the merchant (acquirer) bank, without touching the POS system (the windows computer handling invoicing). This reduces payment fraud and also makes certification for EMVs much easier.

EMV stands for Europay, Mastercard, Visa. After the EMV deadline of Oct 1, 2015, the liability for credit card fraud shifted to whichever party is the least EMV-compliant in a fraudulent transaction. Automated fuel dispensers have until 2017 to make the shift to EMV. ATMs face two fraud liability shift dates: MasterCard’s in October 2016 and Visa’s in October 2017.

Because of EMV securing the terminals, there is predicted to be a rise in online payments fraud.  While counterfeit opportunity dwindles, the next top three types of credit card fraud, Account takeover, Card-not-present fraud, and (fake new) Application fraud are rising. The recent MICROS attack fits the pattern of attackers probing for and finding the weakest links in the payments chain.

A blackhat talk –https://www.blackhat.com/docs/us-14/materials/us-14-Zaichkowsky-Point-Of-Sale%20System-Architecture-And-Security.pdf

A bad update on Lexus cars crashed its car entertainment system, affecting cars from California to Massachusetts. Details were reported  by SecurityLedger this week.

Users need to bring in their car to a Toyota/Lexus dealer to solve the problem via a forced reset and clear the bad data from the system. The bad behavior is due to incorrect handling of error data returned from third party web services.

“As more automakers embrace over-the-air software updates as a way to push out necessary fixes to vehicle owners, the prospect of unreliable and malicious updates causing real world disruptions has grown. In a March report to Congress (PDF), the U.S. Government Accountability Office (GAO) noted that modern vehicles feature many communications interfaces that are vulnerable to attack, but that measures to address those threats are likely years away, as automakers work to design more secure in-vehicle systems.” – SecurityLedger quote.

Updates and secure updates have not been a well-solved problem in the software world. A backup is usually recommended, but not always possible. Bringing the same solutions to cars and IoT seems like a bad idea.  The need for secure OTA auto updates to work has been noted, for e.g. at the “Five Star Automotive Cyber Safety Program” here and here. Yet it has not been a prominent part of the automotive manufacturers’ lexicon.

As we move towards autonomous cars and a corresponding increase in complexity, these problems would need to be solved in more elegant way.

ICSA recently announced an Internet of Things testing and certification program. It has six components (highlights in brackets) –

1. cryptography (FIPS 140-2 crypto algos by default, secure PRNGs)
2. communications (PKI auth, all traffic must be authorized)
3. authentication (secure auth, protect auth data, no privilege escalation)
4. physical security (tamper detection, defense, disable)
5. platform security (secure boot, secure remote upgrade, DoS defense)
6. alert/logging (log upgrades, attacks, tampering, admin access)

Their IoT security requirements framework is found here.

This is a great list. I think another dimension to think about is usability of the security – many products come with security options buried so deep in documentation or UI, that a regular user may not configure the device securely and leave it more open than intended – this has historically been true of a variety of webcams, SCADA systems, wifi routers and other devices.