NFR (Network Flight Recorder available at http://www.nfr.net) is an IDS (Intrusion Detection System) that gives the users a powerful tool for the war against illegal access to your network. With the flexibility of this tool, network managers can feel a little better about who is accessing their network and where their employees are going.
How Does NFR Work? Features of NFR
The NFR Intrusion Detection Appliance (IDA) is a flexible, extensible, general-purpose tool that addresses both security and network management. NFR uses N-Code that was released to allow the users the flexibility to configure the IDA for their configuration. NFR is a programmable traffic analysis/intrusion detection engine that can be instantly updated when a new attack is discovered. Most IDS like ISS RealSecure or Axent’s Intruder Alert/NetProwler require that the vendor send out either an executable from ISS or a signature from Axent. With NFR a user can write their own request order and install it. NFR gives the users a chance to customize the IDA to their needs.
The architecture of NFR was designed as a set of components, each tailored to a specific activity. Data is gathered by one or more packet suckers, forwarded to the decision engine for filtering and reassembly, and possibly recorded to a backend for storage or statistical processing. The query interface is kept completely separate from the input data flow to minimize the performance impact
Of a users querying the system while it is collecting data. The N programming language is a derivation of an interpreted language designed years ago for use in a computer game. The interpreter operates on a byte-code instruction set that implements a simple stack machine. One advantage of this approach is that NFR filters occupy very little memory, yet are quite fast to evaluate. N is a complete programming language including flow control, procedures, variables with scoping rules, and list data types. Unlike many programming languages, however, N has primary data types such as "IP address." Since NFR's may be used on large networks, we chose to implement counter data types as 64-bit integers, to reduce the chance of overflow
Configurations:
NFR can be configured in both distributed and stand-alone configurations. In the stand-alone configuration, a single NFR station gathers and stores information. The distributed configuration places multiple remote stations on the network, and each rolls their data to a central station. Manage, query, and view alerts through the central station and as you network grows, you add a new remote for that segment. You can manage your IDA from any Windows machine on your network. Change system settings, run queries, or view and receive alerts from the location the convenient for you.
How Can You Monitor Your System?
NFR has alerts that can be configured to popup on the NFR Console. The alerts popup and make a beep on the console which require immediate attention. The alerts are sent to the NFR console and the NFR IDA Recorder. If you are not running the console, you can use the alert viewer to view the alerts at a later time.
Triggers within N-code occur upon receipt or detection of an event that the code is attached to. Events can be triggered with limitations on source, destination, ports, client or server side (if known), or patterns within the TCP stream. The syntax looks like:
filter mailtrack tcp (client, dport: 25 ) {
The filter above is a simple TCP stream trigger that will monitor the client side of SMTP connections. The "client" and "server" notion is based on the reassembly engines recollection of which system initiated the connection that is being observed.
Keywords that can be placed within an event are:
client - from the caller
server - from the called
start: "string" - begin matching
stop: "string" - end matching
opensession - on start of connection
closesession - on end of connection
port - IP port number (source or dest)
sport - source port
dport - destination port
host - source or destination address
net - source or destination network
dst - destination address
src - source address
A typical use is to configure an event to call N code for as small a subset of received data as is practical, then implement any further filtering in N code. To detect spam, for example, you might select TCP traffic for port 25/SMTP.
Components:
NFR uses an IDA engine to sniff packets from one or more interfaces on the NFR IDA. Unlike a firewall, NFR IDA engine does not actually touch the packet. It only observes them to be recorded. Events tell the NFR IDA engine to take some sort of action. Events can be a command and control message, passage of time, and an arrival of a packet. Backends is one of the components of the IDA. Within Backends, you will have Filters, which list the event that caused the NFR IDA engine to begin gathering data. Configuration Files provide information about the title of the backend and other information displayed via the NFR console. Recorders write the information gathered by the backends to files. List Recorders collects, records, and maintain a log of activity. Histogram Recorders collects statistical information in many dimensions, rather than the one dimension typically used when gathering statistics. Packages group related types of Backends together. Shared N-Code filters that perform some of the processing for the backends in the package. Configuration files provide information about the title of the package and other information displayed via the NFR console.
"Centralized firewall" problems
DISCLAIMER: This document contains untested ideas, please verify or debunk
me. Perhaps this is already old information? In any case, I would
like some (constructive) feedback.
Introduction
------------
Many Internet Service Providers (ISPs) provide so-called "centralized
firewall" services to leased line customers. This document is an attempt to
highlight problems which may be associated with such a service. Bear in
mind that the ideas have not been tested (yet).
So, what is a centralized firewall service? And what is the idea behind such
a service? Well, let's talk about the idea first. The "easy" way to add
security to a network is to place a firewall between the network to be
protected and the open one (the Internet). The problem with this solution
is that someone has to spend time watching logs, maintaining rules, apply any
patches, and keep the firewall software up-to-date. This costs a lot of time,
and in most cases, a lot of money (security professionals are usually not
cheap these days).
ISPs know this. They also know that it is unlikely that small and medium-
sized businesses (SMBs) have the time, money or expertise to invest in such
a position. The solution they sell to SMBs is the centralized firewall.
The centralized firewall leaves all the log-watching and maintenance to the
ISP, and the ISP provides some sort of report if there is an attack, and
usually some sort of weekly or monthly summary (SMB executives like to know
how "visible" they are on the 'net).
Service types
-------------
I know of three types of ISP "firewall" services. One of them is not
centralized, so will not be covered here (remote maintenance, where there's a
physical firewall at the customer's site, owned and maintained by the ISP).
The two other types are based on a "real" firewall (such as Firewall-1) or
by using access-control lists (ACLs). The two figures below outline the
(usual) configuration for both solutions. Figure 1 describes the solution
using a true firewall, and figure 2 a solution using access-lists. The two
solutions usually reflect the price of the service. Leased-line customers
usually have the benefit of a "true" firewall, while dial-up customers are
given the ACL option.
{Internet} (5) {Internet} (3)
| |
+-------------+ +---------------+
| Core router | (4) | Access Router | (2)
+-------------+ | w/ ACL |
| +---------------+
+-------+ | | | ISDN lines
| Fire- | (3) | | |
| wall | +------+ | +------+
+-------+ | Cust | | | Cust | ...
| +------+ | +------+
+--------+ |
| Access | (2) +------+
| Router | | Cust | (1)
+--------+ +------+
/ | \ Leased Lines
/ | \
+------+ +------+ +------+
| Cust | | Cust | | Cust | ... (1)
| Rtr | | Rtr | | Rtr |
+------+ +------+ +------+
Figure 1 Figure 2
As you can see, there is a great deal more hardware involved when involving
a firewall than just relying on ACL's on the access router (hence the
difference in price). Both setups, however, have the same basic functions. In
figure 1, the traffic is only allowed to travel in the following manner:
(1) -> (2) -> (3) -> (4)
Policy routing ensures that traffic going from the customer _has_ to pass
through the firewall, thus prohibiting inter-customer traffic at level 2.
In figure 2, one uses "reflexive access-lists" (RACL, introduced in Cisco IOS
11.3) to make sure that traffic cannot pass from one customer to another
without passing through the ACL. TACACS+ or RADIUS determines which customer
should have this ACL installed (the ACL is defined in the router
configuration, not in the TACACS+ or RADIUS configuration file). Depending on
the ISP's setup, either a separate RACL will be installed for each customer,
or every customer uses the same RACL. This document assumes the latter.
It may be possible to use standard (extended) ACLs, but the idea behind RACL
is that timeouts are introduced in a kind of "state table". A standard ACL
doesn't have this; it validates packets using static rules.
For more on RACLs, check out http://www.cisco.com/univercd/cc/td/doc/product/
software/ios113ed/113ed_cr/secur_c/scprt3/screflex.htm (no spaces in this
URL).
Where is the problem?
---------------------
Both the firewall and the router containing the RACL uses some form of "state
table". This table defines what packets have left the inside, and usually
contains the following information (at least):
Source IP
Source port
Destination IP
Destination port
The router or firewall determines what packets are allowed through from the
outside depending on this table. TCP packets destined for the inside cannot
have the SYN flag set (unless specified in the filter rule), and are discarded.
UDP packets are not allowed through unless:
a) specified in the RACL
b) a UDP packet has been initiated from the inside first AND
c) the UDP reply has been received within a predefined time limit
Timers are used to invalidate UDP "sessions", since there is no way of knowing
when a UDP session ends (without looking at the overlying protocol).
This sounds innocuous enough if you are the only user of the firewall (this
is what happens when you have your own). However, in the above context, several
networks share the same firewall, and indeed, the same state table. If we
assume that all the customers are Nice(tm), then there shouldn't be a problem.
We should be paranoid, though, and consider the following scenario. What if
Customer-2 really dislikes Customer-1? In fact, how about Customer-2 (mean.com)
dislikes Customer-1 (nice.com) so much that Customer-2 gets in touch with
Mr. Evil (evil.org) on the Internet? See figure 3 for a quick situation
overview.
+----------+
{Internet}----| Mr. Evil | evil.org
| +----------+
|
+----------+
| RACL/ |
| Firewall |
+----------+
/ | \
/ | \
+--------+ +--------+ +--------+
| Cust-1 | | Cust-2 | | Cust-3 | ...
+--------+ +--------+ +--------+
nice.com mean.com
Figure 3
Staging the attack
------------------
Since they all share the same state table, Cust-2 could inject fake UDP packets
containing Cust-1's source IP and Mr. Evil's destination IP. Let's place
ourselves in Mr. Mean's shoes and make a coordinated attack on nice.com.
First, we call up Mr. Evil, or indeed, we just log into an account at evil.org,
that way we don't have to pay anyone to do our dirty deed.
Then there are a few ways we can do the next stage. If we know that nice.com
is comprised of UNIX machines, we could try exploiting the possibility of
poorly configured tftpd(8) servers. Gaining unauthorized files using tftp(1)
is a very old attack, as we well know. However, tftpd(8) servers are
surprisingly often present on networks that rely on firewalls to protect them.
I am quite sure there are some other remote exploits we could use; rpc.statd
or rpc.mountd perhaps. tftp(1) is used as an example as it is an easy thing
to describe. Anyway. Back to our dirty deed.
We send the following spoofed packets from mean.com:
src_ip:src_port dst_ip:dst_port
1.nice.com:69 evil.org:31337
2.nice.com:69 evil.org:31337
3.nice.com:69 evil.org:31337
..
..
254.nice.com:69 evil.org:31337
From evil.org we fire up nmap[1] as root, and tell it to scan for machines
1-254.nice.com using source port 31337 and destination port 69. We (hopefully)
get a few results back. It is probably a good idea to start the nmap scan
fairly soon after we inject the spoofed packets through the firewall/RACL as
the state table won't keep the UDP traffic valid for very long.
When we have a list of usable tftpd(8) servers, we fire up our patched version
of tftp(1) which will let us issue requests with predefined source ports (in
this case 31337).
That's about it. The firewall will (if all goes to plan[2]) let the traffic
through, and if there are any ill-configured tftpd(8) servers there, we might
be able to grab /etc/passwd (or perhaps their gateway-conf[3] files).
Another attack
--------------
We could also stage an attack against a Windows network, but the attack
outlined below doesn't implicitly need mean.com. An attacker from evil.org
could do the same attack without having help from the "inside", i.e. there
would no need for a port forwarder on evil.org; one could just fire up the
BO2K administration software there. (I ran out of ideas here, ok? Perhaps one
could stage a NetBIOS attack or something.)
Set up a port forwarder on evil.org, which points UDP port 1138 to
salesguy.nice.com port 53. Netcat (hobbit@avian.org) can be used for this.
1) Send an email to some of his employees (phone up nice.com's
switchboard for the email of a sales person).
2) Send "Dancing Pigs" + BO2K attachment to sales guy. Configure BO2K
to use UDP on port 53 (perhaps using this port will not seem
too suspicious in any firewall logs, as it could be confused with
a regular DNS request).
3) Wait for BO2K to install itself (SpeakEasy or ButtTrumpet will
tell us when this has been happened).
Send the following fake UDP packet from mean.com:
src_ip:src_port dst_ip:dst_port
salesguy.nice.com:53 evil.org:1138
Start our BO2K administration software, and connect to evil.org:1138. We
should[2] now have control over salesguy.nice.com.
Conclusion
----------
Historically, it has been well documented in security papers that UDP is a
very difficult protocol to handle securely. Despite this well known fact, more
and more applications have been built on this weak foundation. The reasons
vary, but the truth is that UDP is a very simple (and fast) protocol to base
higher level protocols on.
Customers should not rely solely on the protection offered by the ISP when
purchasing this type of service. This paper has discussed two attacks against
a poorly implemented "centralized firewall", with a few hints towards other
attacks. It should be clear that this is a very real threat. Failure to
recognize this fact could lead to a very embarrassing compromise.
It is imperative that there's some form of spoofing protection in place on
the company's border perimeter. In figure 1, this can easily be achieved by
using regular ACLs on the Access Router (2). Without having delved too deep
into the matter, it is possible that CEF[4] could be used too. CEF, however,
does not work on all Cisco IOS routers; consult your manual.
If RACLs (figure 2) are used, the ISP can prevent spoofing by using separate
RACLs for each customer. This, however, can become a huge configuration issue,
depending on how many dial-up customers the ISP has.
Addendum
--------
It should also be noted that some ISPs also provide a hosting service with
"firewall protection". Figure 4 shows a general overview.
{Internet}
|
+--------+
| Router |
+--------+
|
+----------+
| Firewall |
+----------+
|
+------+ +--------+ +------+
| Cust |---| Switch |---| Cust |
+------+ +--------+ +------+
|
+------+
| Cust |
+------+
Figure 4
The "Cust" machines are customer servers, with perhaps one or more of the
following scenarios:
- owned by ISP, customer has no root access
- owned by ISP, multihomed, customers have no root access
- owned by customer, customer has root access
When the machine is owned by the ISP, there is a distict possibility that
the ISP will try to confine the customer to a "safe"[5] environment.
Usually the customers are separated from each other on a switch with VLANs to
prevent them from attacking each other. However, if the theory described above
works, there is no reason the tricks described in the attack section shouldn't
apply here.
--
[1] Infamous scanner written by Fyodor (found at http://www.insecure.org).
[2] Of course, as I disclaimed in the beginning, only if this theory works!!
[3] "-conf" is the usual extension used by Cisco router configurations.
[4] Cisco Express Forwarding (http://www.cisco.com/univercd/cc/td/doc/
product/software/ios112/ios112p/gsr/cef.htm#xtocid262640). A layer 3
switching mechanism.
[5] Probably exploitable.
_filtered.jpg){kind=small}
Tidak ada komentar:
Posting Komentar