Scenario: A linux server running Debian Sarge 3.1 setup according to Falko’s – The Perfect Setup – Debian Sarge (3.1).
Let’s assume we have one working website (www.example.com) and that the document root is: /var/www/www.example.com/web
The IP of the server is 192.168.0.5 and it’s using eth0 as network interface name.

Needed programs and files

• Snort
• Snort rules
• PCRE (Perl Compatible Regular Expressions)
• LIBPCAP
• BASE (Basic Analysis and Security Engine)
• ADOdb (ADOdb Database Abstraction Library for PHP (and Python).)

Downloading and untaring

We need a temporary place for all the files that we are going to download, and untar.
To keep things simple we will create a directory in the /root named snorttemp. (It’s obvious that this download directory can be any name and in anyplace)

cd /root
mkdir snorttemp
cd snorttemp

Now you need to get Snort.
The latest version at the time of writing this is 2.6.0

wget http://www.snort.org/dl/current/snort-2.6.0.tar.gz

When the download is finished untar the file:

tar -xvzf snort-2.6.0.tar.gz

And let’s remove the tar file:

rm snort-2.6.0.tar.gz

We also need the Snort rules!
Go to: http://www.snort.org/pub-bin/downloads.cgi and scroll down till you see the “Sourcefire VRT Certified Rules – The Official Snort Ruleset (unregistered user release)” rules
(If you are a member of the forum you can also download the – registered user release):

wget http://www.snort.org/pub-bin/downloads.cgi/Download/vrt_pr/snortrules-pr-2.4.tar.gz

Move the snortrules-pr-2.4.tar.gz into the snort-2.6.0 map:

mv snortrules-pr-2.4.tar.gz /root/snorttemp/snort-2.6.0

and cd into snort-2.6.0:

cd snort-2.6.0

Untar the snortrules-pr-2.4.tar.gz file:

tar -xvzf snortrules-pr-2.4.tar.gz

Remove the tar file:

rm snortrules-pr-2.4.tar.gz

We are done downloading the files needed to get Snort to work.

To make snort work with BASE, we need more!

PCRE – Perl Compatible Regular Expressions.

Go to: http://www.pcre.org/ and select a download link for the pcre-6.3tar.gz file to download PCRE (at time of writing this it is pcre-6.3.tar.gz)
cd back to the snorttemp map:

cd /root/snorttemp

and download the pcre-6.3.tar.gz file:

wget http://surfnet.dl.sourceforge.net/sourceforge/pcre/pcre-6.3.tar.gz

Untar the file:

tar -xvzf pcre-6.3.tar.gz

Remove the tar:

rm pcre-6.3.tar.gz

Incoming search terms:

• snort base apache windows (1)
• snort programming (1)

1. Install Akismet

This is the simple one that everyone does. Akismet comes bundled with WordPress by default and does a good job of picking up spam – for the average blogger, install Akismet and your spam problems will be sorted. The trouble is though, it just stops spam getting displayed, it doesn’t get to the root of the problem. That’s where this post comes in. We’ll start with some simple methods of stopping spam being displayed and then we’ll move onto stopping the spammers getting on your site in the first place.

2. reCAPTCHA

The reCAPTCHA plugin is one you’ve probably seen around on sites such as Facebook, Twitter and StumbleUpon. It isn’t just your average CAPTCHA (an image containing some letters that are designed so only humans can read them), it uses words from old books, so every time you enter a reCAPTCHA, you’re helping digitise books. At this point, you’re probably thinking but if I’m telling it what the words mean, does that mean I can enter anything? How does that stop spammers? The answer is simple – there are two words, one of which the CAPTCHA knows. The second, it doesn’t and you’re helping digitise it.

The plugin is simple to install, in 2.7+, just do a search for WP-reCAPTCHA and click install. You’ll need a key for the plugin to work, which you can get here. After you’ve done that, reCAPTCHA should appear on your comments’ page.

3. Ask your readers to do 1+1

The second plugin that we’re going to look at as a way of stopping spam being displaued is the ‘Math Comment Spam Protection‘ plugin. Using it, you can add a field to your blog’s comment box with a simple maths (or ‘math’ as they say in the States) question.

I’m not going to go into installing it here as there’s a comprehensive installation guide on the plugin’s website. You can see it in action on WordPress Hacks (image above).

4. Stop spam trackbacks

The final plugin that we’re going to look at is one by the same author who made the plugin above. The ‘Simple Trackback Validation‘ plugin checks if the IP address of the sender of the trackback is the same as the IP address that the trackback URL refers to, thus eliminating [lots]% of trackback spam as spammers won’t use bots running on infected machines. As the plugin’s page says, the plugin also “retrieves the web page located at the URL included in the trackback. If the page doesn’t a link to your blog, the trackback is considered to be spam. Since most trackback spammers do not set up custom web pages linking to the blogs they attack, this simple test will quickly reveal illegitimate trackbacks. Also, bloggers can be stopped abusing trackback by sending trackbacks with their blog software or webservices without having a link to the post.”

Like the ‘Math Comment Spam Protection’ plugin, there’s an installation guide on the plugin’s homepage.

5. Make users login to comment

This is something that probably won’t be a good idea for the majority of bloggers, but it will stop spam – make users login to be able to leave a comment and spammers will be stopped from commenting, but so will one time visitors. Just keep that in mind.

Under ‘Settings’. click ‘Discussion’ and then tick the box ‘Users must be registered and logged in to comment’. Then save changes and you’re done.

6. Ban spammers by IP

Now that we’ve stopped spam being displayed with the tips above, we’re going to move on to blocking spammers getting on your site in the first place. Something we’re going to be using extensively is the .htaccess file. A basic introduction that you should read first is here, and remember the golden rule of .htaccess – always have a backup. Further .htaccess reading is available here on CatsWhoCode and my own blog, WPShout.

In most situations, this tip wouldn’t be too much of a good idea; spammers will fake often their IP, but if there is one IP that is particularly bugging you, then the code below will block them from visiting your site – instert it into your .htaccess file in your blog’s root, changing the second line to include the IP that you wish to ban.

Order allow,deny
Deny from 100.100.100.
Allow from all

7. Ban spammers by IP, on a massive scale

You’ve blocked a single spammer. Well done. Now, with help from Perishable Press, you can block thousands of spammers – Jeff from Perishable has compiled a number of blacklists, from which you can pick and choose which you want to implement into your .htaccess file. The latest blacklists, the ‘fourth generation’ can be accessed below:

• ‘The Perishable Press 4G Blacklist’
• ‘4G Series: The Ultimate Referrer Blacklist, Featuring Over 8000 Banned Referrers‘
• ’4G Series: The Ultimate User-Agent Blacklist, Featuring Over 1200 Bad Bots’

8. Deny comment posting to no referrer requests

Another .htaccess trick and the final comment spam stopping technique we’re going to look at is denying comment posting to no referrer requests – in other words, if the comment isn’t actually coming from your site, then it gets blocked. Make sure you change the url in line four to your blog.

RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-comments-post\.php*
RewriteCond %{HTTP_REFERER} !.*yourblog.com.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) ^http://%{REMOTE_ADDR}/$ [R=301,L]

Source – WordPress Recipes.

9. Stop content theives

Spammers don’t just limit themselves to spamming your comments – often they’ll steal your content too. This next trick will stop spammers who steal your content via RSS. Once you’ve found a site stealing your content, first thing to do is find out the site’s IP address. A search for ‘ping [site name, ie catswhocode.com]‘ should give you a result. Once you’ve got that, head over to the offending site and find their RSS feed. Then, open up your .htaccess file and add the following lines:

RewriteEngine on
RewriteCond %{REMOTE_ADDR} ^69.16.226.12
RewriteRule ^(.*)$ http://newfeedurl.com/feed

Change the IP in line two with the IP of the offending site and the url in line three with the offending site’s feed.

Source - WPShout/ SEO Black Hat

10. Stop spammers stealing your images

Now that we’ve stopped spammers from stealing your content via RSS, now it is time to combat those who just copy and paste your articles onto their site. Yes, this isn’t technically stopping spam, but it is helping combat the spammers.

