Linux CentOS Server Probe attack - how to detect and block

The IP seriously probed the server.
Ideally we should try find some software that if an IP starts to probe the
server its gets automatically blocked.
Do you know of software for this?
RedHat/CentOS server
Who is Participating?
iptables -A INPUT -s -j DROP
iptables -A FORWARD -s -j DROP

# or a bit more lazy
iptables -A INPUT -s -m limit --limit 42/sec --limit-burst 142 -j ACCEP
shaunwinginAuthor Commented:
# or a bit more lazy
Is perhaps on the track...
Pleae explain this command.

However we need a program that automatically can detect and block this type of probing!
LinuxGuruLinux Server AdministratorCommented:
The mentioned commands by ahoffmann will add rules in firewall to DROP the connections from the ip.

-A means Append the rule to iptables chain
-s means source
-j Jump to rule DROP.

If you still see the attack from that ip, you can route the attackers ip and that will be more effective. Just use the following command.

route add x.x.x.x reject

Open in new window

You can install firewall like CSF (Config Server Firewall) to secure the server.

One more option is installing custom script like DDoS Deflate To Block DDoS Attack.

Cheers !!!
Protect Your Employees from Wi-Fi Threats

As Wi-Fi growth and popularity continues to climb, not everyone understands the risks that come with connecting to public Wi-Fi or even offering Wi-Fi to employees, visitors and guests. Download the resource kit to make sure your safe wherever business takes you!

You can a tool like snort, or similar, to detect many attacks and use that information to adjust firewall rules to block attacks. But what is just as important is hardening the server, keeping it up to date w/respect to patches, and using firewall rules to limit connections to only the minimum necessary services.
"iptables -A INPUT -s -m limit --limit 42/sec --limit-burst 142 -j ACCEPT"

Means  for    accept up to 42   matches  (packets)  per second,  with a short burst to 142 packets per second.

You would need to add an iptables rule after the limit rule, in the sequence of rules, to DROP,  in order for this to be effective.     such as

iptables -A INPUT -s -j DROP     following the limit rule.

These are all reactive to  however,  you needed to manually identify the IP address and add the rule.

The --limit option is not  source-IP address specific, it is rule-specific.

You could write
(Assuming your iptables rulesets are currently empty)

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -m state -m hashlimit    --hashlimit-mode srcip  --hashlimit 20 --hashlimit-burst 100  --hashlimit-name  limit1 --hashlimit-htable-expire 20000  --state NEW  -j ACCEPT
iptables -A INPUT -p icmp -m hashlimit    --hashlimit-mode srcip  --hashlimit 10 --hashlimit-burst 100  --hashlimit-name  limit2  --hashlimit-htable-expire 20000   -j ACCEPT
iptables -A INPUT -d -j ACCEPT
iptables -A INPUT -j DROP
iptables -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

Which would be, to say in English:

Rule 1.
1.  Accept traffic related to all established connections  (EG.   Only new connections/connectionless protocols effected)
2.  Accept  packets  for  new TCP/UDP connections, at a specified rate limit on the number of packets  per SOURCE ip address,  of 20 packets per second,  burst to 100,   maintain a hash table, with entries expiring after 20 seconds.    (20 connections per second per source may be overly strict, for certain server applications -  such as DNS servers hosting massive numbers of domains)

3.  Accept other packets, at a specified rate limit  per source IP address  of 10 packets per second,  burst to 100
4.  Accept limited broadcast  to local subnet.
5.  Drop everything else  (EG,  packets not allowed by the limit rules)

