Search This Blog

Thursday, March 17, 2016

Block traffic to your server from a particular Country



Create a file where we can declare some rules to use:


sudo nano /etc/iptables.firewall.rules


Inside there you'll want to paste the following:


*filter
# Allow all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0

-A INPUT -i lo -j ACCEPT

-A INPUT -d 127.0.0.0/8 -j REJECT

# Accept all established inbound connections

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow all outbound traffic - you can modify this to only allow certain traffic

-A OUTPUT -j ACCEPT

# Allow HTTP and HTTPS connections from anywhere (the normal ports for websites and SSL).

-A INPUT -p tcp --dport 80 -j ACCEPT

-A INPUT -p tcp --dport 443 -j ACCEPT

# Allow SSH connections

#

# The -dport number should be the same port number you set in sshd_config


-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT

# Allow ping

-A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# Log iptables denied calls

-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

# Drop all other inbound - default deny unless explicitly allowed policy

-A INPUT -j DROP

-A FORWARD -j DROP

COMMIT

Save that. Next, we need to apply those rules – this is just a text file, and we need to instruct iptables to actually use it.


sudo iptables-restore < /etc/iptables.firewall.rules


That should have loaded the rules and applied them; you can check by


iptables -L


The output of that command ought to look like


Chain INPUT (policy ACCEPT)


target prot opt source destination


ACCEPT all -- anywhere anywhere


REJECT all -- anywhere 127.0.0.0/8 reject-with icmp-port-unreachable


ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED


ACCEPT tcp -- anywhere anywhere tcp dpt:http


ACCEPT tcp -- anywhere anywhere tcp dpt:https


ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh


ACCEPT icmp -- anywhere anywhere


LOG all -- anywhere anywhere limit: avg 5/min burst 5 LOG level debug prefix "iptables denied: "


DROP all -- anywhere anywhere






Chain FORWARD (policy ACCEPT)


target prot opt source destination


DROP all -- anywhere anywhere






Chain OUTPUT (policy ACCEPT)


target prot opt source destination


ACCEPT all -- anywhere anywhere


Great, it's working! But if you reboot the server it won't be. So lets fix that by creating a file which will run at boot.


sudo nano /etc/network/if-pre-up.d/firewall


Inside that file paste:


#!/bin/sh


/sbin/iptables-restore < /etc/iptables.firewall.rules


Save it. Now we must make sure it's allowed to execute:


sudo chmod +x /etc/network/if-pre-up.d/firewall


Done. The firewall is now running with those rules applied and those rules will be re-applied every time the server reboots. But it's not blocking China yet; it's only blocking anything not on port 80 or 443 (http and https).
Using ipset to block China


You can't manually add a few thousand IP addresses to your iptables, and even doing it automatically is a bad idea because it can cause a lot of CPU load (or so I've read). Instead we can use ipset which is designed for this sort of thing. ipset handles big lists of ip addresses; you just create a list and then tell iptables to use that list in a rule.


Note; I assume that the entirety of the following is done as root. Adjust accordingly if your system is based on sudo.


apt-get install ipset


Next, I wrote a small Bash script to do all the work, which you should be able to understand from the comments in it. Create a file:


nano /etc/block-china.sh


Here's what you want to paste into it:


# Create the ipset list


ipset -N china hash:net






# remove any old list that might exist from previous runs of this script


rm cn.zone






# Pull the latest IP set for China


wget -P . http://www.ipdeny.com/ipblocks/data/countries/cn.zone






# Add each IP address from the downloaded list into the ipset 'china'


for i in $(cat /etc/cn.zone ); do ipset -A china $i; done






# Restore iptables


/sbin/iptables-restore < /etc/iptables.firewall.rules


Save the file. Make it executable:


chmod +x /etc/block-china.sh


This hasn't done anything yet, but it will in a minute when we run the script. First, we need to add a rule into iptables that refers to this new ipset list the script above defines:


nano /etc/iptables.firewall.rules


Add the following line:


-A INPUT -p tcp -m set --match-set china src -j DROP


Save the file. To be clear, my full iptables.firewall.rules now looks like this:


*filter






# Allow all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0


-A INPUT -i lo -j ACCEPT


-A INPUT -d 127.0.0.0/8 -j REJECT






# Accept all established inbound connections


-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT






# Block anything from China


# These rules are pulled from ipset's china list


# The source file is at /etc/cn.zone (which in turn is generated by a shell script at /etc/block-china.sh )


-A INPUT -p tcp -m set --match-set china src -j DROP






# Allow all outbound traffic - you can modify this to only allow certain traffic


-A OUTPUT -j ACCEPT






# Allow HTTP and HTTPS connections from anywhere (the normal ports for websites and SSL).


-A INPUT -p tcp --dport 80 -j ACCEPT


