LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices



Reply
 
Search this Thread
Old 11-05-2007, 07:43 PM   #1
joji_in_changwon
LQ Newbie
 
Registered: Jun 2005
Posts: 13

Rep: Reputation: 0
Concerning DDoS attacks


Hello
I am concerned about DDoS attacks on domain name servers and
also DNS servers and I am trying a new method of filtering.
However, I needs some help regarding the following:

a) what type of processes are invoked (programs)
during a smurf type attack? the program names would be
nice. Tcp/ip has a handshaking, and attackers
make use of this by spawning a processes
on the server. What process?

b) Does the Linux kernal have limitations form DDoS type
attacks?

c) What is the best method to measure the processing time
of a running program. I would like to time it.

Looking forward to your comments.

Sincerely
Bear
 
Old 11-05-2007, 09:39 PM   #2
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
Quote:
Originally Posted by joji_in_changwon View Post
a) what type of processes are invoked (programs)
during a smurf type attack? the program names would be
nice. Tcp/ip has a handshaking, and attackers
make use of this by spawning a processes
on the server. What process?
Because an echo request wasn't sent by the victim, there's no process expecting an echo reply. The attacker spoofed the victim's source address when pinging subnet broadcast addresses, causing all the echo replys (if any) to be sent to the victim's IP. A smurf attack isn't an attack on a system's processing, it's an attack on its connection's bandwidth.

That said, this should in fact be a pretty obsolete attack today (although I can't back that up with any statistics or anything). I doubt there are many operating systems shipping with a configuration which responds to broadcast ICMP echo requests. In any case, if you don't want your GNU/Linux box to do so, make sure you have icmp_echo_ignore_broadcasts set to 1. Keep in mind this only prevents your box from participating in a smurf attack - you have no control over other people's setups, as explained below.

Quote:
b) Does the Linux kernal have limitations form DDoS type
attacks?
There isn't really anything the kernel can do against a DDoS attack on bandwidth. You have no control over what people send you. If you are under a DDoS bandwidth attack, you'll need your ISP to mitigate the attack upstream.

Quote:
c) What is the best method to measure the processing time
of a running program. I would like to time it.
If you are referring exclusively to CPU time, the top command shows you this on the 11th column. If you want to time a program you are about to execute, just place a time command in front of it.
Code:
time ./example.sh

Last edited by win32sux; 11-05-2007 at 09:58 PM.
 
Old 11-06-2007, 08:12 PM   #3
joji_in_changwon
LQ Newbie
 
Registered: Jun 2005
Posts: 13

Original Poster
Rep: Reputation: 0
win32sux

Quote:
Originally Posted by win32sux View Post
Because an echo request wasn't sent by the victim, there's no process expecting an echo reply. The attacker spoofed the victim's source address when pinging subnet broadcast addresses, causing all the echo replys (if any) to be sent to the victim's IP. A smurf attack isn't an attack on a system's processing, it's an attack on its connection's bandwidth.