You’ve got two options if people are hotlinking your images – watermark or .htaccess. We’ll look at both, and I’ll leave you to decide which is better. First up, watermarking. The foolproof method is to watermark your images before you upload them, which you can do with some simple software – FastStone Photo Resizer is a great tool that I’d thoroughly recommend. What’s more, it’s free! The second option is to install phpThumb and create a shortcode that resizes and watermarks your image. Copy and paste the following code into your functions.php file, having uploaded phpThumb to your theme’s folder, uploaded a watermark and changed the URLs. You can also change the width that images will be resized to (it’s currently 590).

<?php function imageresizer( $atts, $content = null ) {
return ‘<img src=”/THEMEURL/phpthumb/phpThumb.php?src=’ . $content . ‘&w=590&amp;fltr[]=wmi|/images/watermark.gif|BR”  alt=”">’;
}
add_shortcode(‘img’, ‘imageresizer’); ?>

With the code integrated, now when uploading a picture, upload it in the normal way, then go into HTML mode and copy the image url, then delete the image and then paste the image URL between [img] and [/img].

Of course, you can also easily disable hotlinking by going into your .htaccess file and pasting the following (changing lines three and five – five will display and alternate image – send it to something blank, or perhaps an ad for your site?):

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?yourdomain.com/.*$ [NC]
#RewriteRule \.(gif|jpg)$ – [F]
RewriteRule \.(gif|jpg)$ http://www.yourdomain.com/advert.jpg [R,L]

Wrapping up

So there we are. Ten lovely ways to stop spam in WordPress, in roughly 1323 words. Got any tips to share? Leave a comment below, of course!

Incoming search terms:

• wordpress blocking trackback spam (1)

Open the file “php.ini” by nano editor

nano  /usr/local/lib/php.ini

Find the word “safe_mode”

[ Ctrl + W and type "safe_mode" ]

Change Off to On

[ "safe_mode = Off" to "safe_mode = On" ]

Find “disabled_functions”

[ Ctrl + W and type "disabled_functions" ]

and add functions

[system, exec, shell_exec, passthru, pcntl_exec, putenv, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, popen, pclose, set_time_limit, ini_alter, virtual, openlog, escapeshellcmd, escapeshellarg, dl, curl_exec, parse_ini_file, show_source]

then save the file :

[ Ctrl + X then Y ]

retart Apache web server

[ /etc/init.d/httpd restart ]

Done

Notice : backup php.ini before you change anything . Good luck

Incoming search terms:

• apache security windows (1)
• putenv directadmin (1)

netfilter is a set of hooks inside the Linux kernel that allows kernel modules to register callback functions with the network stack. A registered callback function is then called back for every packet that traverses the respective hook within the network stack.

This Linux based firewall is controlled by the program called iptables to handles filtering for IPv4, and ip6tables handles filtering for IPv6. I strongly recommend that you first read our quick tutorial that explains how to configure a host-based firewall called Netfilter (iptables) under CentOS / RHEL / Fedora / Redhat Enterprise Linux. This post list most common iptables solutions required by a new Linux user to secure his or her Linux operating system from intruders.

IPTABLES Rules Example

• Most of the actions listed in this post are written with the assumption that they will be executed by the root user running the bash or any other modern shell. Do not type commands on remote system as it will disconnect your access.
• For demonstration purpose I’ve used RHEL 6.x, but the following command should work with any modern Linux distro.

#1: Displaying the Status of Your Firewall

Type the following command as root:
# iptables -L -n -v
Sample outputs:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Above output indicates that the firewall is not active. The following sample shows an active firewall:
# iptables -L -n -v
Sample outputs:

Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID
  394 43586 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
   93 17292 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0
    1   142 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  br0    br0     0.0.0.0/0            0.0.0.0/0
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID
    0     0 TCPMSS     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x06/0x02 TCPMSS clamp to PMTU
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
    0     0 wanin      all  --  vlan2  *       0.0.0.0/0            0.0.0.0/0
    0     0 wanout     all  --  *      vlan2   0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0
Chain OUTPUT (policy ACCEPT 425 packets, 113K bytes)
 pkts bytes target     prot opt in     out     source               destination
Chain wanin (1 references)
 pkts bytes target     prot opt in     out     source               destination
Chain wanout (1 references)
 pkts bytes target     prot opt in     out     source               destination

Where,

• -L : List rules.
• -v : Display detailed information. This option makes the list command show the interface name, the rule options, and the TOS masks. The packet and byte counters are also listed, with the suffix ‘K’, ‘M’ or ‘G’ for 1000, 1,000,000 and 1,000,000,000 multipliers respectively.
• -n : Display IP address and port in numeric format. Do not use DNS to resolve names. This will speed up listing.

#1.1: To inspect firewall with line numbers, enter:

# iptables -n -L -v --line-numbers
Sample outputs:

Chain INPUT (policy DROP)
num  target     prot opt source               destination
1    DROP       all  --  0.0.0.0/0            0.0.0.0/0           state INVALID
2    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
3    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
4    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
Chain FORWARD (policy DROP)
num  target     prot opt source               destination
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
2    DROP       all  --  0.0.0.0/0            0.0.0.0/0           state INVALID
3    TCPMSS     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x06/0x02 TCPMSS clamp to PMTU
4    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
5    wanin      all  --  0.0.0.0/0            0.0.0.0/0
6    wanout     all  --  0.0.0.0/0            0.0.0.0/0
7    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination
Chain wanin (1 references)
num  target     prot opt source               destination
Chain wanout (1 references)
num  target     prot opt source               destination

You can use line numbers to delete or insert new rules into the firewall.

#1.2: To display INPUT or OUTPUT chain rules, enter:

# iptables -L INPUT -n -v
# iptables -L OUTPUT -n -v --line-numbers

#2: Stop / Start / Restart the Firewall

If you are using CentOS / RHEL / Fedora Linux, enter:
# service iptables stop
# service iptables start
# service iptables restart
You can use the iptables command itself to stop the firewall and delete all rules:
# iptables -F
# iptables -X
# iptables -t nat -F
# iptables -t nat -X
# iptables -t mangle -F
# iptables -t mangle -X
# iptables -P INPUT ACCEPT
# iptables -P OUTPUT ACCEPT
# iptables -P FORWARD ACCEPT
Where,

• -F : Deleting (flushing) all the rules.
• -X : Delete chain.
• -t table_name : Select table (called nat or mangle) and delete/flush rules.
• -P : Set the default policy (such as DROP, REJECT, or ACCEPT).

#3: Delete Firewall Rules

To display line number along with other information for existing rules, enter:
# iptables -L INPUT -n --line-numbers
# iptables -L OUTPUT -n --line-numbers
# iptables -L OUTPUT -n --line-numbers | less
# iptables -L OUTPUT -n --line-numbers | grep 202.54.1.1
You will get the list of IP. Look at the number on the left, then use number to delete it. For example delete line number 4, enter:
# iptables -D INPUT 4
OR find source IP 202.54.1.1 and delete from rule:
# iptables -D INPUT -s 202.54.1.1 -j DROP
Where,

• -D : Delete one or more rules from the selected chain

#4: Insert Firewall Rules

To insert one or more rules in the selected chain as the given rule number use the following syntax. First find out line numbers, enter:
# iptables -L INPUT -n –line-numbers
Sample outputs:

Chain INPUT (policy DROP)
num  target     prot opt source               destination
1    DROP       all  --  202.54.1.1           0.0.0.0/0
2    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state NEW,ESTABLISHED

To insert rule between 1 and 2, enter:
# iptables -I INPUT 2 -s 202.54.1.2 -j DROP
To view updated rules, enter:
# iptables -L INPUT -n --line-numbers
Sample outputs:

Chain INPUT (policy DROP)
num  target     prot opt source               destination
1    DROP       all  --  202.54.1.1           0.0.0.0/0
2    DROP       all  --  202.54.1.2           0.0.0.0/0
3    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state NEW,ESTABLISHED

