Who's cloggin' up the FALfiles...

[Dr. X]

AGAIN?!! :mad::mad: :mad:

as ever,
Dr. X :mad:

[jerrymrc]

It was fine until 7am MST and then all hell broke loose. last peek there were over 1500 guests and 2300 members.

[lew]

Sorry, I'll stop.:D

I'm sure the 3500 members and 1500 guests aren't helping matters.

[AndyC]

Starting to become ridiculous :mad:

[Dr. X]

GET THE VISITORS SORRY ASSES OFF THERE...I haven't been able to check the Files all day...and you don't want that to happen during a FULL MOON!!!!!:mad: :mad: :mad:

beside myself,
Dr. X :mad:

[AndyC]

I thought visitors couldn't browse the 'files - only registered people?

[AndyC]

Here's something FAL-related in the meantime (from a forthcoming Brit movie called Hot Fuzz (http://www.workingtitlefilms.com/trailers/hotfuzz_trailer_xlarge.php)):

http://img175.imageshack.us/img175/6551/hotfuzzlh4.jpg

[AndyC]

FAL-files:

Currently Active Users: 3216
There are 1699 members
1517 guests on the boards.

It's sort of working now...

[Dr. X]

Not fer me...:mad: :mad: :mad:

as ever,
Dr. X :mad:

[deltaten]

Mike or raeldridge over at the AK side just got on long enough to check...850+/- members and over 5000 "guests"

'Tude sez that it's odd, since Jen's at the big show now
H-m-m-mm-m?

Denial of service attack, no doubt

We're ALL refugees now!

Best to all,
Paul

[HottAK47]

AGAIN?!! :mad::mad: :mad:

as ever,
Dr. X :mad:


It sure aint me, I been a member for five years without a single post. I'm willing to bet that thats a record. Y'all let me know if I get an award or anything.

[Dr. X]

We're ALL refugees now!

NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!!!!!!!!!!! !!!

just this side of complete wig-out,
Dr. X :eek:

[Dr. X]

Y'all let me know if I get an award or anything...

You asked for it...:p :D :D

as ever,
Dr. X :D

[jerrymrc]

Mike or raeldridge over at the AK side just got on long enough to check...850+/- members and over 5000 "guests"

'Tude sez that it's odd, since Jen's at the big show now
H-m-m-mm-m?

Denial of service attack, no doubt

We're ALL refugees now!

Best to all,
Paul

I think this should be the "alternate" place to go. No EBR's here!
How's the heating going Paul? It was -3 two days ago here.

[jerrymrc]

I just went back. I got in but did one check in the marketplace and everything after that was busy. 1600 members and 1491 guests.

[Dr. X]

I was actually able to reply to two whole messages when the too busy came back on...Dammit, man! :mad:

as ever,
Dr. X :mad:

[SmokeEater2]

Thats IT! The freakin' band-width suckin' guests have gotta'go!

[Dr. X]

estupido fuqueros...:mad: :mad: :mad:

really pissed now,
Dr. X :mad:

[Mainer]

NOW I know what it is like to be a FALaholic.

Craving for something ya can't get. Like loged on to the Files :rolleyes:

Jen's out of town? Explains why visitors are surfin. :(

[Palerider]

_BTT_

[Dr. X]

IT'S HAPPENING AGAINNNNNNN!!!!!!:mad: :mad: :mad:

AS EVER,
dR. x

[akfanatic]

WTF?!?!?
I come back after a VERY shitty week and cant get on!!!

[Dr. X]

It started just before 7 pm eastern. I come through a frackin' ban and then can't get on the Files... I'm jonesin', mang! :eek:

as ever,
Dr. X :cool:

[Dr. X]

At the risk of incurring the wrath of Hugh Jass: I WANT MY FALFILES!!! :mad:

as ever,
Dr. X :mad:

[Goldenspurholderx2]

Yeah bro, you and me both.

[Slim]

just my opinion but I believe it has something to do with a certain vendor pre-posting a group buy in Marketplace this weekend

and promising to release the details of the buy and the products offered on Monday (today) at 8:00 am eastern

I already knew it was gonna happen as did the folks who replied to that thread this weekend

