信息来源：iceev
by red0x - Underground Labs; 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. Echelon [e4d - mixter.void.ru]
1. Pros
i. Sniffs ALL Traffic for Sensitive Data
ii. Central Logs
iii. Non PROMISC Sniffer
2. Cons
i. Reactive, takes no action, just logs
ii. Data to be sniffed for can be reversed out of the code.
iii. Central Log Server is a SPOF
iv. Non PROMISC Sniffer
v. Unencrypted Logs
vi. User-Space Process
3. Heuristics Scanning [ewatch -
http://www.eecs.harvard.edu/~rtm/README-ewatch.html ]
1. Pros
i. Scans ALL Traffic
ii. `Learns' to recognize traffic
iii. Recognizes `bad' traffic
iv. Logs `bad' traffic
2. Cons
i. Takes a while to learn (your network must be secured) (V)
ii. No Protection (Firewalling)
iii. User-Space
iv. Annoying
v. Local, SPOF (kill -KILL pid)
D. Designing a Good System
1. What to Avoid
i. Single Point of Failure (SPOF)
ii. Central Log/Config Servers
iii. Self/Net-DoS/DDoS
iv. Raw Logs
v. User Space Processes, if possible
vi. Plain-Text Net Traffic, always
vii. setuid, setgid executables, if possible
2. What to Include
i. Possibility to Distribute (DIDS)
ii. Good Topography
iii. Good IP Logging
iv. Encryption of Logs
v. Encryption of Net Traffic
vi. PROMISC/RAWSOCKS Capability
vii. Intelligence, if possible
viii. Heuristics
ix. Firewalling
x. Tripwire Style IDS
xi. Inter-Agent Communcations
xii. Host Disconnection
xiii. Anti-DoS/DDoS/Flooding
E. Enter Agents
1. What is DDIS? (Agents)
2. Why DDIS? (Agents)
i. Pros
a. No Single Point of Failure (Distributed)
b. Hard to beat
c. Adaptive
d. Insecure Host Disconnection
e. Tripwire Style IDS
f. Spider Net Style NIDS
g. Firewalling
ii. Cons
a. User Space
b. Static Code
c. Not too Intelligent
d. Spoofing (?)
e. Slow Probe Intervals (?)
F. Conclusion: What to expect from distributed IDS (DIDS)
1. Is DIDS Better Than Any Other IDS For My Network
i. Topography
a. Ring
b. Star, Star^n
c. Backbone
d. Others (?)
ii. OS
a. Linux (see terms section for more info)
2. How Is It Better?
i. Pros
a. Distributed Across All Hosts (No SPOF)
b. Encrypted Net Traffic
c. Encrypted Logs on All Hosts (NO SPOF)
d. PROMISC/RAWSOCKS Capability
e. IDS and Inter IDS Communications
f. Heuristics
g. Good Logs
ii. Cons
a. User Space
b. Static Code
c. Sniffable
d. setuid/gid (?)
e. PROMISC in Star Topography on unswitched Networks
3. Where Can I Get a Taste of DIDS?
i. Free Agents NIDS [sourceforge.net/projects/freeagent]
ii. Agents [december Scientific American, "Red Team versus the Agents"]
iii. Any others?
G. Notes, Thanks, Etc.
[1. What This is About]
The Internet today has become a place where security is constantly in question; every hour, just about, it seems there is another exploit out for the most popular service. No one can be completely secure. But, one can try. This paper will outline some popular
(well known) and not so popular (rare) security schemes that have been noted. This informational paper is provided as-is, with no warranty, either expressed or implied, of any kind. The reader chooses what he/she will do with the knowledge contained herein, and the author, host, and contributors take absolutely no responsibility for the readers' action(s). There, now that that is done, lets move on.
[2. Terms]
Some terms you may find helpful to know, which are used in this paper, are defined below. If you know all of them, feel free to skip ahead. These terms are here to help you understand this document.
[a. SPOF]
A SPOF, or Single Point Of Failure, is a single host, program, log, -- whatever --, such that, if that Point is compromised, your whole network IDS is in jeopardy. In other words, say you have an IDS system that reports to a central log server, if that log server gets compromised, the whole IDS is invalidated, and you now have 0 security.
[b. IDS]
An IDS is an Intrusion Detection System. These can range from firewalls to programs that search for `wierd' traffic on your network. These alert the administrator of suspicious activity on his computer/network. These systems are what this paper is about. Read on.
[c. DIDS]
A new term, coined by red0x. A DIDS is almost the same as an IDS, with one exception:
A copy of the DIDS program is distributed to [close to] every host on the network you want to secure (hence distributed). These take many forms, but generally, they communicate amongst themselves and have the ability to shut compromised hosts off from the rest of the network. Pretty spiffy, eh?
[d. Firewall]
A firewall sounds scary, like a hacker's tool almost. But, its not (if you think that, stop being so stupid and narrow minded, read packetstorm.securify.com papers). A firewall is a program or piece of hardware that sits on your network (usually close to the boarder) and blocks access to certain services on your network from the outside world, blocks IP ranges from accessing your network, can hook your entire net into one single IP address [NAT], and can generally be reconfigured from the network/internet.
[e. Topography]
Any network admin should know this. The topography of your network is how it is layed out. If you use hubs to hook up your net, chances are, your topography is `star.' If you use switches, it is still probably `star'; BNC cables, most likely ring; a fiber router hooked to some other routers and hubs, probably 'backbone.' You should get the idea by now. If not, go look online for +"Network" +"Topography". That should help.
[f. Router]
A router is a piece of hardware that forwards packets to where they should go. This is how the internet works. Routers choose the best route (figure that one out) to the destination host, send the packet that way, and return it when it comes back.
[g. Secure]
Secure implies that a certain host or network is either 1) detached completely from the net, 2) Protected behind a single IP address and many access controls, or 3) reasonably unhackable. Hackers will argue that nothing is unhackable; this is true. That is why I said, 'reasonably.'
[h. Insecure]
Insecure inplies that a certain host or network either 1) has been hacked, 2) is not protected in any way, or 3) is not reasonably secure.
[3. Linux]
[a. What]
Linux is an opensource operating system that the greater part of smart internet server admins use. I say smart, because the dumb ones use Windows NT or the like. That is not smart for many reasons: 1) It is not opensource, therefore, the code has not been audited, 2) it is REALLY expensive, compared to linux's hefty price of $0, and 3) Windows crashes WAY more than linux or BSD (if you dont know, dont ask).
[b. Why]
Linux is good for servers. I wouldn't give linux to your staff, they probably wouldn't know how to use it. But, I would put it on your company's servers, instead of Windows. The reasons are simple: 1) Free upgrades, 2) security updates, 3) Linux is free, 4) the damn thing WONT CRASH, and 5) it is open source, so you can easily reconfigure it for your network's needs.
[c. Where]
www.linux.org
www.opensource.org
www.slackware.org
www.redhat.com
www.valinux.com
Search for it, but be warned, there are many flavors of Linux. Try them all if you want. But, this isn't a linux add, so on with the show.
[d. How Much]
Linux is absolutely free to download, my man, but buying it usually comes with support, and that cost depends on what flavor. I wouldn't recommend Redhat for secure networks. If you want really secure, get BSD, but for linux, try Slackware. Look around for more info.
[B. Common IDS Methods]
Today, there are lots of IDS systems. We will only talk about the linux ones. Most of the IDS systems I've seen for linux are one of two sorts: 1) Host-Based, 2) Port-Based. First of all, lets discuss Host-based, then Port-Based.
[1. Tripwire]
Tripwire is a Host-Based IDS system. That means that Tripwire sits on your computer monitoring file changes. If it records changes, it logs them and alerts you. Then, you, as the admin, can see what happened.
[a. Pros]
Tripwire, and the like, easily detect file changes. They use signatures held in either every directory or in a central location (SPOF). Some types of this kind of IDS can detect logins by unauthorized users -- you have to tell it what that means though. Also, most can and will keep logs of who is online and who is changing what file. I'm sure you could also get some that log command lines on a per-user, per-session bassis.
[b. Cons]
Say you are running Linux, and you want to upgrade you X-Windows servers. You go download the new code. Tripwire alerts you of file changes... You extract the code. Tripwire... You configure and compile. Tripwire for everyfile... This can get alittle annoying and can easily cause a DoS of syslog, hiding stuff that should get in it. That is bad, in case you didn't figure that out.
Tripwire and it's variants are dumb, in programming speek. They can't usually tell the difference betweem what was meant to be changed and what wasn't. So it alerts you about all of them. Also, even worse, any person could hack into your system by guessing a password of one of your users, and Tripwire wont alert you. Why? Because no files were changed. That is also bad. Even worse, if you store your file signatures in one directory, what if the hacker deletes them?
That is a SPOF.
[2. Snort]
Snort is my favorite firewall type program. If you want one, its free, and damn-good.
www.snort.org, check it out. What it does is sit on your machine, probably close to your border, listen for packets in PROMISC mode (if you dont know what that is, move on), and takes the appropriate action based on the packet's contents.
[a. Pros]
Snort, and the like, can easily detect connection attempts to ports you specify to block. It can also, easily, detect portscans, even stealth ones. After it detects these, it can block access from the originating host. Also, snort keeps a signature file [SPOF] for the currently known attacks and if any packets match the signature, they are dropped. This eleminates most backdoor attacks from your network. But hackers know how to program backdoors and could easily change one to evade the signatures.
As far as I know, snort has signatures of packets that could start a DDoS of your or somebody else's machine/network, and will block them. Good stuff, huh? Snort, and variants, can also be used like any firewall to block IP ranges, ports, etc.
[b. Cons]
The signature file is snorts first con. If somebody develops a new attack, keeps the code private, and never uses it, except against you, snort might as well be a backdoor. It will let that go right on and continue. This is bad. Not only that but the files are a SPOF, if they get deleted, there goes your protection until you make new ones. Snort works in PROMISC mode, meaning it grabs ALL packets on your unswitched network. Bad idea for some people who want to run a secure network. If you have the right skills, you could reverse engineer snort to dump the packets if they contain sensitive data, a possible security compromise. Snort also has DoS vulnerabilities, pretty much all IDS' do. I'm not sure about them exactly, but I'm sure they are there. Another con, snort offers no tripwire style protection.
What if somebody comes and changes your .rhosts file to contain "+ +", your host is now insecure, and all the traffic to exploit that could get past snort.
Snort's Achilles heel is that it is tough as hell for beginners to use. What about a manual, guys? If you run snort on your border, and somebody who works near it goes over and types "killall -KILL snort", your entire network is compromised now.
Bad to have such a drastic SPOF.
[3. Firewalls]
Everyone should know what a firewall is. The most common for `secure' networks is the hardware flavor. The smartest admins put these close to the border of the network, before the internal network. This allows for the best coverage. Also, if you have separate sub-networks, you may want to put on between these nets and the main network at your site. These firewalls are capable of blocking IP ranges (*.*.*.* is good for security), ports, services, and protocols. It is a good idea to only let incoming TCP/UDP and block everything else.
[a. Pros]
Firewalls are good at your border because they can block the outside net from using certain services that you mark for blocking. So, anyone not `behind' the firewall can't connect to the specified port of ANY machine behind your wall. Another pro is that it can block IP ranges. So if you read your logs and see evidence of an upcomming attack, you can start blocking the IPs, totally. Not only that, but a firewall secures your entire network, just by being at the border. That is the best benefit of a firewall. Even more advantageous is the ability to become transparent on the net. Firewalls can (and should) block ICMP, which will give the impression that your host is down to IP range scanners (a plus). Also, firewalls can port redirect, so you can have one machine serving ONLY port 80 of your single public IP address (saves money), while another machine is serving FTP. That way, each of your services is secured from the rest, making it harder to identify what OS you are running (taking such messages out of connection banners is a good idea.
[b. Cons]
Firewalls are a pain to configure and update; it all must be done by the user and usually from the command line using such ambiguous commands as `ipchains -A ....' You may have no idea what it is doing. Also, firewalls wont adapt to your network, so if you use 192.168.*.* for one subnet, and then add another 10.*.*.* subnet, your firewall will have to be reconfigured to use that new subnet, a slow and annoying process. A big minus for firewalls (the hardware flavor) is that most can be remotely configured. If you choose a bad password, any hacker could guess it, change your configuration to leave your entire net exposed, and hack in using a method that was previously secured. Also, some firewalls wont be transparent, so it is possible to bypass them (if your net topography allows). An example is you bought an IP block 165.67.234.*, you put up your net, and your firewall is on 165.67.234.1 and router is on 165.67.234.2, not directly connected, but through a hub, to your firewall. If your router is misconfigured, that firewall will do nothing at all. Also, a firewall is usually on its own machine (software), your router (software), or hooked in by itself. That is an SPOF. Break the firewall, and the entire net is compromised, bad idea. Also, a new technique has been developed called firewalking. You can read more on packetstorm [link]. Basically, it gets your network layout without setting off alarms and bypassing filters in your firewall. Pretty spiffy, huh?
[C. New/Rare Methods]
Some new methods, mostly good ideas, have been developed. These methods are generally mixtures of the aforementioned methods that add pros and reduce the amount of cons for each. Basically, most of these methods are good things to have, in addition to your current IDS system.
[1. Spider Nets [spidernet - mixter.void.ru]]
This is something I have never seen before coming to mixter's site. Mixter came up with the idea of having multiple Host-Based IDS (tripwire style IDS) `talk' to each other. Pretty Spiffy, huh?
[1. Pros]
The first and most important thing about this method is that it is distributed.
A big plus! This way, there is no SPOF. All the spiders on the network talk to a log server and to each other (V). Another good thing, is not only can you have it do echelon style monitoring (discussed below), but you can also incorporate Tripwire Style IDS. Also, there is a central logs server, that will encrpyt the logs, etc.
[2. Cons]
The downside is that this is weak as a standalone security system. So you have a bunch of computers with logs going out to other places, big deal. A real hacker can easily get around this. :O) Also, the central logs server, if implemented, is a big SPOF. Lose your logs and you lose your protection.
Even worse, arguably, is that spidernet runs as a user-space process, so a simple 'killall -KILL spiderd spidermon' would to the trick to effectively disable this IDS. Good idea tho.
[2. Echelon [e4d - mixter.void.ru]]
One of my favorites, you could call it a distributed sniffer. Sound like a good idea, well it is. Especially if you want to see what computers on your net are access what information.
[1. Pros]
Some good things about echelon is that is sniffs all the traffic at the socket level (IP only). It can read emails, telnet sessions, X windows, everything that isn't encrypted (and that too, but it wont b/f the key for you :p).
Another plus is that the logs can be stored both on and off site. Sound good?
Even better for unswitched networks in the star topography is that this IDS uses NON-PROMISC sniffing techniques, so you wont get a bunch of repeat data in your logs. Even better, all communications to the log server are encrypted using aes. :O)
[2. Cons]
Echelon is good, but not that good; here's why. Echelon is very NOT proactive. all it does is take logs of what and from/to where data is going by. And not all data, only data you enter into the source code. Another minus: you could conceivably reverse the sensitive data that you sniff for out of the sniffer itself. Another bad thing, this system uses a central logging server, another SPOF. If you want to know what information is going past your router, echelon, at least in mixter's implementation, is not for you. It doesn't use PROMISC mode, remember, so it only sees data bound for it. Not only that, but the data in the logs ins't encrypted. The most common minus is here too: echelon runs as a user-space process. 'killall -KILL e4d' = bye, bye echelon.
[3. Heuristics Scanning [ewatch -
http://www.eecs.harvard.edu/~rtm/README-ewatch.html ]]
This is a cool project, because it actually works like modern virus scanners. It searches your net traffic looking for interesting changes in behaviour. If you dont usually do zone transfers, and one hits your DNS server, this takes note and flags you down. Pretty good stuff here. Great combined with a firewall and a tripwire!
[1. Pros]
I don't know much about this project, so here are some good things about heuristics:
i. Scans ALL Traffic
ii. `Learns' to recognize traffic
iii. Recognizes `bad' traffic
iv. Logs `bad' traffic
[2. Cons]
Here are some bad:
i. Takes a while for it to learn (your network must be secured during that time) (V)
ii. No Net Protection (Firewalling)
iii. User-Space (killall -KILL ewatch = bye, bye)
iv. Annoying at first (flags you down alot)
v. Local program = SPOF
[D. Designing a Good System]
On to the good part, here are some helpful hints to take to heart when you are designing a new IDS system. Listed are things to avoid, include, and what to expect.
[1. What to Avoid]
At all costs, try to distribute your IDS throughout your network, avoiding a SPOF.
DO NOT EVER make IDS systems with central configuration servers. Logs servers are ok, but not configuration servers. If they get compromised, your whole entire IDS and network is compromised. Bad idea. Try to avoid the possibility for your IDS to flood itself, the console, syslog, or hosts on the net. Extensive testing and debugging should be able to find all such occurances and weed them out. At all costs, avoid storing raw logs. MD5 sum all logs, keep them in a secure directory (umask 700), and encrypt them. If at all possible, try to avoid developing IDS that run as user-space processes. This will avoid the 'killall -KILL program' SPOF.
Always, Always, Always avoid plain-text net traffic, especially when using DIDS.
The reason is just common sense, you have the element of surprise. If you can, try avoiding developing code that must be run as root or setuid/setgid. This will usually help you avoid developing remote exploits (buffer overflows).
[2. What to Include]
Some things to include in your IDS:
A major design feature is the ability to distribute your IDS (thus making it a DIDS). Once the size of your IDS is dynamic, so is your measure of security. You can run it only on your router machine, or you can put a copy on every host on your net, and they all will `talk' and help secure your network from the inside, even if one host gets compromised. Try to pick a good setup for your topography, make the IDS fit you, not vice versa. If you use a backbone system, an IDS using a PROMISC sniffer on the backbone would be wise. If you use an unswitched star topography, dont use PROMISC mode, or all the hosts will have exactly the same logs (although, that could be good...). Always include good IP logging for questionable packets. It is a good idea to add that last measure of security (even though spoofing is easy as 1-2-3). Encrypt your logs, that is a must. Also, a good idea is to encrypt and sign your network IDS traffic. This way, it is harder to forge.
Try to include the capability to be switched from PROMISC mode to raw sockets at compile time WITHOUT changing encryption keys, etc. That way making more nodes for your DIDS is easier. If you have the code-fu, try to get your nodes to think, whether using heuristics, neural nets, or just plain lisp, intelligent `agents' are better than dumb nodes. Even without intelligence, heuristics is good to have. It is almost a rule now to make IDS that can interface with firewalls and reconfigure them at run time. That is a good practice and can save the network admin a lot of time. Another good idea is to include tripwire style IDS functions in your new DIDS.
This allows for the system to tell some other system if it has been compromised, and to dynamically shut it off from the rest of your net, saving the admin from hell.
Try to have the nodes, or `agents,' talk to each other and tell each other useful info, like 'hey agent 0193a, i'm insecure, shut me down.' Then agent 0193a will mark that system and agent as `evil,' add that hosts to hosts.deny, firewall him out, and tell all the other agents to do so as well. Pretty spiffy, huh? This implies that the nodes of your DIDS must be able to block traffic from or to specific hosts.
That is definitely a good thing to include. Another wise thing, is the spoofing capability to shut down SYN floods (close half-open connections by spoofing FIN/RST packets, etc.) and block other DoS/DDoS/Flood attacks.
[E. Enter Agents]
We have an idea. To make an IDS system that isn't standalone, its distributed. It isn't just host-based, its also network based. It doesn't use signatures, it uses heuristics.
Enter Free Agents NIDS [sourceforge.net/projects/freeagent]
[1. What is DDIS? (Agents)]
What the hell are agents? Think of the IDS (DIDS) we were just talking about. Each node, if it had some intelligence, would become an agent. The good thing about agents is that you can put one on every host on your network, and they will all talk, and learn, what is good and what is bad traffic. Also, they can tell each other if they have been compromised, and therefore, dynamically re-secure your network. So why would you want this kinds of Distributed IDS? (DIDS)
[2. Why DDIS? (Agents)]
The reasoning is simple. Here is your network, a huge backbone with stars off the main fiber.
[your network]
