Site under attack(?) - Ultra slow, huge packet loss!

[de552]

Some kind of attack again?! Web page load takes several minutes and email delivery takes several hours. Something must be seriously wrong right now.

- Thank you!

If I ping ONE HOP BEFORE SG, then everything is fine (ploss 0% with 100 packets). But if I ping SG it's very slow and packet loss is right now up to 85% (100 packets !!!).

I don't wonder why everything is working so slowly if you know how TCP/IP congestion control works. I would say that's unacceptable.

[GordonFJ3]

I agree

Its been slow all day, and I'm relying on it for contract applications.
Can we get an official word from the SG staff on what's going on?

I think I've lost a few emails too, including several for the registration of this bbs, thats why my user id is GordonFJ3 and not GordonFJ.

GordonFJ and GordonFJ2.... I never received any confirmation emails from them, yet I have for GordonFJ3.

I also experimented by sending a few test emails too, and they haven't arrived yet. Including a bounced email test sent to something like sdfsdsdfsdf.20.sdfkjhsdfjgasgh@spamgourmet.com. Normally I would get a bounce report for that.

Cheers
Gordon

[zoechow]

I am experiencing the same (nt)

[josh]

We did have a spike in usage earlier today caused by at least two user accounts with scripted address creation going on -- hard to say whether this is a DOS, or just a user trying to pull a fast one on somebody else (registering a bunch of times, or whatever). Those were cut off.

Other than that, it's been a busy day, but I haven't been seeing the issues you're talking about -- what part of the world are you in?


BTW, that address won't bounce.

[GordonFJ3]

Josh

Thanks for the update, lets hope this kind of crap doesn't happen again. The messages seems to be coming through now (albeit very delayed 5 hours or more) and a tracert works fine too, where yesterday it was stopping because of timeouts to gourmet.spamgourmet.com.

The site seems back up to its responsive self, so thanks for cutting off that idiot user who was abusing the service.

I'm in London, UK, by the way.

Todays tracert:

Tracing route to gourmet.spamgourmet.com [216.75.35.164]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms ????? (????? added by me)
2 36 ms 25 ms 48 ms ?????
3 29 ms 11 ms 46 ms ?????
4 33 ms 81 ms 66 ms ?????
5 27 ms 11 ms 11 ms ?????
6 99 ms 82 ms 93 ms ?????
7 116 ms 108 ms 98 ms ?????
8 96 ms 80 ms 114 ms ?????
9 112 ms 99 ms 107 ms ?????
10 169 ms 134 ms 182 ms ?????
11 168 ms 155 ms 149 ms ?????
12 152 ms 206 ms 193 ms ?????
13 182 ms 191 ms 172 ms ?????
14 162 ms 166 ms 201 ms ?????
15 183 ms 176 ms 181 ms ge1-2.gw65-02.kmc01.sdcix.net [66.28.28.126]
16 169 ms 200 ms 185 ms gourmet.spamgourmet.com [216.75.35.164]

Trace complete.

Thanks again
Gordon

[de552]

We did have a spike in usage earlier today caused by at least two user accounts with scripted address creation going on -- hard to say whether this is a DOS, or just a user trying to pull a fast one on somebody else (registering a bunch of times, or whatever). Those were cut off.

Most interesting that it leads to packet loss on last hop. It would mean that bandwidth was saturated. Usually I'm used to situations where server power runs out before network is being severly flooded. Especially with services which include database / active page creation and so.

Other than that, it's been a busy day, but I haven't been seeing the issues you're talking about -- what part of the world are you in?

Finland

But as I mentioned, because all problems existed only with last hop, it's (almost) meaningless where the tracert or ping originated from. There might be some very moronic routing problem which could affect, but it's not too common.

It's good to keep in mind that the weakest link with SG is bandwidth. It means that DDoSin should be relatively easy. What kind of BW you got? 100 megabits, gigabit? Or something much less than that?

[josh]

The system has at least a 100M/S NIC, and it's in a facility with a lot of bandwidth.

I did see a whole lot of this:

possible SYN flooding on port 25. Sending cookies.
possible SYN flooding on port 25. Sending cookies.
possible SYN flooding on port 25. Sending cookies.
possible SYN flooding on port 25. Sending cookies.
possible SYN flooding on port 25. Sending cookies.
possible SYN flooding on port 25. Sending cookies.
possible SYN flooding on port 25. Sending cookies.
possible SYN flooding on port 25. Sending cookies.
possible SYN flooding on port 25. Sending cookies.
possible SYN flooding on port 25. Sending cookies.
possible SYN flooding on port 25. Sending cookies.


in one of the server logs -- maybe that explains it.