That said, this should in fact be a pretty obsolete attack today (although I can't back that up with any statistics or anything). I doubt there are many operating systems shipping with a configuration which responds to broadcast ICMP echo requests. In any case, if you don't want your GNU/Linux box to do so, make sure you have icmp_echo_ignore_broadcasts set to 1. Keep in mind this only prevents your box from participating in a smurf attack - you have no control over other people's setups, as explained below.

There isn't really anything the kernel can do against a DDoS attack on bandwidth. You have no control over what people send you. If you are under a DDoS bandwidth attack, you'll need your ISP to mitigate the attack upstream.

If you are referring exclusively to CPU time, the top command shows you this on the 11th column. If you want to time a program you are about to execute, just place a time command in front of it.
Code:
time ./example.sh

Replay,

Thank you for replying and I understand what you said. What I am
trying to is design a different method to combat DDoS attacks.
I am doing it at the Process level. Currently running programs
on a Unix or Linux system are shown on the Process stack.
Placing limitations on the number of processes and types running
would regulate a DDoS attack.

In the future, the people who are doing DDoS attacks will conform
to network configuration thus making router filtering difficult.

I am trying to design a program so a server can stay
up during a DDoS attack.

This is my thought.

Any help would be appreciated.

Sincerely
Bear

Last edited by joji_in_changwon; 11-06-2007 at 08:14 PM.
 
Old 11-06-2007, 09:08 PM   #4
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
Quote:
Originally Posted by joji_in_changwon View Post
Placing limitations on the number of processes and types running
would regulate a DDoS attack.
Then you must be talking about some other type of DDoS attack. Perhaps you are referring to local attacks such as fork bombs? Server-side limits won't be of any help during DDoS smurf-like bandwidth attacks.

Quote:
I am trying to design a program so a server can stay
up during a DDoS attack.
Once again, there's nothing you can do to on the server to restore service during a DDoS smurf-like bandwidth attack (aside from waiting for the storm to pass). Your ISP needs to step into the equation. What botnets send your way is completely out of your control. You won't find a server-side solution to a WAN-side problem. If you really want to design something to combat DDoS smurf-like bandwidth attacks, my suggestion would be to write something that runs on ISP's upstream hardware, as that's where countermeasures would be conceivable. Keep in mind you will have some extremely tough competition, though.

Quote:
In the future, the people who are doing DDoS attacks will conform
to network configuration thus making router filtering difficult.
We've actually been experiencing this phenomenon for many years. DDoS attacks designed to look like legitimate traffic are insanely destructive (some even make the mainstream news). Fighting them off is somewhat of an art form AFAICT. If the botnet zombies need to actually establish a connection (as opposed to only send data) in order for the attack to succeed, then it is indeed feasible to implement on-site countermeasures. Is this the type of scenario you are referring to? Please provide as many details as possible.

Last edited by win32sux; 11-06-2007 at 09:42 PM.
 
Old 11-06-2007, 11:06 PM   #5
joji_in_changwon
LQ Newbie
 
Registered: Jun 2005
Posts: 13

Original Poster
Rep: Reputation: 0
Question

Quote:
Originally Posted by win32sux View Post
Then you must be talking about some other type of DDoS attack. Perhaps you are referring to local attacks such as fork bombs? Server-side limits won't be of any help during DDoS smurf-like bandwidth attacks.

Once again, there's nothing you can do to on the server to restore service during a DDoS smurf-like bandwidth attack (aside from waiting for the storm to pass). Your ISP needs to step into the equation. What botnets send your way is completely out of your control. You won't find a server-side solution to a WAN-side problem. If you really want to design something to combat DDoS smurf-like bandwidth attacks, my suggestion would be to write something that runs on ISP's upstream hardware, as that's where countermeasures would be conceivable. Keep in mind you will have some extremely tough competition, though.

We've actually been experiencing this phenomenon for many years. DDoS attacks designed to look like legitimate traffic are insanely destructive (some even make the mainstream news). Fighting them off is somewhat of an art form AFAICT. If the botnet zombies need to actually establish a connection (as opposed to only send data) in order for the attack to succeed, then it is indeed feasible to implement on-site countermeasures. Is this the type of scenario you are referring to? Please provide as many details as possible.

Reply
I agree. The following is my thinking and questions.

Yes I am trying to design a standlone defence system for
a computer but I am working blind.

Regarding the different types of DDoS attacks, does these types of
attacks increase the number of processes currently running on
a computer?

If this is true, then there may be a way to stop
the attack on the server.

Looking forward to your response.

Sincerely
Bear
 
Old 11-07-2007, 12:02 AM   #6
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
Quote:
Originally Posted by joji_in_changwon View Post
Regarding the different types of DDoS attacks, does these types of
attacks increase the number of processes currently running on
a computer?
If we are talking about attacks that require a connection to be established, then yes, many do. But it really depends on the specific daemon which is under attack. For example, Apache might spawn one process per connection, but thttp won't. Even so, daemons will typically have a built-in method for establishing process limits - making this type of third-party application unnecessary.

Quote:
If this is true, then there may be a way to stop
the attack on the server.
Yeah, but it's not gonna be just a matter of setting a limit on the amount of processes being spawned, which is what I think you are envisioning. Here's a really bad analogy I just came up with:

Let's say I have a candy store. My competition across the street decides to put me under denial-of-service on Halloween, so that they will get all the Halloween shoppers. So they start sending tons and tons of ordinary-looking brainwashed zombie kids into my store one after the other. These kids just come in and browse around, they fill up their shopping carts with candy, and then after a while they just leave without buying anything. I've got so many of these kids in my candystore that kids which actually want to buy candy for real simply can't get in (so they go to the candy store accross the street instead).

Will establishing a limit of, say, 25 kids in the store at-a-time ("server connections") help me with my problem? No, because real customers still won't be able to get in. Will establishing a limit of, say, two sales reps ("server processes") help me with my problem? No, because my problem isn't that I have too many sales reps working - it's that I have too many brainwashed zombie kids pretending to be shopping, preventing real customers from getting into the store. Either of these limits might make things even worse for me.

The point being that a high number of processes which might get spawned by some daemon to handle a certain load is only a symptom of the condition of being under cyber attack. What we really need to do IMHO is stop the attack by addressing the underlying problem. Limiting our ability to provide service (considering we presumably have no way to distinguish between a real shopper and a zombie shopper when they walk into the store) might help us deal with the attack - at the cost of having everyone be affected - but it won't do anything to help stop the attack.

As I said before, lots of daemons have config options where we can set process limits. But there's also tools which can monitor processes and take certain actions depending on load, etc. One example is monit. But for our DDoS, what we really need is a guard to stand at the door and only let in kids which are real shoppers, by using some sort of scanner which can determine when a kid is a brainwashed zombie sent by the competition. Making that determination is the key to making sure we are able to sell candy on Halloween.

Last edited by win32sux; 11-07-2007 at 12:55 AM.
 
Old 11-07-2007, 04:51 AM   #7
ledow
Member
 
Registered: Apr 2005
Location: UK
Distribution: Slackware 13.0
Posts: 241

Rep: Reputation: 34
Quite possibly the strangest analogy that I ever heard.

And in answer to the poor chap's questions (and to confirm the existing answer)... resource-consuming DDoS attacks are already very well dealt with (disk quota's, process limits, even the kernel's OOM killer etc. before you even get into processes which "protect" themselves against such things). There's little reason to require third-party software to do this - it won't be anywhere near as effective and it's very difficult for an outside process to determine the difference between high traffic and an actual attack. The only way to stop such things is a hard-coded limit (whether it be in the kernel or a third-party program) and the kernel already has some very good facilities for that and projects like SELinux give you even more.

Fork-bombs (which is what I believe you are talking about when you say you are looking at the number of processes) are easily dealt with using such in-kernel facilities. A third-party utility (which presumably would have to run as root) would do no better, although it might make dealing with things more pleasant for the administrator. There are also dozens of "Intrusion Detection Systems" and similar programs that already manage all of that side too.

And as noted above, the other type of DDoS - bandwidth-consuming DDoS attacks - are impossible to defend against - even for a large ISP, they only way that they "survive" a DDoS attack is that their bandwidth is big enough to cope with it and then filter what gets passed on. And all they can do if *their* bandwidth is consumed is look further upstream for a solution - who will hopefully have a lot more bandwidth and can cope with the incoming data.

This is the problem with DDoS - there is no "solution" except to get someone who can afford to recieve and/or then deliberately NOT FORWARD the traffic onto you - which involves a lot of packet analysis by their routers and is "expensive".
 
1 members found this post helpful.
Old 11-07-2007, 07:06 PM   #8
joji_in_changwon
LQ Newbie
 
Registered: Jun 2005
Posts: 13

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by win32sux View Post
If we are talking about attacks that require a connection to be established, then yes, many do. But it really depends on the specific daemon which is under attack. For example, Apache might spawn one process per connection, but thttp won't. Even so, daemons will typically have a built-in method for establishing process limits - making this type of third-party application unnecessary.

Yeah, but it's not gonna be just a matter of setting a limit on the amount of processes being spawned, which is what I think you are envisioning. Here's a really bad analogy I just came up with:

Let's say I have a candy store. My competition across the street decides to put me under denial-of-service on Halloween, so that they will get all the Halloween shoppers. So they start sending tons and tons of ordinary-looking brainwashed zombie kids into my store one after the other. These kids just come in and browse around, they fill up their shopping carts with candy, and then after a while they just leave without buying anything. I've got so many of these kids in my candystore that kids which actually want to buy candy for real simply can't get in (so they go to the candy store accross the street instead).

Will establishing a limit of, say, 25 kids in the store at-a-time ("server connections") help me with my problem? No, because real customers still won't be able to get in. Will establishing a limit of, say, two sales reps ("server processes") help me with my problem? No, because my problem isn't that I have too many sales reps working - it's that I have too many brainwashed zombie kids pretending to be shopping, preventing real customers from getting into the store. Either of these limits might make things even worse for me.

The point being that a high number of processes which might get spawned by some daemon to handle a certain load is only a symptom of the condition of being under cyber attack. What we really need to do IMHO is stop the attack by addressing the underlying problem. Limiting our ability to provide service (considering we presumably have no way to distinguish between a real shopper and a zombie shopper when they walk into the store) might help us deal with the attack - at the cost of having everyone be affected - but it won't do anything to help stop the attack.

As I said before, lots of daemons have config options where we can set process limits. But there's also tools which can monitor processes and take certain actions depending on load, etc. One example is monit. But for our DDoS, what we really need is a guard to stand at the door and only let in kids which are real shoppers, by using some sort of scanner which can determine when a kid is a brainwashed zombie sent by the competition. Making that determination is the key to making sure we are able to sell candy on Halloween.


Thank you for your response.

I understand what you are talking about but DDoS in it's true
form is a weapon that can be pointed at any server.

A stand must be made. If killing processes about a limit works
for now then it will help keep up a server for now.

Another solution to the problem would be hardware. Place a
band limiting device in front of the server.

A little note,
Solving a problem envolves putting attitudes and differences
aside and focusing on the problem.
Maybe current technology may or may be used but the idea is
to focus on the problem and use the resoures avaliable.

I believe that is how WW2 was won. Not by complaining but by
doing and trying and putting heads together.


Sincerely
Bear.
 
Old 11-07-2007, 07:25 PM   #9
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
I just hope that you now understand why process limits won't help you restore service during a DDoS bandwidth attack.

Last edited by win32sux; 11-07-2007 at 07:30 PM.
 
Old 11-08-2007, 12:18 AM   #10
joji_in_changwon
LQ Newbie
 
Registered: Jun 2005
Posts: 13

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by win32sux View Post
I just hope that you now understand why process limits won't help you restore service during a DDoS bandwidth attack.
Reply
Thank you for your reply.

I understand your comment but is there any thing available now?

Some other things to note:
1) process profile over a year.
2) What is a limiting process factor for a given computer?
start with one then go from there.
3) DDoS requires IPS to work together, how can this be done?
4) If programs do not fork processes, then maybe forking
needs to be considered.
etc.

