Slashdot Log In
Security Expert Dave Dittrich on DDoS Attacks
from the straight-from-the-source dept.
Dave:
First off, I'd like to thank Slashdot for giving me an opportunity to spew my opinions. Since Slashdot readers look for "stuff that matters," I'll #include [std/disclaimer.h] and say that this is me talking, not my employer, and I'll be honest about what I think the issues are (and hopefully not ramble too much).
Is a network proof against DDoS possible?
by Paul Crowley
Is vulnerability to DDoS-type attacks due to a flaw in the design of TCP or IP, or is the design of a network that's inherently resistant to such attacks an unsolved problem? Is it possible to imagine a fix that would address this, or a protocol that wouldn't be vulnerable even when many machines are compromised?
Dave:
There are flaws in anything created by humans. Sure, the TCP/IP protocols we are using today have some weaknesses, but they also work amazingly well, don't you think? And all things created by humans are improved over time as new ideas are developed and known problems are identified and solved. Its just a matter of how quickly these improvements can be implemented, and as we've seen with GOSIP, IPv6, etc. change can come very slowly. (A good book on this topic if you are interested is "Diffusion of Innovations", by Everett M. Rogers, The Free Press, ISBN 0-02-926650-5.)
Denial of service attacks are one of the easiest forms of attacking systems and networks; resources can easily be exhausted, programming flaws in network stacks and devices can be exploited to cause failures, covert channels can be created allowing hidden and practically unstoppable communication and control. In other words, there is no single "this problem" to be solved here, but rather a hole bunch of little "these problems".
In fact, the current DDoS tools implement UDP large packet floods, TCP SYN (session setup resource exhaustion) floods, ICMP "echo" floods and "Smurf" (directed broadcast ICMP "echo reply") floods, and other DoS techniques could easily be added (and many other exploits exist).
Yes, there are some proposed fixes that can address some of these problems. I'll get to them in a minute.
Other methods?
by Dr Caleb
There seems to be several solutions floating around, mostly smart routers that track valid traffic and MAC addresses.
Would changing to IPv6 help eliminate these type of attacks? >From what I read of the specs on IPv6, all the data needed to track a packet from destination right down to the MAC address is included in the packet.
Dave:
I don't claim to be enough of an expert on IPv6 yet to say which of the current set of DoS attacks are eliminated by its features (better to ask the real experts like Steve Bellovin). Perhaps IPv6's Quality of Service features, IPSec authentication features, etc., *may* provide a means of defeating some packet flood attacks by rate limiting flows, allowing quicker discarding of "invalid" packets, etc., but I'm not sure if it will entirely eliminate DoS attacks.
There are other new proposals that have recently been put forward for consideration, such as Bob Moskowitz' "Host Identity Protocol" (which addresses some problems in TCP session establishment and identification of "valid" packets) and a proposed method of tracing packet flows (independent on ISP involvement) that uses a probabilistic packet marking technique developed (coincidentally) by researchers at the University of Washington. Documents describing both of these are available at:
http://staff.washington.edu/dittrich/misc/ddos/
Since IPv6 is *still* not widely implemented, and these other proposals are likely years from implementation as well, it is probably best to focus now on the fundamental issue in large scale DDoS attacks, and that is we need to put a MAJOR emphasis on minimizing the population of systems that can be trivially root compromised. (I didn't say it would be an *easy* solution, but it is one thing that can be started immediately.)
Stop Spoofing At The Backbone?
by Effugas
How viable would spoof protection at the backbone level be? In other words, after a certain date, all downstream links are categorized as either able to peer for other network blocks, or simply not. Admins who can't be bothered to spoof-protect their networks would get IP source ranges outside their IANA assigned IP block dropped at their first upstream provider; sites which need to maintain peering relationships thus have their direct motivation (their backup networks will cease to function) to specifically lock down their peer forwarding to only those IP ranges they're actually peered with.
Yes, you obviously get problems as peering scenarios get traveling-salesman levels of complexity, but most sites (to my knowledge) don't exceed more than a few levels of peering--we should take advantage of this fact to enforce a top down elimination of infinite source spoofability? And, if so, would the precedent that this creates help or hinder the growth and freedom of the Internet?
Dave:
Eliminating IP source address spoofing would eliminate attacks such as forged DNS query attacks and the MacOS 9 TCP/IP stack bug (both packet size/number amplification flood attacks), and would definitely make it easier to trace packets back to their source networks, greatly simplifying and speeding up the (still major) task of stopping the agents from sending out packets and doing forensic investigation. Add to that the elimination of incoming directed broadcast packets and you also get rid of "Smurf" amplification attacks.
Not only do I think this should be done at a site's border routers, but also on all routers within the network. Programs like stacheldraht attempt to determine if they can successfully send packets with forged source addresses, and both it and TFN2K have code to randomize packets on a per octet basis (not exactly CIDR compatible, but still pretty clever and effective.) This means that if you have a /16 network with several hundred subnets, the agents could forge the final two octets, looking like they are coming from hosts on all of a site's subnets at once. Depending on your network infrastructure and political organization and authority, this can either force you to have to sniff on *each* subnet, or do your own router-by-router debugging of packet flows to locate the actual host(s) sending the packets (links to various documents on packet tracing are found on the page I referenced above.) If no host can forge source addresses beyond its own subnet, the task is greatly simplified (and you only need to put filters on one router to stop the flow from one agent host.)
Practices like those described in RFC 2267 should, in my opinion, be a standard requirement under any network peering agreement and AUP, but what motivation do ISPs and NAPs have to enforce them? Its not common for a company to say to a customer, "Hey, I don't want to take your money!" It tends to be a matter of waiting for an attack to happen for upper management to start asking the techies how to react, but by then the damage is already done. More emphasis on prevention and preparation for possible attacks seems to me to be more prudent (some ways of mitigating DDoS attacks are also listed on the page referenced above). If it costs more, so be it. That is the price of betting our economy on the Internet as its fundamental infrastructure.
The bad news here is that this tactic of filtering does nothing to deal with bandwidth (or other resource, like half-open socket) consumption attacks -- e.g., large packet UDP or ICMP floods, or SYN floods to random ports -- so again we've only solved a subset of the problems (forged addresses and directed broadcast), not to mention this solution doesn't help at all with the initial compromises and installation of agents.
Firewalls for Dummies?
by hiendohar
With the increasing popularity of broadband, always-on connections and the increasing distribution of networking software, it seems like "Joe DSL" faces a greater risk of having his system compromised than before. How much can the average user be expected to learn about securing their system? Do you foresee developments, either in software, education or in other services that might help private computer users or small time administrators protect themselves better?
Dave:
I expect the average Joe DSL to probably learn the hard way, just like he learned not to step off the curb in rush hour against the traffic light, and to take everything valuable out of his car when he parks it on a dark city street: by suffering an incident, and the resulting cleanup cost.
This is an education problem of *huge* proportion, and just like the filtering question, there isn't much motivation for ISPs to hand-hold their growing customer base, and their marketing department -- just take a look at their ads -- tells you how fast they are, but doesn't say a word about the new risks you will face (some will mail you a warning a few months later, which may be a bit too late.)
Not only that, but most broadband ISPs have user bases far larger than they have staffing to support, so even trying to contact them, find your way through the tier1/tier2/first line manager/Nth line manager hierarchy, and actually identify the owner of a compromised cable modem or DSL served system can take days. These customer's systems make excellent bases for scanning/attacking other sites, running eggdrop bots, or "bouncing" connections to make it harder to trace attack activity, and the intruders know this.
As for education, I am not quite sure what can be done there. Mandatory "driver's license" style tests before getting a DSL account? Forget it. "Tickets" handed out by the Net Police for allowing your system to be compromised and used to attack other sites? Not likely, and I don't think anyone wants that. Law suits by victims of attacks against the owners of compromised systems? That is already starting to happen, but do we really want people to learn as a result of law suits, to throw lawyers at the problem, diverting badly needed system admin funds to pay $200 an hour to the suits?
There probably will need to be some monetary incentive to securing systems (because people pay attention to money.) The federal government is passing laws about privacy of personal, medical, and credit information (and these can't be private if the systems that house them are not secure), and insurance companies will likely start charging higher rates for systems that are not managed well and become involved in security incidents with high dollar damages (but PLEASE, first raise the rates on anyone who drives a car while talking on a cell phone!)
Some ISPs now offer security services, and will provide "firewall" services for their customers, but this comes at a high price. Most users want $19.95 a month service, which is basically just buying a raw, wide open pipe.
"Personal firewall" software is also becoming popular, but I've wasted many an hour explaining to someone reporting an "attack" that what his program was reporting was either a false positive, or was mis-categorized, and not at all what they thought. Feature filled packet filtering programs allow users to shoot themselves in the foot and break TCP/IP applications, while overly simplified programs leave gaping holes or users turn off too much and only think they have security. A lot more work and education is needed in this area.
A fruitless exercise?
by john@iastate.edu
Isn't the intersection of the sets:
- Clueless enough to allow massive DoS out of their network.
- Yet likely to install this detector.
Dave:
Yes. Next question?
Seriously, the detection of agents/handlers on a system, and on the network, let alone doing forensic data gathering to assist in stopping a distributed attack and identifying the attacker, is not easy. There are too many ways for an intruder to disable logging and accounting, conceal programs and files using "root kits" and loadable kernel modules, and change the defaults for commands and packet contents that will defeat the file system and network scanners that have been developed to deal with these DDoS programs, and the learning curve is steep to counter the intruders' anti-detection measures.
This is one of my pet peeves; THERE ARE NOT ENOUGH GOOD SYSTEM ADMINISTRATORS. There needs to be WAY MORE of them, they need to be PAID AND TRAINED BETTER, and (to put it bluntly) they need to be considered a critical resource REQUIRED for powerful computers on the Internet today, not as overhead expense to be minimized.
The fundamental requirement for securing (or breaking into) any system is knowing how the system works, how to take it apart and how to put it back together again. These DDoS attacks over the past six months have been made more costly to respond to because of things like "root kits", which exceed the average admins ability to get around. For more on why, see:
http://staff.washington.edu/dittrich/misc/faqs/roo tkits.faq
I think a big reason that Universities, K-12s, small businesses and non-profits, and home users with cable modem and DSL lines have their systems regularly compromised is because these systems are often deemed a necessity for research or business, but the only money that goes into them is the money it took to buy the hardware in the first place. They very often do not have tape drives, software upgrade licenses and regular patch application, sufficient manuals or books on system administration, and the person administering the system is usually the first person who can spell "U-N-I-X" and has a "real" job doing research, programming, or Web page design.
People need to start thinking about today's top of the line computers on gigabit networks as the equivalent of a BMW, a Range Rover, or an Audi A series. You would be an idiot to only put gas into it and never take it in for regular maintenance, instead trying to do the work yourself in the garage, and to leave a spare set of keys in plain view on the dashboard. No, you take your car in regularly to a trusted and trained mechanic (and pay $50 an hour for their skills), change the oil and rotate the tires regularly, and do your best to keep it from being stolen (including buying those annoying car alarms that nobody pays attention to when they go off.) But that is basically what too many people do with computers; don't take care of them, don't hire skilled people to regularly maintain them, don't adequately monitor them, and don't really care if someone else hijacks them.
I regularly hear people say, "I don't care about securing my system. I don't have anything important on it. What could they steal?" Well, there are gigabytes of disc space these days, REALLY fast CPUs that can spit out lots of packets, and high-speed network connections. It is when tens or hundreds of thousands of people think and act this same way that someone else suffers. This attitude HAS to change and people HAVE to learn about the risks and ways to address them.
Should security research be done in obscurity?
by crush
It is nearly a mantra among us that there is no security through obscurity. It would seem that with a sufficient number of us too lazy or too ignorant to secure our own machines that there is possibly no security through openness either. Do you think that the open research model that Mixter, Farmer and others have always advanced as a reason for releasing their tools is still justified?
Dave:
Yes, I think the open research model is justified. There is a passage in the Bible (John 8:32, and on a plaque in CIA HQ), "And ye shall know the truth, and the truth shall set ye free." But that only works when everyone knows the truth (and uses that information wisely in their design and purchasing decisions). Until that balance is reached, those who wish to abuse this knowledge win out over those who have not yet attained it. It's that simple (and that hard - ooh, how Zen like.)
As you point out, there is a large percentage of system admins that don't have the same knowledge as those who break into their systems. If that percentage (of a very large, and growing number of powerful computers on fast networks) isn't reduced, the total number of systems that can be compromised and controlled by an attacker grows to the point where its now possible to build attack networks of two or three THOUSAND computers.
What I think needs to happen is to follow the advice of someone (I forget the source) who said, "There should be a hacker on every board of directors," and I would add on every development team. I don't think it helps to ignore weaknesses, or keep them quiet, because they will eventually cause problems. And it is not enough to identify the weaknesses if nobody learns from the mistakes of the past and actively tries to avoid them in the future. One reason that these changes occur so slowly, in my opinion, is that the people who really know the technical details of security are too far removed from the real decision makers, and the layers of managerial filtering inbetween often filter out the security voices in favor of the "lets please the masses" voices.
Engineers are not taught simply how to construct buildings, they are taught how to know when they will fail so they don't come crashing down and kill everyone. There are standards and codes that say how buildings should be constructed, and we (for the most part) don't have much trouble with buildings killing us in the U.S. But software and operating systems are designed for ease of installation and use by the largest number of (untrained) people possible and practically nobody complains. Where is this same sense of "we must build it so it doesn't break?"
I hear an ad for a new online bank and think, "Great. Now all my bank Web based business communication site and think, "Great. Now the people discussing business plans will have their discussions at risk." I hear a news story about a company that facilitates designing buildings online and think, "Great. Now the plans to unknown office buildings are at risk." I can just picture the CEOs and the stock analysts drooling at how cool and efficient these new web tools are, and how much money the company that produced them is going to make, but unless they are designed with security in mind from the start, they should all be considered very risky to use.
Somebody in a position of decision making authority for any e-business needs to understand these weaknesses that are discovered and publicized, and to make sure these weaknesses are acknowledged and addressed in ALL computer based system and application designs.
Recognizing DoS
by angst_ridden_hipster
I think one of the biggest issues will be identifying Denial of Service as an attack. I have a legitimate load testing utility that simulates actual browser traffic. Say I run it against someone else's site. They'll see that a lot of traffic's coming from me, and eventually figure out it's bogus and take appropriate measures. But distribute this and it'll look like actual traffic. Get enough friends doing it, and we take 'em down with what appears to be perfectly normal browsing.
The analogy to the "real" world is roads and bridges. During normal hours, they run well. During rush hour, they clog up and perform poorly. And during a demonstration (like recent examples in Seattle and Miami), they clog up and perform poorly. You can consider the recent anti-WTO situation up in Seattle to have been a DoS attack on downtown. But you wouldn't consider gridlock at 5:30 p.m. in Los Angeles to be a DoS attack.
To solve these problems, you have to know what's causing them. If it's just normal traffic and the infrastructure is insufficient, it gets ignored until people get fed up enough to vote more tax money into building wider roads or better public transportation (again, analogous to buying more servers or a fatter pipe). If it's demonstrators, you either address their concerns or you send in the National Guard to beat the crap out of them (depending on the political climate).
In this world, it's easier to differentiate the two situations. If a bunch of cars are jammed together at rush hour, you know it's a traffic problem. If it's crowds of people singing songs and holding signs, you know it's a demonstration. And if it's a possible sick-out at Northwest Airlines, you're not sure if it's a DoS or not, so you get a warrant to read their home e-mail and find out.
With computer protocols, though, usage and abuse can look identical. Even wild surges in activity can be from legitimate usage. How do you forsee systems being put in place that can differentiate between actual usage and DoS? Doesn't this almost inevitably lead to some non-forge-able, traceable, unique identifier? And doesn't this translate to the demise of privacy on the Web?
Dave:
Not necessarily. Sure, normal usage may exceed capacity. But a protest by thousands of people is not "normal usage;" that is a mass exercise of individual rights in a democracy to gather and express their opinions. [I live about four blocks from where the tear gas and concusive grenades were being lobbed at protesters, and I personally think the response was excessive and the protesters had a right to protest. They weren't damaging property in my neighborhood, they were chased into it, and traffic could simply go around it. Seattleites are used to backups, like you point out.]
I'm really don't know if I'd have a problem if 3,000 people decided to all individually use their browsers and click away at a major Web site as a form of protest, using their own computers and risking possible legal action as a price. (The JavaScript used to protest the WTO was a cool hack, and quite publicly known and used by individuals with their choice. That is less quesionable in my mind as a means of protest.) That's what it means to have freedom of assembly and freedom of speech; you protest in person, gathering with like minds. I marched against the Gulf War bombing, and was glad I could exercise that right when I felt it was important.
I *don't* think it is OK for a single individual (or small group) to take control of the resources of 3,000 *unknowing* individuals' resources and anonymously force them into that individual's service. That is not an exercise of democratic speech, that's theft of private resources. That's what DDoS attacks are.
If there is a problem with truly normal usage exceeding capacity, you could argue that capacity simply needs to be increased, and there is a cost associated with that increase. I start to question things when this increase in capacity is made on an insufficient budget, so there is nothing left for people and tools to protect the new "required" infrastructure. If the infrastructure is so vital, should its proper monitoring and administration be neglected? Is it wise to use this as the infrastructure for our record-setting-growth economy? If we build a fragile infrastructure for our economy just for the sake of growth and short term revenue (and pandering to customers demanding more and more services at lower and lower prices), and the result is that an individual can wage an anonymous protest and take parts of it down. I'd rather that the growth was a bit slower and infrastructure was more secure.
Antionline: True help?
by cswiii
I saw this evening on CNN that the FBI has enlisted the help of none other than Antionline, in its search for the perpetrators of the DoS attacks. What is your opinion, regarding this decision? How does this reflect upon the FBI's ability to investigate cybercrimes?
Dave:
I have not seen any news reports that Antionline was enlisted to assist the FBI (and don't see anything searching CNN online.) I also read a Reuters article that claimed Mixter wrote stacheldraht (he did not), and that stacheldraht is used to break into systems (it has nothing to do with breaking in, just sending packets -- the break-ins are done using other tools, which usually implement buffer overflows in services like rpc.cmsd, rpc.ttdbserverd, amd, named, etc.)
Just because the media says something (or worse, one reporter quotes another reporter) that doesn't mean it is true. They make plenty of mistakes, especially when reporting on tight deadlines (I have published corrections to some articles in the DDoS page I referenced above.)
Government
by interiot
If you've had much contact with security specialists working for the government, how much confidence do you have in them that they're smart enough to:
- Understand the problem well enough
- Spot good solutions if they come along
DDoS attacks ARE a problem. I could imagine that they could serve as terrorist/psychological attacks in time of war. Because the computers that are doing the actual DoS attacks could be within the country being attacked, the attacks would be nearly impossible to stop at the borders.
Dave:
"The government" is a pretty big population, which includes federal law enforcement (as you point out), as well as a huge slew of departments and agencies, their state/local equivalents (including public schools and universities). In such a large population, you will find both skilled and unskilled members of that population (fitting a bell-shaped curve like most populations).
If we don't like it that all attacks are attributed to "hackers", we should likewise have some respect and not just jerk our knees and say anyone who works for the government is automatically clueless.
The Government Accounting Office (GAO) has been auditing and analyzing many of the federal departments and agencies for years, and some of its reports (I have a number linked on my home page) are pretty critical, while others highlight agencies that have done a lot to secure their systems and provide "best practices" advice to improve the situation.
As for law enforcement, the FBI has been doing a lot recently to create a skilled central core of computer crime analysis and investigation resources, and in establishing training facilities and developing working relationships with their peer agencies in other countries (since the Internet is global, response must be global). Since they haven't been at this very long, of course this will be a bumpy and sometimes inconsistent process, and it will take time to build depth and breadth of computer forensics skills (and there is usually a LOT of forensic data to process and understand), but they are working very hard.
I would also say that I think the Clinton administration has done a much better job than its predecessors in trying to address these issues (e.g., the President's Commission on Critical Infrastructure Protection, the formation of NIPC to coordinate incident response and information dissemination to the public and private business sectors, and the National Plan for Information Systems Protection.)
If you've read the National Plan -- subtitled "An Invitation to a Dialogue" -- you will see that a great deal of thought has gone into dealing with infrastructure protection, and that they are asking for cooperation and input from the private sector security experts, which means us. (Now is the time to make your opinions known, and that doesn't just mean ranting on the dc-stuff list, where you are preaching to the choir. Of course, people there will agree with you, but does that change anything? You need to write your Congressional representatives, the President's Council, and vote.)
I, too, question the amount of emphasis in the current budget being placed on surveillance, but I'm really happy to see money being allocated to programs like better forensic analysis capabilities and identifying talented high-school students and helping them to study computer security in college, rather than ignoring their talent (a form of disrespect or a result of fear) and risking losing them to a life of attacking systems instead of securing them.
For example, I know at least one admin (who was 15 at the time I met him) who knows more about securing Unix systems than many admins I encounter on a daily basis. Sure, he was 15 and had some issues with judgment that 15-year-olds have that caused friction with his employers, but he was just 15! Give him a break, and respect his talents! If he was managed more closely, his obvious skills would *still* be an asset to his former employers. I don't want to see someone like this get frustrated at not finding a place to get paid for what he loves to do, and land in jail for following his curiosity and passion in his own way (which usually involves making an eventual mistake in judgment that draws the attention of law enforcement). I already pointed out there is a lack of skilled system administrators, and I'd rather see young talent be put to use to solve these problems, and the National Plan addresses this.
Internet Worm
by Ex Machina
What do you have to say to the idea that this could be a DoS attack launched by computers infected with a Robert T. Morris style worm? Would it be possible to launch something like this and have it and its probes remain undetected until a date where it will launch a synchronized DoS?
Dave:
Given what I've seen as far as these particular tools go (including the scanner used by one group), I have no reason to believe the current attacks are automated and worm-like.
That said, I think it won't be long before someone *tries* to take that next step and further automate the process of scanning & intrusion to constitute DDoS networks.
Think about it, though, for a moment. Using the current DDoS tools, the intruders need to create a large network, without losing agents due to attrition as system/network admins notice the initial "setup" intrusions, and they would have to control the growth of this network so that the handlers are not crushed under the weight of an overly large network (or exposed because the agent "Hi mom!" traffic gets too noisy), hope that clocks are synchronized well enough to not expose the attack too early, and to control the resulting network during an attack, all without being detected. There are some tricky issues of coordination and communication that must be dealt with to prevent such a worm from running wild and disclosing itself. Whoever wants to try this should probably ask rtm about what it feels like to make that kind of mistake.
The alternative is to not use a coordinated/distributed model, but instead use the more standard model of propagating uncontrolled attack agents using a combination of social engineering and trojan horse programs. This has already happened.
In early February, 1999, a message faked to look like it came from Microsoft, claiming to be an upgrade to Internet Explorer (with an attached program named "ie0199.exe") was sent to many thousands of users on the Internet. Those who ran this program got what appeared to be an innocuous error message about a missing DLL, and most just gave up and deleted the message. What they didn't realize was that they had just unwittingly installed a program on their system that set itself up to run on boot the *next* time the system came back up. At next system startup, the program then started sending packets (as a self-described act of revenge) to random hosts on the Bulgarian Telecommunications Company network, causing them significant problems for who knows how long.
Worms also seem to work best against a single, self similar operating system/architecture/service combination, which means the attackers would have to do the same recon scanning they do now to get a list of these hosts, so why not just stick with what they know works and infect systems on the list in parallel, instead of by some non-deterministic spreading behavior?
Request for Practical Advice (Score:2)
I've set up a simple ipchains firewall. It allows local network (192.168.x.x) traffic and loopack traffice, but not over ppp. It lets eth0 (but not ppp0) packets access the NetBIOS port, which Samba seems to need. It rejects all packets sent to all of the ports I'm not using--especially port that NMAP finds interesting.
I uses strong passwords and don't operate as root unless I really need to. I use a dial-up connection and don't leave it open when I'm not using it.
What else should I be doing? I'm not a skilled SysAdmin, and my PC is unlikely to be the target of a determined attack, but I'd like keep the script kiddies at bay.
It's gonna get worse.... (Score:2)
A large part of the problem WRT basing economic growth
on a vulnerable system is a combination of greed and naivete
on the part of those who are not fascinated
by the technological details
(read PHB's and J.Random Luser).
I have to wonder what will happen if UCITA becomes the law of the land.
Does anybody else see the irony of government
on the one hand, spending money with an eye towards making things more robust,
yet on the other hand removing the onus of liability
from those who produce the engines on which
the info economy is based?
Great interview though...
browsing comments at 2 it almost seemed like 1998 again....
Re:Main stream media & these attacks (Score:2)
surely I'm not the only one . . . (Score:2)
Main strem media & these attacks (Score:2)
Then they went on to say that even if people think they're smart, they're leaving their ID behind and showed what they called a "unique ID #" on every bit of network information. They displayed something like this:
128.1.5.666 (yes they actually had 666 for the last 3 digits of the IP address). They also failed to point out IP spoofing, etc.
Is it REALLY asking too much for journalists to know something about what they report on?
Re:Personal firewalls, perhaps something for cobal (Score:2)
Security cannot be left to people who don't constantly work to improve it. Joe DSL has neither the ability nor the desire to do this. Sadly, neither do most self-styled sysadmins.
Re:Me Average Joe (Score:2)
Here's my solution: Have all ISP's providing DSL and cable service host the firewall for all their customers. Have them hire vigilant security minded sysadmins (there are few of them, but they are out there), who's only job is to keep the firewalled area secure. This way, Joe DSL doesn't have to worry about it all.
Re:Question (Score:2)
Anyway, if using ipchains, I prefer:
"ipchains -A input -i ! -d -j DENY"
where 'ifname' is each interface and 'ifaddr' is the corresponding address. That basically ignores all broadcast or multicast traffic; only point-to-point IP to _your_ host is accepted. Of course if you have a router or you actually need to receive broadcast traffic for some reason, you have to RTFM...
Ten bit bytes (Score:2)
Well, you see, modern modems strip off the start and stop bits before sending data to the V.42bis compressor. That way, it's even faster, right? Well, the compromised systems were all running some type of Unix variant, and everyone knows Unix is old. Even older than 9600 baud modems. So those Unix longhair hackers, when they make a PPP connection to The Internet, have to use start and stop bits, making their bytes 10 bits long. Now, even though they pay a penalty in speed (it's 1.25 times slower), they get the side benefit of getting to use IP addresses like 257.1023.1.666. It's sort of a 31337 status symbol.
I think we should all explain that to the journalists.
---
Getting /.ed (Score:2)
Re:Learning "Good" system administration? (Score:2)
Re:Perhaps a NINJA should be consulted. (Score:2)
I'll approach her tonight about it if I can find her. She likes to blend into the wall and jump out behind me and try to lop my head off with her katana. You'll probably want to consult over email with her because it's pretty dangerous being in the same room with her. She goes by "Nuprin" (little, yellow, different...).
Re:Joe DSL will be told by isp "All servers banned (Score:2)
Hey Rob, Thanks for that tarball!
Re:Joe DSL will be told by isp "All servers banned (Score:2)
#1: Don't make anything available that you wouldn't allow anonymous users to get and,
#2: Use an account that has NO access to anything except those files. Duh.
Hey Rob, Thanks for that tarball!
Re:Teach Me How To Be Secure (Score:2)
But one thing about your post concerns me. You say that you don't trust Mediaone to protect you from script kiddies. I would take that a step further: It is not their job to protect you from script-kiddies, it's yours. MediaOne's job is to provide you with a fat pipe. What you do with it is up to you (within their acceptable-use policy).
Unfortunately, most users expect their ISP to protect them, which is a nearly impossible task, (unless you WANT them to sniff all traffic going to your machine).
Re:Proper Systems Administration (Score:2)
At the time, it looked like it was some annoying irc related product, and as you might know, sys admins are overworked. Hence I had to fix this, report the problem to the upstream, and make a report to my boss, along with the rest of my work.
Hence, reporting a script kiddie didn't seem like a big deal to me. because it was definately a manufactured root kit, with no knowledge required, otherwise they would have gotten the ftp ls as well.
If I had a dollar for every script kiddie....
--
Gonzo Granzeau
Personal firewalls, perhaps something for cobalt? (Score:2)
Low-price nifty looking boxes with 2 plugs: 1 for your DSL stuff, 1 for your pc.
(and of course you can make it yourself using that old 386 lying around)
_
/
\_\ sig under construction
Re:Teach Me How To Be Secure (Score:2)
Re:Teach Me How To Be Secure (Score:2)
The problem with services is eliminated with a properly built ipchains firewall. Don't need people telnetting in? Reject requests from outside of the 'sandbox'. You should never have to deactivate a useful service if the firewall is configured properly.
In the case of SuSE, I usually kill Apache and Sendmail, and finger, etc, are disabled by default.
Besides, I would have mentioned service deactivation but I had to scoot off to a meeting and cut comment short... I appreciate you filling in the gap..
Re:Average Joe and PHB (Score:2)
On a side note, it's the only box I have access to that has Rogue installed.. And I didn't even do it!
Learn From Others (Score:2)
-John
Re:Average Joe and PHB (Score:2)
It comes close that what you want, in a way.
-John
NetBSD/i386 Firewall does that (Score:2)
It can be found at www.dubbele.com [dubbele.com]
-John
Thousands? How about free? (Score:2)
Re:Personal Firewalls (Score:2)
Re:Me Average Joe (Score:2)
Re:Linksys (Score:2)
2. Can't argue there.
3. Hardware solutions may be quicker and more reliable, but tend to get updated slower and less often when a security issue is discovered. Witness the many routers and switches which have known security loopholes that still have not yet had firmware upgrades issued.
The biggest issue, though, is that if you're using a hardware solution because it's quick, easy, and most importantly because you don't have to learn anything to use it, then you aren't really doing much to secure yourself. Without active knowledge backing up your security measures, people WILL find ways around them.
Re:University Crackdown (Score:2)
Employees in general, not just sysadmins. (Score:2)
That is an idea that businesses (big business and corporations in particular) need to realize.
A happy workforce (regardless of job) is a loyal workforce. Give them all good pay and good benefits and you'll have employees willing to work late and go the extra mile 10 out of 10 times.
It never made sense to me that management would want an unhappy workforce.
Personal Firewalls (Score:2)
Re:Learning "Good" system administration? (Score:2)
Experience, experience, experience. It's the best way.
Mail me if you have any specific questions, and I'll try to answer them for you.
If you can't figure out how to mail me, don't.
Learning "Good" system administration? (Score:2)
In reading the very well written questions and answers, one question came to my mind.
It was mentioned that there aren't enough Good system adminitrators. I am a very small time SA, and I probably fall under the "not good" category right now. My question to the /. community is, where can I go to learn to be a good SA? What books are recommended, what HOW-To's? (I've got Trinity bookmarked, it seems very extensive, but is it "good"?) How does one start to become a good SA?
Thanks!
--Adam
This is my
This is what Clinton will be talking about (Score:2)
Question (Score:3)
My question is: has anyone found a way to emulate Windows' behavior under Linux? I would think you could do this with ipchains, but have not been successful thus far.
ipchains -A input -s 0.0.0.0/0.0.0.0 0:0 -d <broadcast address>/255.255.255.255 -i eth0 -p 1 -j DENY -l
does not work, although I thought it would.
Re:University Crackdown (Score:3)
key word == privileges
Proper Systems Administration (Score:3)
Nothing can replace proper Systems Administration.
As a real world example of this, I busted a TFN client that appeared on two Suns we had 2 days after they appeared (These were non-used systems, I just noticed the network traffic). The traffic was high, I didn't believe the results that the rootkit were telling me, and found the kit and client (Thank you ftp's static ls!). And this was before TFN was out on BugTraQ and other security mailing lists! I didn't know what it was, so I just cleaned up the systems, and threw a P-90 Linux firewall in between. Also notified the uplink that they were the ones talking to the client. (Strange udp packets incoming are not to be trusted!) Now that's proper Systems Administration!
Oh, and to sell people on my company, Collective Technologies [colltech.com], all we do is Systems Administration (and networks and DBA's now too). The best of the best sys admins out there... `8r)
--
Gonzo Granzeau
Average Joe and PHB (Score:3)
When you break through all the hype that the press has put on this and boil it all down, it is just common sense. It's a shame that it takes events like this to have "the average Joe" and the PHB finally understand that a little caution and a little foresight go an awful long way. The three or however many of them they were, who pulled off the larger of the DdoS attacks really did the industry a favor in raising awareness, although I don't think this was the motive.
I would also say that I think the Clinton administration has done a much better job than its predecessors in trying to address these issues (e.g., the President's Commission on Critical Infrastructure Protection, the formation of NIPC to coordinate incident response and information dissemination to the public and private business sectors, and the National Plan for Information Systems Protection.)
I think the administration is still lacking in some major areas and it will take years to catch up with all the red tape. On a side note I heard on the radio that Clinton has requested $9M for cyber security, White House officials and the Internet community say they will band together to make computer security a high-profile issue. Hee hee, what do they really expect to do with only $9M?
OpenBSD (Score:3)
I've been using it for five months and it is awesome. Easy to install (newbies: be sure to read the directions), everything works without a lot of messing around (something I can't say about the other freenixes I've tried), and version 2.6 now has OpenSSH to allow you to securely administer your machine (not like it needs much once you have it up and running). Just check out ipnat (network address translation) and ipf (packet filtering) on the OpenBSD website (the man pages are the place to look) for more information
It is definitely better to run a basic OpenBSD firewall than to have Linux, Windoze, Solaris, or whatever else hooked up directly to the pipe. Run it on as little as a 486 with 8MBs RAM and a 200MB HD (you could probably run it on less, but I have only used it with the above minimum hardware). And if you really wanna get funky, run it as your workstation. Lotsa of programs have been ported to it, and the rest you can run using Linux emulation.
Check it out: http://www.openbsd.org/ [openbsd.org]
Also, for those of you interested in OpenSSH outside of OpenBSD use: http://www.openssh.org/ [openssh.org]
For those of you with lingering doubts about ease of installation: five months ago when I first put it up, I was virtually clueless about Unix. I had muddled around with several Linux distros (Red Hat, Mandrake, Slackware, Turbo, Suse, Caldera, and Corel to be precise) but none of them worked as flawlessly as many Linux proponents say (two of them crashed on me (Mandrake and Corel), and many times library inconsistencies made my life a living hell when installing software from the Internet). It took me two weeks of spare time to figure out enough about OpenBSD to go ahead and install it with ipnat and ipf enabled. Since then I have learnt more about packet filtering in my spare time and tightened things up further. The machine has been going for 5 months strong and only came down once because I wanted to upgrade it to OpenBSD 2.6. In short, if I could get it running in two weeks, any regular moron should be able to do it in one, and any Unix knowledgable person should be able to get it going in a couple of hours.
Me Average Joe (Score:3)
I'm an Average Joe. Actually, that's a lie. I know significantly more about computers than 50% of those who saw a commercial or a kiosk at a mall and signed up for a cable modem. In any case, I'm still an Average Joe when it comes to securing my computer. I would have to say that ISPs, especially broadband, need to start taking some responsibility for educating their customers. If a third party uses my computer's resources to attack someone who returns the favor with a lawsuit, you better believe that I'm not going down without involving my ISP. It would be in their best interest to hook me up with a little "Did you know..." pamphlet at the very least. All it took for me to get online was some guy to plug a modem into my wall and drop some IPs into my settings. Shouldn't these things come with a warning sticker like cigarettes or something?
Am I blaming someone else for my own igorance? You tell me. I'm not too worried about a DDoS on my home PC. I'm upset about the tabloid journalism surrounding these events. But, beneath it all, the media is indirectly raising an important issue about making assumptions on your network security.
Thanks for the interview, too. Good stuff.
Peace. Sway
icq 5202646
Peace. Sway
Sorted. (Score:4)
The large numbers of Pixies that can traverse these fat pipes is the main problem as I see it. A good short-term solution would be the replacement of the fat pipes with bundles of thin pipes. At the targets end, each thin pipe would have a small tap - when a DoS attack is detected, simply open the taps in turn to allow the unwanted Pixies to drain out into a bucket. Alternatively, a manned barrier could be set up at the end of each thin pipe, and any swarthy looking, suspiciously odious, black hatted, or otherwise dubious Pixies can be turned away. This doesn't aid tracing the source, but will allow the froce of the attack to be diminished such that the target can remain relatively unscathed.
Tracing an attack to the immediate source can easily be accomplished by having a little valve in the thin pipe that when turned will shut off the Pixie flow. Subsequent Pixes entering the pipe will cause it to bulge gradually as the backlog builds up. By repeating this procedure back from each machine the source will eventually be found. To save having to walk all that way, the valves could have long pieces of string attached to them so they can be turned on and off remotely.
Finding the perpetrator of the DoS is more problematic. These days, the normal breadcrumb back trail can be easily garbled by the less than savoury elemnt on the internet. The new Internet Pixie v6 implements the Taut String from End to End system to tie the source to destination - any severing of the string to re-route it can be instantly detected by loss of tension. However, this does us no good currently.
It only takes a single Pixie to start a DoS attack, and finding it may not always be possible. An amateur will often leave the initial Pixie unharmed, if a suspicious one is found, sieze it immediately (ensure to keep its hands away from any magic pouches/flowers/musical intruments that it may have on its person). A poorly cast Mind Erasure spell can easily be undone by any one of a number of Re Mind perl scripts. A properly cast Mind Erasure can be tricky to undo and will require a special Module be used - if you're not at ease with compiling programs, pop the Pixie in a Jiffy Bag and post it to hemos@slashdot.org (you may need to flatten the packet a little to get it into the floppy disk orifice) - hemos will de-spell it and send the results back by return).
A professional won't allow such evidence to remain - a common method is the Pixie On A Bungee technique. The perpetrator fires said Pixie into the attack machine with a long rubber band attached. With skill, the Pixie shoots in, pushes the Start lever and gets yanked back out at very high speed. A telltale clue of this is often fingernail scratches - sometines a misjudgement as to bungee length can leave fingers embedded in the lever handle. Unfortunately, unless the Pixie drops his ID card, the chances of tracking back further are very small, and really best left to the authorities.
Wingnut
What to do... What to do... (Score:4)
First of all, you should understand System Administration to some degree, this will help you understand basics like daemons, permissions, basic networking, and figuring out what you need and what's just cruft on your system. A text which I gladly recommend is Essential System Administration [fatbrain.com]. This will *not* secure your system but it will help. A lot. Step two, learn about security specifically. You can read Practical Unix and Internet Security [fatbrain.com] which gives a good overview and a fair amount of detail on securing a system, and being assured that they remain that way.
Once you finish doing this, you'll be on your way to being a *competant* admin (even if it is just your own machine). From then on, while you'll be far from a security expert, when some kiddie checks your doorknob, you can be assured that your door is locked, and they'll move on.
I know the books I mentioned cost $35 or so, which if you're young might be a non-trivial amount of money. If it is, I suggest saving up and buying them anyway. If you understand the stuff in them, then you'll know what you need to look up on the net for further info.
Good luck, and feel free to e-mail me with any further questions.
----------------------------
Stay up to date (Score:4)
Having a genuine hacker reverse-engineer a bug in a network service and turn it into a root exploit against your system is very rare; I've never seen it done. Having a script kiddie use that reverse engineering to automatically probe and attempt to crack entire blocks of IPs, on the other hand, that happens every day. The trick is to get the bugfix installed before the kiddies start trying to exploit it.
Start out by removing all network services you don't need and using TCP wrappers to limit access to the ones you do need. A firewall wouldn't hurt, but is probably overkill. Then get onto one of those security mailing lists and make sure that no alert goes by without you either disabling the compromisable program or installing a secured update.
That's about all you need to worry about. Most systems that get broken into are cracked simply because their owner never heard about an imapd exploit 6 months before, shouldn't have been running imapd in the first place, and so wasn't ready when the script kiddies started port scanning for it.
DDoS FAQ available (Score:4)
A DDoS FAQ is available here. [securityportal.com]
Kurt Seifried - Senior Analyst http://www.securityportal.com/ http://www.cryptoarchive.net/ http://www.seifried.org/
University Crackdown (Score:4)
I'm just shaking my head (Score:5)
I especially like the part about the Banks not telling the FBI that the attacks were coming.
I worked with the FBI and Army Investigators at the end of August when some co/lo hosts on our network were used as launch pads for a trin00 attack. At the beginning we couldn't understand why they would have chosen our network (we're that high profile). Turns out that they saw that one of our Co/Lo boxes had been hacked 24 hours before (it was posted on www.attrition.org). From there they scanned the network looking for other boxes (which they found). Assuming this was their SOP I started checking with other UNIX sites which had been posted on Attrition not long after/before ours and found 4 other sites which had the exact same thing happen.
A few notes from that experience.
1. Person(s) responsible were stupid and made numerous mistakes which allowed me to track them all the way back to one of their base accounts. There I found all the source code and numerous binaries involved in my attack and in the others I mentioned above.
2. Although the DDoS attacks can have a devastating effect on the target I'm more concerned with the effect it had on the source network. Our outbound bandwith never went above 60 mb, (we have 150mb), but our core router was slammed to 100% by having to process millions of tiny UDP packets (which is why it never went above 60mb). This effectivly shutdown our backbone for normal customer traffic (which is how we got the FBI to take notice).
Again this happened in late August, about three weeks after it happened at AboveNet on the west coast. Seems to me like this was their (alpha-beta) testing period.
My concern with these tools is if they can be used to attack backbones instead of sites. i.e. Use many distributed systems to flood backbones with hundreds of millions of tiny UDP packets, keeping their processors so busy they can't pass normal traffic.
Or is it just me?
Re:Teach Me How To Be Secure (Score:5)
Apart from the other recommendations made (Essential Sys Admin and Practical Unix Security are must-haves), I would suggest:
- Install TCP Wrappers [purdue.edu] and configure it appropriately. Block anything that you don't need, log everything else.
- Read the corresponding tech tips [cert.org] from CERT [cert.org], depending on what you need (e.g. if you want to set up an FTP server, read the "Anonymous FTP Configuration guidelines")
- Read the WWW security FAQ [w3.org] if you are planning on running a web server.
- Use Tripwire [tripwire.com]. They have a commercial version, but you can always use the free version (1.3). I think they also give the newer version for Linux for free.
- Read other documents at http://www.cert.org/nav/securityim provement.html [cert.org] and http://xforce.iss.net/library/faqs/ [iss.net].
- Be always alert for anything strange that happens on your system. There is no substitute for an alert and informed sysadmin.
--DiegoRe:Teach Me How To Be Secure (Score:5)
Second, print a copy of the Ipchains HOWTO. Yeah, you just killed
Sit down and determine what ports you need wide open, what ports you need one-way and what ports you need closed.
Now you actually write the firewall script. You've got your ports picked and you know the basics of the ipchains command, so it shouldn't be hard. Test it. Have a friend nmap you, etc. Test your applications. Do they still make it out fine? Print it and staple it to the HOWTO.
Why have I told you to make hard copies? That box is probably going to be running without intervention far longer than you will remember every decision you just made. When it does need attention, or you need to do the same sort of thing again, pull down the HOWTO and you have everything you need.
Teach Me How To Be Secure (Score:5)
I'm a SysAdmin newbie. I know only rudimentary UNIX. I am ignorant. I also have a constant cable modem connection.
(There, I said all the facts, so now none of you can for me.)
I want to learn how to be more secure. I don't trust MediaOne to protect me from all the Big Bad Script-Kiddies. I want to do this myself, but I have no idea how to start. And I feel this is a fundamental problem with many people who have constant connections.
The question was asked in the interview but I don't think the answer was satisfactory (instead of "here is a solution" it was more like "here is what everyone should do"). Does anyone have some easy references for people like me who want to keep their constantly connected system "more secure"?
Any pointers or links would be highly appreciated, by myself and others.
------------
Wrong answers (Score:5)
Wrong answer. We need systems that need less system administration, not more system administrators. The problem is that Microsoft and the UNIX/Linux crowd have both botched it so badly it's hard to conceive of getting it right. (The Mac, before it had to interoperate with non-Mac stuff, wasn't bad.) Bottom line: it's got to be secure out of the box.
System administration is an afterthought of existing operating systems. It needs to be a driver in the basic design. UNIX/Linux, in particular, needs a major rethink in this area. There are all those vaguely related text files, and no formal model that defines what a "valid" or "secure" configuration is. If the Linux crowd got their act together on this, it would give them a big edge over Windows. (That's a tough thing for the open source process to do - change a large number of different programs to behave consistently. But that's a different discussion.)
Certainly you could have a network that was immune to DoS attacks. It would look like X.25 or ISDN. You "dial up" an end-to-end connection, you get a virtual circuit, for which you pay by either time or traffic, and you're very limited on bandwidth. That was the telco model of data transmission, and it lost out to the pure datagram model.
The key thing to realize about denial-of-service attacks is this: any attack that's more effective than simply sending datagrams that get dropped represents a problem in the receiver's protocol stack. Once those problems get fixed, the attacker has to generate enough traffic to saturate the links, not just the servers. That takes much more traffic than SYN flooding.
Now we have a straight network congestion problem, made worse by forged source addresses. There are things you can do about that. It's hard, given forged IP addresses, but it's not hopeless. Among other things, that level of traffic is very visible at routers in the path involved. The traffic has wierd statistics; the ratio of IP source addresses to packets is way too high, and you can detect that from a sample of the packets. (If some security vendor isn't selling something that does that, I'd be suprised.) You immediately apply rate limiting to an incoming pipe with statistics like that, (yes, this will hurt legit users too, but only ones on subnets generating attacks), and bitch to the operator of the other end of the pipe, who clearly isn't checking outgoing source IP addresses. If something like that is deployed at major routers, it will a strong incentive for ISPs and other subnet operators to implement IP source address checking.
As for an attack that simply consists of huge numbers of legitimate requests from captured zombies, that's a pure congestion management problem, to which known techniques can be applied.
And please, stop making dramatic announcments to the press about how it's unfixable.
Re:Teach Me How To Be Secure (Score:5)
Anyways, the Sercity-How-To [tucows.com] would be an excellent place to begin. Along with check some of the other how-tos. Shadow Password [tucows.com] and Secure Programs [tucows.com] would also be decent documents. Beyond that, make sure to keep a constant eye on Bugtraq (mailing list) as well as CERT advisories for newly found bugs.