#5: Save Firewall Rules

To save firewall rules under CentOS / RHEL / Fedora Linux, enter:
# service iptables save
In this example, drop an IP and save firewall rules:
# iptables -A INPUT -s 202.5.4.1 -j DROP
# service iptables save
For all other distros use the iptables-save command:
# iptables-save > /root/my.active.firewall.rules
# cat /root/my.active.firewall.rules

#6: Restore Firewall Rules

To restore firewall rules form a file called /root/my.active.firewall.rules, enter:
# iptables-restore < /root/my.active.firewall.rules
To restore firewall rules under CentOS / RHEL / Fedora Linux, enter:
# service iptables restart

#7: Set the Default Firewall Policies

To drop all traffic:
# iptables -P INPUT DROP
# iptables -P OUTPUT DROP
# iptables -P FORWARD DROP
# iptables -L -v -n
#### you will not able to connect anywhere as all traffic is dropped ###
# ping cyberciti.biz
# wget http://www.kernel.org/pub/linux/kernel/v3.0/testing/linux-3.2-rc5.tar.bz2

#7.1: Only Block Incoming Traffic

To drop all incoming / forwarded packets, but allow outgoing traffic, enter:
# iptables -P INPUT DROP
# iptables -P FORWARD DROP
# iptables -P OUTPUT ACCEPT
# iptables -A INPUT -m state --state NEW,ESTABLISHED -j ACCEPT
# iptables -L -v -n
### *** now ping and wget should work *** ###
# ping cyberciti.biz
# wget http://www.kernel.org/pub/linux/kernel/v3.0/testing/linux-3.2-rc5.tar.bz2

#8:Drop Private Network Address On Public Interface

IP spoofing is nothing but to stop the following IPv4 address ranges for private networks on your public interfaces. Packets with non-routable source addresses should be rejected using the following syntax:
# iptables -A INPUT -i eth1 -s 192.168.0.0/24 -j DROP
# iptables -A INPUT -i eth1 -s 10.0.0.0/8 -j DROP

#8.1: IPv4 Address Ranges For Private Networks (make sure you block them on public interface)

• 10.0.0.0/8 -j (A)
• 172.16.0.0/12 (B)
• 192.168.0.0/16 (C)
• 224.0.0.0/4 (MULTICAST D)
• 240.0.0.0/5 (E)
• 127.0.0.0/8 (LOOPBACK)

#9: Blocking an IP Address (BLOCK IP)

To block an attackers ip address called 1.2.3.4, enter:
# iptables -A INPUT -s 1.2.3.4 -j DROP
# iptables -A INPUT -s 192.168.0.0/24 -j DROP

#10: Block Incoming Port Requests (BLOCK PORT)

To block all service requests on port 80, enter:
# iptables -A INPUT -p tcp --dport 80 -j DROP
# iptables -A INPUT -i eth1 -p tcp --dport 80 -j DROP

To block port 80 only for an ip address 1.2.3.4, enter:
# iptables -A INPUT -p tcp -s 1.2.3.4 --dport 80 -j DROP
# iptables -A INPUT -i eth1 -p tcp -s 192.168.1.0/24 --dport 80 -j DROP

#11: Block Outgoing IP Address

To block outgoing traffic to a particular host or domain such as cyberciti.biz, enter:
# host -t a cyberciti.biz
Sample outputs:

cyberciti.biz has address 75.126.153.206

Note down its ip address and type the following to block all outgoing traffic to 75.126.153.206:
# iptables -A OUTPUT -d 75.126.153.206 -j DROP
You can use a subnet as follows:
# iptables -A OUTPUT -d 192.168.1.0/24 -j DROP
# iptables -A OUTPUT -o eth1 -d 192.168.1.0/24 -j DROP

#11.1: Example – Block Facebook.com Domain

First, find out all ip address of facebook.com, enter:
# host -t a www.facebook.com
Sample outputs:

www.facebook.com has address 69.171.228.40

Find CIDR for 69.171.228.40, enter:
# whois 69.171.228.40 | grep CIDR
Sample outputs:

CIDR:           69.171.224.0/19

To prevent outgoing access to www.facebook.com, enter:
# iptables -A OUTPUT -p tcp -d 69.171.224.0/19 -j DROP
You can also use domain name, enter:
# iptables -A OUTPUT -p tcp -d www.facebook.com -j DROP
# iptables -A OUTPUT -p tcp -d facebook.com -j DROP

From the iptables man page:

… specifying any name to be resolved with a remote query such as DNS (e.g., facebook.com is a really bad idea), a network IP address (with /mask), or a plain IP address …

#12: Log and Drop Packets

Type the following to log and block IP spoofing on public interface called eth1
# iptables -A INPUT -i eth1 -s 10.0.0.0/8 -j LOG --log-prefix "IP_SPOOF A: "
# iptables -A INPUT -i eth1 -s 10.0.0.0/8 -j DROP
By default everything is logged to /var/log/messages file.
# tail -f /var/log/messages
# grep --color 'IP SPOOF' /var/log/messages

#13: Log and Drop Packets with Limited Number of Log Entries

The -m limit module can limit the number of log entries created per time. This is used to prevent flooding your log file. To log and drop spoofing per 5 minutes, in bursts of at most 7 entries .
# iptables -A INPUT -i eth1 -s 10.0.0.0/8 -m limit --limit 5/m --limit-burst 7 -j LOG --log-prefix "IP_SPOOF A: "
# iptables -A INPUT -i eth1 -s 10.0.0.0/8 -j DROP

#14: Drop or Accept Traffic From Mac Address

Use the following syntax:
# iptables -A INPUT -m mac --mac-source 00:0F:EA:91:04:08 -j DROP
## *only accept traffic for TCP port # 8080 from mac 00:0F:EA:91:04:07 * ##
# iptables -A INPUT -p tcp --destination-port 22 -m mac --mac-source 00:0F:EA:91:04:07 -j ACCEPT

#15: Block or Allow ICMP Ping Request

Type the following command to block ICMP ping requests:
# iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
# iptables -A INPUT -i eth1 -p icmp --icmp-type echo-request -j DROP
Ping responses can also be limited to certain networks or hosts:
# iptables -A INPUT -s 192.168.1.0/24 -p icmp --icmp-type echo-request -j ACCEPT
The following only accepts limited type of ICMP requests:
### ** assumed that default INPUT policy set to DROP ** #############
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
## ** all our server to respond to pings ** ##
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

#16: Open Range of Ports

Use the following syntax to open a range of ports:
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 7000:7010 -j ACCEPT

#17: Open Range of IP Addresses

Use the following syntax to open a range of IP address:
## only accept connection to tcp port 80 (Apache) if ip is between 192.168.1.100 and 192.168.1.200 ##
iptables -A INPUT -p tcp --destination-port 80 -m iprange --src-range 192.168.1.100-192.168.1.200 -j ACCEPT

## nat example ##
iptables -t nat -A POSTROUTING -j SNAT --to-source 192.168.1.20-192.168.1.25


#18: Established Connections and Restaring The Firewall

When you restart the iptables service it will drop established connections as it unload modules from the system under RHEL / Fedora / CentOS Linux. Edit, /etc/sysconfig/iptables-config and set IPTABLES_MODULES_UNLOAD as follows:

IPTABLES_MODULES_UNLOAD = no

#19: Help Iptables Flooding My Server Screen

Use the crit log level to send messages to a log file instead of console:
iptables -A INPUT -s 1.2.3.4 -p tcp --destination-port 80 -j LOG --log-level crit

#20: Block or Open Common Ports

The following shows syntax for opening and closing common TCP and UDP ports:

 
Replace ACCEPT with DROP to block port:
## open port ssh tcp port 22 ##
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 22 -j ACCEPT

## open cups (printing service) udp/tcp port 631 for LAN users ##
iptables -A INPUT -s 192.168.1.0/24 -p udp -m udp --dport 631 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -p tcp -m tcp --dport 631 -j ACCEPT

## allow time sync via NTP for lan users (open udp port 123) ##
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p udp --dport 123 -j ACCEPT