All I am saying try because of the animal that DDoS is.

Sincerely
Bear.
 
Old 11-08-2007, 01:54 AM   #11
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
Quote:
Originally Posted by joji_in_changwon View Post
I understand your comment but is there any thing available now?
Go to, for example, Cisco's website and have a look at the anti-DDoS solutions they offer. Notice how all the solutions are based on traffic (as opposed to process) analysis. Also notice who they are marketed toward.

Quote:
Some other things to note:
1) process profile over a year.
2) What is a limiting process factor for a given computer?
start with one then go from there.
3) DDoS requires IPS to work together, how can this be done?
4) If programs do not fork processes, then maybe forking
needs to be considered.
etc.

All I am saying try because of the animal that DDoS is.
The bandwidth DDoS attacks which this discussion started with would NOT be mitigated by any amount server-side process limitations or profiling. This has already been explained to you *several* times. What part are you having trouble understanding?

Last edited by win32sux; 11-08-2007 at 02:06 AM.
 
Old 11-08-2007, 05:19 AM   #12
ledow
Member
 
Registered: Apr 2005
Location: UK
Distribution: Slackware 13.0
Posts: 241

Rep: Reputation: 34
Quote:
Originally Posted by joji_in_changwon View Post
I understand what you are talking about but DDoS in it's true form is a weapon that can be pointed at any server.
Yes, and there's nothing you can do to stop them pointing it at you.
You can don a bulletproof vest but it's still gonna hurt like hell and there's *nothing* you can do to stop them pulling the trigger. And if they fire enough bullets at you, no vest in the world can help you.