I could be totally wrong , it`s just a theory

[powermad]

I was getting the server to busy notice yesterday morning and could barely get on all day.

[English Mike]

This has nowt to do with Ricketts' announcement - someone out there is trying to kill the Falfiles.

Could be anti gunners(doubt it)

Could be extortionists(quite possible)

Could be Bwian

Whoever it is, I hope Jen has the authorities informed, as DDoS is a criminal action.

[powermad]

Another site I am on stopped this kind of crap by going to a paid membership.
Non paying members were only alowed to post in one forum, no search and not able to view or post pix.

It put an end to the BS real fast.

[English Mike]

Another site I am on stopped this kind of crap by going to a paid membership.
Non paying members were only alowed to post in one forum, no search and not able to view or post pix.

It put an end to the BS real fast.

I dunno about that; there's a lot of good people on the 'files who aren't contributors (though they should be...) & I reckon we'd lose the easygoing attitude that generally exists there.

Certainly make it members only & have some sort of vetting procedure for new ones - there's at least 20 recently joined who are definitely spammers to my mind.

Maybe have each new member monitored by an established one for a while - then killing off the spamturds will be personally satisfying.

(Hmm, I think I'll change my Avatar - looks like I've got tits!)

[Andy the Aussie]

My guess (and nothing more) is some little fucktard geek with an attitude toward guns had made the Fal Files his/her personal project. I could be wrong but it sure seems like someone is going to a great deal of effort to screw the place up.

I am starting to go into withdrawals.

Andy:(

[mike minihan]

No lights coming on here,or falfiles,apparently.
It's rather suspicious that we have had as many visitors as members,sometime more.

I see it as a lowlife denial of service attack,probably,as Doc says utilizing bots.Here's hoping Jen gets it figured out soon and prosecutes the little shit smears to the full extent of the law.

Change the avatar? I thought it was C.E.
best regards,
Mike Minihan

[English Mike]

Change the avatar? I thought it was C.E.
best regards,
Mike Minihan

You can go off people, you know.....:p

[AndyC]

I'm in the mood to murder someone - by the way, nice tits, Mike :p

[Andy the Aussie]

I'm in the mood to murder someone - by the way, nice tits, Mike :p.....yes if a person is IDed as responsible for this a good 'ol time lynching is in order....!!

I feel vaguely "dirty" at the discussion of Mikes "attributes"....:eek:

[mike minihan]

Things could be MUCH worse.Most of the guys develop
the oft discussed,much feared Dread Dresser Disease in their late 40's or early 50's.
Now,if that don't terrify you,you aren't paying attention.

best regards,
Mike Minihan

[powermad]

I dunno about that; there's a lot of good people on the 'files who aren't contributors (though they should be...) & I reckon we'd lose the easygoing attitude that generally exists there.

Certainly make it members only & have some sort of vetting procedure for new ones - there's at least 20 recently joined who are definitely spammers to my mind.

Maybe have each new member monitored by an established one for a while - then killing off the spamturds will be personally satisfying.

(Hmm, I think I'll change my Avatar - looks like I've got tits!)

LOL... man boobs :eek:


When that went into effect there was alot of people that had the same views and concerns that you have.
But when think about it, say $25 a year isn't that much compared to what we all spend in a year on whatever hobby/obsession we have.

I seen guys that would spend thousands on their stuff and balk at $25 to be able to have a secure place to hangout with like minded people without having the site crashed every other day.

It did not put most of the folks off, in fact it made for a tighter knit community.

Just my two coppers on it.
Ron

[AndyC]

I've contributed - just don't have my status yet. I PM'd Jen to tell her no rush - I realise she's busy :cool:

[Dr. X]

I blame the Bush administration! :rolleyes: Oh, and Andy? I liked the santa-smiley better...

as ever,
Dr. X :cool:

[Andy the Aussie]

Given the contribution can be as low as $5 a year then it is not going to break the bank. It will see many of the good new members who just browse in lost though. If they can't get a real feel for "The Files" they wont realise just what good value it is. Difficult to say just what to do to be honest.

I do know we should strive to keep the English out though...they don't seem to be able to put together a decent cricket team nor do they fancy a tub enough for public fraternisation.....(that should get a bite).

Andy:p

[AndyC]

Oh, and Andy? I liked the santa-smiley better...

as ever,
Dr. X :cool:
Ok, ok, ok.... it's back :p

BTW - I posted a link to the Rawles book you wanted on that other thread, mate :D

[Dr. X]

Actually, the linky was for GSHx2. I already have a copy, but thanks. Oh, and thanks for the smiley as well...:D

as ever,
Dr. X :cool:

[W.E.G.]

Preventing Denial of Service Attacks
by Avleen Vig
06/24/2004

The Internet is no longer the cute and fluffy cloud it once was. Protecting your servers, workstations, and networks can only go so far. Attacks that consume your available Internet-facing bandwidth or overpower your router's CPU can still take you offline. This article will help you mitigate the effects of such attacks, guiding you in what to do if you are attacked.

The techniques here apply equally well to FreeBSD 4.x and 5.x.

Different Types of Attacks
Denial of Service (DoS) attacks set out to remove a service from functional use by its clients. Web servers will stop serving web pages, email servers will stop accepting or delivering email, and routers will go dark, taking you off the Internet all together.

Denial of a particular service will come in one of two forms:

Complete consumption of a resource such as bandwidth, memory, CPU, file handles, or any other finite asset.
Exploiting a weakness in the service to stop it functioning or causing the service to crash.
Over the last few years, attackers have refined their methods. As developers make software more reliable and more resilient to DoS, the attack vectors have changed to target hard-to-secure parts of a service. We'll discuss the first type of attack and what we can do to protect our services from it.

Make the Most of your Services
Protecting your services from attack is similar to tuning your services for maximum performance. The greater the load you can handle, the more resilient you are. Things change slightly when the attack alters the profile of your service.

Related Reading


BSD Hacks
100 Industrial Tip & Tools
By Dru Lavigne

Table of Contents
Index

For example, if you have a web server tuned to transfer large files and the attack forces through a lot of small, short-lived transactions, you could find you run out of network memory buffers very quickly. I would recommend starting by reading the papers on tuning FreeBSD for different applications. The paper describes good ways to start tuning your servers. Also, the tuning(7) man page is an excellent resource on performance improvements.

Analyzing and Blocking Denial of Service
The first step to protecting yourself from an attack is to understand the nature of different types of attacks. As we said earlier, resource-consumption attacks target your system in places that can cause bottlenecks. The most popular targets are network bandwidth, system memory, network stack memory, disk I/O, operating system limitations such as a limit on the number of open file handles, and the CPU. These bottlenecks can be on your systems or in your network hardware.

Attacks on Bandwidth
Attacks against your network bandwidth are difficult to defend. How you deal with them depends heavily on your network topology and how helpful your ISP is. Start by asking the following questions:

Is the attack against a single host, or multiple hosts?
Is the attacker hitting a small set of ports, or randomly hitting many ports?
Does the attack consists of protocols that would normally not be used with the attacked servers?
We are fortunate today that most attacks are simple in their nature. They choose one or two styles of attack and at most a small number of IP addresses. This makes sense — bandwidth is as hard for attackers to acquire as it is for us to defend. If your Internet-peering bandwidth is not saturated, the accepted approach is to block traffic to the attacked host(s) at your gateway.

It's a good idea to run tcpdump on the attacked servers if you can, to see what kind of attack is taking place. Look for floods of very similar packets — all TCP SYN, UDP, or ICMP. Look for packets all headed for a particular port. If you find the number of source IP addresses is reasonably small, it may be possible to block packets based on source address.

However, if the source addresses are highly volatile in addressing, this can indicate spoofing or forging. When this is the case, you may need to look for other similarities in the attack such as packet size, window size, fragmentation, etc. If you have the ability to block based on these less common criteria you may want to investigate here further.

With modern, multi-gigabit networks, it is not unusual for an Internet connection to have more bandwidth than the local LAN, so it may be possible for you to block the attack at your Internet gateway. More often than not though, this does not apply. Having your Internet bandwidth consumed can be tiring and frustrating. This might be the right time to call your ISP, if they're willing to work with you on these problems.

Before you make the call, try to analyze the attack. This will help your ISP in selectively filtering the attack off your network. If filtering is possible, you'll have one of two common options available: selectively filtering out the attacking systems or dropping all packets to the attacked servers. The latter is easier to manage and is more effective in the event that the attack profile changes against those hosts.

If you run Border Gateway Protocol (BGP) at your Internet gateway to announce your IP space to the Internet, you may have a third option, one that UUNet, C&W, XO, and many ISPs allow users to export routes as small as /32 with a special community string that causes their border routers to drop all incoming data for the route. This is a highly effective method of dropping an attack with the least damage to yourself and your ISP. Of course, this only works well with a small number of hosts under attack and if your ISP offers such functionality. Contact your ISP to find out. The obvious downside of this is that the IP addresses you export in this fashion will lose all connectivity to the Internet.

In general it is a good idea to keep your network clean; only allow the traffic that your services need to operate. Allow TCP to ports 80 and 443 on your servers and allow UDP to your game servers. Allow SSH connections only from trusted hosts. All of these limit the options of the attackers when they come to visit.

Attacks on Systems and Services
If your bandwidth is not saturated, the attack is most likely against your systems and the services they host, rather than your entire network. Again, the remedy depends on the nature of the attack. You may find that any one system exposes multiple targeted bottlenecks. Attacks on systems and their services generally fall into the following categories:

Network subsystem limitations (very high number of packets per second).
OS or application memory limitations (memory consumption).
Disk or CPU limitations (large numbers of valid requests).
System-targetting attacks are very frustrating, as they're hard to defend against. FreeBSD does have some special defensive magic, however.

By default, each time your network card receives a packet, it generates an interrupt to the CPU along its IRQ. The CPU will catch this and dedicate a small amount of time to fetch this packet from the interface. Under normal operations this can happen several thousand times per second — well within the capabilities of even low end CPUs. It is quite likely with older CPUs that you will start to see performance impacts between 25,000 to 50,000 packets per second. With packet sizes of 1,500 bytes, this works out to around 40Mbytes/sec to 75Mbytes/sec, quite a lot for most older CPUs to serve anyway. Most 1Ghz systems will begin to feel pressure around 75,000 packets per second. Two factors exacerbate the problem:

TCP SYN packets require full processing before the system can respond with SYN ACK packets back to the source address. TCP and UDP packets to closed ports as well as ICMP packets in general also need similar processing and replies. While not as expensive as SYN processing, this still takes time and consumes outbound bandwidth.

Packet size also plays an important factor. You can fit more small packets in a particular amount of bandwidth than you can large packets. The more packets you take in, the more CPU time you need to process them, no matter what type of packets they are.

As we discussed previously, each interrupt request eats up some CPU time. With enough IRQs generated, the CPU will have no time to do anything other than serve the interrupts. Inbound packets stay unprocessed, applications receive no CPU time, and your system is effectively dead in the water. This is known as "Live-lock." Your system is still live, inasmuch as it has not crashed, but it cannot perform any useful functions. Once packets stop coming in to the interface, the CPU starts to process all of the backlogged packets it has already accepted. This can take anything from a few minutes to several hours.

There are several things you can do to prevent or mitigate the effects of a high rate of packets without buying any hardware upgrades. All of these use FreeBSD's sysctl(8) command. Here are the settings you will need to place in /etc/sysctl.conf:

net.inet.tcp.msl=7500net.inet.tcp.msl defines the Maximum Segment Life. This is the maximum amount of time to wait for an ACK in reply to a SYN-ACK or FIN-ACK, in milliseconds. If the computer does not receive an ACK in this time, it considers the segment lost and frees the network connection.

This has two implications. When you are trying to close a connection, if the final ACK is lost or delayed, the socket will close more quickly. However, if a client is trying to open a connection to you and their ACK is delayed more than 7,500 ms, the connection will not form. RFC 753 defines the MSL as 120 seconds (120,000 ms). However, this was written in 1979; timing issues have changed slightly since then. Today, FreeBSD's default is 30,000 ms. This is sufficient for most conditions, but for stronger DoS protection you can lower this to 7,500 or less.

net.inet.tcp.blackhole=2net.inet.tcp.blackhole defines what happens when the system receives a TCP packet on a closed port. When set to 1, SYN packets arriving on a closed port will be dropped without a RST packet being sent back. When set to 2, all packets arriving on a closed port are dropped without an RST being sent back. This saves CPU time, because packets don't need as much processing, and outbound bandwidth, by not sending out packets.

net.inet.udp.blackhole=1net.inet.udp.blackhole resembles net.inet.tcp.blackhole in its function. As the UDP protocol does not have states like TCP, there is only one choice when it comes to dropping UDP packets. When net.inet.udp.blackhole is 1, the system will drop all UDP packets that arrive on a closed port.

net.inet.icmp.icmplim=50The name net.inet.icmp.icmplim is somewhat misleading. This controls the maximum number of ICMP "Unreachables" and also TCP RST packets to return every second. It helps curb the effects of attacks that generate a lot of reply packets.

kern.ipc.somaxconn=32768kern.ipc.somaxconn limits the maximum number of concurrently open sockets. The default here is just 128. If an attacker can flood you with a sufficiently high number of SYN packets in a short enough period of time, he can use up all of your possible network connections, successfully denying your users access to the service.

You may find these settings to be either too aggressive or not aggressive enough. Tune them until you receive satisfactory results.

Finally, if you are blessed enough to own one of the following network cards, you can enable a kernel feature call DEVICE_POLLING:

dc
em
fxp
nge
rl
sis
DEVICE_POLLING changed interrupt handling; with DEVICE_POLLING, the kernel does not handle them at all! Instead, at certain times, the CPU will poll the network card to pick up any packets that are waiting for processing. This can significantly reduce the amount of CPU time used in processing inbound traffic. This only works with the above cards, as their drivers must support DEVICE_POLLING.

The FXP cards generally work best with this feature, as their drivers and hardware are very well developed. The hardware design and quality of RL cards is a lot lower — without sufficient CPU (usually around 1Ghz), they have a hard time achieving the full 100MB/s at all. Keep this in mind if you are looking for a new network card.

You can learn more about DEVICE_POLLING at the author's home page. You can also find good installation and tuning instructions there, as well as statistics from comparative tests with DEVICE_POLLING enabled and disabled.

Tracking the Source of the Attack
Attacks can come from inside and outside your network. Obviously one is easier to isolate than the other. Tracking the sources of attacks requires some familiarity with packet-sniffing tools such as tcpdump, ngrep, and ethereal. Unless you have spent several months carefully profiling your network traffic and set up monitoring specifically to alert you of anomalies, the chances of discovering you are under Denial of Service conditions before someone else does are slim. More often than not, complaints such as "The Internet is slow" or "I can't get my email" will lead you to the truth. It is important to realize two things:

Attacks can come from inside and outside your network.
Not all service-denying events constitute a Denial of Service attack and not all Denial of Service attacks constitute a service-denying event.
What does this mean to you? It means that when you start to look for why your Internet is slow or why people cannot download their email, remember that the source of the problem could be from any machine on your network or the Internet. If there's a denial, it may be accidental.

A good place to start is the point of bottleneck. This could be the CPU on your HTTP proxy or your Internet gateway. If your bottleneck is a system process such as a proxy server, examine the logs for this. Is a single system or small number of systems making an unusually large number of requests or using more resources than normal?

If your bottleneck is your Internet gateway (which we assume is running FreeBSD), you can use the following command to view the IP packets passing through your gateway:

router# tcpdump -n -i <interface> -c 100This command will display a summary of the first 100 packets (-c 100) it sees on the given <interface> (-i <interface>) and will not resolve the IP addresses to host names (-n), which can take extra time and may itself fail if you are having connectivity issues. An example output line will resemble:

04:59:53.915324 192.168.0.3.2327 > 192.168.0.10.1214:
S 3199611726:3199611726(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)Let us look at the first few parts of this output, which can be useful to us.

04:59:53.915324This is the timestamp of when the packet was processed.

192.168.0.3.2327This is the source IP address. The numbers after the last octet, 2327, indicate the packet's source port number.

192.168.0.10.1214This is the destination IP address. The numbers after the last octet, 1214, indicate the destination port number.

SThis indicated the type of packet, in this case a SYN packet. See Daryl's TCP/IP Primer to learn about the process and life of a TCP connection and the types of packets you would see here.

What you may see during an actual attack is hard to predict, as Denial of Service attacks come in so many shapes and sizes. A typical attack involves flooding a listening port on your server with SYN packets. The idea is to make your system so busy processing the new connections that it cannot do anything else. Here you may see a large number of SYN packets. Normally, you'll see a balance of packets of all types.

References and Credits
This is a list of references I found when writing this article. Most of them contain much more detail on their particular subject than I have provided here. Hopefully they will be as useful to you as they were to me.

The FreeBSD handbook. A great source of information about FreeBSD. Have a read here if you want to learn something new about FreeBSD.

Google Groups. I used this extensively to search USENET for articles others had posted in the past. You should too!

HTMLHelp.com is made by the Web Design Group to "promote the creation of non-browser specific, non-resolution specific, creative, and informative sites that are accessible to all users worldwide." It was valuable in the creation of this site.


Avleen Vig is a Systems Administrator at Google.

Avleen Vig is a Systems Administrator at Google. He has been a Unix advocate for most of his professional career and enjoys being a part of various high-tech communities, writing new articles and encouraging the growth and development of junior geeks. He maintains several open source projects and enjoys spending his spare time with his family or fixing and improving cars.

[fal_762x51]

What in sweet Jebus happened to the Falfiles?! I go on today during work and nothing. Is it the same twat bags that clogged it up last time? I needed to ask EX1 a question too.

[Jen]

What in sweet Jebus happened to the Falfiles?! I go on today during work and nothing. Is it the same twat bags that clogged it up last time? I needed to ask EX1 a question too.

No.. It's my fault. I turned the forums off to work on a few things and thought I turned things back on before I left for work.. well apparetly I didn't and for some reason didn't catch on that things were a weeeee bit slow today until just a few minutes ago.

[English Mike]

No.. It's my fault. I turned the forums off to work on a few things and thought I turned things back on before I left for work.. well apparetly I didn't and for some reason didn't catch on that things were a weeeee bit slow today until just a few minutes ago.

Well the tinfoil manufacturers wont mind.....;)

[CabofDoom]

Been tryin gto see what rickett has up for sale....:(