## open tcp port 25 (smtp) for all ##
iptables -A INPUT -m state --state NEW -p tcp --dport 25 -j ACCEPT

# open dns server ports for all ##
iptables -A INPUT -m state --state NEW -p udp --dport 53 -j ACCEPT
iptables -A INPUT -m state --state NEW -p tcp --dport 53 -j ACCEPT

## open http/https (Apache) server port to all ##
iptables -A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT

## open tcp port 110 (pop3) for all ##
iptables -A INPUT -m state --state NEW -p tcp --dport 110 -j ACCEPT

## open tcp port 143 (imap) for all ##
iptables -A INPUT -m state --state NEW -p tcp --dport 143 -j ACCEPT

## open access to Samba file server for lan users only ##
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 137 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 138 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 139 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 445 -j ACCEPT

## open access to proxy server for lan users only ##
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 3128 -j ACCEPT

## open access to mysql server for lan users only ##
iptables -I INPUT -p tcp --dport 3306 -j ACCEPT

#21: Restrict the Number of Parallel Connections To a Server Per Client IP

You can use connlimit module to put such restrictions. To allow 3 ssh connections per client host, enter:
# iptables -A INPUT -p tcp --syn --dport 22 -m connlimit --connlimit-above 3 -j REJECT

Set HTTP requests to 20:
# iptables -p tcp --syn --dport 80 -m connlimit --connlimit-above 20 --connlimit-mask 24 -j DROP
Where,

1. –connlimit-above 3 : Match if the number of existing connections is above 3.
2. –connlimit-mask 24 : Group hosts using the prefix length. For IPv4, this must be a number between (including) 0 and 32.

#22: HowTO: Use iptables Like a Pro

For more information about iptables, please see the manual page by typing man iptables from the command line:
$ man iptables
You can see the help using the following syntax too:
# iptables -h
To see help with specific commands and targets, enter:
# iptables -j DROP -h

#22.1: Testing Your Firewall

Find out if ports are open or not, enter:
# netstat -tulpn
Find out if tcp port 80 open or not, enter:
# netstat -tulpn | grep :80
If port 80 is not open, start the Apache, enter:
# service httpd start
Make sure iptables allowing access to the port 80:
# iptables -L INPUT -v -n | grep 80
Otherwise open port 80 using the iptables for all users:
# iptables -A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT
# service iptables save
Use the telnet command to see if firewall allows to connect to port 80:
$ telnet www.cyberciti.biz 80
Sample outputs:

Trying 75.126.153.206...
Connected to www.cyberciti.biz.
Escape character is '^]'.
^]
telnet> quit
Connection closed.

You can use nmap to probe your own server using the following syntax:
$ nmap -sS -p 80 www.cyberciti.biz
Sample outputs:

Starting Nmap 5.00 ( http://nmap.org ) at 2011-12-13 13:19 IST
Interesting ports on www.cyberciti.biz (75.126.153.206):
PORT   STATE SERVICE
80/tcp open  http
Nmap done: 1 IP address (1 host up) scanned in 1.00 seconds

I also recommend you install and use sniffer such as tcpdupm and ngrep to test your firewall settings.

Conclusion:

This post only list basic rules for new Linux users. You can create and build more complex rules. This requires good understanding of TCP/IP, Linux kernel tuning via sysctl.conf, and good knowledge of your own setup. Stay tuned for next topics:

• Stateful packet inspection.
• Using connection tracking helpers.
• Network address translation.
• Layer 2 filtering.
• Firewall testing tools.
• Dealing with VPNs, DNS, Web, Proxy, and other protocols.

Incoming search terms:

• -m mac --mac-source (1)
• nginx rules firewall ip iptables (1)
• netfilter programming examples (1)
• iptables telnet allow deny (1)
• iptables examples log (1)
• iptables example (1)
• iptables drop active connection (1)
• Chain INPUT policy ACCEPT (1)
• cenots iptables port add (1)
• redhat hardening shell script (1)

PHP’s default configuration file, php.ini (usually found in /etc/php.ini on most Linux systems) contains a host of functionality that can be used to help secure your web applications. Unfortunately many PHP users and administrators are unfamiliar with the various options that are available with php.ini and leave the file in it’s stock configuration. By utilizing a few of the security related options in the configuration file you can greatly strengthen the security posture of web applications running on your server.

Safe Mode

PHP safe mode is a comprehensive “attempt to solve the shared server security problem” that includes many useful features. Note that safe mode support is being removed in PHP 6. Safe mode effectively checks if functions in one file on the server that affect other files all have the same ownership. For instance, if you have a page script1.php that attempts to read the contents of a directory img/. Safe mode with check the UID of script1.php and the img/ directory. If they match then the script will be allowed access, if they don’t match then safe mode will disable access. This is an interesting security mechanism that allows you to restrict access by scripts outside of the normal application installation directory. Safe mode may cause problems though when the web server ends up owning files (for instance when a new file is uploaded or created by an application it is usually owned by ‘apache’ or a similar web server account).

Safe mode will also restrict executables that may be run by scripts in the same way it restricts file and directory access. Safe mode can also be configured so that only executables in a certain directory can be run. This can help limit exposure of shell commands to certain scripts.

To enable safe mode, alter (or add) the safe mode directive in the php.ini to:

safe_mode = On

In some cases you’ll want to use a group to check ownership (for instance in the case that you have multiple people deploying web application scripts). To have safe mode check group permissions use:

safe_mode_gid = On

If you want to limit directories that can contain included files or executables use the following php.ini directives respectively:

safe_mode_include_dir = /path/to/dir
safe_mode_exec_dir = /path/to/exec/dir

Safe mode has several other useful features that are worth looking into. Browse the documentation at the PHP website and see if safe mode is right for your environment.

Restricting Includes

Using the open_basedir directive in PHP makes a lot of sense given most file include vulnerability vectors. This directive limits all PHP file operations to the listed directory and below. It is common for attackers to search for ways to include local files in PHP scripts to expose local filesystem files through the web server. For instance, if an attacker found a file inclusion vulnerability they might try to include the /etc/passwd file to enumerate all the user accounts on the system. With the open_basedir directive PHP can restrict file inclusion to the web root, for instance /var/www. Once set files outside that directory cannot be included in scripts, and thus the aforementioned attack would fail. To enable the open_basedir directive update your php.ini file to include:

open_basedir = /path/to/web/root

Disabling Functionality

There are certain functions in PHP that you probably don’t want your developers to use because of the danger they pose. Even if you know your users aren’t utilizing certain functions it is wise to completely disable them so an attacker can’t use them. This security precaution is especially effective at stopping an attacker who has somehow managed to upload a PHP script, write one to the filesystem, or even include a remote PHP file. By disabling functionality you ensure that you can limit the effectiveness of these types of attacks. It should be noted that it is virtually impossible to do something like preventing an attacker from executing a command at a shell by disabling functions, but it can certainly stop an attacker who isn’t a skillful PHP programmer.

By disabling functions like shell_exec() and system() you can prevent users and attackers from utilizing these functions. It is important to restrict functionality for developers because use of these command opens the potential for a remote code execution vulnerability if not utilized with great care. There are certainly cases for operations such as executing a command at a shell, but PHP provides a drove of functions that are essentially the same. Developers can standardize on one such function and the rest can be disabled to help prevent attacks. While this isn’t a foolproof solution it will probably prevent attacks like the dreaded c99 shell. To enable the disable_functions directive simply add it to your php.ini with a comma separated list of functions you want to restrict. For instance:

disable_functions = php_uname, getmyuid, getmypid, passthru, leak, listen, diskfreespace, tmpfile, link, ignore_user_abord, shell_exec, dl, set_time_limit, exec, system, highlight_file, source, show_source, fpaththru, virtual, posix_ctermid, posix_getcwd, posix_getegid, posix_geteuid, posix_getgid, posix_getgrgid, posix_getgrnam, posix_getgroups, posix_getlogin, posix_getpgid, posix_getpgrp, posix_getpid, posix, _getppid, posix_getpwnam, posix_getpwuid, posix_getrlimit, posix_getsid, posix_getuid, posix_isatty, posix_kill, posix_mkfifo, posix_setegid, posix_seteuid, posix_setgid, posix_setpgid, posix_setsid, posix_setuid, posix_times, posix_ttyname, posix_uname, proc_open, proc_close, proc_get_status, proc_nice, proc_terminate, phpinfo

Preventing Information Disclosure

Attackers will often use information that your web server exposes in order to gain information about the server configuration, application layout, and components. Error messages are some of the most common paths to information disclosure, often leaking information such as application installation path, database connectivity, data model details such as table and column names, and script details such as variables. While this debugging information is invaluable to developers it is useless to end users and dangerous to expose to attackers. PHP debugging output should be disabled in the php.ini using:

display_errors = Off

This prevents PHP from showing run time errors in pages served to users. PHP will continue to log the errors as normal, however, so they can be reviewed by developers. Be wary of developer tactics to end run PHP errors, however, as disabling this functionality does not prevent information disclosure. Some developers may use custom debugging output nested in HTML comments, third party tools like FirePHP, or writing PHP error logs to local directories using .htaccess files and the error_log directive. However, by preventing the display of errors by default you reduce the possibility of exposing information to attackers.

Disable Globals

Global variables are a horrible hold over from the PHP 3 days. In most distributions register global variables is set to off (and thankfully it won’t be supported in future versions of PHP). However, you should ensure that the directive is properly in place. You should find the following in your php.ini file:

register_globals = Off

Register globals allows various HTTP variables to be used without specifying their source. For instance, if a developer wants to use a URL variable named ‘id’, for instance from the URL request index.php?id=4, with globals they can simply use $id rather than $_GET['id']. This is a great convenience but it can cause collisions. For instance, if a form post uses a variable called ‘id’ and there is a variable $id defined in a script and a user alters the URL of the script to include an ‘id=’ in the URL which variable has precedence? Even more damaging is the ability of attackers to override configuration variables such as DOCUMENT_ROOT from the URL. This can cause no end of problems, especially if attackers are able to call scripts that are normally included in other scripts and expect predefined variables, which could be overwritten via GET variables by an attacker.

Many legacy applications may require globally registered variables. If this is the case at least limit the configuration to specific application directories rather than throughout your PHP installation. You can do this using PHP directives in .htaccess files included in specific directories. Ensure that register_globals is set to Off, however, in your php.ini configuration!

Disable Remote File Includes

Attackers will often attempt to identify file inclusion vulnerabilities in applications then use them to include malicious PHP scripts that they write. Even if an attacker doesn’t have write access to the web application directories if remote file inclusion is enabled the attacker can host malicious PHP scripts on other servers and the web application will fetch them and execute them locally! This can have devastating consequences. To restrict remote file execution be sure the following appears in your php.ini file:

allow_url_fopen = Off
allow_url_include = Off

This prevents remote scripts from being included and executed by scripts on your system.

Restrict File Uploads

If you’re not utilizing file upload functionality in any of your PHP scripts then it’s a good idea to turn it off. Attackers will attempt to (mis)use file uploads to quickly inject malicious scripts into your web applications. By disabling file uploads altogether this makes moving scripts onto your web server more difficult. To disable file uploads change the file_uploads directive in your php.ini to read:

file_uploads = Off

Even if you do allow file uploads you should change the default temporary directory used for file uploads. This can be done by changing the upload_tmp_dir directive. You may also want to restrict the size of files that can be uploaded. This is usually more of a system administration alteration than a security fix, but it can be useful. Use the upload_max_filesize directive for this purpose. To restrict upload directories and file sizes change your php.ini so that it reads:

upload_tmp_dir = /var/php_tmp
upload_max_filezize = 2M

Protect Sessions

Session stealing is a popular attack that allows a malicious user to hijack the session of a legitimate user. Using session hijacking an attacker can bypass authorization and access portions of web applications without authorization. PHP uses strong (meaning long pseudo randomly generated) session identifiers so that guessing a session id is extremely difficult. When logging into a PHP application you can view your cookies and likely identify a cookie with an name like ‘phpsessid’ and a value similar to ‘bbbca6bb7a23bdc8de3baef2b506e654′. The cookie is composed of 32 hexadecimal characters, making it extremely hard to predict. The flaw in this system, however, is that these session identifiers are written to the filesystem when they’re created so PHP can keep track of them. Changing the default location of these session identifiers will confound some attempts to read them. To change the location where session information is written alter the session.save_path in the php.ini configuration so that it points to your desired location like so:

session.save_path = /var/lib/php

Make sure that the web server can read and write to the location you specify, however, or sessions won’t work. You may also wish to set PHP so that it writes cookies in such a way that they are inaccessible to JavaScript. If you don’t have any PHP applications that utilize JavaScript to manipulate cookies this is a great idea. Attackers will often exploit Cross Site Scripting (XSS) flaws in web applications to inject JavaScript into pages, which could be used to steal session cookies. By setting the php.ini directive:

session.cookie_httponly = 1

you restrict JavaScript from accessing your cookies. Another small security feature is allowing PHP to check HTTP referer values so that session information is only passed internally while a user is viewing an application. This prevents users from accidentally publishing session information in a way that would allow external users to follow links and steal a session. This is especially useful if session information is being passed in a URL that could accidentally be published to a mailing list or web site. To enable this functionality use the following in your php.ini:

session.referer_check = your_url.tld

For more information about session security see http://devzone.zend.com/manual/ref.session.html.

Conclusions

Implementing these security features within your PHP configuration isn’t a recipe for complete security, but it does increase the overall security posture of your web applications. By combining these measures with others, such as Suhosin and an intrusion detection system like OSSEC you incrementally increase the security of your server and web applications. You must be careful to implement configurations that restrict functionality that could be used to the detriment of your installation but not to restrict developers. Frustrating developers is a sure fire recipe for home grown solutions to end run your restrictions and invariably these solutions weaken the overall security of your server and often introduce vulnerabilities. Take care to harden your servers as much as possible, but don’t become over zealous. Beginning the process of server hardening with your php.ini configuration is a great step as it affects all the PHP web applications installed on the server and can be applied incrementally. Remember to restart your web server after making changes to the php.ini file so that those changes are put into effect.

Incoming search terms:

• access php files form centos to windows (1)
• secure plesk c99 shell (1)
• Remote File Inclusion centos (1)
• php session exploit network solutions (1)
• php posix_setuid module centos (1)
• php ini centos variables sesion php (1)
• php cookie allow_url_include (1)
• no effect of php ini change in centos (1)
• hardening centos (1)
• harden php (1)

error message: from firewall software ~ iptables: Unknown error 4294967295

you need to make sure the required iptable modules are loaded in the host server kernel. You have to use modprobe to load the following modules in the kernel:

modprobe ipt_MASQUERADE
modprobe ipt_helper
modprobe ipt_REDIRECT
modprobe ipt_state
modprobe ipt_TCPMSS
modprobe ipt_LOG
modprobe ipt_TOS
modprobe tun
modprobe iptable_nat
modprobe ipt_length
modprobe ipt_tcpmss
modprobe iptable_mangle
modprobe ipt_limit
modprobe ipt_tos
modprobe iptable_filter
modprobe ipt_helper
modprobe ipt_tos
modprobe ipt_ttl
modprobe ipt_REJECT

Once the modules are loaded, add the modules to your VPS using the vzctl command. You will have to stop the VPS first

vzctl stop VEID

and then add the modules to a VPS

vzctl set VEID –iptables ipt_REJECT –iptables ipt_tos –iptables ipt_TOS –iptables ipt_LOG –iptables ip_conntrack –iptables ipt_limit –iptables ipt_multiport –iptables iptable_filter –iptables iptable_mangle –iptables ipt_TCPMSS –iptables ipt_tcpmss –iptables ipt_ttl –iptables ipt_length –iptables ipt_state –iptables iptable_nat –iptables ip_nat_ftp –save

Once the above command is executed, start the VPS

vzctl start VEID

Now you are set to use iptables on your VPS.

Incoming search terms:

• modprobe ipt_redirect vps (2)
• geoip database 갱신 centos iptables (1)
• plesk iptables 4294967295 (1)

By setting up daily reporting, this notifies you within, at most, 24 hours of when any file was changed, added, or removed.  It also helps establish an audit trail in the event your site is compromised.

These instructions are designed for an end user, where you don’t need to have root access, to implement and assumes your server has the aide binary installed.  Most hosts will have this installed already, or will install it for you upon request.

Step 1: Download A Sample AIDE config file

We will start with a simple one, this will scan your web root directory for md5 hash changes.

To download the file, SSH into your account and run:

$ wget securehostingdirectory.com/aide.conf

What you will want to change in this file, is replace “username” on the first line, and confirm that is the path to your root directory.

Then on the last line, confirm that public_html is your web root directory.  If your host uses the cPanel control panel, then public_html is your web root.

Step 2: Initialize the AIDE database

The command to initialize the AIDE database is:

$ nice -19 aide --init --config=/home/username/aide.conf

AIDE is not the least resource intensive software in the world so we are running it with a 19 priority using nice.

Now copy your AIDE output database file to the input file:

$ cp aide.db.out aide.db.in

You can test aide by doing:

$ nice -19 aide -C --config=/home/username/aide.conf

Go ahead and run that now, it will say all files match, then make a change to a file and add a file, rerun it and see what the report says.

Step 3: Daily Reporting

There are a few ways to get the aide reports, a common one is to have it email you the reports, for this you can set a cronjob to run aide everyday, or even more frequently if you’d like.

Open up the crontab editor and paste in:

0 1 * * * nice -19 /usr/local/bin/aide --config=/home/username/aide.conf -C| mail you@domain -saide\ domain

The reports can get rather lengthy overtime, so if you want to reset the database, say weekly, you can add this to the crontab:

0 2 * * 0  nice -19 /usr/local/bin/aide --config=/home/username/aide.conf --init;mv -f /home/username/aide.db.out /home/username/aide.db.in

Step 4: Extras

We have covered the basics, and that is actually only the tip of the iceberg of what you can do with AIDE.

You can get the full AIDE config file here: Full AIDE Config File

And you might want to exclude certain files, for example if you have a forum or gallery and a lot of images are added regularly you can exclude those from the report. For example to exclude all jpg files in images/ you would put the following in the config file:

 !@@{TOPDIR}/public_html/images/.*\.jpg$

And that would go right above this line:

@@{TOPDIR}/public_html MD

Another thing you can do for extra security is, have your host chown your in database file, and your config file to another user, this way if your user is compromised, the hacker could not compromise your AIDE database, without also gaining access to the second user.

To be even more secure, you can download your AIDE database after creating it, and then upload it before you run a scan.

I hope this Howto lets you see the need for a file integrity checker, and makes it easy to setup, no matter what your user level is.

Incoming search terms:

• advanced intrusion detection environment (1)
• aide conf example (1)
• centos aide config (1)
• configure aide in shell script (1)
• htdocs centos 5 5 location (1)
• nice 19 aide --check (1)

This rule limits one connection to the SSH port from one IP address per minute.

hashlimit match options

  --hashlimit-upto            max average match rate
                                   [Packets per second unless followed by
                                   /sec /minute /hour /day postfixes]
  –hashlimit-above           min average match rate
  –hashlimit-mode           mode is a comma-separated list of
                                   dstip,srcip,dstport,srcport (or none)
  –hashlimit-srcmask      source address grouping prefix length
  –hashlimit-dstmask      destination address grouping prefix length
  –hashlimit-name           name for /proc/net/ipt_hashlimit
  –hashlimit-burst 	    number to match in a burst, default 5
  –hashlimit-htable-size     number of hashtable buckets
  –hashlimit-htable-max      number of hashtable entries
  –hashlimit-htable-gcinterval    interval between garbage collection runs
  –hashlimit-htable-expire        after which time are idle entries expired?

Incoming search terms:

• hashlimit (6)
• ipt_hashlimit input (4)
• ipt_hashlimit not working (3)
• hashlimit match options (2)
• hashlimit-upto (2)
• iptables hashlimit (2)
• hashlimit-burst (2)
• iptables: hashlimit with recent (1)
• iptables rate hashlimit (1)
• iptables: using hashlimit and recent matches (1)

Prelude will allow to log all of the events to the prelude database and be consulted using one interface (prewikka). This howto will describe how to install and configure the different tools that will make up the complete solution.

This howto is based on bits and scraps I found in order to resolve some issues, parts from the manuals and my own experiance with installing the complete solution.

For more information on snort visit: www.snort.org

For more information on ossec visit: www.ossec.net

For more information on prelude visit: www.prelude-ids.org

Prerequisites:

Let’s just assume you followed the The Perfect Server – Ubuntu Gutsy Gibbon (Ubuntu 7.10). If not follow that howto and only install / add those part’s you havent got installed on your system.

The following packages are useful, so please check that they are installed correctly:

apt-get install ntpdate
apt-get install dbconfig-common

Installing And Configuring Prelude

Normally, we would have to compile and install libprelude, libpreludedb, and then create the databases. Luckely enough the packages are provide by the Ubuntu repositories.

Prelude Manager

apt-get install prelude-manager

- Using default TLS settings from /etc/prelude/default/tls.conf:
- Generated key size: 1024 bits.
- Authority certificate lifetime: unlimited.
- Generated certificate lifetime: unlimited.

- Creating analyzer prelude-manager.
- Creating /etc/prelude/profile/prelude-manager…
- Allocated ident for prelude-manager: 4232957740008155.
- Generating RSA private key… This might take a very long time.
[Increasing system activity will speed-up the process.]

- Generating 1024 bits RSA private key…

During the installation, the manager will create the profile for the prelude user. It can take a (very) long time, since GnuTLS tries to access /dev/random instead of /dev/urandom (for security reasons). This may change in the future (maybe using an option to have a faster generation, but crytographically less secure).

dbconfig will then ask you if you want it to configure the database automatically. If you don’t want to, just say no, and configure everything manually (the sql scripts are in directory /usr/share/libpreludedb/). Let’s suppose the answer is yes.

Note: the number of questions may change, depending on debconf verbosity (set using dpkg-reconfigure debconf), and dbconfig parameters, in file /etc/dbconfig-common/config.

configure database with dbconfig-common: yes
database type:

Set the type to the database you previously installed. In this case mysql.

Database admin password: ******

dbconfig-common will ask for a password for the ‘prelude’ user. If you don’t provide any (just pressing enter), it will generate a random one. Don’t worry, the configuration file will be update automatically.

dbconfig-common: writing config to /etc/dbconfig-common/prelude-manager.conf

Creating config file /etc/dbconfig-common/prelude-manager.conf with new version
granting access to database prelude for prelude@localhost: success.
verifying access for prelude@localhost: success.
creating database prelude: success.
verifying database prelude exists: success.
populating database via sql… done.
dbconfig-common: flushing administrative password
Starting Prelude Manager: prelude-manager.

The Ubunty package automatically creates the user and the database for prelude. If you want to change the password, do so first in mysql and after in /etc/prelude-manager/prelude-manager.conf.

Prelude-Manager should now be running:

ps auxw | grep manager

prelude 28530 0.0 0.1 59384 4480 ? Ssl 13:49 0:00 /usr/sbin/prelude-manager

The first part is over, you now have a manager up and running.

Listen address:

The default listen address is localhost (127.0.0.1). This means that you have to change this to add sensors on different hosts in order for the agents to be able to reach the prelude-manager.

Edit  /etc/prelude-manager/prelude-manager.conf:

listen = xxx.xxx.xxx.xxx

Restart the server, and check the address (if you changed the address):

# /etc/init.d/prelude-manager stop

Stopping Prelude Manager: prelude-manager.

# /etc/init.d/prelude-manager start

Starting Prelude Manager: prelude-manager.

# netstat -pantu | grep prelude

tcp 0 0 192.168.66.1:4690 0.0.0.0:* LISTEN 30544/prelude-manager

Prelude-LML

You need to install prelude-lml on every host you want to monitor. Prelude-LML will analyze your logs and reports event to the managers.

# apt-get install prelude-lml

…
Starting Prelude LML: prelude-lml.

Before it can be used, two things needs to be done:

• The address of the manager must be configured on the lml
• The manager won’t trust sensors, until they are registered

Manager address

If you changed the address the manager is listening on, you need to change the address in the client config on every machine you install prelude-lml .

The adress of the manager is stored in file /etc/prelude/default/client.conf:

[prelude]
server-addr = 127.0.0.1

Registering the sensor

Registering the sensor is a four-step process, which requires to run commands on both the sensor and the manager:

On the LML client, run the register command:

prelude-adduser register prelude-lml “idmef:w” <manager address> –uid 0 –gid 0

Tip: if you don’t remember the command, just run prelude-lml. Since it is not registered, it will fail, but is smart enough to display the help:

# prelude-lml
- Subscribing plugin pcre[default]
- pcre plugin loaded 394 rules.
- Monitoring /var/log/messages through pcre[default]
* WARNING: /var/log/everything/current does not exist.
prelude-client: error starting prelude-client: could not open ‘/etc/prelude/profile/prelude-lml/analyzerid’ for reading

Profile ‘prelude-lml’ does not exist. In order to create it, please run:
prelude-adduser register prelude-lml “idmef:w” <manager address> –uid 0 –gid 0.

LML must be registered with uid and gid 0, since the process will be executed as root (to be able to analyze logs).

LML will then one for the One-Time Password(OTP), which will be provided by the manager:

Enter the one-shot password provided by the “prelude-adduser” program:
- enter registration one-shot password:

On the manager, run the following:

prelude-adduser registration-server prelude-manager

…
- Starting registration server.
- generated one-shot password is “dummypass”.
…

Enter the password to the LML prompt:

- enter registration one-shot password:
- confirm registration one-shot password:
- connecting to registration server (127.0.0.1:5553)…
- Anonymous authentication to registration-server successful.
- Sending certificate request.

The LML is now waiting for the Manager to sign the certificate.

On the manager, validate the certificate signing request:

- Anonymous authentication one-shot password check successful.
- Waiting for client certificate request.
- Analyzer with ID=”3559090256170900″ ask for registration with permission=”idmef:w”.
Approve registration [y/n]: y
The certificate is generated and sent to the client:
- Registering analyzer “3559090256170900″ with permission “idmef:w”.
- Generating signed certificate for client.
- Sending server certificate to client.
- ::ffff:127.0.0.1:47054 successfully registered.

On the client you will see:

LML registration is successful
- Receiving signed certificate.
- Receiving CA certificate.
- prelude-lml registration to 127.0.0.1 successful.

Now, the manager and the sensor have a trust relation, and can send messages to each other.

This process takes some time, but it increases security and th communication between the sensor and the manager is encrypted.

Finally, the LML sensor should be up too:

/etc/init.d/prelude-lml start

Starting Prelude LML: prelude-lml.
ps auxw | grep lml
root 1946 0.3 0.0 20856 3424 ? Ss 14:35 0:00 /usr/bin/prelude-lml -d -q -P /var/run/prelude-lml.pid

This concludes the first part.

Install Prewikka

Prewikka is the graphical frontend to Prelude, using a web server.

Installation

Prewikka requires two databases: one to get the Prelude alerts (which is the same as configured before), and one to store its own data (prewikka). Actually, the Ubuntu packages does only create the prewikka database, and does not configure access to Prelude alerts, so alert installation needs to be done manually.

Install Prewikka

apt-get install prewikka

The package will install required dependencies (python, for ex), and will ask for the database configuration. As for Prelude, we choose to use dbconfig-common, give the administrator password and press enter for the DB password to let dbconfig-common generate one for us.

Configure Prelude-Manager Access

Get the password from prelude-manager configuration file /etc/prelude-manager/prelude-manager.conf and edit prewikka configuration file /etc/prewikka/prewikka.conf:

vi /etc/prewikka/prewikka.conf

[idmef_database]
type: mysql
host: localhost
user: prelude
pass: **********
name: prelude

The [database] section is automatically configured by dbconfig-common, so do not modify it.

Web Server Configuration:

The configuration is explained in file /usr/share/doc/prewikka/README.Debian. You can choose between 3 configurations:

• Apache / CGI setup with VirtualHost
• Apache / mod_python setup with VirtualHost
• Prewikka from the command line tool

As an example I’ll use the mod_python setup.

apt-get install libapache2-mod-python

Add a VirtualServer to your apache configuration with the following content:

NameVirtualHost *
<VirtualHost *>
        ServerAdmin admin@domain.com
        <Location />
                SetHandler mod_python
                PythonHandler prewikka.ModPythonHandler
                PythonOption PrewikkaConfig /etc/prewikka/prewikka.conf
        </Location>

        <Location /prewikka>
                SetHandler None
        </Location>

        Alias /prewikka /usr/share/prewikka/htdocs
        Alias /htdocs /usr/share/prewikka/htdocs
</VirtualHost>

Restart you apache webserver and you can login to the prewikka interface.

Note: you can of course always us a setting for apache like:

NameVirtualHost xxx.xxx.xxx.xxx:80
<VirtualHost prewikka.yourdomain.tld:80>

This is usefull when you have other services running on your apache server.

Part 2: Installing And Configuring Snort

I will not write the complete howto for this since there is a hwto for snort: Intrusion Detection: Snort, Base, MySQL, and Apache2 On Ubuntu 7.10 (Gutsy Gibbon) (Updated).

I’ll describe here the steps necessary to have snort logging to prelude. In this setup you also don’t need to install a mysql database and the base webinterface since snort will log to prelude and you can use the prewikka interface to see the snort alerts.

Follow all of the steps described in the howto above and replace the entry below with the new one:

Replace

./configure -enable-dynamicplugin –with-mysql
make
make install

With

./configure -enable-dynamicplugin –eanble-prelude
make
make install

Instead of doing:

Scroll down the list to the section with “# output database: log, mysql, user=“, remove the “#” from in front of this line.
Change the “user=root” to “user=snort”, change the “password=password” to “password=snort_password“, “dbname=snort”
Make note of the username, password, and dbname. You will need this information when we set up the Mysql db.
Save and quit.

Do:

Scroll down the list to the section with “# output alert_prelude: profile=snort“, remove the “#é in front of this line and that’s it.

From step 5 on (5. Set up the Mysql database.) everything can be skipped.

Now we have to register the snort agent to the prelude manager:

prelude-adduser register snort “idmef:w” <manager address> –uid snort –gid snort

On the prelude manager server:

prelude-adduser registration-server prelude-manager

This will register the snort agent to the prelude manager, as you did above for the prelude-lml.

Once the registration process is complete run:

snort -c /etc/snort/snort.conf

If everything goes right than you will see:

Initializing Network Interface eth0
Decoding Ethernet on interface eth0
- Connecting to 127.0.0.1:4690 prelude Manager server.
- TLS authentication succeed with Prelude Manager.

The entry eth0 depends on the ethernet adapter you specified. Important is that you see that snort is connecting to the prelude manager server and tls authentication was successfull.

If the agent is connecting, and you see snort in the agent list of prewikka than you can stop the process with ctrl-c and issue:

snort -c /snort/snort.conf -D

to start snort as a daemon. In the line above you can always add -i ethX if you don’t listen on all network interfaces and want to specify a specific interface.

Part 3 : Installing And Configuring Ossec

First of all we will download and unpack the ossec source:

cd /src
wget http://www.ossec.net/files/ossec-hids-1.4.tar.gz
tar xvzf ossec-hids-1.4.tar.gz

Now do the following to add prelude support:

cd ossec-hids-xx
cd src
make setprelude

Then edit Config.OS and add -lgcc_s in all lines ahead -lpthread like this:

CPRELUDE=-DPRELUDE -lprelude -pthread -lgcc_s -L/usr/lib -lprelude -lgnutls -lgcrypt -lrt -ldl

The majority of this HOWTO is taken directly from the Installation Manual for OSSEC-HID which is a very easy to follow manual. If you run into trouble please look at the manual first as it will always have the most up to date information.

Now the easy part. Ossec comes with an install script install.sh which does all of the hard work for us.

cd ..
./install.sh

Pick what language you want to read everything in and hit enter.

** Para instalação em português, escolha [br].
** Fur eine deutsche Installation wohlen Sie [de].
** For installation in English, choose [en].
** Per l’installazione in Italiano, scegli [it].
** Aby instalować w języku Polskim, wybierz [pl].
** Türkçe kurulum için seçin [tr].
(en/br/de/it/pl/tr) [en]: en <enter>

Next it is going to warn us that we need a C compiler on the machine, and give you some general information about your computer (kernel version, user and host).

Go ahead and hit enter likes it says.

You are about to start the installation process of the OSSEC HIDS.
You must have a C compiler pre-installed in your system.
If you have any questions or comments, please send an e-mail
to dcid@ossec.net (or daniel.cid@gmail.com).
- System: Linux some information
- User: root
- Host: your hostname
– Press ENTER to continue or Ctrl-C to abort. –

Next select a local install:

1- What kind of installation do you want (server, agent, local or help)? local <enter>

Now choose were you want to install it. Use the default or change it if you want to. This howto however will assume the default location.

Choose where to install the OSSEC HIDS [/var/ossec]: <enter>

Now select you notification options. You can choose answers used in this howto or different ones. I would recommend setting “Y” to everything. Active responses are really nice. It will set some default configuration variables based on your answers and certian things it finds on your system.

3- Configuring the OSSEC HIDS.

3.1- Do you want e-mail notification? (y/n) [y]: y
- What’s your e-mail address? youremail@yourdomain.com
- What’s your SMTP server ip/host? your smtp server address (localhost)

3.2- Do you want to run the integrity check daemon? (y/n) [y]: y

- Running syscheck (integrity check daemon).

3.3- Do you want to run the rootkit detection engine? (y/n) [y]: y

- Running rootcheck (rootkit detection).

3.4- Active response allows you to execute a specific
command based on the events received. For example,
you can block an IP address or disable access for
a specific user.
More information at:

http://www.ossec.net/en/manual.html#active-response

- Do you want to enable active response? (y/n) [y]: y

- Active response enabled.

- By default, we can enable the host-deny and the
firewall-drop responses. The first one will add
a host to the /etc/hosts.deny and the second one
will block the host on iptables (if linux) or on
ipfilter (if Solaris, FreeBSD or NetBSD).
- They can be used to stop SSHD brute force scans,
portscans and some other forms of attacks. You can
also add them to block on snort events, for example.

- Do you want to enable the firewall-drop response? (y/n) [y]: y

- firewall-drop enabled (local) for levels >= 6

- Default white list for the active response:
- 192.168.2.1

- Do you want to add more IPs to the white list? (y/n)? [n]: n

3.6- Setting the configuration to analyze the following logs:
– /var/log/messages
– /var/log/auth.log
– /var/log/syslog
– /var/log/mail.info
– /var/log/apache2/error.log (apache log)
– /var/log/apache2/access.log (apache log)

- If you want to monitor any other file, just change
the ossec.conf and add a new localfile entry.
Any questions about the configuration can be answered
by visiting us online at http://www.ossec.net .

— Press ENTER to continue —

Now it will compile everything. This shouldn’t take too long to complete. It only took around 1-2 minutes for my box. After it is completed press enter to finish.

- Unknown system. No init script added.
- Configuration finished properly.
- To start OSSEC HIDS:/var/ossec/bin/ossec-control start
- To stop OSSEC HIDS:/var/ossec/bin/ossec-control stop
- The configuration can be viewed or modified at /var/ossec/etc/ossec.conf
Thanks for using the OSSEC HIDS.If you have any question, suggestion or if you find any bug,contact us at contact@ossec.net or using our public maill it atossec-list@ossec.net(http://mailman.underlinux.com.br/mailman/listinfo/ossec-list). More information can be found at http://www.ossec.net
— Press ENTER to finish (maybe more information below). —

Now unfortunately it doesn’t detect Ubuntu so it will not create an init script. This is simple enough to take care of. (Yes, its basic. If you want to improve it please feel free to do so) Copy and paste the following into /etc/init.d/ossec:

#!/bin/sh

case "$1" in
start)
  /var/ossec/bin/ossec-control start
;;
stop)
  /var/ossec/bin/ossec-control stop