There is currently NO way to stop a bandwidth-DDoS - theoretically, practically or otherwise - except for asking an upstream provider with the hardware to cope to filter on your behalf. Why do you think these enormous gambling companies etc. are forced off the web themselves? They can't just throw brains at the problem, all they can do is to throw money at it by getting a larger and larger connection and hope their upstream provider can filter it better for them.

Quote:
Originally Posted by joji_in_changwon View Post
A stand must be made. If killing processes about a limit works for now then it will help keep up a server for now.
It doesn't. It helps a little against certain types of (non-bandwidth) attacks on certain types of processes. And the tools to "help" are there. People use it everyday. Large companies have it enabled. Most secure linux distributions have it enabled. It doesn't do much at all. If you want to use process limits, do so. They are here, now, today and you can turn them on. They won't do much at all against a DDoS of any type. Similarly, SYN-cookies and a thousand other measures - they worked well against particular types of primitive attacks and then people moved into the era where a bandwidth-DDoS attack was much easier than trying to crash or confuse remote servers. Anything that you COULD do against these problems, you CAN do today. Nothing helps much at all.

Quote:
Originally Posted by joji_in_changwon View Post
Another solution to the problem would be hardware. Place a band limiting device in front of the server.
NO! If use place a bandwidth limiting device in front of your server on YOUR side of the connection, it won't help at all. It can't magically increase your bandwidth. All it will do it make sure that only genuine requests get to your servers. If you only have 1 genuine request out of a million fake ones, then it still has to recieve and process 1,000,001 requests, which take 1,000,001 lots of traffic.