-A INPUT -p tcp --dport 443 -j ACCEPT






# Allow SSH connections


#


# The -dport number should be the same port number you set in sshd_config


#


-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT






# Allow ping


-A INPUT -p icmp -j ACCEPT






# Log iptables denied calls


-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7






# Drop all other inbound - default deny unless explicitly allowed policy


-A INPUT -j DROP


-A FORWARD -j DROP






COMMIT


Right now, nothing has changed with the server because no new rules have been applied; to do so, run the block-china.sh script:


/etc/block-china.sh


This should show some output as it pulls a fresh list of Chinese based IPs and then, after a few seconds or so, it will complete and drop you back to a command prompt.


To test if it worked, run:


iptables -L


You should now see a new rule blocking China – the output ought to look like this:


Chain INPUT (policy ACCEPT)


target prot opt source destination


ACCEPT all -- anywhere anywhere


REJECT all -- anywhere loopback/8 reject-with icmp-port-unreachable


ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED


DROP tcp -- anywhere anywhere match-set china src


ACCEPT tcp -- anywhere anywhere tcp dpt:http


ACCEPT tcp -- anywhere anywhere tcp dpt:https


ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh


ACCEPT icmp -- anywhere anywhere


LOG all -- anywhere anywhere limit: avg 5/min burst 5 LOG level debug prefix "iptables denied: "


DROP all -- anywhere anywhere






Chain FORWARD (policy ACCEPT)


target prot opt source destination


DROP all -- anywhere anywhere






Chain OUTPUT (policy ACCEPT)


target prot opt source destination


ACCEPT all -- anywhere anywhere


Almost done! This works, and will continue to work on re-boots. But, IP addresses change and that list will grow stale over time. If you want to pull and apply an updated list of IPs you can just run the block-china.sh script again.






Configure your websever:


We use Ngnix, So steps to block traffic from China do as follow :


Check ip modules are enabled






nginx -V






If you see --with-http_geoip_module in the output, you are ready to use the GeoIP database with nginx:


root@server1:~# nginx -V
nginx version: nginx/1.2.1
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-pcre-jit --with-debug --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_realip_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-http_xslt_module --with-ipv6 --with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl --with-mail --with-mail_ssl_module --add-module=/build/buildd-nginx_1.2.1-2.1-amd64-fMGfEu/nginx-1.2.1/debian/modules/nginx-auth-pam --add-module=/build/buildd-nginx_1.2.1-2.1-amd64-fMGfEu/nginx-1.2.1/debian/modules/nginx-echo --add-module=/build/buildd-nginx_1.2.1-2.1-amd64-fMGfEu/nginx-1.2.1/debian/modules/nginx-upstream-fair --add-module=/build/buildd-nginx_1.2.1-2.1-amd64-fMGfEu/nginx-1.2.1/debian/modules/nginx-dav-ext-module
root@server1:~#





Installing The GeoIP Database


On Debian/Ubuntu, the GeoIP database can be installed as follows:


apt-get install geoip-database libgeoip1


This places the GeoIP database in /usr/share/GeoIP/GeoIP.dat.


It is possible that it is a bit outdated. Therefore we can optionally download a fresh copy from the GeoIP web site:


mv /usr/share/GeoIP/GeoIP.dat /usr/share/GeoIP/GeoIP.dat_bak


cd /usr/share/GeoIP/
wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz
gunzip GeoIP.dat.gz





Configuring nginx


Open /etc/nginx/nginx.conf...


vi /etc/nginx/nginx.conf


... and place this in the http {} block, before any include lines:



[...]
geoip_country /usr/share/GeoIP/GeoIP.dat;
map $geoip_country_code $allowed_country {
default yes;
FK no;
FM no;
EH no;
}
[...]




This allows all countries, except the three countries set to no (you can find a list of country codes here). To do it the other way round, i.e. block all countries and allow only a few, you'd do it this way:



[...]
geoip_country /usr/share/GeoIP/GeoIP.dat;
map $geoip_country_code $allowed_country {
default no;
FK yes;
FM yes;
EH yes;
}
[...]




Now, this actually doesn't block any country, it just sets the $allowed_country variable. To actually block countries, you must open your vhost configuration and place the following code in the server {} container (this can go inside and also outside any location {} block):



[...]
if ($allowed_country = no) {
return 444;
}
[...]




This returns the 444 error code to any visitor from a blocked country. What this does is it closes the connection without sending any headers. You can also use another error code like 403 ("Forbidden") if you like.


Reload nginx afterwards:


/etc/init.d/nginx reload





4 Links


· nginx: http://nginx.org/


· nginx Wiki: http://wiki.nginx.org/


· HttpGeoipModule: http://wiki.nginx.org/HttpGeoipModule









































Monday, August 17, 2015

Multiple JDK versions in Centos






