Upload
ruo-ando
View
111
Download
0
Embed Size (px)
Citation preview
A rapid filtering rule management plane implementation using distributed in-memory caching system
Network Security Research Institute, National Institute of Information and Communications TechnologyRuo Ando
情報通信研究機構ネットワークセキュリティ研究所安藤類央
IT・ISEC・WBS合同研究会 3/2 – 3/3(23) 16:40-17:05
http://starbed.nict.go.jp/
概要:仮想ネットワーク上での分散インメモリキャッシュを用いたフィルタリングルール処理の高速化
ネットワーク仮想化(抽象化)とその周辺技術(Software Defined Network, クラ
ウドコンピューティング)の発達により、アクセス制御技術、特にパケットフィルタリングルール処理に修正が求められている。
また、SDNの基本設計方針の結果として、データプレーンは分散、大規模化し、コントロールプレーンに処理が集中し、SPOF(単一障害点)やスケーラビリティの点で問題が生じている。
提案システムには大規模なフィルタリングルールの処理のためにMemcached(分散インメモリキャッシュシステム)を用いた。また、C (Consistency)、A(Availability)、P(Partition Torelance)のうち、Cの制約を緩めることでスケールアウトまたは冗長化が容易なシステムの構築を行った。
評価実験では、radix treeを用いたIPフィルタリングを実装し、10, 1000, 10000, 100000までのルールセットの処理を行い、通常のデータストアを用いたシステムではルール1000以上で処理が許容不可能になるのに対し、提案システムはルール数が100000を越えても許容可能な負荷率で稼動する(CPU負荷率で10%以内)ことを示した。
Network Virtualization: Separation of data, control and management plane
HW
DataPlane
HW
Control Planerule DB
upcaller
HW
DataPlane
HW
DataPlane
Control Plane
HW
Data Plane
Control Plane
HW
Data Plane
Control Plane
HW
Data Plane
Firewall
Load Balancer Application FirewallFirewall
Load Balancer
Application Firewall
Management Plane
本論文での改良対象
スケーラビリティを確保することが現状では困難
Avenues of Attack
Sensitive data
Enterprise Network
MissingSecurity Patches
MisconfiguredDatabase
Advanced Attacks
Sensitive Data Leaks
EscalatingUser Privileges
DefaultPasswords
Weak Passwords
Unauthorized Database
WeakPRNG
CDP:Functional & Operational Firewall Pattern - AWS-CloudDesignPatternNemesis: preventing authentication & access control vulnerabilities in web applications, SSYM'09 Proceedings of the 18th conference on USENIX security symposiumDetecting BGP configuration faults with static analysis, NSDI'05 Proceedings of the 2nd conference on Symposium on Networked Systems Design & ImplementationA security enforcement kernel for OpenFlow networks, HotSDN '12 Proceedings of the first workshop on Hot topics in software defined networks
MisconfiguredFiltering
Management planeの対象領域
Network virtualization: abstraction and centralization
NIC
HD
CPU
RAM
FW
LB
VLANS
VRF
2001 2012
image
vCPU
vRAM
vNIC FlowTable
vFW
vLB
abstraction layer
XenKVM
VMWare
OpenFlowOpen vSwitch
FloodLight
Decouple
Virtualization layer
reproduce
Automate
Network virtualization: slicing after virtualization and abstraction
x86 / ARM
Virtualization Layer
Windows Linux
Open Flow
Virtualization Or Slicing
NOX NOX
CPU, Hardisk, PIC, IO
X86 instruction set
Xen, QEMU, etc
Windows Linux
Hardware Resources
Abstraction layer
Virtualization Layer
slice slice
Bandwidth, CPU, FIB
OpenFlow
FlowVisor
Controller Contoller
Definition of a slice• Slice is a set of flows (called flowspace) running on a topology of switches.https://www.clear.rice.edu/comp529/.../tutorial_4.pdf
Network virtualization: Deployment example
• Virtualized Networking environment = SDN + Cloud computing.
• Instance is virtualized
• Network is also virtualized
hypervisor
VM VM
hypervisor
VM VM
SDN controller Network operating system
Routing Traffic Engineering
Load Balancing
Open Flow Switch Open Flow SwitchData Plane
Control Plane
各ノードは仮想化され、マルチテナントとして同一物理NIC上に配置される。
ネットワークも仮想化され、フィルタリングとマッチング処理が分離一元化される。
Open vSwitch. B. Pfaff, J. Pettit, K. Amidon, M. Casado, T. Koponen, an
d S. Shenker. Extending Networking into the Virtualization Layer. In HotNets, 2009
Operational / Functional FW
Amazon EC2 Design Pattern
Drawbacks of SDN: Distributed Dataplane vs Centralized Controller
HW
DataPlane
HW
Control Plane
Switch DB
upcaller
HW
DataPlane
HW
DataPlaneデータセンターなどのコアネットワークでは
データプレーンはスケールアウトし、性能は変わらない。
②通常のvSwitchの設計では
パケットデータはユーザ空間に転送されるが、その際のボトルネックが生じる。
①SDNの一元管理の性
質から、コントローラに処理が集中する。
本論文では、①と②の問題点に対して、ユーザモードで稼動するMemcachedを用いてスケーラブルなシステムを構築する。
設計上の問題:仮想化環境とスケーラビリティ
Centralized access control model
2000 2005 2010 2014
Virtualization Technology (hypervisor)
Cloud computing
Domain Specific / Declarative Language
Open Flow
DSL for IDS and access control
New Security Concerns
DSL for SDN
Rules and conflict management
sHype
Pyretic
Xen
Chimera
ForNox
RuleBricksRemote Attestation
Attack on multi-tenant
アクセス制御の一元化
ネットワーク抽象化
アクセス制御の表現方法の問題
Open vSwitch
vMAC
sandbox xenprobe
subvirt
仮想化、ハイパーバイザー内でのAC一元化
スケーラブル、合成可能な観測システムの構築BGP attack
ネットワークのスライシング仮想化技術を用いた動的解析
ConfAid
BotMiner解析の大規模化
大規模システムでの設定・Access Ctrlの検査
Flowvisor
HyperDex Ensenble
CAP定理:分散システムでの3つの設計条件
"Logically centralized?: state distribution trade-offs in software defined networks", Dan Levin, Andreas Wundsam, Brandon Heller, Nikhil Handigol and Anja Feldmann, HotSDN '12 Proceedings of the first workshop on Hot topics in software defined networks
Controller component choices:
[1] Strongly consistent – controller components always operate on the same world view. Imposes delay and overhead.
[2] Eventually consistent – controller components incorporate information as it becomes available but may make decisions on different world views.
http://www.richardclegg.org/node/21
C A
P
NoSQLRDBMS
Consistency Availability
Tolerance to networkpartition
CAP Theorem (Eric Brewer 2000)
Enforced Consistency Eventual Consistency パケットフィルタなどの処理ではStrongly Consistentであることが
求められる(望ましい)
NoSQLを用いることでA (availability)P (Tolerance to network partition) S (Scalability)が達成される。
Memcached – In memory distributed caching system
Memcached
Client
memcachedは、汎用の分散型メモリキャッシュシステムである。
DataBase WebServer
Client Client
HW
DataPlane Forwarder
本システムでは、ユーザモードで稼動するforwarderがMemcachedに問い合わせる。
cache miss
memcachedの API は、複数のマシン上に分
散された巨大なハッシュテーブルを提供する。テーブルがいっぱいの場合、以降のデータの新規挿入により古いデータはLeast Recently Used順序で削除される。memcachedを用い
るアプリケーションは、背後にあるデータベースなどの低速な記憶装置へのアクセスの前にmemcachedのリクエストを挿入する。
オンメモリで稼動し、クライアントがConsistent Hashingをもちいることで、分散・冗長化が可能。
Rapid filtering rule management plane with memcached tier
Memcached 1
Memcached 2
Memcached 3
ruleDB
ruleDB
ruleDB
control plane
Hardware
data plane
Hardware
data plane
Hardware
data plane
Hardware
upcaller
Select memcached1..n with consistent
hashing
Cache miss
同手法はFlow Tableがほとんど変化しないCore networkで有効であると想定される。
Memcached tier achieves A (availability) and P (partition tolerance)
"Logically centralized?: state distribution trade-offs in software defined networks", Dan Levin, Andreas Wundsam, Brandon Heller, Nikhil Handigol and Anja Feldmann, HotSDN '12 Proceedings of the first workshop on Hot topics in software defined networks
Controller component choices:
[1] Strongly consistent – controller components always operate on the same world view. Imposes delay and overhead.
[2] Eventually consistent – controller components incorporate information as it becomes available but may make decisions on different world views.
http://www.richardclegg.org/node/21
C A
P
NoSQLRDBMS
Consistency Availability
Tolerance to networkpartition
CAP Theorem (Eric Brewer 2000)
Enforced Consistency Eventual Consistency パケットフィルタなどの処理ではStrongly Consistentであることが
求められる(望ましい)
NoSQLを用いることでA (availability)P (Tolerance to network partition) S (Scalability)が達成される。
Basic SDN architecture and proposed system
Node (VM)
Node (VM)
Node (VM)
Flow Table
ControllerSecure Channel
Node (VM)
Node (VM)
Node (VM)
Filtering rule
TableData store
match
match
判定処理(match)はノード側で行い、パケットは転送しない。→ これにより、フィルタリングの一元管理を達成しつつ、Control/Management Planeの負荷を下げる。
Ingress packets
Ingress packets
Data plane Control plane
Control and Data plane Management plane
VCRIB: Virtualized rule management in the cloud Masoud Moshref, Minlan Yu, Abhishek Sharma, Ramesh Govindan the
4th USENIX Workshop on Hot Topics in Cloud Computing (HotCloud). Boston, MA, June 2012.
Basic SDN
提案手法
Management Plane Isolation:提案システムの機能配置
DataStoreの適用
Scalabilityを確保する
一元管理:設定管理ミスをなくす
Data planeとControl planeは同一ホスト(インスタンス)内で分離しない。
フィルタリング・設定情報の管理用にManagement planeを設置して管理。
全てのcomponentをuser modeで実装することでdeploymentのコストを下げ、迅速にする。
Adopting basic datastore on management plane
auto_ptr<mongo::DBClientCursor> cursor =
client.query(ns, mongo::BSONObj());
while(cursor->more()) {
mongo::BSONObj p = cursor->next();
mongo::OID oid = p["_id"].OID();
string dest = p["dest"].str();
int mask = p["mask"].numberInt();
string gateway = p["gateway"].str();
const char *p0 = dest.c_str();
const char *p1 = gateway.c_str();
add_rtentry(p0, mask, p1);
int res;
res = find_route(dstAddress);
if(res==0)
printf("route find \n");
/* flush entry /*
rm_rtentry(p0, mask);
{"_id": "$oid":"53370eaeb1f58908a9837910"
"dest":"10.0.0.0","mask": 8,"gateway":"192.168.0.2"}
Radix treeのエントリを動的に読み出すことでリモート(management plane)から任意のタイミングでフィルタリングルールを変更できるようにする。
Filtering ruleはBSON (JSON)で記述
a radix tree (also patricia trie or radix trie or compact prefix tree) is a space-optimized triedata structure where each node with only one child is merged with its parent.
14 entry.addr = ntohl(addr dst.s addr);15 entry.prefix len = 32;17 radix tree<rtentry, in addr>::iterator it;1819 it = rttable.longest match(entry);20 if (it == rttable.end()) f21 std::cout << ‘‘no route to ‘‘ << dst << std::endl;22 return 1;
if ((memc = memcached_create(NULL)) == NULL) {
fprintf(stderr, "failed to allocate memory\n");
// return 1;
}
rv = memcached_server_add(memc, "localhost", 11211);
if (rv != MEMCACHED_SUCCESS) {
fprintf(stderr, "failed to set server\n");
return 1;
}
char *result;
uint32_t flags;
size_t result_length;
/* retrieving gateway address */
sprintf(key1,"gate-%s", dstAddress);
printf("key1: %s \n", key1);
result = memcached_get(memc, key1, strlen(key1),
&result_length, &flags, &rv);
if (rv != MEMCACHED_SUCCESS) {
fprintf(stderr, "failed to fetch record\n");
return 1;
}
/* retrieving netmask */
snprintf(key2,32,"mask-%s", dstAddress);
printf("key2: %s \n", key2);
result = memcached_get(memc, key2, strlen(key2),
&result_length, &flags, &rv);
if (rv != MEMCACHED_SUCCESS) {
fprintf(stderr, "failed to fetch record\n");
return 1;
}
Adopting Memcached on management plane
import bmemcachedimport random
client = bmemcached.Client(('127.0.0.1:11211', ),'user','password')
client.set('gate-10.0.0.8', '10.0.0.1')client.set('mask-10.0.0.8', '8')
{"_id": "$Basic datastore query representationoid":"53370eaeb1f58908a9837910"
"dest":"10.0.0.0","mask": 8,"gateway":"192.168.0.2"}
Experimental result on Amazon VPCWe compiled our system on ubuntu12 LTS with Linux kernel 3.2.0. proposed system is hosted on Intel Xeon E5645 with 2.4 GHZ clock.
ルール数が10~100以内であれば、CPU負
荷率(3%以内)、コンテキストスイッチ(5000回以内)とも許容範囲内で稼動。
設定した環境内では、1000~10000のルールを用いるケースは稀なため、提案手法は妥当。
vNIC1 vNIC2
Bridge
IP capture
1
2
3
MongoDB
5
8
7
8
Radix Module
6
0
Management plane Control plane
Python module
パケットキャプチャはユーザモードでのpcapを利用。ルールはPythonを用いて設定
Experimental result on Amazon VPC (Memcached)
vNIC1 vNIC2
Bridge
IP capture
1
2
3
Memcached
5
8
7
8
Radix Module
6
0
Control plane
Python module
パケットキャプチャはユーザモードでのpcapを利用。ルールはPythonを用いて設定
We compiled our system on ubuntu12 LTS with Linux kernel 3.2.0. proposed system is hosted on Intel Xeon E5645 with 2.4 GHZ clock.
通常のNoSQLシステムを用いると、ルール数
が1000を越えると負荷率が錯乱(10%を超えて不安定になる)するが、Memcachedを用いるとルール数が100000を越えても許容可能な範囲で安定している。
まとめ:仮想ネットワーク上での分散インメモリキャッシュを用いたフィルタリングルール処理の高速化
ネットワーク仮想化(抽象化)とその周辺技術(Software Defined Network, クラ
ウドコンピューティング)の発達により、アクセス制御技術、特にパケットフィルタリングルール処理に修正が求められている。
また、SDNの基本設計方針の結果として、データプレーンは分散、大規模化し、コントロールプレーンに処理が集中し、SPOF(単一障害点)やスケーラビリティの点で問題が生じている。
提案システムには大規模なフィルタリングルールの処理のためにMemcached(分散インメモリキャッシュシステム)を用いた。また、C (Consistency)、A(Availability)、P(Partition Torelance)のうち、Cの制約を緩めることでスケールアウトまたは冗長化が容易なシステムの構築を行った。
評価実験では、radix treeを用いたIPフィルタリングを実装し、10, 1000, 10000, 100000までのルールセットの処理を行い、通常のデータストアを用いたシステムではルール1000以上で処理が許容不可能になるのに対し、提案システムはルール数が100000を越えても許容可能な負荷率で稼動する(CPU負荷率で10%以内)ことを示した。