If you place it on the upstream side of your connection - THAT'S WHAT WE ARE TALKING ABOUT. That's all you can do - get your upstream provider to filter and limit traffic on your behalf. It's not a "solution", it's circumventing the problem. But that's all that can be done.

Quote:
Originally Posted by joji_in_changwon View Post
A little note, Solving a problem envolves putting attitudes and differences aside and focusing on the problem. Maybe current technology may or may be used but the idea is to focus on the problem and use the resoures avaliable.
Problem: You can't stop a DDoS that's aimed at you, short of getting an upstream provider (with more resources than yourselves) to do it for you.

Attitude: If you can't stop it, even if you're a group of experts who designed the IP infrastructure (DNS root servers have DDoS attacks against them all the time, as do any large company like Microsoft etc., as do almost all "money" sites like banks, Paypal, online gambling etc.), and there is no current theoretical way to reduce the attack, all you can do is handle it the best you can until you find one. Which means asking your upstream provider to stop it for you. You can do research on the side if you want but if you understand how the IP infrastructure works, you'll find that there's not an awful lot than can be done at all, now or in the future, without an enormous redesign.

That's what we've all been focusing on. All of the resources available are already in use (process limits, IP filtering etc.). There's nothing you, as an end-recipient, can do to stop people sending you data, short of turning off your Internet connection. You can't "decide" what to recieve - you get what is sent and you can only choose not to reply. By then it's too late. You've wasted a mbps in recieving it. Your upstream provider can decide what to pass on to you but they themselves cannot decide what to recieve. Whether you computer has 10 processes or 12 makes no difference. Whether it's at 100% CPU or 0% makes no difference (and DDoS'd computers tend to go to 0% CPU not 100% when attacked because there's just nothing for them to do). You can spot changes, yes, but that won't stop or mitigate the attack. All it will do is let you know.

Quote:
Originally Posted by joji_in_changwon View Post
I believe that is how WW2 was won. Not by complaining but by doing and trying and putting heads together.
Please stop being stupid by bringing in pathetic analogies and somehow comparing a World War to a technological problem that is dealt with every single day by thousands of people around the world.

The heads have been put together and that's where you are today. There are multi-million dollar companies that make a living doing nothing but trying to solve DDoS attack problems - they make very little practical progress to an end-user like yourself and have some of the best networking brains on their side. All they can do is look for patterns and reject false requests quicker than "ordinary" equipment... which can give very large ISP's a small percentage advantage in dealing with DDoS. And it is only a small percentage.