;;
restart)
  $0 stop && sleep 3
  $0 start
;;
reload)
  $0 stop
  $0 start
;;
*)
echo "Usage: $0 {start|stop|restart|reload}"
exit 1
esac

Now make it executable:

chmod +x /etc/init.d/ossec

Add it to our runlevels so it starts on boot:

update-rc.d ossec defaults

ossec.conf/var/ossec/etc/ossec.confossecprelude:

<global>
 ...
<prelude_output>yes</prelude_output>
</global>

Finally we’ll add ossec as an agent in prelude:

prelude-adduser registration-server prelude-manager

On the management server do:

prelude-adduser register OSSEC “idmef:w” localhost –uid ossec –gid ossec

Note: The sensor name MUST be in uppercase > OSSEC.

Start the ossec with init.d script powered by OSSEC (1.4 version should now detect ubuntu/debian OS and the init script will work!) or RShadow script.

If you see this you’r up and running.

Starting OSSEC HIDS v1.4 (by Daniel B. Cid)…
Connecting to 127.0.0.1:4690 prelude Manager server.
TLS authentication succeed with Prelude Manager.

Now go to the url where you installed prewikka, and login with the user admin and password admin. Change this password immediately in order to prevent unauthorized access.

Incoming search terms:

• ubuntu intrusion detection (3)
• prelude ids debian (2)
• ossec prelude centos ids (2)
• ubuntu install prelude-manager tar gz (2)
• apt-get install prelude-manager (2)
• ubuntu ossec eth disabled (2)
• prelude tar gz (1)
• prelude prewikka database management (1)
• prelude tar gz ids ubuntu (1)
• prelude ossec ubuntu (1)

