Although most RPC traffic is blocked on the Internet today, the real arising problem is
that RPC exploits are becoming increasingly common on ???trusted??? networks, such as
internal corporate LANs. Simply clicking on the wrong website and downloading
scumware, malware, and viruses from the Internet can turn a client on the network into
an attacking host, exposing critical server components to exploit and damage.
Understanding the Need for RPC Filtering Versus RPC Blocking
The reaction to RPC issues in the past has been to block the RPC traffic by disallowing Port
135 between network segments on routers and/or firewalls. This can cause severe problems
with internal network traffic because a large quantity of critical network services rely on
RPC calls and protocol access. For example, shortly after the Slammer virus was released
and wrecked havoc on IT infrastructure, it took months to sort out what routers were
blocking necessary functionality such as Active Directory domain controller replication.
The initial reaction was to drop all RPC traffic, regardless of whether it was needed or not.
What is needed is a way to secure the RPC protocol itself, by delving further into its functionality
than simple Layer 3 packet analysis can.
Pages:
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665