6.  Output rule: accept anything outgoing, and load the tcp/udp connection in the conntrack table.     (This means, that traffic returning from an outgoing connection  the server initiated won't be subject to the limits  -- this can be important,  if the server makes DNS queries, for example)

This sort of thing is OK  for  "port scan"  typed probes.

A better strategy, is to not have unneeded ports open.

This does nothing, regarding probes of well-known protocols.

EG.    Someone connecting to port 80 on a web server,  to ask/search for various common file paths that might contain exploitable scripts;  or to probe for vulnerabilities in common protocols.
Those are the most common probes.

Full port scans are rare,  so   it is   unlikely that limiting the rate of connections or  "port probes"    would be an effective security measure.

Implementing an IDS  such as Snort would provide better monitoring for probes, and be more effective -- although,  it would be  more time consuming to configure,

and the impact on server performance or capacity requirements would be much greater,  as an IDS on an active machine is no  light resource consumer.

Generally, it would be advisable to run an IDS on the network as a separate machine,  either running snort, or a commercial network intrusion detection solution.

The functionality is also commonly provided by firewalls.
There are firewall solutions that provide mechanisms for detecting probes or attacks, and logging them to a file for review,  so you can  kick off a callout to an alarm process.

The alarm process could be a script  that triggers an automatic response,  which could include notification of the admin,  and/or   automatic blocking of all traffic from the offending IP address.

Some firewalls,  will have active response as a built-in functionality.

There are also some  lighter-weight Intrusion prevention point solution software products you could deploy,  such as

Denyhosts,  or OSSEC,  on the servers.

These would utilize fewer resources than snort,  and they can also be configured to firewall off or add to hosts.deny an IP address,  based on  "access denied"  attempts in system logs,  such as brute force password guessing attempts.

OSSEC  has XML based configuration files,  so it is possible to custom taylor this and search for messages of your choice appearing in system logs.

And then configure active response accordingly.

It is a lot of work to configure and maintain an IDS on a server,  such as Snort or OSSEC.

If you don't have a lot of time to read and understand documentation for the software,  you may need to look at getting a commercial solution,  hiring a consultant to implement,   or  just getting a firewall to implement this,
as out of the box,  these may not detect all kinds of probing that can happen.

IMO,   "stopping probing"  alone may be wasted effort -- it may not be worth the money,   considering  the resources that need to be leveraged.

If you just need to prevent the box from getting "owned";  the first steps should be to shut off any unnecessary services,   and make sure  everything that is opened is hardened against attack.

Then concentrate "detection"  measures,   against  detecting unapproved services or ports running   (EG.    _You_  probing  and auditing is part of a good security strategy),

And measures to detect attack, exploit, or abuse,   of  the approved services or ports active on the server,

through remote log monitoring (sending logs to a remote monitoring server, and analyzing),  network-based intrusion detection,   and  local  intrusion prevention software.
> ... we need a program that automatically can detect and block this type of probing
please define in every detail "this type of probing"
I guess this is impossible ;-)

beside this a bit helpless comment, you got a lot descriptions how it works above
as long as you cannot define "this type of probing" you will not be able to anything automated (which is impossible at all, IMHO)
keep in mind that any program you'll find (including iptables) will only partly do what you described so far

security is a process and not a product
means that even if you find a tools claiming to automate it, you'll have to check if it real does what you want

sorry for not giving the link to click&go&forgetallmysecurityproblemsandjustdoitright
but it hopefully helps to undersatnd the previous descriptions and give you a hint about what to do
oops, forgot to ask for DDoS, how would you deal with the fact that millions of IPs are probing?
that's what I mean with "impossible"
Yes indeed...  you have to have an understanding of what kind of probing is happening, before you can reliably determine if it will be possible to block or stop that probing event.
Application layer probing would be particularly difficult to anticipate.

Probes may use multiple source IP addresses, and various stealth techniques to avoid being detected.    Some (not all)  kinds of events might be capable of being stopped automatically. The more events you anticipate, the greater either the time/cost you have to invest in doing so,  or the
greater the risk of false positives  (identifying legitimate traffic as probes).

If you can provide more information or system logs about what sort of probes you are experiencing or concerned about,  we might have more specific options to suggest.
Jan SpringerCommented:
I use fail2ban [with iptables].  That's what I would recommend.
IIRC fail2ban's main purpose is to detect failed logins and block those IPs, but not to detect portscans or whatever
anyway, step in the right direction ...
Daniel McAllisterPresident, IT4SOHO, LLCCommented:
If you have your IPtables firewall setup properly, only certain ports (for which you have a service running) will be open...

But you're right if you say "dropping" all the failed requests in a port scan isn't enough... that's why I prefer a "tarpit" approach...

Read Symantec's take here:

In addition, even though I allow SSH access to my server, I use fail2ban to stop potential attackers from attempting to break in the old-fashoined way (password guessing).

Just my 2-cents worth...

shaunwinginAuthor Commented:
tx for feedback  - investigating...
IIRC fail2ban's main purpose is to detect failed logins and block those IPs, but not to detect portscans or whatever
anyway, step in the right direction ...

Actually there are several tools and several ways, the most important thing is to find out how to make it work for you. For example, with fail2ban you could have a failregex that reads from your syslog/messages all entries with an specific pattern, defined by iptables with its "-j LOG --log-prefix", so when iptables reads a PORT DENIED: it will append it to syslog/messages and fail2ban will detect the ip address and automatically ban it.

In short, in iptables:

"-A <chain_name> -j LOG --log-prefix "PORT DENIED: " --log-level 5 --log-ip-options --log-tcp-options --log-tcp-sequence"

In fail2ban:

"failregex = PORT DENIED: .* SRC=<HOST>  "

 enabled = true  
 filter  = portscan  
 action  = iptables[name=portscan]  
 logpath = /var/log/messages  
 maxretry = 3  

P.S.: this was not of my personal knowledge, its just an example I found and documented at:
shaunwinginAuthor Commented:
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.