Edit the SSHD configuration and make the changes listed below:

    vi /etc/ssh/sshd_config

1) Set the default SSH port 22 to a higher value, by changing the ‘Port’ directive

    Port 2233

2) To make SSH work on a secure protocol, set the ‘Protocol’ directive as

    Protocol 2

3) Bind SSHD service to a specific IP of the server, which you can achieve by replacing ‘#ListenAddress’ directive to

    ListenAddress xx.xx.xx.xx

where, xx.xx.xx.xx is the additional IP of the server and the only one which will allow you to SSH into the server.

4) To disable root access, set ‘PermitRootLogin’ directive to ‘no’

    PermitRootLogin no

Make sure you add an alternate SSH user on the server who have privileges to gain root access before disabling this option.

5) To allow SSH access to specific users, add the “AllowUsers” directive at the end of the configuration

    AllowUsers user1 user2

This will allow SSH access to users user1 and user2. You need to allow SSH access to the user who is allowed to gain root access incase root access is disabled.

Save the file and restart the sshd service

    service sshd restart

6) Using the TCP wrappers i.e. hosts.allow and hosts.deny, you can restrict SSH access to specific IPs i.e. edit /etc/hosts.allow and add the following

sshd : yourlocalip: allow
sshd : all : deny

“yourlocalip” is the one assigned by your ISP. It will restrict SSH access to your local IP only.

Incoming search terms:

• centos hosts allow ip (3)
• /etc/hosts allow ssh plesk (1)
• sshd plesk (1)
• ssh listenaddress * (1)
• restrict root login centos to one ip cpanel (1)
• plesk restrict ssh by ip (1)
• plesk permitrootlogin (1)
• limit ip to access directadmin and ssh (1)
• kloxo permitrootlogin (1)
• kloxo host deny ssh (1)