In general, there's no point fighting a battle you can't win. Much better to focus the energy on doing something practical, i.e. forming a new "internet" that is resistant to such DDoS - that's part of what IPv6 was supposed to do. Even they (the IP working groups) couldn't do it.

Now, let's get an analogy you can understand.

People keep ringing your business phone. Some of them are genuine customers. Some of them are hoax calls. You have no way of knowing because the attackers are able to fake their Caller-ID. So you have to answer *every* call. You can't tell the difference between the attackers and your real customers without answering the phone and speaking to them, by which time you've wasted several seconds talking to them. While you do that, other calls can't get through - both genuine customers and attackers.

Meanwhile your servers (the people who actually DO the work for the customers) are sitting absolutely idle because so few genuine customers can actually get through amid all the fake calls. Your phone rings constantly day and night. What do you do?

Your options are:

1) Call the authorities/telephone company in to filter your calls, track the offenders and get them to stop. There will be THOUSANDS of fake calls from THOUSANDS of hijacked phone lines. It will take forever to trace them all and by then a thousand more will have joined in. Even then, the source of the phone calls will be innocent people whose phone lines have been hijacked by the real attacker to make the phone calls.
2) Change your number. This is quite a common circumvention - basically you move your IP range to another one. The problem is that your genuine customers have to be informed too, and then the attacker is free to resume their attack on your new number.
3) Hire more telephone-centre staff and put in more phone lines. And more. And more. And more. And hope that the attacker can't ring as many phones as you can answer.

Now do you get it? It's not a problem that can be solved by putting a magic box into each network. It's not a problem that can be solved by turning some fanciful "futuristic" option on. A DDoS-bandwidth attack is like trying to take a million fake phone calls looking for the one real customer that's phoned.

Similarly, DDoS attacks that target individual processes/services (i.e. things that try to crash Apache etc.) are a never-ending problem that you can only "solve" by keeping your software up-to-date and by using the readily-available and already-suitable-for-the-job monitoring software. You can't "stop" them. You can only fend them off for a short while. Even then, flooding a webserver with requests will quickly turn into a bandwidth-DDoS attack.

Everything that can be done, is being done. It still won't help you keep your website up if someone decides to attack it with a large enough botnet.
 
Old 11-08-2007, 05:27 AM   #13
ledow
Member
 
Registered: Apr 2005
Location: UK
Distribution: Slackware 13.0
Posts: 241

Rep: Reputation: 34
Sorry... I meant to add this too...


Have you heard of Akamai? They are a large internet company that often deal with websites that are being DDoS'd - they help Microsoft, gambling websites, banks, the BBC (which runs one of the most popular sites on the Internet). Their solution? They have thousands of servers across the world on high-bandwidth connections that serve webpages on behalf of whatever company pays them. That's all they can do.

And when a company is DDoS'd, they go to Akamai and basically say "Please let me use your thousands of high-bandwidth servers to serve my web page". And that's exactly what happens. That's how places like Windows Update are still running today - they have far too much traffic for one place to deal with them by itself, so they contract Akamai to use all their servers to help spread the load.

When websites are DDoS'd, they use Akamai. Paypal have used them, I think, Microsoft uses them all the time, places like Yahoo etc. use them too when they are attacked. That's all that these massive companies can do - hire more bandwidth to deal with the problem.
 
Old 11-27-2007, 12:12 PM   #14
chellemybelle
LQ Newbie
 
Registered: Nov 2007
Location: OK
Distribution: Fedora 4 -I think
Posts: 7

Rep: Reputation: 0
That's quite an interesting argument, you have given me a lot more insight into the problem than my textbook did. Thank you for putting DDoS attacks into perspective in that manner.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
DDOS Attack studiofos Linux - Security 3 09-12-2006 04:42 AM
What is the best router that can prevent most DDoS for under $5k? abefroman Linux - Security 2 03-02-2006 10:26 AM
ddos or hacked? Please help!! lucastic Linux - Security 8 12-16-2004 08:56 PM
Ddos Mag|c Linux - Security 2 08-16-2003 10:41 PM
ddos attack ashis Linux - Security 1 06-14-2001 03:31 AM


All times are GMT -5. The time now is 01:16 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration