server blocked/stopped by host

my strato server has stopped working on sunday, I have been trying to fix it the whole last night, but then realized that inside my control panel from strato it said: host has been suspended please contact support.

here they try to tell me that there is an application on my server which causes too high load 21001 packets/sec and that my server could have been hacked - they suggest that I backup my server and reinstall...

this seems highly contradictory to me as they told me about DOS first then state I have a rogue application that has a high number of incoming packets - ??? AND in their first email they told me my server would be back online in a few hours, after I asked for more details they come up with this story about this application...

I think that an high volume of incoming packets does not mean automatically that your server is highjacked. It depends on the port. If e.g. a high number of packets where send to port 80, its an DOS attack but it does not mean that your apache has been highjacked.

I got another mail from them: please excuse our second mail (about the rogue application) it was sent by mistake to you and was not intended for you )

I have seen this happen frequently when the guys doing the support know nothing about their job and just skim the support seeking mails for keywords and then select from a database of ready made emails and send them back

I got an email from strato saying that my server was the target of another DOS attack. They sent me a link to their fair usage document where they say are rules against which I am acting (by letting myself getting attacked !)

They will cut my server of the net to prevent damage to their networks...
I can still access my server through a remote recovery console and I should resolve my problems.

If I have any explanations as to why I am being attacked I shall notify them and they tell me to do anything possible to prevent myself from further attacks.

They gave me time to resolve the problems until the 17.02.2006 - what problems?

What the heck can I do if I am getting attacked?

I was still able to access the server through ssh for maybe an hour and neither the logs neither netstat was showing me an unusual amount of incoming connections, neither were there syn attacks to be seen at the first glance. Neither my graphical output of statistics showed anything...

Now I think that if there was an attack there had to be at least some traces of this attack in my logfiles.

I am going to write them a similar email asking for details about the type of the attack, the duration and log excerpts - I mean they must base their accusations upon something.

AND I think I have to change providers although I am usually a very steady customer but this is too much.

any suggestions or ideas?

###edit###

sorry I have to give you more info: the mail reached my with a huge severall hours delay, after I talked to them on the phone they gave me the exact time of the attack and I found some traces. I am currently examining the logfiles.

not much inside the usual syslog files, any other place where I can grab some info? If not can anyone explain how to setup some firewall rules to log attacks of any kind ? just some hints or so would be great.

I am currently checking out nagios screenshots to find out what it can do and if it got more info than hotsanic I am using curretnly.
besides I checked if I got hacked, did it last time too, and there is no sign of such activity, anyway I am talking about an incoming attack - there was a traffic spike at 23:50 during the night from thursday to friday. you can check it out here: http://www.web-designerz.de/serverstats/traffic/eth0.html

these stats are all I have there is no more logging being done - so what can I do?

I think there is not much that you can do if there is an incoming attack. Only your provider can try to block the traffic at the routers in front of your server.

Click to expand...

I know and they won't
I am talking about strato, they even told me that they usually ask people to sign a statement that one won't do it again (Unterlassungserklärung) or even cancel their contract, so soon, if I don't start logging so I can file an abuse report to those f***ing idiots attacking my server I will have top look for a new server provider.

so if someone could suggest some logging rules or at least give me some hints as to where and what to log...

@till
nothing noticeable in the logfiles neither in their size, thats why I was asking for help with logging...

@falko
I have had another attack these days, the peaks I am talking about are the green ones, thats incoming traffic. The red ones are indeed the nightly backups which indicates outgoing traffic.

these attacks did not do any harm, the server is still available as I found out by chance. The last attack was registered at midnight, but Strato only cut off my server the next day at lunch so I was able to see what happened: the server load went up to 12 and more, still everything was functionable, the DOS did not succeed, to me it looks like the attacking server was not powerfull enough?

yet strato does not like these attacks and threatened to cancel my contract if there will be any more occurances. So I need logging to file abuse complaints about the originating server.

# 12) Logging (all systems)
# With this enabled, ipchains will log all blocked packets.
# ** this could generate huge logs **
# This is primarily intended for the port mointoring system;
# also note that you probably do not want to "AUDIT" any services
# that you are not allowing, as doing so would mean duplicate
# logging
LOG_FAILURES="N" # do not log blocked packets

# 15) Log level (iptables/netfilter/Linux 2.4 only)
# Control what level of logging is used when the firewall logs
# information. Default is warning (4). Lowest priority is
# debug (7); highest is emergency (0). To prevent syslog
# from copying iptables error messages to the console, set
# this to 6 (7 would also work, but 6 is recommended)
# You can also stop syslogd/klogd from printing kernel
# messages to the console by issuing the command
# setterm -msg off
#IP_LOG_LEVEL=6 # level used in 2.2/ipchains
IP_LOG_LEVEL=4 # iptables/netfilter default

# 16) Always attempt to use stateful features for inbound connections
# Always using state will allow the firewall to reject invalid
# packets sent to otherwise open TCP services, e.g. XMAS, NULL
# and SIN/FYN scans. The downside to choosing this behavior is that
# services may become unreachable if the packet filter's state
# table becomes full.
IP_ALWAYS_USE_STATE="N" # default, ensures services remain available
#IP_ALWAYS_USE_STATE="Y" # disallow invalid packets