RedZone Down Again?

15 02 2011

I know its not just me, but…

It appears all attempts to access through the HTTP port (port 80) are generating a TCP RST packet. A RST packet is sent when a TCP packet is sent to a TCP port on a working computer for which there is no listening application.

Because this has broken the technical support forums, we cannot hear the spyware operators squealing, so it is a little hard to know what is happening[1]. However, as RedZone works by communication to this web server, the upshot is that all RedZones in world are currently broken again.

Long may it last.

[1] The reasons for this failure could be:

1. The apache server has simply fallen over on zFire’s MacPro he uses as the server.
2. The server could be out of memory. This could be indicative of a DDOS attack.
3. Something messed up on his DynDNS account, and having changed IP address with his ComCast service, the DynDNS did not update. If this is the case, the poor new owner of the IP address is probably wondering why thousands of people are trying to connect to their nonexistent web service!
4. It could be a deliberate firewall policy, the RST being generated from the firewall rather than the server. But why zFire would have suddenly shut himself away is not clear.
5. Something else I haven’t bothered to think about!

EDIT 16 February:

zFire admitted on his forums that he had, in fact, taken his Mac out of service for 5 hours because he wanted to upgrade it. He did not provide any service announcement, warning, backup or anything else – to the consternation of his customers.

The ever delightful “crackerjack” complained:

Crackerjack Tue Feb 15, 2011 3.22pm

Why cant there be a website or a site?
Content theives will theive whether the site is down or not and yet redzone users will only worry more when the site is down

I just have to add here, that I just love the way redophiles spell. There is a whole thread right now about RedZone being aprooved[sic].

But in any case, yes: zero points to zFire on systems and network administration! But being a kid in a basement, what do we expect? I wonder if his customers realise the kind of cowboy outfit he is running. Well I guess they have a better idea now.

Although once again zFire tries to pretend that all is well. Crackerjack’s posting – like all criticism of RedZone and the kid who runs it – was deleted from the forum within hours.

Bad luck crackerjack. It seems that you have been censored.




4 responses

15 02 2011
15 02 2011

Ok Sadly the website seems to be back up again now. Still, the last five hours when it was down were most enjoyable. No word yet as to why it vanished. Not that we would expect a true explanation anyway.

Also looks like zFire has fixed the “bones” now, so he has had to push out another software update. We can expect the number of “installations” of Redzone to leap up this week.

16 02 2011

Technically, an RST packet simply indicates the connection should be reset. It could be sent if your particular IP is being blocked at the firewall, meaning the service application is still up and running, you just cannot access it. Typically a firewall would drop, rather than RST unless set to block instead.

Try something like

16 02 2011

Anax, thanks. Yes I had already tested from a variety of IP addresses (which is why I said I knew it was not just me).

A RST packet is generated as I said. See RFC 793:

If the state is CLOSED (i.e., TCB does not exist) then

all data in the incoming segment is discarded. An incoming segment containing a RST is discarded. An incoming segment not containing a RST causes a RST to be sent in response.

I am aware that a RST can also be generated by Microsoft TCP/IP stacks when the Microsoft side of the connection conducts a passive close. However, this use of a RST is not compliant with the RFC and had the effect of breaking half closed connections.

In any case, a RST in response to a SYN packet indicates the port state is closed on a listening computer. A firewall application may choose to generate a RST to mimic a closed port, although these days most firewalls are configured to silently drop such packets so as not to give portscanners knowledge that there is a device actually listening at the chosen IP address.

Thus a RST packet response told me that there was a device listening, but no listening application. Turns out the listening device was zFire’s router, because he has admitted he decided to update his computer without informing any of his customers.

The fact a RST was generated tells me something about zFire’s network setup. A router would not generate a RST packet. To generate a RST, the TCP SYN segment had to arrive at the destination IP address. This tells me that the router is his destination IP address, and generated the RST during his downtime. He is thus running a NAT router, with his Mac Pro on a private IP address range behind it. A typical home setup.

But then again, we could tell that because no business would take down their service for an upgrade without telling their customers first or at least providing them information during the upgrade.

%d bloggers like this: