http://staff.
Some thoughts on modern denial of service
Contact:http://www.packetnexus.com
http://www.e-gerbil.net/ras/dos.txt
Table of Contents
1. Modern Denial of Service
2. What we face
3. Distributed Denial of Service
4. High packet per second floods
5. Attacking the infrastructure
6. LAN attacks
7. Dropping packets on the floor
8. How to filter
9. What to filter
10. Protecting router interfaces
11. Protecting everyone else
12. Assume = Ass + U + Me
Section 1 - Modern Denial of Service
However Denial of Service truly began, most people acknowledge that it has
evolved into its current form by Internet Relay Chat. Denial of Service
didn't just happen, it required effort and motivation to reach today's
levels.
Unfortunantly, what was once a game of "high tech" petty vandalism for
teenagers has begun leaking out into the rest of the internet. Once it
could be argued that if you simply weren�t on IRC, you would not ever have
to deal with attacks. Many providers have even gone so far as to blame the
victim for inviting the attacks, and if called for assistance the answer
would be to simply unplug or null-route the victim. This solution may have
worked for small-time customers, but how do you say that to a Yahoo, eBay,
or CNN?
But on the other side of the coin, what provider wants to advertise that
they are attack-proof and invite someone to prove otherwise? Who wants to
invite customers that will attract attacks? After all, what most providers
see as a "big attack" is pretty small and infrequent in comparison to what
could be done if there was sufficient motivation for the attackers.
Back in Feburary 2000, a canadian kid with the nick "mafiaboy" wanted to
impress some people on IRC. He turned some scripts and tools which took
almost no advanced technical skills to use from their usual target of IRC
and against some big names in "e-Commerce", and proceeded to change the
way people think about DoS. The only reason he was caught was he bragged
about it on IRC. The most supprising thing about this is that no major
attacks have followed.
Section 2 - What we face
So you think the tools which exist now are bad? Think about this:
If attacks were rate-limited to not use "full force", they would be
extremely difficult to detect and trace. What if an attacker used 10,000
boxes which generated a relatively "unnoticable" amount of traffic?
What happens when someone writes a DDoS network which uses more then badly
ripped crypto from eggdrop source code? What happens when someone designs
a self-maintaining network which can't be traced back to a single human.
What if there was a totally modular DDoS network, where when a new attack
comes out, a new module is simply pushed out through the network.
What if thousands of network nodes were able to automatically select the
best method of attack? Can't spoof outbound, well use an unspoofed attack
which blends in with spoofed attacks generated by other nodes.
What if nodes analysed the paths they took to the victim and tuned for the
most damage. This could also be used to bypass any automatic path
auto-detection, auto-tracing, and/or auto-filtering mechanisms.
What if an attacking node automatically backed off the attack if it
detected reasons to do so. What if the attacking nodes reported
information about which are the most useful nodes so the human operator
could make better decisions about what to use, and where to hack next.
After all, one of the biggest causes of smurf failures is the attacker
using broadcasts which generate a lot of nasty looking dupes at low rates
and small packet sizes, but which actually put out an extremely small
amount
Responding to a Security Incident
Contact:http://www.packetnexus.com
Jose Nazario Autumn, 2000
This article focuses on gathering information about systems or networks
that are trying to compromise your security. We discuss using the
network databases to find contact information, what information to
include and what style of memo to write.
------------[ Introduction
By now, nearly everyone who has been using Linux for some time and had
their system connected to the Internet has seen attempts to compromise
their security. The next questions that often comes up is what to do
about it. Unless it's a financial or safety issue, it's probably going
to get laughed at by the legal authorities, but it's worth reporting.
I spend a good chunk of my time on mailing lists and organizations
concerned with monitoring hacker activity. Such lists are the INCIDENTS
list from SecurityFocus.com and the SANS GIAC effort, providing a daily
update of hacker activities from various parties around the world.
Often, the question of the value of reporting an incident is debated. I
routinely counsel people to report most incidents they see. What this
does for the ISP to whom you are reporting this is a set of
independently correlated data about a nefarious customer, or a
compromised machine on their network. Just don't expect much to be done
about it, to be honest with you. Most ISPs don't react, and aren't very
neighborly. Some of us in the business routinely block entire networks
from connecting to our networks based on patterns of allowing unseemly
activity to continue.
We'll not go into detecting incidents, but we will define them as port
probes, port scans, denial of service (DoS) attempts, and unauthorized
access attempts. Each of these warrants investigation, some more than
others. Combining intrusion detection software with log analysis (which
you should be doing anyhow), these events should stand out.
-----------[ An Example Detect
We'll start with a simple detect and extract information from it,
deciding how best to proceed. This first one is a log message of a
refused connect request from a service wrapped using TCP wrappers
(tcpd). As of this writing, FTP sweeps are all the rage:
$ grep refuse /var/log/secure
Nov 8 15:26:31 linux ftpd[3689]: refused connect from
7dyn94.ztm.casema.net
TCP_wrappers makes an excellent basic intrusion detection system,
logging both successes and failures. You should be using at least
TCP_wrappers for access control, and minimizing what services people can
connect to at all.
A brief note about connection attempts: One important thing that gets
overlooked by the casual paranoid Internet user is the threshold of what
defines a probe or an attack, and what is worth reporting. Usually it's
not worth reporting SMTP (port 25/TCP) or HTTP (port 80/TCP) probes,
unless you can demonstrate that it was more than a simple connection
attempt. Why? Say I see you on a chatline, and I want to send you some
mail directly, or see if you have an interesting website. If you are
blocking those requests, they would show up as port probes. But they're
usually more innocent than they may appear. The same goes for ping
requests (ICMP_ECHO), which are used, for example, in gaming an Napster
to determine latency. Don't get in a tizzy about simple things, focus on
actual intrusion attempts, like an FTP exploit or a network sweep for a
service.
--------------[ Finding Information
One of the first things we do is to to map an IP address to that
hostname. I prefer to work with IP addresses rather than hostname as
sometimes ISPs will sell their netblocks in smaller quantities, yet
retain administrative control of them:
$ nslookup 7dyn
Another Paper on Linux Security
Contact:http://www.packetnexus.com
Another Paper on Linux Security
13 Aug 98
Last Update 07 Sept 98
Version Beta 0.2
Bronc Buster
[email protected]
------------------------------------------------------------------------
Another paper on Linux Security? Why? Well most of the ones I've seen
floating around the net are never complete, only someone's tips or
tricks on how to secure a part of it, or to tweak some daemon or process
or a quick fix to a problem. They never cover from step one, though
going multi-user and going online with users and user processes and all
that goes along with it. I want to cover that. I know, no matter how
hard I try, I'll end up missing something, but I'm going to try and
cover everything I do when I install a system and prepare it for online
use, plus cover some free tools that I have found to be very effective.
Now if you are totally clueless and don't have any idea about how to use
Linux, I'll save you some time and tell you now, just don't go any
further. To get any use out of this paper, you have to be an
intermediate user, or a new admin who is familiar with Unix as a whole.
If you are thinking about going by this list when you are installing
your system, READ THIS ENTIRE PAPER FIRST, then start over following it,
otherwise you may miss something you might want when you install or when
you pick a kernel.
I'll say this now before you start. This paper is ongoing, and a
work in progress. I want to make a comprehensive paper, so I welcome all
suggestions, tips and advice on how to make this paper a better one.
------------------------------------------------------------------------
Contents
1. Installation
2. Boot-Up
3. SUID files and the File System
4. Quotas
5. Logs
6. Access security (remote and physical)
7. Misc. Files
8. Third Party Tools
9. Conclusions
------------------------------------------------------------------------
1. Installation
This is a step every paper I have seen has over looked. Right from
install you can manage to cut your problems by at least one-third if you
install correctly, installing only what your system needs. Think about
it. Ask yourself what is this box going to be doing? Is it going to be
on a LAN as a file server of some sort, or sitting on a direct Internet
Connection as a web server of some sort, or just sitting on your
desk at home running PPP? These are important questions you need to
answer BEFORE you start your install.
If this system is going to be sitting on a rack as a web server, why
would you want to install X-Windows, for example. If you're not going to
use it, you'll most likely overlook it in day to day operations, and
that's something a hacker is going to look for. Along with this comes
SUID programs, programs you might not even know exist, but programs a
hacker will head for like a shark for blood. On the other hand, if it's
on a LAN, where you're going to be at the console, and an X-Windows
server is necessary, look for other components you won't need, like any
of the PPP or SLIP components.
If you're not sure, go out and buy a book, or if you're really poor,
borrow a book. Read up on what each component does and why you need it.
If worse comes to worse, when you are installing, read each section
before you just go down the line and check off everything. Read the
parts which you are unsure of and don't install what you think you don't
need. Remember that you can always go back later and add things. The
Unix file system can be very complex and very deep, and hackers depend
on this when they are hiding programs and backdoors. The better you
understand what you have put
Air Gap
Contact:http://www.packetnexus.com
We had some discussion of thier e-Gap product after a consultant brought it
to us as a possible solution for something... We requested a demo of it but
they weren't willing to let us play with it unless we were planning to buy
it already and just wanted to confirm that it worked. Since we never got a
hold of the real device, Jon Squire had some quick thoughts and possible
theoretical attacks on it.. His main discussion follows as attached. If
anyone has actually used this product, we would be interested to hear what
you have to say.
thanks,
larry
From: Squire, Jonathan
Sent: Tuesday, October 26, 1999 3:00 PM
Subject: Squire's take on Air Gap Technologies -- READ FIRST (PART 1)
OK since I have a fair amount ot say I'm seperating out my general
impression of thier propoganda from my theoretical attack.
General Impression:
They don't have a lot (READ ANY) real technical infomation about thier
implementation available... proabbly for good reason... it's not really
a novel idea to transfer data via sneakernet... thier just doing it in
hardware... and very fast... which could prove usefull later for an
attack.... anyway, moving on...
I'm just going to comment on some of the things they say on thier web
site... black is them... blue is me
Air gap Security Guarantees:
To transfer the whole data and nothing but the data
To deliver the data to the exact, specified location in your network
To let you check the data before it is delivered to that location
To guarantee the above promises even if the external unit is
compromised by intruders
Thier fourth claim is proabbly not possible to guarantee... I'll get into
the attack on it in my next email... but that is a very hard claim to make,
and one if they put money on it I would be more then happy to take from
them.
Air gap resembles the security system at an after-hours gas station, where
the cashier sits behind bullet-proof glass. At no time is there any direct
contact between the cashier and the client, however they can exchange
money and payment receipt via a metal tray or drawer. The cashier and the
cash register are fully protected against external threats, since there is a
complete physical disconnection between the two. air gap draws its
inspiration from this type of architecture, in which a transaction can
clearly take place, but the trusted network (the cashier and cash register)
cannot be easily compromised by the untrusted network (the customer). An
"Air Gap" is always kept between the trusted and untrusted networks, however
transactions can take place in real-time.
Ok real simple attack... and thier system is proabbly dumber...
but I can take a stick of dynamite, light it and stick it in the drawer w/
my money.... the drawer contents are to some degree obscured from view until
the attendant opens the drawer... if the fuse is short enough... blam!
(Bear in mind that I'm aware that I can always use the dyanamite to take
out the glass... the point was I sent an attack across the gap security
mechanism.
Why is air gap technology so secure?
Air gap technology is the safest network access security system
available because it relies on:
- No TCP/IP or network protocols
- No physical connection
- No operating system
air gap allows only a narrow path for specific data or transaction exchange.
In this way, air gap prevents any protocol or operating system attack on
your back office network.
I'll get into this on the technial front in the next email, but you'll see
as I paste in some of thier other propganda how they are really playing on
FUD and nothing else (they don't offer any proof that it's the safest
network access security system available) ... and infact after saying they
provide no network acces
Securing Your Network
Contact:http://www.packetnexus.com
Securing Your Network
Securing your network is a vital task for any ISP or other
internet-connected body. That is undisputed - no internet-connected body can
afford to ignore security issues. This talk focuses on how to effectively
secure your network and machines.
The first step in securing a network must be the security policy. To
effectively secure any network you must have and implement a good security
policy.
In forming a security policy it is often it is useful to consider the idea
of security zones - divide your network into security zones and define
boundaries which separate security zones or domains. Then, make sure you
cannot cross any of these boundaries without appropriate authentication
(such as passwords). Remember that if you permit someone any access on a
system which is not actively maintained, there is a good chance they will be
able to obtain superuser access.
Of critical importance is the security of your servers, both due to the data
which may be contained in them and the potential for well-connected servers
to be broken into and used to attack a third party. This is an area where
you cannot be too careful - you must watch security mailing lists as it may
be just a few hours between a security vulnerability being published and
millions of sites being attacked.
Just as important, but more often neglected, is the protection of your
traffic against "traffic stealing". Open proxy servers and mail relays can
pose just as much of a threat to your internet connectivity and
profitability as any break-in. Related to this is "spam" prevention -
unsolicited e-mail, or "spam", is another form of "traffic stealing" by
using you and your customers bandwidth to send unsolicited advertising. It
is important to make sure your network and all network services you provide
are secure and well-configured to prevent traffic stealing.
Another important part of security is protecting your clients, their systems
and their connection to the internet. While some of this responsibility must
fall on the clients, it is up to you to keep them informed and to give some
reasonable protection from outside attacks.
Firewalls and filtering routers may help you secure your network however
they have some downfalls. Often a firewall is installed and it is then
assumed that "all is secure, we have a firewall". This is simply not true,
and almost never true - it should certainly not be assumed. The firewall
itself may even add insecurity into your network - a prominent firewall only
recently was found to give out it's SNMP community names to a SNMP probe on
it's external interface. Also, there must be holes in a firewall in order
for any services to be provided to the outside world. Maintaining these
holes is one hassle you take on when you decide to install a firewall. Two
more important issues to consider if you plan to install a firewall are
preventing a false sense of security and that you must remember that a
firewall only protects one side from another - where do you put your
customers? They could end up victims of hackers on the outside, or if you
put them on the inside they may be just as much a threat as any "random
internet hacker".
Two other vital areas are physical security and social engineering. Just as
the best firewall is an air gap, the best way past a firewall is to just
walk past it. Do you have a secure machine room, or could people walk into
it? Do you give potential customers office tours and have insecure consoles
or passwords written on notes? All security is void if you have no physical
security. Similarly, social engineering allows a way to bypass the normal
security systems you may design. Phone calls can
The Ten Immutable Laws of Security
Contact:http://www.packetnexus.com
By Scott Culp
October 2000
Here at the Microsoft Security Response Center, we investigate thousands of
security reports every year. In some cases, we find that a report describes
a bona fide security vulnerability resulting from a flaw in one of our
products; when this happens, we develop a patch as quickly as possible to
correct the error. (See "A Tour of the Microsoft Security Response Center").
In other cases, the reported problems simply result from a mistake someone
made in using the product. But many fall in between. They discuss real
security problems, but the problems don't result from product flaws. Over
the years, we've developed a list of issues like these, that we call the Ten
Immutable Laws of Security.
Don't hold your breath waiting for a patch that will protect you from the
issues we'll discuss below. It isn't possible for Microsoft � or any
software vendor � to "fix" them, because they result from the way computers
work. But don't abandon all hope yet � sound judgment is the key to
protecting yourself against these issues, and if you keep them in mind, you
can significantly improve the security of your systems.
Law #1: If a bad guy can persuade you to run his program on your computer,
it�s not your computer anymore.
Law #2: If a bad guy can alter the operating system on your computer, it�s
not your computer anymore.
Law #3: If a bad guy has unrestricted physical access to your computer, it�s
not your computer anymore.
Law #4: If you allow a bad guy to upload programs to your web site, it�s not
your web site any more.
Law #5: Weak passwords trump strong security.
Law #6: A machine is only as secure as the administrator is trustworthy.
Law #7: Encrypted data is only as secure as the decryption key.
Law #8: An out of date virus scanner is only marginally better than no virus
scanner at all.
Law #9: Absolute anonymity isn't practical, in real life or on the web.
Law #10: Technology is not a panacea.
Law #1: If a bad guy can persuade you to run his program on your computer,
it's not your computer anymore.
It's an unfortunate fact of computer science: when a computer program runs,
it will do what it's programmed to do, even if it's programmed to be
harmful. When you choose to run a program, you are making a decision to turn
over control of your computer to it. Once a program is running, it can do
anything, up to the limits of what you yourself can do on the machine. It
could monitor your keystrokes and send them to a web site. It could open
every document on the machine, and change the word "will" to "won't" in all
of them. It could send rude emails to all your friends. It could install a
virus. It could create a "back door" that lets someone remotely control your
machine. It could dial up an ISP in Katmandu. Or it could just reformat your
hard drive.
That's why it's important to never run, or even download, a program from an
untrusted source � and by "source", I mean the person who wrote it, not the
person who gave it to you. There's a nice analogy between running a program
and eating a sandwich. If a stranger walked up to you and handed you a
sandwich, would you eat it? Probably not. How about if your best friend gave
you a sandwich? Maybe you would, maybe you wouldn't � it depends on whether
she made it or found it lying in the street. Apply the same critical thought
to a program that you would to a sandwich, and you'll usually be safe.
Law #2: If a bad guy can alter the operating system on your computer, it's
not your computer anymore.
In the end, an operating system is just a series of ones and zeroes that,
when interpreted by the processor, cau
The Ten Immutable Laws of Security Administration
Contact:http://www.packetnexus.com
By Scott Culp
November 2000
We recently published the Ten Immutable Laws of Security, a listing of ten
facts of life regarding computer security. We realized that administrators
have their own set of immutable laws, one that's entirely separate from the
list for users. So, we canvassed the network administrators, security gurus,
and other folks here at Microsoft, and developed the list that follows,
which encapsulates literally hundreds of years of hard-earned experience.
As in the case of the immutable laws for users, the laws on this list
reflect the basic nature of security, rather than any product-specific
issue. Don't look for a patch from a vendor, because these laws don't result
from a technology flaw. Instead, use common sense and thorough planning to
turn them to your advantage.
Law #1: Nobody believes anything bad can happen to them, until it does.
Many people are unwilling partners in computer security. This isn't because
they're deliberately trying to endanger the network � they simply have a
different agenda than you do. The reason your company has a network is
because it lets your company conduct business, and your users are focused on
your company's business rather than on the vagaries of computer security.
Many users can't conceive why someone might ever go to the trouble of
sending them a malicious email or trying to crack their password, but an
attacker only needs to find one weak link in order to penetrate your
network.
As a result, relying on voluntary measures to keep your network secure is
likely to be a non-starter. You need the authority to mandate security on
the network. Work with your company's management team to develop a security
policy that spells out specifically what the value of the information on
your network is, and what steps the company is willing to take to protect
it. Then develop and implement security measures on the network that reflect
this policy.
Law #2: Security only works if the secure way also happens to be the easy
way.
As we discussed in Law #1, you need the authority to mandate security on the
network. However, the flip side is that if you turn the network into a
police state, you're likely to face an uprising. If your security measures
obstruct the business processes of your company, your users may flout them.
Again, this isn't because they're malicious � it's because they have jobs to
do. The result could be that the overall security of your network would
actually be lower after you implemented more stringent policies.
There are three key things you can do to prevent your users from becoming
hackers' unwitting accomplices.
Make sure your company's security policy is reasonable, and strikes a
balance between security and productivity. Security is important, but if
your network is so secure that nobody can get any work done, you haven't
really performed a service for your company.
Look for ways to make your security processes have value to your users. For
instance, if you have a security policy that calls for virus signatures to
be updated once a week, don't expect your users to do the updates manually.
Instead, consider using a "push" mechanism to do it automatically. Your
users will like the idea of having up to date virus scanners, and the fact
that they didn't have to do anything makes it doubly popular.
In cases where you must impose a restrictive security measure, explain to
your users why it's necessary. It's amazing what people will put up with
when they know it's for a good cause.
Law #3: If you don't keep up with security fixes, your network won't be
yours for lo
3 major problems with WEP
Contact:http://www.packetnexus.com
There are 3 major problems with WEP (which stands for "Wired Equivalanet
Privacy," BTW. I will list them in order of increasing severity.
1) Key distribution. If you aren't the only person on the network,
getting the key out to other people is a non-trivial task and can be the
weakest link.
2) 40-bit - the standard WEP keysize is completely insufficient and can
be cracked in relatively no time. 128bit versions of the hardware are
available, however, so this is an improvement.
3) This is the biggie - the WEP authentication protocol relies on DNS
and is therefore prone to massive man-in-the-middle attacks. There is a
paper by Jesse Walker called "Wireless LANs Unsafe at Any Key Size; and
analysis of the WEP encapsulation" that I encourage everyone to read.
WEP is especially dangerous because it establishes a false sense of
security that cause people to be more willing to send sensitive data
over the network. You still need to use some other encryption method on
to of WEP - even at best it gives the privacy of a standard ethernet
LAN.
Other technologies are under development to improve the state of
wireless security, such as the IEEE 802.11 Task Group E, which is trying
to develop an authentication scheme suitable for 802.11 wireless
networks, or the IEEE 802.1x protocol which will do similar things at a
more generic level.
There is no existing good solution to the wireless problem (PPPoE hacks
aside).
-Alison
http://www.andrew.cmu.edu/~alison/
Back to the Index
Sniffing wireless
Contact:http://www.packetnexus.com
You'd be surprised the fun which goes on at conferences such as RIPE and
IETF when WaveLAN virgins get onto the network and realise it isn't
secure.
You might have heard of a guy called Randy Bush, whose favourite party
trick at such events is to sniff the WaveLAN, and email out to captured
POP3 usernames their own password with the message 'Be careful with
radio!'. It's not even a switched network as a default install.
Setting up some sort of VPN using PoPToP isn't a bad idea in such cases,
although WaveLAN does have some security built into it. Personally I use
the Buffalo Technology kit which seems to work for 'doze, BSD and Linux.
I've heard rumours that if you wander through Stockholm's business
district or through the Square Mile in London, if you're in promiscuous
mode you can pick up all sorts of transmissions and a large number of
DHCP servers offering IPs to anyone who gets the ESS ID right.
Hope this helps someone. Just be careful out there ;)
Back to the Index
Wireless Security Overview
Contact:http://www.packetnexus.com
By Benjamin J. Field ([email protected])
April 25, 2000 - Wireless networks are adopting online commerce at a
dizzying pace, reminiscent of the Internet's adoption of ecommerce
during the last two years. Applications such as stock trading, shopping,
and banking are now available on wireless networks (Ameritrade,
Amazon.com, Bank of Montreal).
It is the market of the future, but wireless is worth paying attention
to right now. According to the Strategis Group (www.strategisgroup.com),
the number of professional mobile data users in the United States is
upwards of 32 million, and growing. Ericsson (www.ericsson.com) predicts
that there will be around 600 million mobile Internet subscribers
worldwide by 2004.
Why this sudden growth? In part, it springs from consumers and
developers getting better at thinking alike. But the wireless growth
phenomenon ultimately comes down to security. Here's how it happened.
Early on, demand was easily met for wireless information such as weather
and stock tickers, because for these basic applications, security is no
concern. The problem was that professionals wanted more than a portable
weather watch. They wanted the functionality of the Internet merged with
the convenience of the telephone. A great deal of security is required
for financial transactions, though, and a trustworthy standard for
wireless network security was absent. This meant slow growth for the
wireless industry, until the WAP.
WAP
The Wireless Application Protocol (WAP) is the standard for wireless
applications.
It was developed by the WAP Forum -- a group of more than 200
telecommunications and software companies who see the need to cooperate.
The WAP addresses a lot of subjects, but the chief concern is, and will
continue to be security. A robust and reliable security model was
defined, to be usable on existing wireless networks. This move has
instilled real confidence in wireless developers and consumers alike.
WAP Security Model
The WAP Security model relies upon WTLS (see Wireless Transport Layer
Security below) and SSL (see The Internet Security Model below).
The central component in the model is the WAP Gateway, a virtual
gatekeeper between the worlds of WTLS and SSL. Picture this progression:
Wireless
Device
Wireless
Network
WAP
Gateway
Internet
Network
Content
Server
A wireless phone communicates with the WAP Gateway over a wireless
network, using WTLS. The WAP Gateway then communicates with the Web
server over the Internet, using SSL.
WTLS is built on the Internet Security Model. A quick review--
Internet Security Model
Just as the wireless world, the Internet world experienced a push for
stronger security, only it happened in the mid-90s. The wish couldn't
become a reality, though, until Secure Sockets Layer (SSL) came along.
Here's a typical scenario for the SSL security mechanism:
1. A Web browser requests a secure conversation with a Web server.
2. The server provides the browser with its server certificate.
3. The browser authenticates the server by confirming that a valid
certificate authority issued the certificate.
4. The browser uses the public key stored in the certificate to encrypt
a shared secret key.
5. The browser sends the encrypted shared secret key to the server.
6. The (more efficient) shared secret key encrypts the rest of the
conversation.
Some web servers require a client certificate, but usually, a server
relies on a simple username/password system for authentication and
non-repudiation.
The Internet Security Model is the basis for WTLS.
WTLS
Wireless Transport Layer Security (WTLS) was formulated specific
So You Want To Be A Wireless Security Professional
Contact:http://www.packetnexus.com
by William Sieglein, Senior Security Engineer, Fortrex Technologies
[ November 28, 2000 ]
Q: I wish to know more about the security threats in the wireless area,
and I also want to know how dangerous these threats are. What types of
skill sets are required to deal with wireless security threats? I wish
to pursue a career in this area. What should one learn in order to
become a wireless security professional?
- Vivek Kashyap
A: You're either the pioneering type, or you're thinking this is the
next big wave and you want to get rich as a wireless security
consultant. Actually you might be both.
Wireless technology is not brand-new; neither are the threats associated
with it. We've all heard about cases of cell phone cloning and the
incredible costs this brings to the industry. But now we're talking
about sending data over wireless networks -- potentially sensitive data.
We're opening up our trusted intranets to the public Internet. Of
course, we're already doing that over the wire-based Internet. But our
mobile friends need it via the airwaves.
Is wireless any more dangerous than traditional wire-based networking?
The definitive answer is yes, it very possibly is. Wireless is just
another medium for getting data packets from point A to point B. The
wireless architecture provides possible points of attack against the
portable device (phone, PDA, laptop and so on), the wireless network and
the wireless gateway. Portable devices are vulnerable to DoS attacks,
malicious code, theft and compromise. Their packets, in transit over the
wireless network, are vulnerable to interception, modification and
replay or fabrication. Finally, the wireless gateways are potentially
vulnerable to DoS attacks and compromise.
Does this mean there are "whackers" (wireless hackers) looming in the
shadows, waiting to pounce? Although there are no well-known incidents
of major attacks against wireless technology to date, there are ongoing
discoveries by research organizations and development companies that
expose weaknesses. So far, wireless technology providers have been less
than serious about closing these holes, primarily because the demand for
wireless technology is still modest. But rest assured that as wireless
picks up steam, these attacks will increase and the technology firms
will provide more solutions.
You must keep this in mind as you educate yourself about wireless
security: Nothing in the real world happens in a vacuum. You can't just
look at a single solution to solve your security issues. You have to
consider the entire IT infrastructure when designing security solutions.
Putting up a WAP gateway is much like putting up a Web-based application
server. It usually exposes some portion of your back-end, trusted
infrastructure. So you must consider the entire solution, end to end,
and ensure that security addresses these vulnerabilities at all points.
Merely encrypting the link or requiring the user to authenticate is not
enough. You must consider intrusion detection, anti-virus, firewall
configuration, DMZ architecture, user authorization, access controls and
logging.
I recommend that you become proficient in information security, with an
emphasis on wireless security technology. Wireless certainly holds
promise but, like all technologies, it will be superseded by another,
even cooler technology before you know it.
Back to the Index
High school packet sniffing
Contact:http://www.packetnexus.com
My high school http://global.mpa.pvt.k12.mn.us is one of the first in
the country to use Apple's AirPort wireless technology in the classroom.
We all have Apple iBooks. Everyone uses AOL Instant Messenger in class
all day long. :-)
One day someone figured out that packet sniffers can be used on the
network to see other people's POPmail passwords and AIM conversations,
as well as whatever websites they are at. It is genuinely disturbing.
However, I am terrified of telling our administration about this because
of a kill-the-messenger syndrome.
Let me just say that this is one of the most ridiculously insecure
technologies in the world, just waiting for the packets to be pulled
down out of the air with a packet sniffer program like EtherPeek. People
have been doing this for months around here.
This is just a school. It's terrifying to think that the world's
important financial institutions rely on this technology's security.
Back to the Index
Known Vulnerabilities in Wireless LAN Security
Contact:http://www.packetnexus.com
http://www.tml.hut.fi/Studies/Tik-110.300/1999/Wireless/vulnerability_4.html
Known Vulnerabilities in Wireless LAN Security
11.10.1999
Asma Yasmin
Department of Electrical and Communication Engineering
Helsinki University of Technology
[email protected]
Abstract
Wireless Local Area Networks are becoming a respectable alternative in
indoor communications. It offers flexibility and mobility in networking
environments, as the user is not bound to a certain workplace anymore.
Wireless technology allows the network to go where wire cannot go.
Mobile workforce who require real time access to data benefit from
wireless LAN connectivity since they can access it almost any time any
place. Wireless LANs are also ideal for providing mobility in home and
hot spot environments. Unfortunately, disgruntled employees, hackers,
viruses, industrial espionage, and other forms of destruction are not
uncommon in today's Networks. This essay addresses the common
vulnerabilities to the security of the wireless LAN.
------------------------------------------------------------------------
--------
Contents
1. Introduction to Wireless Local Area Network
1.1 Wireless LAN Architecture
1.2 Benefits of Wireless Local
2. Known vulnerabilities in WLAN
2.1 Inherent flaws
2.2 Hackers, Virus, and Intruder
2.3 Distribution file and quality of password
2.4 Interception
2.5 Masquerading
2.6 A denial-of-service attack
2.7 Others
3. Conclusion
References
Further Information
------------------------------------------------------------------------
--------
1. Introduction to Wireless Local Area Network
Conventional Local Area Networks are fixed and deploy cables as physical
medium. They were developed for interconnecting computers to enable
sharing of resources, and to interconnect various organizations. LANs
are typically restricted in size and offer a maximum throughput from 10
Mbit/s to 100 Mbit/s. The increased use of mobile phones and laptop
computers has created a need for communication methods that would enable
a user to access network resources from anywhere and at anytime. Office
workers may spend a lot of their working time away from their desks, and
yet they need to access the network resources without physically being
at their desks. Due to bandwidth limitations and expensive technologies,
cellular data networks, such as Global Systems for Mobile Communications
(GSM), are not suitable for local area high speed data networking.
Various wireless LAN standards have been developed to address the needs
of mobile users [3].
1.1 Wireless Local Area Network Architecture
Due to its architectural inheritance, wireless LAN poses some intrinsic
security flaws. So It seems to me incomplete if something regarding the
wireless LAN architecture is not mentioned in this study before going to
discuss it's security vulnerabilities.
Figure 1.1 Wireless LAN Architecture
The wireless LAN consists of access points and terminals that have a
wireless LAN connectivity. Finding the optimal locations for access
points is important, and can be achieved by measuring the relative
signal strength of the access points. Placing the access points in a
corporation network opens an access way to the resources in the
intranet. With wired LANs an intruder must first gain physical access to
the building before she can plug her computer to
Securing OSPF
Contact:http://www.packetnexus.com
http://www.liquifried.com/securingospf.html
Securing OSPF
Jason Chan, version 1.1, 6 February 2001
OSPF Background
OSPF (Open Shortest Path First) is an open standard IP routing protocol.
Developed in the late 1980's in response to the need for a higher
performance, vendor neutral routing protocol, OSPF was first specified
in RFC 1131. The current OSPF RFC is 2328.
OSPF is a link-state routing protocol. Link-state routing protocols take
the actual state of the network link into account when creating routing
tables and calculating routing decisions (hence the name). This
basically means that factors like bandwidth and delay can be used when
calculating a route's best path, instead of the traditional metric of
hop count used by the distance-vector family of routing protocols.
A large number of network administrators choose OSPF as their interior
routing protocol. Its fast convergence time and high degree of
configuration control contribute to OSPF's popularity. However, the fact
that OSPF is an open standard may be the biggest reason for its
popularity. EIGRP (Enhanced Interior Gateway Routing Protocol) is one of
OSPF's counterparts in the world of interior routing protocols. Although
it is quite popular and performs well, EIGRP is a proprietary Cisco
protocol. Hence, it is an inappropriate choice for heterogeneous
networks.
Rather than focus on the details of OSPF (of which there are many), this
paper focuses more narrowly on some of the security aspects of OSPF.
Specifically, this article describes the secure configuration of OSPF in
a heterogeneous network environment. The network described will include
both a Cisco router and Unix machines running the popular gated routing
package. For further details on OSPF, gated, and other subjects
mentioned in this article, please consult the references provided.
Defense in Depth
The security of routing protocols doesn't get a lot of press. Most of
the security material you'll read will be about the more 'glamorous'
aspects of information security like firewalls, intrusion detection, and
VPNs. And, while all of these topics merit attention, I myself am an
advocate of what is often described as 'defense in depth.'
'Defense in depth' basically refers to the idea that security
(information or otherwise) should be provided at as many layers as
possible. This idea is seen often in everyday life. For example, a
deadbolt lock will do a good job of securing your house, but wouldn't an
alarm system in addition be even better? How about bulletproof glass or
armed guards? Probably out of the question for your normal home security
plan, but what about when it comes to securing your company's network?
With the speed of developments in both sides of the information security
field (the good guys and the bad guys) it is more important than ever to
provide defense in depth. Statements like "I have a firewall, so my
network is secure" or "I have an IDS installed so I'll be able to tell
when someone's breaking in" just aren't true. What about when the
firewall's been misconfigured or just plain fails? What about when there
is a new attack that your IDS signatures don't detect? For that matter,
what about when an employee decides to install a modem in his desktop PC
so he can dial in from home, potentially subverting both your firewall
and your IDS? All of these and more are reasons for the implementation
of defense in depth in any endeavor to provide information security.
Being proactive rather than reactive and thinking and designing in
layers are two of the best pieces of advice I could give about securing
networks and information. Now, eno
Using IPSec for Remote Administration on Linux Firewalls
Contact:http://www.packetnexus.com
http://www.sans.org/infosecFAQ/encryption/remote_admin.htm
Using IPSec for Remote Administration on Linux Firewalls
Danny Chang
August 2, 2000
Introduction
The corporate security administration function includes among many other
daily tasks, the remote administration of firewalls or proxy servers
from a central location. The task of remotely logging on and
administrating Linux firewalls presented a problem for my organization.
We have used other firewall set-ups like CheckPoint VPN-1 and Cisco
routers configured to use VPN either as a plugin or software application
that came with the firewall or router package, but we did not have any
secured channel established to administer our Linux firewalls from the
security administration console. As we all know without a VPN or secured
channel, all traffic is not encrypted including, administrator
passwords.
Background
We experimented with different approaches to provide a cost-effective
method of remote logon activities including SSH scripting and S/WAN
IPSec implementation but due to the private network we are using for our
core business, we have chosen a simple solution provided by NIST
Cerberus IPSec and the PlutoPlus IKE software for encapsulation or
tunneling between our Linux firewalls and the security console. Also, we
are currently using IPv4 and not IPv6. [By the end of August 2000, the
Cerberus software will be made available to the public.] We have chosen
Cerberus because of its built-in user interface and web-based tester
(WIT) for interoperability testing capability. More importantly, NIST
Advanced Networking Technologies Division has provided substantial
research in IPSec, and has incorporated IPv6 standardization in the
Cerberus software. We have come to realize that VPN is the answer or
solution to our specific problem. VPN can be used with the following
types of network communications and configurations:
Peer-to-Peer
Client-Server
Protected Workgroup
Protected Enterprise
Protected Inter-Enterprise
VPN and Remote Access
IPSec and Linux firewalling
Linux firewalling chains consisting of three chains, the input, output
and forward, and other user defined chains that provide different
functionality. A chain is a checklist of rules. Each rule determines how
the packets are handled either masquerade, redirect, accept, deny,
reject or return. These rules are based on the security policies
established by the security administrator. Linux uses the Ipchains built
into recent Linux kernels' distributions for firewalling. Many
commercial firewalls today support VPN functionality in their firewall
products. As a result, vendors came out with their own ways of
implementing IP encryption. I will highlight how IPSec is implemented in
general as it is applied to "Our Solution".
The starting point for implementing IPSec in firewalls is how to apply
the rules to the AH (Authentication) or the ESP (Encapsulating) header.
These packets are screened or filtered for AH or ESP based on IP
addresses. After the initial installation, the SADB database has to be
loaded. At this point there are "one-sided" Security Associations
established, then the same procedure has to be followed on all machines
(hosts/gateways).
Implementing Cerberus for Linux
The NIST Cerberus IPSec Reference Implementation for Linux was developed
based on the current ESP and AH specifications and other RFCs and IPv6
Standards. The main components of the reference module are the Security
Association Da
Examining Advanced Remote OS Detection Methods/Concepts using Perl
Contact:http://www.packetnexus.com
Examining Advanced Remote OS Detection Methods/Concepts using Perl
------------------------------------------------------------------
------[ Feb 03, 2001 - by f0bic - http://www.low-level.net ]------
"Half of the work that is done is this world,
is to make things appear what they are not."
-- Elias Root Beadle
Abstract
This paper discusses the theory and practice behind
OS detection with a specific focus on the practice
related to the PERL programming language. Methods
and concepts for remote operating system detection
are closely examined and implemented into Perl code.
I. Introduction
Throughout the years, a host of information has been posted online
about the use of various techniques and methods to determine what OS
(operating system) a certain host is running. Since these OS detection
techniques rely on certain factors that are not constant, the accuracy
of these OS predictions can not be guaranteed a full 100 percent.
This paper stresses the importance of these factors and gives pointers
on how to apply these various OS detection methods in perl.
II. Basic OS Detection Methods
Before I get to Advanced remote OS detection concepts, I wanted to
briefly point out some other methods which can be used to detect a
remote hosts' OS. These techniques may old, but they get the job done.
(1) telnet banner grabbing
I hope this is pretty self-explanatory to you. :) But just in-case,
you connect to telnetd on the remote host, and see what the telnet
login banner prints :)
(2) FTP banner grabbing
Same basic concept as telnet banner grabbing, just w/ ftpd instead
of telnetd.
(3) http head method
You can try and determine an OS by checking what web server (httpd)
the target is running. i.e. Microsoft-IIS should be WindowsNT/2k.
Okay. I think this concludes our basic OS detection methods lesson for
today.
III. Remote OS Detection and Path Projection Concepts
There is a wide variety of techniques to determine a hosts OS. This
paper discusses four ways to do so.
* telnetd fingerprinting:
relies on telnet session negotiations and telopts.
* identd fingerprinting:
relies on identd/auth (113) to be open.
* TCP stack fingerprinting:
relies on Window, TTL, ToS, and DF.
* Queso fingerprinting:
relies on Window, Seq, Ack_seq
relies on various IP/TCP header flags.
* Passive fingerprinting:
closely related to TCP stack fingerprinting.
relies on Window, TTL, ToS, and DF.
relies on network traffic.
I'll discuss each of these methods in more detail throughout the next
couple of sections.
Some terminology:
* Window: TCP Packet Window-size - the maximum amount of packets that
can be sent out without receiving an acknowledgement.
* TTL: Time-To-Live - the maximum number of hops a packet can pass
through before being discarded.
* ToS: Type of Service
* DF: Don't Fragment bit
* MSS: Maximum Segment Size
These factors can be used in determining what kind of operating system
a remote host is running. Depending on the combination of all of these
flags, a match can be ran against a database of flags and an operating
system guess can be made. The following is a tcpdump snippet of an
incoming packet:
00:44:09.194998 eth0 < 203.9.66.52.www > my.ip.com.domain:
S 2006693595:2006693595(0) ack 1 win 9112 (DF)
(ttl 232, id 25119)
When we dis
SMTP bastion host
Contact:http://www.packetnexus.com
> I attempted to make a bastion host that basically runs sendmail 8.10.1
> and sits in the DMZ of our network. It's responsibility is to accept
> all incoming E-mails for corporate and forward it into an internal MS
> Exchange server. This it does fine. What I also want it to do is also
> act as a relay server to the outside world for the Exchange server.
> [...]
IMHO the best way to do what you want is as
follows:
A) make the bastion host primary MX for "internal" domains
B) use mailertable for "internal" domains routing
C) allow relaying from some internal IP addresses
D) allow relaying to "internal" domains
Additional info:
B1) add the following line to your *.mc file
FEATURE(`mailertable',`hash /etc/mail/mailertable)dnl
B2) in the mailertable file add the following line
domain1.internal esmtp:[ip-address]
domain2.internal esmtp:[ip-address]
B3) compile mailertable with makemap
C) in your access file add the following line
connect:ip-address
D) in your access file add the following line
to:domain1.internal
to:domain2.internal
OR use "non local" virtusertable
*.mc file:
VIRTUSER_DOMAIN_FILE(/etc/mail/virtuser_domains)dnl
FEATURE(`virtusertable',`hash /etc/mail/virtusertable')dnl
/etc/mail/virtuser_domains file:
domain1.internal
It will allow relaying to domain1.internal and it will give
a chance to redirect some addresses in the domain to another
internal mail server e.g.
virtysertable file:
[email protected] [email protected]
--------------------
URL(s):
http://www.sendmail.org/tips/relaying.html
Allowing controlled SMTP relaying in Sendmail 8.9
Back to the Index
Wireless LAN security flawed
Contact:http://www.packetnexus.com
http://www.computerworld.com/cwi/stories/0,1199,NAV47-68-84-88_STO57597,
00.html
Wireless LAN security flawed
Report: Systems have several vulnerabilities
By BOB BREWIN
(February 12, 2001) Computer security specialists at the University of
California, Berkeley, sounded new alarms last week about the security
vulnerabilities of wireless LANs. But network managers said they're
aware of problems with the technology and are beefing up their defenses
in response.
The Internet Security, Applications, Authentication and Cryptography
research group at Berkeley said in a report posted on its Web site
(www.isaac.cs.berkeley.edu) on Feb. 2 that it had "discovered a number
of flaws" in the Wired Equivalent Privacy (WEP) 40-bit algorithm used to
secure all IEEE 802.11 standard wireless LANs. These flaws, the Internet
Security, Applications, Authentication and Cryptography (ISAAC) report
stated, "seriously undermine the security claims of the system."
The ISAAC report said wireless LANs have several vulnerabilities,
including a susceptibility to passive attacks aimed at decrypting
traffic based on statistical analysis - a process made easier by the
broadcast nature of wireless systems. WEP also has flaws that make it
easier to inject unauthorized traffic from mobile base stations and that
make traffic vulnerable to decryption by tricking the base station,
which in turn is connected to a wireless network, the report said.
Enterprise network managers said the ISAAC report highlights problems
inherent in wireless LANs. But they said savvy users have already
factored the vulnerabilities into their defensive architecture.
Michael Murphy, director of IS support services at Minneapolis-based
Carlson Hotels Worldwide, said his organization plans to deploy a
wireless LAN architecture encompassing about 250 properties. "I've been
aware of the shortcomings in WEP for some time," Murphy said. "I want
something stronger [including] VPN encryption."
Tom Mahoney, network manager at Franklin & Marshall College in
Lancaster, Pa., is in the midst of deploying a 100-node wireless LAN
from Apple Computer Inc. A virtual private network (VPN) "seems to be a
reasonable solution to the problem," he said. But "only end-to-end
encryption will provide true security."
The security warning comes as wireless LANs - which currently provide
high-speed connections at 10M bit/sec., with new products in the
pipeline that will double that speed - continue to gain popularity in
the corporate and home markets. Gartner Group Inc. in Stamford, Conn.,
estimates that more than half of Fortune 1,000 companies will have
deployed wireless LANs within two years.
John Pescatore, a security analyst at Gartner Group, said the
proliferation of enterprise wireless LANs demands increased security
because every laptop equipped with a wireless PC LAN card is a potential
"sniffer."
Pescatore said the underground hacker community is hard at work
developing downloadable scripts to tap into wireless LAN networks, and
he predicted that such tools will be available this year.
"Within six months, 'script kiddies' are going to be able to drive
around corporate campuses" and easily tap into unprotected networks, he
said.
Phil Belanger, chairman of the Mountain View, Calif.-based Wireless
Ethernet Compatibility Alliance, downplayed the ISAAC report.
"This is not new news," Belanger said, noting that the IEEE has a group
working to beef up wireless LAN security. Organizations should take
steps to secure their wireless LANs, he said, suggestin
802.11 Wireless Security
Contact:http://www.packetnexus.com
http://securityportal.com/closet/closet20010207.html
802.11 Wireless Security
By Kurt Seifried ([email protected]) for SecurityPortal
Kurt's Closet Archive
----------------------------------------------------------------------------
----
February 07, 2001 - Wireless networks are becoming de rigeur, something you
must have if you want to keep up with the Joneses. You can now surf the Web
and pick up email while sitting in an airplane lounge, have your laptop in a
conference room with no unsightly cables, or read email while in bed. The
cost of these networks has plummeted. Base stations like the Apple AirPort
can be had for $300, and the cards are around $100 (both support 11
megabit/sec operation).
However, like all network technologies, they both solve problems (like where
to run cable) and create a lot of new ones (like how to communicate
securely). Unfortunately, most sites seem to have implemented 802.11
wireless networks without much (if any) thought for security.
A Wild Wireless World
The first problem is controlling access to your network. With Ethernet and
related (cable-based) technologies, your site was usually physically secure,
helping to prevent people from plugging their laptops, etc. into your
network. Thus, even if someone managed to plug into your network, they had
to manually discover who else was attached. While this wasn't impossible,
its difficulty improved the chances of you noticing an attacker (since they
couldn't use completely passive techniques).
With a wireless network, unless your building is externally shielded or has
a large open area around it, an attacker will be able to gain "physical"
access to the network just by bringing his laptop into proximity with your
network (up to several hundred feet). An attacker can as well use entirely
passive methods to monitor network traffic. All they need, again, is a
laptop with a wireless card and slightly modified software to grab all the
wireless data � instead of ignoring any traffic not destined to their
computer.
Another largely unremarked problem is that of wandering wireless users. They
are likely to leave their wireless card in and operating, meaning an
attacker can set up a rogue wireless network to which the users attach
themselves. If the users then send any unencrypted data, or have open file
shares, for example, they potentially open themselves up for an attack.
Attackers can also set themselves up as servers on other legitimate
networks, and by running a rogue DHCP server redirect all traffic through
their machine or commit other attacks. Users will open themselves up to
monitoring of how much data they transfer, what kinds of data, when they
transfer it, and so on. If your network is not properly secured, people will
use it as a free ISP and likely commit illegal acts to gain access to the
Internet.
WEP Will Encrypt Everything
This is going to be the biggest problem with wireless networking. Once it is
up and running, people will be quite pleased with themselves and not likely
to spend real time or effort securing it. Since this form of networking is
new and not very well understood � not that much of networking is well
understood � administrators are likely to think, "well, it has 128-bit WEP
encryption, so we're secure." Unfortunately, it is very easy to set up a
network (wireless or otherwise) in such a manner that it works and data
moves happily between systems � but leave it insecure.
You can configure a wireless network to broadcast its name, or not. It's
probably wise not to broadcast, so that people are less like
DIDS - Distributed IDS Systems
Contact:http://www.packetnexus.com
==================================================
[DIDS - Distributed IDS Systems]
Creating the Ultimate Security Tools
**********************************
[red0x - Underground Labs]
[mixter - ]
Copyright (C) 2000 red0x, mixter
==================================================
/---------------Legend----------------\
| (?) = not sure if I'll include this |
| (V) = verify |
\-------------------------------------/
Prelim Outline:
A. Intro
1. What This is About
2. Terms
a. SPOF = [S]INGLE [P]OINT [O]F [F]AILURE
b. IDS
c. DIDS
d. Firewall
e. Topography
f. Router
g. Secure
h. Insecure
3. Linux
a. What
b. Why
c. Where
d. How Much (FREE)
B. Common IDS Methods
1. Tripwire
a. Pros
i. Detects File Changes
ii. Detects unauthorized users
iii. Can keep lists of users
iv. Can log commands
b. Cons
i. DDoS
ii. Annoying
iii. Dumb
iv. No Network Protection
v. SPOF (only on one host at a time)
2. Snort
1. Pros
i. Easily detects unauthorized connects
ii. Logs portscans
iii. Can block Backdoor attacks
iv. Blocks DDoS
v. Firewalls
2. Cons
i. Signature Files
ii. Promiscuous Mode
iii. DoS
iv. No file protection (tripwire style)
v. Hard to configure for Beginners
vi. SPOF
3. Firewalls
1. Pros
i. Block Services
ii. Block IP Ranges
iii. Secures entire network
iv. Transparent
2. Cons
i. Hard to configure
ii. Non-Dynamic (wont adapt, usually)
iii. Remotely Configurable (Hackable)
iv. Non-Transparent
v. Only on Your Router
vi. SPOF
vii. Firewalking
C. New/Rare Methods
1. Spider Nets [spidernet - mixter.void.ru]
1. Pros
i. Distributed Across Network
ii. Incoporates Tripwire Style IDS
iii. Central Logs
2. Cons
i. Weak as Standalone Security System
ii. Central Log Server is a SPOF
iii. User-Space Process
2. Ec
Subject: WLAN/ Response of WEP Security
Contact:http://www.packetnexus.com
Subject: WLAN/ Response of WEP Security
Importance: High
Response from the IEEE 802.11 Chair on WEP Security
Recent reports in the press have described the results of certain
research efforts directed towards determining the level of security
achievable with the Wired Equivalent Privacy algorithm in the IEEE
802.11 Wireless LAN standard. While much of the reporting has been
accurate, there have been some misconceptions on this topic that are now
spreading through the media. Befitting the importance of the issue, I am
inclined to make a response from the Chair to clarify these issues with
the following points:
1. Contrary to certain reports in the press, the development of WEP as
an integral part of the IEEE 802.11 standard was accomplished through a
completely open process. Like all IEEE 802 standards activities,
participation is open to all interested parties, and indeed the IEEE
802.11 committee has had a large and active membership.
2. The acronym WEP stands for Wired Equivalent Privacy, and from the
outset the goals for WEP have been clear, namely to provide an
equivalent level of privacy as is ordinarily present with a wired LAN.
Wired LANs such as IEEE 802.3 (Ethernet) are ordinarily protected by the
physical security mechanisms within a facility (such as controlled
entrances to a building), and the IEEE wired LAN standards do not
incorporate encryption. Wireless LANs are not necessarily protected by
physical security, and consequently to provide an equivalent level of
privacy it was decided to incorporate WEP encryption into the IEEE
802.11 standard. However, recognizing that the level of privacy afforded
by physical security in the wired LAN case is limited, the goals of WEP
are similarly limited. WEP is not intended to be a complete security
solution, but, just as with physical security in the wired LAN case,
should be supplemented with additional security mechanisms such as
access control, end-to-end encryption, password protections,
authentication, virtual private networks, and firewalls, whenever the
value of the data being protected justifies such concern.
3. Given the goals for Wired Equivalent Privacy, WEP has been, and
continues to be, a very effective deterrent against the vast majority of
attackers that might attempt to compromise the privacy of a wireless
LAN, ranging from casual snoopers to sophisticated hackers armed with
substantial money and resources.
4. The active attacks on WEP reported recently in the press are not
simple to mount. They are attacks, which could conceivably be mounted
given enough time and money. The attacks in fact appear to require
considerable development resources and computer power. It is not clear
at all whether the payoff to the attacker after marshalling the
resources to mount such an attack would necessarily justify the expense
of the attack, particularly given the presence of cheaper and simpler
alternative attacks on the physical security of a facility. Key
management systems also reduce the window of these attacks succeeding.
5. In an enterprise or other large installation, the complete set of
security mechanisms typically employed in addition to WEP would make
even a successful attack on WEP of marginal value to the attacker.
6. In a home environment, the likelihood of such an attack being mounted
is probably negligible, given the cost of the attack versus the typical
value of the stolen data.
7. IEEE 802.11 is currently working on extensions to WEP for
incorporation within a future version of the standard. This work was
initiated in July 1999 as Task Group E, with the specific
How Computer Criminals Defeat Intrusion Detection Systems
Contact:http://www.packetnexus.com
How Computer Criminals Defeat Intrusion Detection Systems
by Carolyn Meinel
We covered "The ABCs of Intrusion Detection Systems (IDSs)" in a previous
column. Now we get to the really, truly, scary part: how computer criminals
defeat IDSs, and how to fight back.
The wily attacker may be able to slip undetected into your network via the
following techniques:
Incomplete IDS coverage
Lost or unknown network elements
An overwhelmed IDS
Excessive false positives (crying "wolf" too many times)
Unicode protocols disguising signatures
Fragmented packets
The 0-day problem
Highly switched networks
Compromise of the IDS itself
An improperly configured IDS
The unique challenges of the middleware environment
Incomplete IDS Coverage
One IDS sitting on top of your connection to the Internet is going to miss
internal attacks. It also may not detect attacks against systems it is not
designed to defend. You probably will need to use products from more than
one vendor, and use both a network IDS (NIDS) and a host-based IDS (HIDS).
There also may be portions of attacks that no IDS can monitor, except by
observing traffic once it enters the more standard portions of your network.
This vulnerability may be a blessing in disguise if it motivates management
to modernize your network.
In the meantime, any decent IDS in a middleware environment will require
products from many vendors. So how do you coordinate the output from these
systems?
"Let me give you the honest answer," offers Marcus J. Ranum of Network
Flight Recorder (NFR). "There's not a lot of cooperation in the security
products industry. Most vendors would rather have their customers use only
one product than support gateways between two products.
"Right now," he continues, "most IDS users that have several systems make
them all e-mail their alerts to one place, and then they process the alerts
together. There is a market evolving for systems to do alert correlation. I
predict that market will grow rapidly soon. NFR's actually looking to break
that model with some very unique stuff. I can't talk about it, sorry, but
pay attention around April."
The Intrusion.com NIDS is expected to soon include the ability to aggregate
input from Netranger, RealSecure and Firewall-1.
And according to the hacker known as Talisker on the Networkintrusion.com
Web site: "The fact that they are from differing vendors is immaterial; they
have such different roles. From experience, I don't like HIDS [hybrid IDS]
and NIDS output on the same console, the only exception being possibly
router output with the NIDS. There is very little correlation between the
two--98 percent of the HIDS traffic is by trusted internal users doing
things they shouldn't. NIDS output is cluttered with false positives, but
when you get a real bite, it's usually a good one."
Lost or Unknown Network Elements
You can't fully protect what you don't know exists. Large, complex systems
often change every day, sometimes in unexpected ways. One company recently
discovered that modem abuse was consuming the equivalent of several T3s of
bandwidth on its PBX. It discovered employees sneaking in external modems to
evade firewall bans on Napster, porn, stock trading and sports sites. (To
learn more about the hazards of modems, see "It's 2 a.m.: Do You Know Where
Your Modems Are?"
Computer criminals also look for orphan computers. A busy sysadmin (and most
are always too busy) may set up a test server and then leave it on the wire.
Once forgotten, it doesn't receive critical security updates.
To make sure your IDS covers e
The ABCs of IDSs (Intrusion Detection Systems)
Contact:http://www.packetnexus.com
The ABCs of IDSs (Intrusion Detection Systems)
by Carolyn Meinel
You have the world's best firewall, your Windows computers update their
antivirus software regularly and your Information Security staffers enforce
your policies with an iron fist. Does this mean you're safe?
Maybe not. In 1998, a news story asserted that the firewall for the New York
Times was one of the best. Yet at 7:08 a.m. on Sunday, Sept. 13, 1998,
someone on the paper's network e-mailed reporters:
...COM3 V1S1T HTTP://WWW.NYTIMES.COM AND S33 0UR LAT3ST P13C3 0F ART. 1F 1T
D0ESN'T L0AD, JUST H1T 'REL0AD' A F3W T1MES. CL3V3R ADMINZ HAD S0M3 W3IRD
CR0NTABZ OR S0METHING.
0H. W3 0WN YOU. Y0U JUST HAV3NT N0T1C3D US 0N Y3R N3TW0RK Y3T. UNT1L THE
N3XT T1M3...
No one at the Times had noticed weeks worth of the Hacking for Girliez gang
on their network. The intruders finally chose to go public by defacing the
opening page of their Web site�on the day the Times expected millions of
visitors to view the Monica Lewinsky transcripts. Instead, visitors
encountered soft porn and an ad for Lewinsky-scented cigars.
Thanks to a cron job (that is, a Unix job that schedules events), several
attempts to eliminate the offensive index page failed, exposing yet more
thousands of patrons to the Girliez' exploit. It took almost two weeks to
eradicate the intruders' back doors from the New York Times' network. Damage
was estimated at $1.5 million, and a grand jury is currently hearing
testimony in the case.
All this might have been avoided had the Times been running a good enough
intrusion detection system (IDS).
What Is an Intrusion Detection System?
Intrusions fall into two major classes. Misuse intrusions are attacks on
known weak points of a system. An IDS looks for this type of attack by
comparing network traffic with signatures of known attacks. The second
class, anomaly intrusions, consists of unknown attacks and other anomalous
activity. This may include detection of an intruder who is already inside a
network. Anomaly detection is hardly a plug-and-play function. It requires
an intimate knowledge of one's network and patterns of user behavior, and an
IDS with powerful scripting options.
The basic function of an IDS is to record signs of intruders at work inside
and to give alerts. Depending on the product, how it is deployed and its
network configuration, an IDS may only scan for attacks coming from outside
one's network or it may also monitor activities inside the network.
Some also look for anomaly intrusions. This requires an IDS that can be
extensively configured by the user to match the peculiarities of the network
to be defended. When Susie the systems administrator is at work at 2 a.m.,
this may be her normal behavior. But when Artie the administrative assistant
logs on to his workstation at 2 a.m., that is most likely an anomaly. An IDS
that detects anomalies must be scripted to tell the difference between the
two log-ons.
In the New York Times case, the intruders installed a number of "root kits"
to hide themselves and open back doors. An installation process like this
may be detected as an anomaly�if one can set up an IDS to tell the
difference between installing a root kit and a legitimate program.
An IDS may include a feature to take automatic action when certain
conditions occur, for example to page the systems administrator on call.
Many IDSs are flexible enough that one can configure them to launch
automatic attacks against suspected intruders, such as denial-of-service
attacks. In many situations, this is illegal and inadvi
Protecting Network Infrastructure at the Protocol Level
Contact:http://www.packetnexus.com
Protecting Network Infrastructure at the Protocol Level
V1.0. Curt Wilson, Netw3.com Consulting. 12/15/00
This paper is posted in the Netw3.com security reading room and can be
found along with other security documents at
http://www.netw3.com/documents.html
Scope of paper
This paper will briefly discuss attacks and attack prevention methods
for network infrastructure protocols. Particular focus will be given to
router and routing protocol vulnerabilities such as Routing Information
Protocol (RIP), Border Gateway Protocol (BGP), Open Shortest Path First
(OSPF), and others.
Routers perform a critical function for each network and if a router is
compromised or a route is successfully spoofed, network integrity can be
seriously damaged especially if hosts are not using encrypted
communications channels. The potential for data manipulation through
man-in-the-middle attacks, denial of service, data loss, disruption of
network integrity, and packet sniffing is great. Security mechanisms are
often available, but are commonly not used because attacks on routing
protocols have been rare. Due to the lack of hard data on actual
incidents, some approaches outlined in this paper will be theoretical in
nature.
Routing is a huge and complex topic; therefore this document will be
updated and corrected as I continue my research. Note that I am not a
routing engineer and would be glad to accept corrections to any
information contained herein.
Commonly known router security issues
Various types of routers have well-known security issues. A collection
of some of the commonly known vulnerabilities for network infrastructure
equipment vendors such as Cisco, Livingston, Bay and others, can be
found at
http://www.antionline.com/cgi-bin/anticode/anticode.pl?dir=router-exploi
ts. Most of these vulnerabilities are non routing-protocol level attacks
that rely on misconfiguration, bugs in IP packet handling, SNMP
insecurities such as default community name strings, weak password or
weak password encryption, DOS conditions due to bad IP/UDP packets, etc.
These types of attacks are commonly known, and a standard NIDS should be
able to be programmed to detect these, at least on an IP based network.
IDS are still in the emerging stages as far as non-TCP/IP based routing
protocols are concerned. Any of these types of attacks can weaken a
network infrastructure and could be used in combination with
higher-level protocol-based attacks.
Proper configuration management can resolve many of these common
vulnerabilities. This would involve standard procedures such as not
using SNMP (or choosing strong passwords/encryption), keeping up to date
with vendor patches, proper use of access lists, ingress/egress
filtering, firewalls, encrypted management channels and passwords, route
filtering, and use of MD5 authentication. However, to understand and
implement these security procedures, network engineers must be given the
time and training to understand the security implications of their work
Recent Developments in Infrastructure Defense
A recent development in network defense comes in an IDS called JiNao,
which can be found at http://www.anr.mcnc.org/projects/JiNao/JiNao.html.
JiNao is funded by DARPA and is currently in development as a joint
research project between MCNC and North Carolina State University.
Intrusion Detection-- Fun with Packets: Designing a Stick
Contact:http://www.packetnexus.com
Fun with Packets:
Designing a Stick
By Coretez Giovanni
This paper outlines a denial-of-service attack against not the computer
network, but the human processes that support intrusion detection. This
attack is a resource exhaustion attack as outlined in the previous paper
"Topology of denial of service".
It is informally written to express my opinion by which the tool "stick"
was written to exploit. Hopefully this tool clearly shows some IDS flaws
that will soon be remedied by better IDS products. Arthur Money spoke at
Blackhat '00 about quality. Too bad there must not have been any
software developers there to listen.
I use Stick and other self-developed tools for evaluating stress
capability of IDS and firewalls. At this time I do not have
comprehensive listing of IDS that are unaffected by the preceding
methodology that can be implemented using the Stick code.
I am not endorsing any products in this paper. This paper and tool are
opinion and should be treated as such. There are two IDS that I found
checked the state before payload alarm which is essential for defending
against Stick, but these systems did not detected other header attacks
nor were they robust enough to detect a good deal of other attacks.
If my home lab ever gets big enough I might be able to give a fair
unbiased opinion. Until then, you should evaluate and consider this
opinion with your own opinion and testing (as you always should do).
Designing of the Attack
People are the essential element in intrusion detection. Automated
responses are rare due to self induced denial-of-service . Alarms are
sorted in priority and are reviewed and summarized for response.
Organizations hire just enough, people as to accomplish handling a
normal load of alarms.
Therefore, when a high number of false alarms are produced, finding the
actual attack becomes impossible due to the lack of resources to
investigate actual from spoofed attacks. When a high number of false
alarms occur, the shear number of alarms makes the alarm data useless in
informing the decision makers of the real status of the network. This is
a form of information overload.
The key of course is to create a high number of alarms that will trigger
the system/network intrusion logs.
Create An Alarm
The easiest system to create alarms on is signature based intrusion
detection systems (IDS). I will refer to IDS, in particular I mean
network based IDS.
Signature based IDS use a predetermined criteria in order to determine
bad from good. The three most common attributes in signatures are IP
packet header fields, transport layer header fields and packet data
payload. If the attributes to set off the criteria for these three
sections are known, a trigger packet can be created.
Stateless Analysis
For reasons of speed and processing power, a packet is often evaluated
on its own individual merit regardless of other packets on the network.
This is seen in many early detectors like "Shadow" and exists in most
commercial detectors. It is a primary concern to most IDS companies and
a common measure of quality when evaluated by the media.
A design based on speed most likely means that a trigger packet needs no
precursor event or post event in order for the trigger packet to set off
an alarm.
Triggering an alarm purposefully is not something the designers think
about much. Designers do care about false-positives (bad alarms), but
false-positives are considered in the context of normal traffic, and
that these alarms can be filtered out in time.
Validity
The first weakness that an
Realistic Expectations for Intrusion Detection Systems
Contact:http://www.packetnexus.com
This is a multi-part message in MIME format.
------_=_NextPart_001_01C0B0C1.C890F940
Content-Type: multipart/alternative;
boundary="----_=_NextPart_002_01C0B0C1.C890F940"
------_=_NextPart_002_01C0B0C1.C890F940
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Realistic Expectations for Intrusion Detection Systems=20
by Richard Wiens =20
last updated March 19, 2001=20
Intrusion detection forms an increasingly important segment of the
security technology market. While intrusion detection systems were,
until recently, both expensive and difficult to maintain, they have
become more affordable. With the arrival of less expensive off-the-shelf
solutions, IDSs are becoming a more common feature of security regimens.
The emergence of IDSs causes some security commentators to see them as a
panacea, solving all of the complex and diverse threats to network
security. However, as does any weapon in the security arsenal, an IDS
has limited capabilities. To expect too much of an IDS places the user's
network at risk. This article will discuss reasonable expectations of
Intrusion Detection Systems (IDSs). Its purpose is to help users and
potential users realize the increasing importance of intrusion detection
in all organizations, while also pointing out the realistic outcomes to
be expected from current IDS products. The discussion will also discuss
future trends in IDS development.=20
Realistic Expectations of Intrusion Detection Systems=20
Intrusion detection is considered by many to be the logical complement
to network firewalls, thus extending the security management
capabilities of system administrators to include security audit,
monitoring, attack recognition and response. The following real-world
examples point up the concrete tasks that IDSs can be expected to
perform efficiently, ensuring increased real security protection.=20
IDSs monitor the Internet to detect possible attacks=20
Monitoring the Internet for potential attack is both time-consuming and
tedious. By performing the ongoing task of monitoring the Internet to
detect possible attacks, intrusion detection systems allow security
personnel to accomplish other essential security functions. However, IDS
vendors include extensive attack signature databases against which they
match information from the user's system. Vendors have expert staffs
that monitor the Internet and other sources for new attack tools and
techniques. They then use this information to develop new signatures
that are provided to customers, thereby enabling network administrators
to keep up-to-date without expending valuable time and monetary
resources.=20
IDSs help organizations to develop and implement an effective security
policy.=20
Many intrusion detection systems offer security policy tools that help
to define and implement the security policy of the organization. All
organizations should have a security policy in place. This policy should
clearly dictate from the CEO level the security priorities of the
organization and define a procedure for what happens when an intrusion
is suspected. An effective security policy should consider the
following: operating systems, services (web servers, e-mail servers, and
databases), network IDSs, firewalls, and the network management platform
(such as OpenView). IDSs should be included as part of the overall
security policy of an organization: they help to enforce the security
policy by detecting prohibited traffic and/or activities, and they play
an active role
Is Network Intrusion Detection Software Being Used Correctly?
Contact:http://www.packetnexus.com
Viewpoint
Is Network Intrusion Detection Software Being Used Correctly?
By Marcus J. Ranum
------------------------------------------------------------------------
--------
It's early Sunday morning and the network manager is sleeping at home. A
stealth hacker program is unfolding itself behind the company's
firewall, preparing to open a path into the network. Immediately, the
network manager's pager is activated: "Attack in progress!"
Within minutes, the network manager has logged in over a secure link,
accessed the company's intrusion detection system, and obtained complete
details of the origin and nature of the attack. After a few quick phone
calls, the penetration is blocked, and law enforcement agents will soon
be knocking on the hacker's front door.
Sounds great, doesn't it? Unfortunately, the reality of network
intrusion detection and response doesn't even come close to this
hypothetical scenario. For one thing, most intrusion detection
systems--software and hardware components that detect incursions into a
network--cannot trace an attacker back to his or her point of origin.
Yet many network managers are purchasing intrusion detection systems
anyway. Are they getting their money's worth? Are their networks any
safer? The evidence suggests that the answer is no to both questions,
but that need not be the case.
IDS type.
Researchers have been working on intrusion detection systems for a long
time without achieving what could be called a major breakthrough.
Currently, users have two choices: anomaly detection and misuse
detection. But each has serious limitations.
Anomaly detection. The usual line of research focuses on what is called
the anomaly detection intrusion detection system (AD-IDS). An AD-IDS
"learns" what constitutes normal network traffic, developing sets of
models that are updated over time. These models are applied against new
traffic. Traffic that doesn't match the normal model is flagged as
suspicious.
These systems are attractive conceptually, but it is hard to create a
reliable model for normal traffic. As networks grow, the mix of
applications becomes so complex that traffic looks random. A patient
hacker may even generate his or her own traffic to generate a distorted
model of normal so that, sooner or later, an attack may look normal and
get past the IDS. On the other hand, if the IDS is set up with a narrow
definition of normal, the system will generate large numbers of false
positives, and the IDS will be ignored.
Much research is still being done on AD-IDS, but for now these systems
are not the answer.
Misuse detection. Many companies offer an easier to operate form of IDS
called misuse detection intrusion detection systems (MD-IDS). The MD-IDS
resembles a virus scanner attached to a network. It is usually
programmed with signature sets representing the types of connections and
traffic that indicate a particular attack. Other forms of these systems
rely on host platform information, such as C2 audit logs (which record
information such as file accesses), to detect patterns of suspicious
activity.
These systems are fast and don't generate false positives because they
"understand" what attacks look like. But, like virus scanners, MD-IDSs
cannot detect something that the network manager doesn't know about--the
type of attack the network manager most wants to detect. For an MD-IDS
to be useful, its signature sets must be constantly updated. Even so,
the network will still be vulnerable to new attacks.
It is also distressingly easy f
Protecting Critical Systems in Unbounded Networks
Contact:http://www.packetnexus.com
Protecting Critical Systems in Unbounded Networks
Robert J. Ellison, David A. Fisher,
Richard C. Linger, Howard F. Lipson,
Thomas A. Longstaff, Nancy R. Mead
Society is growing increasingly dependent on large-scale, highly
distributed systems that operate in unbounded network environments.
Unbounded networks, such as the Internet, have no central administrative
control and no unified security policy. Furthermore, the number and
nature of the nodes connected to such networks cannot be fully known.
Despite the best efforts of security practitioners, no amount of
hardening can assure that a system that is connected to an unbounded
network will be invulnerable to attack. The discipline of survivability
can help ensure that such systems can deliver essential services and
maintain essential properties such as integrity, confidentiality, and
performance, despite the presence of intrusions.
The New Network Paradigm:
Organizational Integration
From their modest beginnings some 20 years ago, computer networks have
become a critical element of modern society. These networks not only
have global reach; they also affect virtually every aspect of human
endeavor. Networked systems are principal enabling agents in business,
industry, government, and defense. Major economic sectors, including
defense, energy, transportation, telecommunications, manufacturing,
financial services, health care, and education, all depend on a vast
array of networks operating on local, national, and global scales. This
pervasive societal dependence on networks magnifies the consequences of
intrusions, accidents, and failures, and amplifies the critical
importance of ensuring network survivability.
A new network paradigm is emerging. Networks are being used to achieve
radical new levels of organizational integration. This integration
obliterates traditional organizational boundaries and integrates local
operations into components of comprehensive, network-based business
processes. For example, commercial organizations are integrating
operations with business units, suppliers, and customers through
large-scale networks that enhance communication and services. These
networks combine previously fragmented operations into coherent
processes open to many organizational participants. This new paradigm
represents a shift from bounded networks with central control to
unbounded networks.
Unbounded networks are characterized by distributed administrative
control without central authority, limited visibility beyond the
boundaries of local administration, and a lack of complete information
about the entire network. At the same time, organizations' dependence on
networks is increasing, and the risks and consequences of intrusions and
compromises are amplified.
The Internet is an example of an unbounded environment with many
client-server network applications. A public Web server and its clients
may exist within many different administrative domains on the Internet.
Many business-to-business Web-based e-commerce applications depend on
conventions within a specific industry segment for interoperability.
Within the Internet, there is little distinction between insiders and
outsiders. Everyone who chooses to connect to the Internet is an
insider, whether or not they are known to a particular subsystem. This
characteristic is the result of the desire, and modern necessity, for
connectivity. A company cannot survive in a highly competitive industry
without easy and rapid access to its customers, suppliers, and partners.
More and more, a company's partners on one pr
Experts ponder securing the wireless world
Contact:http://www.packetnexus.com
Experts ponder securing the wireless world
April 13, 2001
Web posted at: 10:23 a.m. EDT (1423 GMT)
By Cameron Crouch
SAN FRANCISCO, California (IDG) -- As security experts watch the
airwaves get crowded with wireless transmissions of voice and data, they
see their field becoming more vital -- and complicated, in this world of
mixed network protocols.
Unlike the Internet, which uses only a handful of standard protocols,
the wireless world is built on many disparate protocols that don't
necessarily work together at all. This lack of standards complicates the
security of wireless networks, which discourages their wider adoption.
Effective security requires widely accepted standards, agree security
gurus and vendors at the RSA Conference here this week. Discussion at
the gathering has tackled proposed new protocols, algorithms, and
networks for both the wired and wireless worlds.
While still in their infancy, wireless broadband and other forms of
wireless networking, including home LANs, show great promise as an
alternative to wired services used by businesses and home users. But
unless the security of those networks can be assured, the young industry
could be stillborn, the security experts warn.
To protect you, these networks will have to incorporate new security
protocols and algorithms as well as some existing methods found on the
wired Internet. But agreeing on which standards to adopt may be as big a
challenge as getting the high-speed services out the door.
New toys raise risks
"Modern expectations of the Internet include [service that's] always on,
handy, and immediate as well as secure," says Shawn Abbot, president of
IVEA Technologies, a developer of security infrastructure products for
e-commerce. "But the challenge of these connected personal devices is
that they put more personal data into cyberspace, raising the threat to
privacy."
The most dire risks include forms of identity theft. Someone might learn
and misuse your personal information through eavesdropping or
information tapping, Abbot says.
Also, marketers are eager for the opportunities offered by global
positioning functions, which could let them target ads or services based
on your location. But "location-based services only magnify these
threats, increasing the need for trust from consumers," Abbot adds.
Current networks won't do
Today's mobile phone and paging networks -- used for wireless devices --
weren't really designed to meet the security needs of transactions,
corporate communications, and network-based personal profiles, the
experts agree.
The traditional mobile phone network has limited security, says Yiquin
Lisa Yin, research leader at NTT DoCoMo's Multimedia Communications
Labs. "The proprietary protocols and algorithms only provide security
for the air interface and not the whole network," Yin says.
The air interface in traditional cell phone networks includes the
traffic between the handset and the cellular base station, Yin says.
Then, the base station connects to a core network for the carrier, often
with little security between them, she adds.
On the reverse end, Internet data connects to the core network through a
wireless application protocol gateway. There, it is temporarily
decrypted and then re-encrypted in a mobile-phone-friendly format, Yin
says.
That WAP gap isn't a big deal for simple applications, but it's becoming
more important with transaction services, Abbot agrees.
But Yin urges security improvements not for the gateway, but for every
link in the network. She says security in traditional networks is
802.11 and swiss cheese
Contact:http://www.packetnexus.com
802.11 and swiss cheese
By Stephan Somogyi,
April 16, 2001
URL:
http://www.zdnetasia.com/biztech/security/story/0,2000010816,20196487,00
.htm
There is no doubt that 802.11b - the technical name for products also
known as AirPort, Orinoco, Aironet, et al- is a life-changing
technology.
All of a sudden companies don't have to string as many cables through
their offices to provide connectivity. Small offices, home offices, and
even just plain homes, are all beneficiaries as well, since you can set
up an access point somewhere in the house, ideally hidden from plain
sight, and still engage in e-mail and wander around the Web.
YES
The problem is that, unlike a piece of cable that you have to get
physical access to in order to connect, it's comparatively easy to get
near enough to a wireless access point to get good signal strength. Say,
in a caf� across the street.
OK, but just because you're in the radio footprint of an access point
doesn't mean you can do anything useful with that wireless network,
right? Well, maybe.
Placebo
Even the most user-friendly access points come with basic security
facilities. These security features give the appearance of protecting a
wireless network in two ways: making the traffic that flies through the
ether undecipherable by outsiders and making the access point, well,
inaccessible to anyone unauthorized.
The encryption part is accomplished by defining a password that the
access point and all its clients share. One known weakness is that the
encryption scheme--called WEP--uses a key length of 40 bits, so it's
well behind the state of the art. However, I wouldn't be nearly so
perturbed if one really needed to brute force attack the full key
length. One doesn't.
But wait, there's more. It also turns out that the parts of 802.11's
security not related to encryption are also flawed and can be
compromised. In short, even if you put all three available security
mechanisms--WEP encryption, MAC-based access control, and closed
networks--a smart and determined evildoer can still compromise your
network.
At least as far back as last October, the IEEE 802.11 committee knew
about the security flaws in 802.11 and was starting work to fix them.
Earlier this year, researchers with the Isaac project at UC Berkeley
publicized quite a few problems with WEP. Upon reviewing this work and
the design of 802.11's security, respected Bell Labs security researcher
Steven Bellovin was quoted in the Wall Street Journal on February 5th as
saying that there were some "real howlers" in the design.
WECA, the Wireless Ethernet Compatibility Alliance, promptly issued a
formal response after the Berkeley researchers announced their findings.
Unfortunately, this response evoked little more than the lightbulb joke
whose punchline is "none--they redefine darkness as the standard." The
response spent more time focusing on semantic quibbles and how hard it
is to perform the attacks than admitting there were fundamental flaws in
the protocol in the first place.
Adding to the UC Berkeley findings, a group of researchers at the
University of Maryland published a paper of their own outlining even
more vulnerabilities in 802.11.
Both the quality and quantity of examination of 802.11's security leaves
little doubt about its significant shortcomings.
It's worth pointing out these many vulnerabilities that make 802.11's
security reminiscent of swiss cheese are manageable now that they're
understood. There can no longer be any false sense of security.
It requires a determined attacker to put si
Fortress Strengthens Wired Equivalent Privacy
Contact:http://www.packetnexus.com
Windows IT Security News / Mark Joseph Edwards / April 18, 2001
Fortress Strengthens Wired Equivalent Privacy
http://www.ntsecurity.net/Articles/Index.cfm?ArticleID=20706
Article Information
InstantDoc ID: 20706
To strengthen known weaknesses in the Wired Equivalent Privacy (WEP)
protocol used in the 802.11b wireless network standard, Fortress
Technologies has released a new Layer 2 protocol called Wireless Link
Layer Security (wLLS). The new protocol provides secure frame and packet
transmissions by automating critical security operations, including
encryption, authentication, data integrity-checking, key exchange, and
data compression. Fortress based wLLS on techniques it uses in its
patented Secure Packet Shield (SPS) technology.
WEP provides basic security mechanisms to help protect data as it
travels across the radio waves. The protocol also provides
authentication to help prevent unauthorized access to the network from
rogue wireless devices. In February 2001, we reported that scientists at
the University of California, Berkeley, released a report detailing
several security problems in the WEP protocol. In April 2001, we also
reported that researchers at the University of Maryland's Department of
Computer Science had discovered three more security risks in the
protocol. Fortress' new wLLS protocol resolves all of the WEP-related
vulnerability issues reported to date and could help prevent similar
risks in the future.
In March 2001, Microsoft announced that Windows XP will support the new
802.1x wireless network standard (see our report Windows XP to Support
802.1x Wireless Network Standard, Windows IT Security News, March 27,
2001). The 802.1x standard defines port-based network access control for
wireless networks. John Dow, vice president of marketing and corporate
development for Fortress Technologies, said that wLLS complements 802.1x
and that Fortress intends to work with Microsoft to ensure seamless
integration of the two technologies. "We are excited to introduce our
solution to wireless equipment providers and, based on initial feedback,
we are confident that they recognize the immediate benefit wLLS would
offer their customers." Fortress will license the wLLS protocol to
wireless LAN equipment makers.
Back to the Index
Your 802.11 Wireless Network has No Clothes
Contact:http://www.packetnexus.com
http://www.cs.umd.edu/~waa/wireless.pdf
Abstract
The explosive growth in wireless networks over the last few years
resembles the rapid growth of the Internet within the last decade. Dur-
ing the beginning of the commercialization of the Internet, organiza-
tions and individuals connected without concern for the security of
their system or network. Over time, it became apparent that some
form of security was required to prevent outsiders from exploiting the
connected resources. To protect the internal resources, organizations
usually purchased and installed an Internet firewall.
We believe that the current wireless access points present a larger
security problem than the early Internet connections. A large number
of organizations, based on vendor literature, believe that the security
provided by their deployed wireless access points is sufficient to
pre-vent
unauthorized access and use. Unfortunately, nothing could be
further from the truth. While the current access points provide sev-
eral security mechanisms, our work combined with the work of others
show that ALL of these mechanisms are completely in-effective. As a
result, organizations with deployed wireless networks are vulnerable to
unauthorized use of, and access to, their internal infrastructure.
Back to the Index
Network Security: What are you waiting for?
Contact:[email protected]
http://www.securityfocus.com/templates/forum_message.html?forum=2&head=5560&
id=5560
Network Security: What are you waiting for?
by Daniel Tatone ([email protected]
)
Mon May 07 2001
The field of computer Security is basically one big horror story after
another. Major attacks are continuously being identified on the media:
In early 2000,Yahoo, eBay, and CNN were victims of denial of service attacks
launched by �Mafiaboy�
CNN � October 27th, 2000: Hackers have broken into Microsoft's computer
network in what the company has described as "a deplorable act of industrial
espionage."
Trend Micro � May 18, 2000: Major Virus Outbreak Alert from Trend Micro �
VBS_LOVELETTER Hits Users Worldwide The �love bug� caused billions of
dollars of damage worldwide.
With the advent of high-speed Internet access, and the massive underground
�hacker� community that has developed in cyberspace, organizations and
companies put their image (websites) and their data (confidential
information) at high risk when establishing a connection to the Internet
that is not securely implemented.
Attrition.org reported a record 1542 website defacements for the month of
April 2001, mostly due to the �Cyber-War� currently on the go between China
and the United States. That more than quadruples the number of defacements
in April 2000, and is up 570% from the reported defacements in April 1999.
Do you see a trend?
Internet Security breaches are on the rise, and most companies are virtually
unaware of the trend or are portraying the �Ostrich Syndrome� (sticking
their heads in the sand) and avoiding the issue altogether, thinking: �that
won�t happen to me, why would someone want to attack me�my presence on the
Internet is minimal�. But from a Hacker\�s perspective it is easier to
attack a small/medium size business who has a mistakenly connected their
backbone directly onto the Internet with no firewall or means of access
control rather than a government agency or large firm (the �big boys� like
Microsoft or Cisco) who have invested a large amount of resources in
securing their infrastructure. Once a small/medium business has been
compromised the attacker could then launch attacks anonymously against the
�Big boys� from there.
There are principally three types of attackers: The first we will discuss is
the Amateur Hacker also known as a �cracker�. Crackers have developed an
underground community often comprised of young individuals in their teens
known as �Script Kiddies�. These Script Kiddies pride themselves on their
web defacements, denial of service attacks (as seen against Yahoo and eBay
in January 2000) and system breaches. They usually do not understand the
technical details behind the attacks that they perform; they rather collect
and rely on already made hacker tools and scripts to perform their system
breaches. They usually sign their �Hacker Alias� or �Hacker Group� on the
website they deface, greet their fellow hackers, dismiss their �rivals� in
the hacker community and occasionally post a political message. Often the
messages left on the defaced site include comments to the administrator of
the site, indicating that no �real� damage has been inflicted on the system
and a backup of the original web page is available. By not actually deleting
any information they assume it is merely a prank showing their �hacking�
ability. However, what they do not realize is that the defacement costs the
victim companies unavailability and downtime, lead
Postfix as a bastion SMTP gateway
Home: www.packetnexus.com
How-To configure Postfix as a bastion SMTP mail gateway
A common problem with SMTP daemons today is their lack of security. Postfix
was built with security in mind and in my opinion, should replace Sendmail
where possible. This How-To will show you how to configure Postfix on a
machine so that it relays mail for example.com to a mail server on the
internal network. It is very easy to install a linux box just to handle mail
to and from the Internet and you can use your own mail server software (MS
Exchange, Notes, etc.) on your internal server. This How-To refers to the
most recent version of postfix.
First thing to do is create a user named postfix. We will need to set the
shell for this user to false so it can't login.
useradd -c "postfix user account" -s /bin/false postfix
This user account will be used by postfix for all actions, except binding to
port 25, for that it needs root. One of the big security problems with
sendmail is that everything runs as root, so any exploits give the attacker
root access. Postfix is several small programs that work together....and
they don't run as root.
Next, get postfix from www.postfix.org
Untar it
tar -xvzf postfixXXXXX.tar.gz
Next, cd into the postfix directory and type make
Then run make install.
A script will automatically be run after the install and it will prompt you
for some input, the defaults should be good.
Something that I found when I installed postfix over an existing sendmail
install, was the main.cf was pointing to /etc/aliases for the aliases file.
It needs to be pointing to the /etc/postfix/aliases file. Double check to
make sure yours is correct. Reality is, that it doesn't matter, I just
prefer to have all the config files in the /etc/postfix directory. You might
want to delete or rename the unused aliases file.
Now, let's edit some files so our postfix install just acts as a gateway and
forwards mail to our internal mail server. Postfix can be used as an SMTP
server right after install, if you had a POP3 server running you caould use
it as your mail server. I run Exchange internally so this install needs to
just relay mail.
Postfix files exist in /etc/postfix
Make the following changes to route mail to an internal host and NOT to the
local machine. Don't include the comments in parentheses.
/etc/postfix/main.cf:
mydestination = (so no mail is routed to the localhost)
relay_domains = example.com (so mail is relayed to your domain)
transport_maps = hash:/etc/postfix/transport
/etc/postfix/transport:
my.domain smtp:internalhost.example.com (forwards user@domain)
.my.domain smtp:internalhost.example.com (forwards user@firewall)
/etc/postfix/master.cf:
Comment out the local delivery agent (so no mail is delivered locally)
That line is the similar to the one below
# local unix - n n - - local
Execute the following command whenever you change the transport table.
postmap /etc/postfix/transport
Execute the following command after a configuration change.
postfix reload
That is it, now test it out. I usually do the following to test things out.
tail -f /var/log/maillog - this command will open the log file and actively
update it so you can see what is happening.
Use an external mail account to send mail. Watch for when the external
server connects, you should see status=sent somewhere in the log. If not, it
is time to troubleshoot.
I have a few things below that may help with other configs.
Ok, so now you want this box to also relay other domains. It is easy.
Postfix supports virtual domains. Make