Defending Against Attacks

173.88.199.104 (Talk)
(Created page with " == Defending Against Attacks == A firewall is your first line of defense, But if you allow public access to ports 22, SSH (secure shell), 23, Telnet, or 21, FTP these ports ...")
Newer edit →

---

Defending Against Attacks

A firewall is your first line of defense, But if you allow public access to ports 22, SSH (secure shell), 23, Telnet, or 21, FTP these ports can be bombarded with login attempts using common ID/PW combinations probing for access. In the case of port 80, Web server it can be bombarded with access requests designed to consume server resources resulting in a denial of service to legitimate user requests. To the firewall these all look like legitimate packets.

Know Who Your Attacker is

98 percent of the attackes come from script kiddies or robots. These attacks are all most totally based on indiscriminate rolling through a range of sequential IP address. (IE: They never use DNS to lookup your domain name.) You were found by plain bad luck. These attacks most offten only address the know port numbers listened on by those services. You use this knowledge to defend against this type of attack.

The most common program used to probe is nmap. It's even in the ports system as, security/nmap. Nmap is a utility for network exploration or security auditing. It supports ping scanning (determine which hosts are up), many port scanning techniques, version detection (determine service protocols and application versions listening behind ports), and TCP/IP fingerprinting (remote host OS or device identification). Nmap also offers flexible target and port specification, decoy/stealth scanning, sunRPC scanning, and more.

Check out http://www.insecure.org/nmap/ for more details.

Read Phrack Magazine article September 01, 1997, for overview of the different probing techniques http://www.insecure.org/nmap/p51-11.txt

The simplest defense is to change the port numbers these services use. The /etc/services is where SSH, Telnet, and FTP port numbers are defined and where you would change them at. (Note: Your firewall should only allow passive FTP by not opening high value port number for active FTP data transmission.) For Apache web server you specify the access port number in httpd.conf definitions.

Remote clients who want to access your public services on the alternate port number will have to enter the alternate port number as part of the login command. After setting up alternate port numbers you can have your firewall log all access to ports 21,22,23,or 80 and report the abuse to the ISP owner of the sending IP address using the FreeBSD port ppars-1.0 See Abuse reporting system

Or if you don't want to use the automated Abuse reporting system you can take the sending IP address from your firewall log and do manual whois command to find the ISP owner of the offending IP address along with the ISP's abuse reporting email address and send your own email to them about their client sending you attack packets.

Installers Note: The technique of assigning non-standard ports for SSH, Telnet, and FTP is security through obscurity and is one of the first and easiest security measures an administrator may consider. By no means does this provide protection from the dedicated attacker who has targeted your IP address for some reason. This is just the first security level of hiding through obscurity from the majority of the high school / college freshmen script kiddies who really don't know what they are doing yet. You will be surprised at how effective this really is at discouraging repeat port scan attacks and fraudulent login attempts.

Stopping Login Attacks

Using the customary port numbers or alternate port numbers for SSH, FTP, or Telnet all failed logins are logged to /var/log/auth.log file. In most cases the sending IP address is the real IP address of the attacker. In the long term the solution is to do whois on the attackers IP address and report him to the ISP who owns the IP address.

In the short term to stop the login attack in progress many people will add a "deny this IP address" rule to their firewall rule set file. Yes this will stop the attack immediately, but when a firewall keeps all these special "deny this IP address" rules the firewall becomes very hard to maintain as that list of denied IP address rules grows longer. A far better solution is to separate the denied IP address list from the firewall rule set. This can be done using the "routed blackhole" command.

Example:

To Add use route add -host attacker_ip 127.0.0.1 -blackhole

To Delete use route delete -host attacker_ip 127.0.0.1 -blackhole

To List use netstat -nr|grep 127

This is executed in the IP stack and is faster than in the firewall when you have over 20 of those special "deny this IP address" rules in the firewall. The "attacker_ip" in found in the log records in /var/log/auth.log file.

You can create a script (route_blackholed_ip.sh) containing route commands for all the IP address that have attacked you in the past and save it to /usr/local/etc/rc.d/ so it will be run at boot time.

The same process used by the abuse reporting system to process the /var/log/security log file can be modified by you to automate the processing of the /var/log/auth.log file to create the route blackhole commands on the fly while the attack is occurring.

Installers Note: The ports system currently contains /security/bruteforceblocker and /security/sshit for automating the capturing of the fraudulent login attempts IP address and inserting firewall rules to block that offending IP address. The PF firewall has built in self limiting parameters (max-src-conn & max-src-conn-rate)which when execded can add the offending IP address automatically into a table of IP address that are blocked by the firewall.

BruteForceBlocker is a perl script, that works along with pf - OpenBSD's firewall. It's main purpose is to block SSH bruteforce login attacks via firewall. When this script is running, it checks for sshd log records in the syslog and looks for failed Login attempts and counts number of such attempts. When given IP reaches configured limit of fails, script puts this IP into pf's table and blocks any further traffic to the that box from that given IP.

sshit is a perl script, which works along with ipfw, ipf, and pf. It parses the output of syslogd, finds SSH/FTP bruteforce fraudulent login attempts. If the number of failed login attempts is greater than a threshold set by the administrator, sshit will block the source IP via firewall for a while (administrators can set the period of blocking).

PF Firewall Method Using the self limiting parameters max-src-conn & max-src-conn-rate coupled with the overload and expiretable parameters for automatic population of a table containing the offending IP address and the automatic removal of the offending IP address after no activity in a predefined time span. This method works for FTP, telnet, and ssh bruteforce logon type attacks in a simple and clean manner. IPFW & IPF firewalls do not have this built in capacity

See this link for rule coding details: http://www.bgnett.no/~peter/pf/en/bruteforce.html

Stopping Web Server attacks

Web server attacks are denial of service (Dos) attacks. There is no trigger that will notify you when this occurs. Most likely your first warning something is wrong is when people start asking you why is your web server down. When you have reason to suspect your web server is under attack you can check /var/log/hpptd-access.log file. This log file gets a log record for every file accessed by your web server. Part of the log record is the requesting IP address or it's DNS name. When you see a lot of log records (in the hundreds) from the same IP address, that is your attacker. In most all cases the requesting IP address is spoofed. Spoofed means the IP address is a real public internet routable IP address belonging to a legitimate user that unknown to him, the attacker has used to hide his real identity.

Like with Login attacks you can add a special "deny this IP address" rule to your firewall rule set file or use the "routed blackhole" command.

The same process used by the abuse reporting system to process the /var/log/security log file can be modified by you to automate the processing of the /var/log/hpptd-access.log file to create the route blackhole commands on the fly while the attack is occurring.