Downloading Latest Java Archive

Java latest archive is available on its official site. We recommend to download latest version of Java from Oracle official website. After completing download also extract archive with given commands.

For 64 Bit:-

# cd /opt/
# wget --no-cookies --no-check-certificate --header "Cookie: gpw_e24=http%3A%2F%2Fwww.oracle.com%2F; oraclelicense=accept-securebackup-cookie" "http://download.oracle.com/otn-pub/java/jdk/7u79-b15/jdk-7u79-linux-x64.tar.gz"

# tar xzf jdk-7u79-linux-x64.tar.gz

For 32 Bit:-

# cd /opt/
# wget --no-cookies --no-check-certificate --header "Cookie: gpw_e24=http%3A%2F%2Fwww.oracle.com%2F; oraclelicense=accept-securebackup-cookie" "http://download.oracle.com/otn-pub/java/jdk/7u79-b15/jdk-7u79-linux-i586.tar.gz"

# tar xzf jdk-7u79-linux-i586.tar.gz
Note: If Above wget command doesn’t not work for you watch this example video to download java source archive using terminal.
Use archive file as per your system configuration. For this example we are using CentOS 7.0 (64 bit) system.
Install Java with Alternatives
After extracting Java archive file, we just need to set up to use newer version of Java using alternatives. Use the following commands to do it.
# cd /opt/jdk1.7.0_79/
# alternatives --install /usr/bin/java java /opt/jdk1.7.0_79/bin/java 2
# alternatives --config java
There are 3 programs which provide 'java'.

  Selection    Command
-----------------------------------------------
*  1           /opt/jdk1.7.0_60/bin/java
 + 2           /opt/jdk1.7.0_72/bin/java
   3           /opt/jdk1.7.0_79/bin/java

Enter to keep the current selection[+], or type selection number: 3 [Press Enter]
Now you may also required to set up javac and jar commands path using alternatives command.
# alternatives --install /usr/bin/jar jar /opt/jdk1.7.0_79/bin/jar 2
# alternatives --install /usr/bin/javac javac /opt/jdk1.7.0_79/bin/javac 2
# alternatives --set jar /opt/jdk1.7.0_79/bin/jar
# alternatives --set javac /opt/jdk1.7.0_79/bin/javac 
Check Installed Java Version
Use following command to check which version of Java is currently being used by system.
# java -version

java version "1.7.0_79"
Java(TM) SE Runtime Environment (build 1.7.0_79-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)








Thursday, May 21, 2015

New Features in Mongo DB 3.0



Enhanced Query Language and Tools

Key MongoDB tools mongoimport, mongoexport, mongodump, mongorestore, mongostat, mongotop and mongooplog have been re-written as multi-threaded processes in Go, allowing faster operations and smaller binaries.
mongodump and mongorestore now execute parallelized backup and recovery for small MongoDB instances. Dumps created by earlier releases can be restored to instances running MongoDB 3.0. 

mongoimport can parallelize loads across multiple collections with multi-threaded bulk inserts allowing for significantly faster imports of CSV, TSV and JSON data exported from other databases or applications. Ensuring data quality, mongoimport now also supports input validation of field names during the import process.

Improved DBA Productivity: Enhanced Query Engine Introspection The MongoDB "explain() method is an invaluable tool for DBAs in optimizing performance. Using explain() output, DBAs can review query plans, ensuring common queries are serviced by well-defined indexes, as well as eliminating any unnecessary indexes that can increase write latency and add overhead during query planning and optimization.
In the latest MongoDB 3.0 release explain() has been significantly enhanced:
  • The query plan can now be calculated and returned without first having to run the query. This enables DBAs to review which plan will be used to execute the query, without having to wait for the query to run to completion.
  • DBAs can run explain() to generate detailed statistics on all query plans considered by the optimizer. Execution statistics are available for every evaluated plan, down to the granularity of execution stage. Now, for example, it is possible for the DBA to distinguish the amount of time a query plan spent sorting the result set from the amount of time spent reading index keys.
  • The explain() method exposes query introspection to a wider range of operations, including find, count, update, remove, group, and aggregate, enabling DBAs to optimize for a wider range of query types.
Richer Geospatial Apps: Big Polygon Support for Multi-Hemisphere Queries 
MongoDB’s geospatial indexes and queries are widely used by developers building modern location-aware applications across industries as diverse as high technology, retail, telecommunications and government. MongoDB 3.0 adds big polygon geospatial support with$intersects and $within operators, allowing execution of queries over geographic areas extending across multiple hemispheres and areas that exceed 50% of the earth’s surface. As an example, an airline can now run queries to identify all its aircraft that have traveled across multiple hemispheres in the past 24 hours.

Enhanced Data Type Support: Easier Time-Series Analytics & Reporting 
The MongoDB 3.0 aggregation pipeline offers a new $dateToString operator that simplifies report generation and grouping data by time interval. The operator formats the ISO Date type as a string with a user-supplied format, allowing developers to construct rich queries with less code.

Faster Issue Resolution: Enhanced Logging 
Log analysis is a critical part of identifying issues and determining root cause. Now in MongoDB 3.0 developers, QA and operations staff have much greater control over the granularity of log messages and specific functional areas of the server to more precisely investigate issues.

Deploying Geo-Distributed, Datacenter-Aware Applications 
Delivering a low latency experience to customers wherever they are located is a key design consideration for distributed systems. Using MongoDB’s native replica sets, copies (replicas) of the database can be deployed to sites physically closer to users, thereby reducing the effects of network latency. Reads can be issued with the nearestread preference, ensuring the query is served from the replica closest to the user, based on ping distance.


Pluggable Storage Engines: Extending MongoDB to New Applications


Multiple storage engines can co-exist within a single MongoDB replica set, making it easy to evaluate and migrate engines. Running multiple storage engines within a replica set can also simplify the process of managing the data lifecycle. For example as different storage engines for MongoDB are developed, it would be possible to create a mixed replica set configured in such a way that:
  1. Operational data requiring low latency and high throughput performance is managed by replica set members using the WiredTiger or in-memory storage engine (currently experimental).
  2. Replica set members configured with an HDFS storage engine expose the operational data to analytical processes running in a Hadoop cluster, which is executing interactive or batch operations rather than real time queries.
MongoDB replication automatically migrates data between primary and secondary replica set members, independent of their underlying storage format. This eliminates complex ETL tools that have traditionally been used to manage data movement.

MongoDB 3.0 ships with two supported storage engines:
  1. The default MMAPv1 engine, an improved version of the engine used in prior MongoDB releases, now enhanced with collection level concurrency control.
  2. The new WiredTiger storage engine. For many applications, WiredTiger's more granular concurrency control and native compression will provide significant benefits in the areas of lower storage costs, greater hardware utilization, higher throughput, and more predictable performance.

Higher Performance & Efficiency

Between 7x and 10x Greater Write Performance
MongoDB 3.0 provides more granular document-level concurrency control, delivering between 7x and 10x greater throughput for most write-intensive applications, while maintaining predictable low latency.

Compression: Up to 80% Reduction in Storage Costs
Despite data storage costs declining 30% to 40% per annum, overall storage expenses continue to escalate as data volumes double every 12 to 18 months. To make matters worse, improvements to storage bandwidth and latency are not keeping pace with data growth, making disk I/O a common bottleneck to scaling overall database performance.


Administrators have the flexibility to configure specific compression algorithms for collections, indexes and the journal, choosing between:
  1. Snappy (the default library for documents and the journal), providing a good balance between high compression ratio – typically around 70%, depending on document data types – and low CPU overhead.
  2. zlib, providing higher document and journal compression ratios for storage-intensive applications, at the expense of extra CPU overhead.
  3. Prefix compression for indexes reducing the in-memory footprint of index storage by around 50% (workload dependent), freeing up more of the working set for frequently accessed documents.
Administrators can modify the default compression settings for all collections and indexes. Compression is also configurable on a per-collection and per-index basis during collection and index creation.
By introducing compression, operations teams get higher performance per node and reduced storage costs.

Creating Multi-Temperature Storage
Combining compression with MongoDB’s location-aware sharding, administrators can build highly efficient tiered storage models to support the data lifecycle. Administrators can balance query latency with storage density and cost by assigning data sets to specific storage devices. For example, consider an application where recent data needs to be accessed quickly, while for older data, latency is less of a priority than storage costs:
  1. Recent, frequently accessed data can be assigned to high performance SSDs with Snappy compression enabled.
  2. Older, less frequently accessed data is tagged to higher capacity, lower-throughput hard disk drives where it is compressed with zlib to attain maximum storage density and lower cost-per-bit.
MongoDB will automatically migrate data between storage tiers based on user-defined policies without administrators having to build tools or ETL processes to manage data movement.

Source : Mongo DB

Thursday, January 29, 2015

Wordpress image upload http error on Nginx




This was due to the following param in Nginx.conf under http section, Just change it to maximum size of you want to upload 

example
client_max_body_size 5M;

Thursday, October 9, 2014

Indian Rupee Symbol in OpenCart


Execute these Queries in you database

Alter table oc_currency change column symbol_left symbol_left varchar(50);

Update oc_currency set symbol_left='<i class="fa fa-inr">&nbsp;</i>' where currency_id=4;
Change the stylesheet.css in "catalog/view/theme/default/stylesheet/stylesheet.css" To remove the font size to make it even across the application

Note by default Font Awesome is included in 2.0 Opencart if your theme doesn't have added it to make this solution work