How To Migrate Iptables Firewall Rules to a New Server

Introduction

When migrating from one server to another, it is often desirable to migrate the iptables firewall rules as part of the process. This tutorial will show you how to easily copy your active iptables rule set from one server to another.

Prerequisites

This tutorial requires two servers. We will refer to the source server, which has the existing iptables rules, as Server A. The destination server, where the rules will be migrated to, will be referred to as Server B.
You will also need to have superuser, or sudo, access to both servers.

View Existing Iptables Rules

Before migrating your iptables rules, let's see what they are set to. You can do that with this command on Server A:

sudo iptables -S

Example output:
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 15.15.15.51/32 -j DROP

The example rules above will be used to demonstrate the firewall migration process.

Export Iptables Rules

The iptables-save command writes the current iptables rules to stdout (standard out). This gives us an easy way to export the firewall rules to file, by redirecting stdout to a file.
On the Server A, the one with the iptables rules that you want to migrate, use the iptables-save to export the current rules to a file named "iptables-export" like this:

cd ~

sudo iptables-save > iptables-export

This will create the iptables-export file, in your home directory. This file can be used on a different server to load the firewall rules into iptables.

View File Contents (Optional)

Let's take a quick look at the file's contents. We'll use the cat command to print it out to the terminal:

cat iptables-export

iptables-export contents:
# Generated by iptables-save v1.4.21 on Tue Sep  1 17:32:29 2015
*filter
:INPUT ACCEPT [135:10578]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [8364:1557108]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 15.15.15.51/32 -j DROP
COMMIT
# Completed on Tue Sep  1 17:32:29 2015

As you can see, the file contains the configuration of the active iptables rules. Now we're ready to copy this file to our destination server, Server B.

Copy Exported Rules to Destination Server

We need to copy the rules file to our destination server, Server B. The easiest way to do this is to use scp or to copy and paste the file contents to a new file on Server B. We will demonstrate how to use scp to copy the file over the network to the /tmp directory.
On Server A, run this scp command. Be sure to substitute the highlighted parts with your server's login and IP address:

scp iptables-export user@server_b_ip_address:/tmp

After providing proper authentication, the file will be copied to the /tmp directory on Server B. Note that the contents of /tmp are deleted upon a reboot—feel free to place it somewhere else if you want to preserve it.

Import Iptables Rules

With the exported rules on the destination server, you can load them into iptables. However, depending on your situation, you may want update the rules in the file with new IP addresses and ranges, and perhaps update interface names. If you want to change the rules before loading them, be sure to edit the /tmp/iptables-export file now.
Once you are ready to load the rules from the iptables-export file into iptables, let's use the iptables-restore command to do so.
On Server B, the destination server, run this command to load the firewall rules:

sudo iptables-restore < /tmp/iptables-export

This will load the rules into iptables. You can verify this with the sudo iptables -S command.

Save Rules

Iptables rules are ephemeral, so special care must be taken for them to persist after a reboot—it is likely that you will want to perform this step on Server B. We will show you how to save the rules on both Ubuntu and CentOS.

Ubuntu

On Ubuntu, the easiest way to save iptables rules, so they will survive a reboot, is to use the iptables-persistent package. Install it with apt-get like this:

sudo apt-get install iptables-persistent

During the installation, you will asked if you want to save your current firewall rules. Response yes, if you want to save the current rule set.
If you update your firewall rules in the future, and want to save the changes, run this command:

sudo invoke-rc.d iptables-persistent save

CentOS 6 and Older

On CentOS 6 and older—CentOS 7 uses FirewallD by default—you can use the iptables init script to save your iptables rules:

sudo service iptables save

This will save your current iptables rules to the /etc/sysconfig/iptables file, which gets loaded by iptables upon boot.

Conclusion

Congratulations! Your firewall rules have been migrated from your original server to your new one.

Read more »

How secure is your Asterisk PBX?

A growing problem

Like a slice of Victoria sponge cake on a summers day attracts wasps, so new technologies seem to attract the attention of cyber-criminals. The more widely used the technology, the greater the interest. It was inevitable, and widely predicted, that VoIP would become a favorite target for hackers as its popularity and uptake increased – it has the accessibility of an email server combined with the potential for fraud of an online bank account. Irresistible!
And so it has come to be. The level of sophistication and the number of attacks against VoIP servers and PBX’s has gradually escalated over the years and then really taken off in the last 12 months. Automated port scanning and security probing can be seen many times a day, even on IP addresses that are not part of any published SIP service. What is more, each new attempt seems to come from a different IP address! This makes it harder to just block them at the firewall and indicates that the would-be hackers are using a botnet. Another possibility is that the source address is being deliberately spoofed. This would make it difficult to detect the true source address which is masked by the “noise” of many randomly generated addresses. Whatever the mechanism, it suggests that the hackers are really serious about their undertaking and expect to make a lot of money out of it.

What are the hackers hoping to do?

In most cases they want to find a weakness that will allow them to make long distance, international or other chargeable calls for free. The numbers that get called are often in African countries, but I have also seen North Korea and others. One service provider told me that China is a popular destination. This is often described as “toll fraud”. In some cases, the fraudster is reselling the hijacked call time from your server to unsuspecting end users who think they have signed up to a legitimate call service (or who don’t care if it is legal as long as it is cheap). Alternatively, the numbers being called are on a premium rate service – this allows the fraudster to collect part of the call charges directly to their own bank account.
Another possibility for an attack on your systems would be DoS (Denial of Service). Asterisk servers are not that good at handling floods of SIP requests, so once someone has identified your server it would be relatively easy for them to fire hundreds of requests at it with the intention of bringing it to its knees. Deliberate DoS attacks are not common compared to toll fraud. However, brute force password guessing can have the same impact as a DoS attack – see “password guessing gone crazy” below.
Toll fraud is clearly the main issue today. However, the time may come when unwanted spam calls (enjoying the delightful acronym of SPIT) are as big a problem as toll fraud. When that happens, it will present administrators with a whole new set of problems.

What do the attacks look like?

SIP port scanning – locating target servers

Port 5060 is the standard SIP port and the first step for the would-be hacker is to send a SIP request to this port to see what response comes back. If you can use a non-standard port or block all access at the firewall except from addresses known to be trusted, then it will elevate your protection to a completely new level. However, for most VoIP applications this is simply not possible.
Probing requests may come in the form of a SIP INVITE, REGISTER or OPTIONS request. I have recently seen a big increase in OPTIONS requests that come from a wide range of Internet IP addresses, but they contain certain elements that identify a common ancestry. First, all the requests have the User-Agent field set to either “sundayddr” or “friendly-scanner”. Second, they often identify their origin as ”sip:100@1.1.1.1″, “sip:100@192.168.1.9″ or similar. It may not be possible to block or even detect these if you are using an Asterisk server, but in OpenSIPS, I recommend that you drop the packet rather than send any response.

Password guessing

Once a SIP server has been identified, vulnerabilities can be searched for. I have seen Asterisk logs that clearly show an initial scan where an attempt is made to register on every extension number from 10 to 9999. The response coming back tells the attacker if that extension exists (bad password) or does not exist (not found). Then, armed with a list of your extensions, the second phase of the scan will keep trying hundreds of passwords on a known extension.

Password guessing gone crazy

Under some circumstances (possibly when Asterisk is more tightly locked down than usual) the password guessing attack seems to get stuck in an endless loop. It sends REGISTER requests for various randomly named accounts in a relentless and unceasing stream at a rate in excess of 80 per second. I have written an article dedicated just to this one problem and its solution. Click here to be linked to the relevant article.

Open relay

If the SIP server has been configured by an inexperienced person who perhaps did not appreciate the risks, then the worst case scenario would be that your Asterisk server will accept INVITE requests from any Internet address without any password being required and connect the caller to destinations on the PSTN. I’m glad to say that Asterisk, Trixbox or FreePBX will not generally do this “out-of-the-box”, but it would be easy to tweak the dial plan such that it could. For many years, I have seen evidence in the logs of SIP requests to numbers on the PSTN, often with various prefixes, in the hope that they will hit the jackpot.

Weaknesses in the server

This form of exploitation is more likely with OpenSIPS than with Asterisk because the rules and routing logic in OpenSIPS are almost completely under the control of the installer and system administrator rather than the authors of the product. With a protocol as complex as SIP, there is plenty of scope for missing some detail or assuming a function behaves one way when it actually behaves in some subtly different manner. One of my clients was caught out by a weakness in the handling of deliberately malformed From headers. A function that should return true if the SIP domain is local would return false when the caller’s number was missing. This meant the calls were not being challenged for a password yet would then be handled as if coming from an authenticated user. Such mistakes can be very costly.

The human factor

Remember that not all IT fraud takes the form of a unknown third party hacking into your systems from the Internet. A disgruntled or dishonest employee finding they have access to account passwords or the ability to add a hidden access route, may be tempted to exploit their position of trust. As a VoIP service provider, you may find you are approached by clients who talk of temptingly large and growing volumes of traffic that they want to put through your service. They might be very believable and indistinguishable from a legitimate client, but it may not always be what it appears. Your billing systems need to be able to stop traffic from a client whose credit limit has been reached. And always get advance payment for your minutes!

Protecting your Asterisk server

In part 1, we examined the techniques that are used to probe for vulnerabilities in a SIP server and reviewed the types of exploitation a would-be hacker hopes to use. In this second part, I look at the ways you can protect your Asterisk or other SIP server and guard against weaknesses that could potentially cost your organisation a lot of money.

Basic Internet Security

The first line of defence is your firewall. You must block all unnecessary access from the Internet which generally means everything except port 5060 and the range of ports used for RTP. You will probably also need a rule to permit remote access – typically port 22 for SSH – but if at all possible set all remote access rules so they only allow connections from known source addresses. If you do allow remote access from the Internet of any sort (including through a web browser) then make sure you set a strong password. Never leave the original system default password on any system exposed to the Internet.
As mentioned in part 1, you can greatly improve security by changing to a non-standard port for the incoming SIP or by blocking access to port 5060 from all sources except those you already know and trust. This might be possible in a business that wants to connect a number of branch offices together using VoIP. However, it is far less convenient if you want to allow home based workers to connect to the office PBX using IP phones. For some applications it may be possible to connect through a VPN tunnel, but beware of possible performance issues if the speech (RTP) is going through VPN.

Check logs regularly

Even if you have a smart billing or call logging system, it is sensible to check the application log files quite often. The main log file for Asterisk is either /var/log/asterisk/messages or /var/log/asterisk/full. It is here that you might see hundreds of failed register attempts from the Internet. This may provide essential information in your fight against hackers because it shows you the scale of the problem, the accounts they are trying to crack, the type of attack and, sometimes, the IP addresses that the attack is coming from (the worst offenders can then be blocked at the firewall).

SIP User Accounts

Call requests arriving at your Asterisk server will generally need to be validated with a user id and password. There are exceptions to this rule, most notably when the request comes from a pre-defined peer whose definition in sip.conf includes a setting such as ”insecure=invite”.

Use strong passwords

To protect your Asterisk server from brute force password guessing attacks, always make sure all your SIP user accounts have a strong password – at least 6 chars with a mix of upper and lower case letters plus numeric digits and at least one non-standard character such as $, !, #, *, etc. However, note that a few special characters will not work – avoid & or %. The importance of using strong passwords cannot be over-emphasised. It is essential even when you are setting up the accounts for internal extension phones because, unless you are very careful, the same credentials will work for calls from the Internet. To check the list of user accounts and passwords in Asterisk, it sometimes works to run the command “sip show users” at the CLI.

Other cautions when adding SIP User Accounts

Never include the parameter “insecure=invite” or “insecure=very” when defining a dynamic SIP user account. If you do, it will disable password checking for that account. Where possible, restrict the range of IP addresses from which the user is allowed to connect using the “deny” and “permit” parameters. This is a good idea where all possible source IP addresses are known in advance such as from a local LAN in an office. If possible, avoid setting the type to “friend”. Instead use “type=peer” and “host=dynamic” (see below).

Configuration tip:

In the [general] section of sip.conf, set “alwaysauthreject=yes”. This makes it much harder for a hacker to scan your server and identify what extension numbers are being used because it tells Asterisk that when the supplied credentials are wrong on an INVITE or REGISTER request, it should always return the same error no matter whether it was the user id or the password that didn’t match. However, it may also cause the so-called “friendly-scanner” to go into an endless cycle of manic password guessing – if you suspect this is happening to you, then you need to read my article here.

Outbound Routes

If you are using FreePBX (or a package based on it), then you should look carefully at the configuration for “Outbound Routes”. It makes sense to add a route specifically for International calls and, if possible, to restrict the countries that can be called. You can do this by adding a number of “Dial Patterns” that match the countries you want to allow and do not match any others. Make sure no other Outbound Route has a Dial Pattern that allows International calls.
A variation on the above would be to set a “Route Password” on the route that handles International calls or to have two Outbound Routes for International calls – one having no password but restricted to certain acceptable countries and another that has a password and is used for all other International destinations. Note that Outbound Routes are checked in sequence so you must put those with a dial pattern matching specific countries first, then put one with a Dial Pattern that works as a catch-all for any other International destination.
On its own, controls on the Outbound Routes may not be sufficient to fully protect your system, but it is a big help and acts as a second line of defence behind the user accounts.

SIP Peers

When Asterisk receives a SIP INVITE request, the sender will broadly fall into one of three categories:

1. Those from a dynamic IP address which have to authenticate with user id and password
2. Those from a “trusted” pre-defined IP address (authentication by password is optional)
3. The rest.

Security relating to the first category, using password authentication, was discussed in the section above. I now want to look at the second category – Static SIP peers – which are defined in sip.conf. You can list all the SIP peers (categories 1 and 2), at the Asterisk Command Line Interface using the command sip show peers. here is an example:

Name/username              Host            Dyn Nat ACL Port     Status
voiptalk/801234543         77.240.48.94                5060     OK (23 ms)
smartvox/221221            114.32.159.2                5060     OK (27 ms)
sipgate/7654567            217.10.79.23                5060     OK (33 ms)
sipbroker                  64.34.162.221               5060     Unmonitored
myopensips-in              192.168.0.116               5060     Unmonitored
2001                       (Unspecified)    D       A  0        UNKNOWN
2002                       (Unspecified)    D       A  0        UNKNOWN
2003/2003                  192.168.0.53     D       A  5060     OK (31 ms)
2004/2004                  192.168.0.31     D          5070     OK (6 ms)
9 sip peers [Monitored: 5 online, 2 offline Unmonitored: 2 online, 0 offline]

The IP address of each static peer is defined using “host=<ip_address>” in the relevant section of sip.conf and you can specify that a peer does not need to authenticate (i.e. that you trust it soley on the basis of knowing the sender’s IP address) by adding the line “insecure=invite” to the peer definition. SIP Peers can be used very effectively to protect Asterisk against unauthorised call handling as long as you set the parameter “allowguest=no” in the general section of sip.conf. On FreePBX/Trixbox, this parameter is found on the General Settings page, near the end, and is called “Allow Anonymous Inbound SIP Calls?: no”. When set like this, Asterisk will only accept SIP requests from the pre-defined peer addresses or from peers that authenticate using a valid username and password. Unfortunately, some VoIP service providers may require that you set this parameter to Yes because it suits them to send calls to your PBX from several different addresses (for reasons of load balancing and/or resilience). I am aware that Voiptalk send calls from more than one server, but others do it too.

Always use “type=peer” and never “type=friend”

When adding static SIP peers (or so-called “SIP Trunks” in FreePBX/Trixbox) set the type to “peer” and never set it to “friend”. This advice may run counter to the majority of documentation, sample files and examples shown on the voip-info.org site and on Asterisk forums, but you’ll have to take my word for it – using “type=friend” is a big mistake! It will make your Asterisk server much more vulnerable because “type=friend” actually causes two objects to be created – a SIP peer and a SIP user. This gives the potential hacker two entrance doors into your PBX, one of which has comparatively weak security. The problem is that a “user” is allowed to connect from any remote IP address, not just the address specified in the host parameter. Even if you want to allow connections from any address, it is much better to use “host=dynamic” than to use “type=friend”.
By far the worst mistake that you could make when defining a static SIP peer would be to have both “type=friend” and “insecure=invite”. In this situation, a hacker could initiate calls from any remote IP address without needing to authenticate with a password. They would only need to guess one piece of data – the user name.

Default Contexts

If your Asterisk server cannot be locked down as described above, perhaps because it needs to accept legitimate requests from IP addresses that cannot be predicted in advance, then it is essential that you examine your configuration and make sure you understand how dial plan contexts are selected for each type of inbound call, especially those in category 3 above. A specific context can, and generally should, be defined for each peer in the sip.conf file using “context=<context_name>” in the peer definition in sip.conf. By doing that you can then be confident that INVITE requests from all other sources (category 3) will use the default context. FreePBX generally expects you to set the context to “from-trunk” when defining a new SIP trunk. To check which context is assigned to any given peer, run the command “sip show peer <name>” at the CLI using the name shown by the “sip show peers” command.
This all sounds straightforward, but in fact there is potential for a huge amount of confusion here! First, you must understand that Asterisk comes with a special pre-defined “default” context. Out of the box, Asterisk will generally use the context called “default” to route any category 3 calls. However, you can reset which context should be used for category 3 SIP calls by inserting a line “context=<my_default_context>” in the [general] section of sip.conf. FreePBX or Trixbox will almost certainly have done this for you using a context with a name like ”from-sip-external”. To see which context will be used for calls from unknown sources, run the command “sip show settings” at the CLI. The final section of the output from this command shows you various default settings, including the default context. Here is a sample from a FreePBX unit:

Default Settings:
-----------------
  Context:                from-sip-external
  Nat:                    RFC3581
  DTMF:                   rfc2833
  Qualify:                0
  Use ClientCode:         No
  Progress inband:        Never
  Language:               (Defaults to English)
  MOH Interpret:          default
  MOH Suggest:
  Voice Mail Extension:   *97

Each context contains steps that define the dial plan for calls handled by that context. One context may insert the code from a number of other contexts using the “include” directive. To see the dialplan details of any given context, run the command “dialplan show <context_name>” at the CLI. For example:

fpbxwarp*CLI> dialplan show from-sip-external
[ Context 'from-sip-external' created by 'pbx_config' ]
  'h' =>            1. NoOp(Hangup)                               [pbx_config]
  'i' =>            1. NoOp(Invalid)                              [pbx_config]
  's' =>            1. GotoIf($["${ALLOW_SIP_ANON}"="yes"]?from-trunk|${DID}|1) [pbx_config]
                    2. Set(TIMEOUT(absolute)=15)                  [pbx_config]
                    3. Answer()                                   [pbx_config]
                    4. Wait(2)                                    [pbx_config]
                    5. Playback(ss-noservice)                     [pbx_config]
                    6. Playtones(congestion)                      [pbx_config]
                    7. Congestion(5)                              [pbx_config]
  't' =>            1. NoOp(Timeout)                              [pbx_config]
  '_.' =>           1. NoOp(Received incoming SIP connection from unknown peer to ${EXTEN}) [pbx_config]
                    2. Set(DID=${IF($["${EXTEN:1:2}"=""]?s:${EXTEN})}) [pbx_config]
                    3. Goto(s|1)                                  [pbx_config]

-= 5 extensions (13 priorities) in 1 context. =-

The above example, from FreePBX, is rather over-complicated to explain here, but it does illustrate how you can use the “dialplan show” command to see if calls from unknown sources will be handled safely.

Getting more advanced

In part 2, we looked at several ways in which an Asterisk system administrator can help to make their system more secure, with special emphasis on avoidance of toll fraud. In this, the third and final article in the series, I will pick up on a topic that was left unfinished at the end of part 2 – sip domains. I also want to look at a couple of other topics that were barely touched on in the first two articles, but which are profoundly important for security – the dial plan and Denial of Service attacks.

The relevance of SIP Domains

When a SIP request is sent to your Asterisk server, the main header should contain a Request URI (or R-URI) that looks somewhat like one of the following:

• sip:012345678@mysipservice.com
• sip:012345678@sip.mydomain.com
• sip:012345678@114.32.159.60

In each case, the destination is defined as a number then the @ symbol and finally the “SIP domain”. In the first two examples, the SIP domain is given as a host name and would have to be resolvable by public DNS servers to be useful. In the third example, the sip domain is given as an IP address – it would therefore need to match the IP address of your Asterisk server (or perhaps the external, or WAN, IP address of your NAT router if behind NAT).
Asterisk can be configured to be indifferent to SIP domains or you can specify a list of “allowed” domains that it will support. How this is achieved is explained in detail in another article on this site:
Configuring and using SIP domains in Asterisk

A benefit of SIP domains

Activating support for SIP Domains in Asterisk can give you one more layer of security, but it will only be effective if you can:

1. Avoid having your PBX’s Internet IP address as one of the domains, and
2. Set the parameter allowexternaldomains = no

Doing both of the above will cause Asterisk to reject all SIP requests where the R-URI is using the external IP address of the PBX rather than a legitimate SIP domain – one that you have configured and approved. Since most hacking attempts are based on IP address only, this could be a useful extra layer of protection for your server.

A potential pitfall with SIP domains

Every silver lining has a cloud and so it is with SIP domains. All the advice offered in part 2 about checking which dial plan will be used for inbound calls can be rendered invalid if you have defined a sip domain with the additional optional parameter, context, appended on the end. For example:

sip.conf

[general]

domain=mysipdomain.com,mycontext

Any request sent to your Asterisk server where the R-URI is using the above sip domain, will use the dial plan configured for the context called mycontext. I would recommend avoiding using the additional parameter when defining a sip domain in Asterisk because it could act like a hidden back-door that is easy to overlook.

Automated-Attendants, DISA and other risks

The vulnerabilites discussed so far have mostly involved quite technical weaknesses, especially related to malicious SIP requests arriving over the Internet. However, it is also possible to leave the door open for mis-use through the menus and options that are offered to ordinary callers. Features that are very convenient for legitimate users can provide a route in for hackers, especially if weak passwords have been used. You would be ill advised to assume that a “hidden” menu option known only to employees will never be found by a potential hacker – there are only 12 keys on a telephone key pad so it doesn’t take much effort to try all twelve at various points in the caller menus.
Areas to watch include Automated-Attendants, voicemail access, follow-me and call forwarding options, DISA or any similar trunk-to-trunk callout feature.

Protecting against Denial of Service attacks

Asterisk is good at many things, but handling a lot of simultaneous requests is not one of them. It would be relatively easy to overwhelm most Asterisk servers by bombarding them with a lot of SIP requests in a short space of time. Restricting access at the firewall is the best solution because it stops the requests before they reach Asterisk, but it is not always an option. Correct use of security parameters within Asterisk such as “allowexternaldomains” and “allowguest” can help deflect unauthorised requests before they demand too much processing, but once again it may not always be possible to use them. So how might it be possible to protect your Asterisk servers against Denial of Service attacks if the aforementioned options are not available or are not adequate?

OpenSIPS as an intelligent firewall

One possibility would be to use an OpenSIPS server as a barrier between the Internet and Asterisk. OpenSIPS is able to handle much greater demands in terms of requests per minute and is also able to inspect SIP requests in great detail to determine if they are valid or malicious. In this scenario, the OpenSIPS server would be accessible from any address on the Internet, but the Asterisk server would only accept connections from the OpenSIPS server. This configuration also has the advantage of being scalable – if one Asterisk server is not enough, you can add more behind a single OpenSIPS server which will load balance requests across all the Asterisk servers.

Fail2ban

Another option to consider is the use of Fail2ban or a similar add-on product. Fail2ban is an open-source product that will dynamically modify the rules in an iptables (or similar) firewall based on the number and frequency of unauthorised access attempts made from a given remote address. It works by constantly monitoring the Asterisk log file – or other log file – to identify brute force attacks. Parameters can be configured to adjust settings such as how long to block the remote address, how many failures before it should be blocked, etc. It comes with standard rule sets and templates that will work with a number of commonly used applications, but you can also configure your own rule sets to cope with unsupported applications.
Link: Click here to visit the Fail2ban web site.

SIP firewall

There are few products available that can honestly be described as purpose-built SIP firewalls. However, there is at least one device now available designed exclusively to be used as a SIP firewall installed in front of your IP-PBX. It is the Pika µFirewall or µWarp. You can read the Smartvox review of this device here.

Stopping a “friendly-scanner” DoS attack

One form of attack that has been widely reported (and which may even be made more likely if you use settings such as “alwaysauthreject=yes”) is an intense and endless stream of REGISTER requests sent from one source address on the Internet and using the “friendly-scanner” user agent name. If you are, or suspect you may be, on the receiving end of such an attack, then please read the article located here.

Summing up

The level of risk has certainly intensified in the last year or possibly even the last few months and there is little doubt that the unwary will get caught and will end up paying for someone else’s phone calls to weird and unlikely destinations like North Korea or Ethiopia. Once an unsecured PBX has been found, it is likely to be hit with hundreds of expensive calls and very large bills can be run up in a matter of hours. This is not a problem to be taken lightly – it could even sink a small business.
You cannot seriously expect protection or redress from the authorities or the Telcos – you would be extremely lucky to get more than passing sympathy from either. Protecting your PBX is therefore up to you, your PBX maintainer and IT support team. If all Asterisk PBX’s were locked down and properly protected then the hackers would soon lose interest and look for other ways to make money, so make it as difficult for them as you can. Make sure all your passwords are very strong, that you have set “alwaysauthreject” to yes and check all the other points raised in these articles.
I hope this has been useful and would welcome feedback from interested readers, either using the voting buttons or by leaving a comment.

Read more »

Seven Steps to Better SIP Security with Asterisk

In case any of you were wondering why there has been a fairly notable upswing in the attacks happening on SIP endpoints, the answer is “script kiddies.”  In the last few months, a number of new tools have made it easy for knuckle-draggers to attack and defraud SIP endpoints, Asterisk-based systems included.  There are easily-available tools that scan networks looking for SIP hosts, and then scan hosts looking for valid extensions, and then scan valid extensions looking for passwords.  You can take steps, NOW, to eliminate many of these problems.  I think the community is interested in coming up with an integrated Asterisk-based solution that is much wider in scope for dynamic protection (community-shared blacklists is the current thinking) but that doesn’t mean you should wait for some new tool to defend your systems.  You can IMMEDIATELY take fairly common-sense measures to protect your Asterisk server from the bulk of the scans and attacks that are on the increase. The methods and tools for protection already exists – just apply them, and you’ll be able to sleep more soundly at night.

Seven Easy Steps to Better SIP Security on Asterisk:

1) Don’t accept SIP authentication requests from all IP addresses. Use the “permit=” and “deny=” lines in sip.conf to only allow a reasonable subset of IP addresess to reach each listed extension/user in your sip.conf file.  Even if you accept inbound calls from “anywhere” (via [default]) don’t let those users reach authenticated elements!

2) Set “alwaysauthreject=yes” in your sip.conf file. This option has been around for a while (since 1.2?) but the default is “no”, which allows extension information leakage.  Setting this to “yes” will reject bad authentication requests on valid usernames with the same rejection information as with invalid usernames, denying remote attackers the ability to detect existing extensions with brute-force guessing attacks.

3) Use STRONG passwords for SIP entities. This is probably the most important step you can take.  Don’t just concatenate two words together and suffix it with “1” – if you’ve seen how sophisticated the tools are that guess passwords, you’d understand that trivial obfuscation like that is a minor hinderance to a modern CPU.  Use symbols, numbers, and a mix of upper and lowercase letters at least 12 digits long.

4) Block your AMI manager ports. Use “permit=” and “deny=” lines in manager.conf to reduce inbound connections to known hosts only.  Use strong passwords here, again at least 12 characters with a complex mix of symbols, numbers, and letters.

5) Allow only one or two calls at a time per SIP entity, where possible. At the worst, limiting your exposure to toll fraud is a wise thing to do.  This also limits your exposure when legitimate password holders on your system lose control of their passphrase – writing it on the bottom of the SIP phone, for instance, which I’ve seen.

6) Make your SIP usernames different than your extensions. While it is convenient to have extension “1234” map to SIP entry “1234” which is also SIP user “1234”, this is an easy target for attackers to guess SIP authentication names.  Use the MAC address of the device, or some sort of combination of a common phrase + extension MD5 hash (example: from a shell prompt, try “md5 -s ThePassword5000”)

7) Ensure your [default] context is secure.  Don’t allow unauthenticated callers to reach any contexts that allow toll calls.  Permit only a limited number of active calls through your default context (use the “GROUP” function as a counter.)  Prohibit unauthenticated calls entirely (if you don’t want them) by setting “allowguest=no” in the [general] part of sip.conf.

These 7 basics will protect most people, but there are certainly other steps you can take that are more complex and reactive.  Here is a fail2ban recipe which might allow you to ban endpoints based on volume of requests.  There is discussion on the asterisk-user and asterisk-dev mailing lists of incorporating this type of functionality into Asterisk – let’s hear your ideas!

If you’d like to see an example of the tools that you’re up against, see this demo video of an automated attack tool that does scan, guess, and crack methods via a click-and-drool interface.

In summary: basic security measures will protect you against the vast majority of SIP-based brute-force attacks.  Most of the SIP attackers are fools with tools – they are opportunists who see an easy way to defraud people who have not considered the costs of insecure methods.  Asterisk has some methods to prevent the most obvious attacks from succeeding at the network level, but the most effective method of protection are the administrative issues of password robustness and username obscurity.

Read more »

Chặn IP Trung Quốc bằng Iptables + Ipset

WHY ? 

---

Không phải phân biệt chủng tộc hay kích động thù hằn dân tộc nhưng có một sự thật là TQ là nước chiếm tỉ lệ lớn nguồn gốc các cuộc tấn công mạng vào các Website của thế giới nói chung và VN nói riêng. Nhiều website nước ngoài cũng tiến hành chặn IP Trung Quốc để ngủ ngon hơn, mình cũng nên học hỏi.
Lưu ý : Việc chặn IP chỉ là biện pháp đối phó tương đối (chỉ hiệu quả trước một số loại tấn công như DoS, Spam..) . Đối với những kẻ tấn công có chủ đích nhắm vào ứng dụng của bạn thì chúng có thừa thủ đoạn để qua mặt các bộ lọc IP. Về lâu dài, bạn cần định kỳ kiểm trả bảo mật và đảm bảo các quy tắc lập trình an toàn trong quá trình phát triển.

HOW ?

---

Công cụ :

• iptables - firewall mặc định trên hầu hết Linux Distro (Lưu ý : CentOS 7 và FC20 trở đi sử dụng firewallD thay thế iptables, cần cài lại iptables thay thế firewallD hoặc viết rule cho firewallD)
• ipset - công cụ hỗ trợ iptables, có chức năng tạo cái list IP để add rule cho iptables (Cài đặt : yum install ipset hoặc apt-get install ipset)

Tạo file bash script có nội dung :

/etc/china-block.sh

# Tạo list ipset tên china
ipset -N china hash:net # Xóa nội dung file cn.zone cũ (file danh sách IP china) để cập nhật list mới.
rm ~/cn.zone
# Tải list IP Trung Quốc mới nhất về từ site ipdeny, lưu ở home
wget -P ~ http://www.ipdeny.com/ipblocks/data/countries/cn.zone
# Đọc từng dòng trong file cn.zone rồi lưu vào list ipset china
for i in $(cat ~/cn.zone ); do ipset -A china $i; done
# Restore các rule iptables khi khởi động lại
/sbin/iptables-restore < /etc/iptables.firewall.rules

Thêm rule vào file iptables.firewall.rules

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

Chạy thử file china-block.sh

$ sh china-block.sh

Kiểm tra kết quả

$ iptables -L Chain INPUT (policy ACCEPT)
target     prot opt source               destination
...
DROP       tcp  --  anywhere             anywhere             match-set china src
..

Cuối cùng là tạo crontab định kỳ thực hiện sáng sớm mỗi ngày

$ crontab -e * 1 * * * /etc/china-block.sh

Read more »

Chống DDOS với iptables

Giới thiệu về iptables

Nguyên tắc làm việc của iptables là nó cho phép người dùng định nghĩa các quy tắc (rules), các quy tắc này nằm trong bộ nhớ và sẽ được iptables kiểm tra để thực thi mỗi khi có một request đến máy chủ. Nếu một request thỏa mãn quy tắc, nó sẽ được thực hiện theo action của quy tắc đó.

Các request được nhận diện bằng các thông số sau:
- địa chỉ nguồn (một ip hay cả một dải ip)
- địa chỉ đích
- giao thức (giao thức phổ biến là TCP/IP)
- cổng (các cổng phổ biến là cổng 80 http, cổng 21 ftp ...)
- interface vật lý (là request đến từ card mạng nào của máy chủ)

Còn các action mà iptables có thể thực hiện là
- ACCEPT cho phép request đó được thực hiện, hay nói đúng hơn là cho gói tin thỏa mãn các điều kiện trên đi qua.
- REJECT không cho phép gói tin đi qua, gửi trả lại địa chỉ xuất phát request một thông báo
- DROP không cho phép gói tin đi qua và cũng không gửi trả lại thông báo gì
- LOG cho phép gói tin đi qua nhưng sẽ ghi log lại để phân tích
- DNAT cho phép gói tin đi qua nhưng dùng NAT để thay thế địa chỉ đích
- SNAT cho phép gói tin đi qua nhưng dùng NAT để thay thế địa chỉ nguồn

Ngoài ra các rules còn được kiểm soát bởi kiểu của request, có 3 kiểu sau đây
- INPUT: là các request đến máy chủ
- FORWARD: là các request đi qua máy chủ (vào cổng mạng này và đi ra cổng mạng khác) nó áp dụng trong trường hợp máy chủ của bạn làm việc như một routing server.
- OUTPUT: áp dụng cho các request đi từ máy chủ ra ngoài (ví dụ bạn không muốn các website trên VPS của bạn truy cập đến một website khác nằm ở đâu đó trên internet).

Các lệnh quản lý iptables

Bạn có thể khởi tạo một rule và kiểm tra iptables ngay từ dùng lệnh của hệ điều hành linux. Dưới đây là một số lệnh cơ bản

Kiểm tra xem dịch vụ iptables đã chạy hay chưa:
     # service iptables status

Nếu như iptables đang chạy nó sẽ liệt kê ra các rules nằm trong 3 kiểu là chain INPUT, chain FORWARD và chain OUTPUT. Nếu như iptables chưa chạy sẽ có thông báo là Firewall is stopped. Lưu ý là trong trường hợp chưa có một rule nào đã được định nghĩa, thì có thể bạn cũng nhận được thông báo Firewall is stopped. Lúc đó bạn chỉ cần thêm vào một rules là iptables sẽ được bật.

Bật dịch vụ iptables
     # service iptables start

Khởi động lại dịch vụ iptables. Thông thường mỗi khi bạn tạo rules từ dòng lệnh, thì các rule này có hiệu lực ngay. Tuy nhiên trong trường hợp bạn tạo rules vào file thì bạn cần dùng lệnh sau để khởi động lại iptables và tải lại các rules từ file

     # service iptables restart

Ghi các rules hiện thời vào file. Thông thường các rules được lưu trong bộ nhớ RAM để thực thi cho nhanh. Tuy nhiên khi tắt máy hoặc khởi động lại, các rules này sẽ không còn. Để lưu lại các rules bạn cần thực hiện lệnh sau:

# service iptables save

Lệnh trên sẽ lưu các rules đang chạy vào file /etc/sysconfig/iptables Sau khi đã có file này, các bạn có thể thêm trực tiếp các rules vào trong file này. Tuy nhiên lưu ý là các rules trong iptables sẽ có tác dụng ngay lập tức vì vậy để tránh tạo ra các rules lỗi, bạn nên tạo các rules trong một file nháp ví dụ như file /etc/sysconfig/iptables.tmp  sau đó chạy kiểm tra iptables bằng lệnh sau:

# iptables-restore < /etc/sysconfig/iptables.tmp

Nếu các bạn muốn lưu các rules đang chạy ra một file bất kỳ (để backup hoặc để gửi cho người khác) thì có thể dùng lệnh sau

# iptables-save > /etc/sysconfig/iptables.backup

Nếu dùng lệnh trên mà không có tên file theo sau, nó sẽ in các rules đang chạy ra màn hình để bạn kiểm tra.

Các lệnh tạo rules cho iptables.

Cú pháp chung cho các lệnh tạo rules của iptables như sau

# iptables [command] [kiểu] [mô tả rule] [-j acction]

Trong đó kiểu là INPUT, FORWARD, hoặc OUTPUT như đã nói ở trên. Acction = ACCEPT, REJECT, DROP.... như đã nói ở trên, còn command, các bạn có thể tham khảo danh sách các command bằng cách gõ lệnh:

# iptables -h

Các command thông dụng là:
      - I  (Thêm một quy tắc mới vào iptable)
      - A (chèn thêm các mô tả vào một quy tắc)
      - D (xóa bỏ một quy tắc)

Còn đoạn mô tả rule thì được xây dựng từ địa chỉ nguồn, địa chỉ đích, cổng dịch vụ, cổng mạng.... các bạn tìm hiểu các rule này qua các ví dụ sau:

- Rule 1: chặn một địa chỉ bên ngoài đến interface ethe0 và truy xuất cổng 80 giao thức tcp,  tới địa chỉ đích 27.118.22.10
      -s 116.10.191.15 -i ethe0 -d 27.118.22.10 -p tcp --dport 80

- Rule 2:  chặn một network (cả một dải ip) truy xuất các cổng 3000 đến 4000 của địa chỉ 27.118.22.10
      -s 116.10.191.0/24 -d 27.118.22.10 -p tcp --dport 3000:4000

- Rule 3: Cấm một ip dùng cổng 20 (ftp) truy xuất đến máy chủ
      -s 116.10.191.15 -d 27.118.22.10 -p tcp --sport 20

Giải thích các option:

      -s (chỉ ra địa chỉ nguồn của gói tin)
      -d (chỉ ra địa chỉ đích của gói tin)
      -p (chỉ ra giao thức, có thể là tcp, icmp, udp....)
      -dport (chỉ ra các cổng dịch vụ ở địa chỉ ip đích )
      -sport (chỉ ra các cổng dịch vụ của ip nguồn)
      -i (chỉ ra cổng vật lý mà gói tin xuất hiện ví dụ cổng ethe0)

Tham khảo các option khác bằng lệnh # iptables -h

Bây giở chúng ta sẽ ghép các thành phần trên để tạo thành một rule thực sự. Giả sử chúng ta cần cấm tất cả các gói tin có địa chỉ IP nguồn đến từ một network là 116.10.191.0 đi đến VPS của chúng ta, bất kể là gói tin đó sử dụng giao thức gì, dịch vụ gì, và bất kể nó đòi truy xuất đến địa chỉ IP nào, chúng ta gõ lệnh sau trực tiếp vào dòng lệnh của hệ điều hành

# iptables -I INPUT -s 116.10.191.0/24 -j DROP

Ngay sau khi gõ lệnh trên, toàn bộ các host có địa chỉ IP là 116.10.191.x sẽ không còn truy xuất được đến máy VPS của bạn nữa.  Nếu muốn xóa bỏ quy tắc trên, chúng ta gõ lệnh

# iptables -D INPUT -s 116.10.191.0/24 -j DROP

Sau khi thực hiện việc tạo, thêm bớt các rule, các bạn nhớ dùng lệnh sau để ghi lại các rules để nếu như có khởi động lại VPS thì iptables có thể dùng lại các rule này.

# service iptables save

Sau đó cũng cần phải đặt chế độ tự khởi động dịch vụ iptables mỗi lần khởi động VPS bằng lệnh sau:

# chkconfig iptable on

Áp dụng iptables

Qua các bước trên các bạn đã biết cách dùng iptables để ngăn chặn các truy xuất từ các IP xấu. Vậy bây giờ chúng ta sẽ dùng nó như thế nào? Để chống lại các cuộc tấn công DDOS, chúng ta có nhiều phương án khác nhau.

Cách thứ nhất: Phân tích log

Phân tích thường xuyên file log để biết IP nào hay trọc phá VPS và block ip đó. Các bạn hãy xem toàn bộ file /var/log/secure để biết được các request bất thường hay đến từ địa chỉ IP nào. Sau đó  các bạn tạo ra một file shell như sau để dùng nhiều lần

# cd /etc/sysconfig/
# vi iptables.sh (sau đó đặt các lệnh tạo rules của iptables vào trong file này)
# chmod +x iptables.sh   (cho phép chạy file này)
# ./iptables.sh  (chạy file để tạo ra các rules)

Từ nay về sau mỗi khi phát hiện một ip xấu nào, bạn chỉ cần thêm một dòng vào file iptables.sh này và chạy nó thì các rules sẽ được tạo ra.

Cách thứ 2: Chặn IP theo vùng

Nhận xét thấy là các cuộc tấn công DDOS thường đến từ các quốc gia như Trung Quôc, Hàn Quốc... trong khi VPS của bạn không có khách hàng nào ở các quốc gia này thì bạn có thể chặn toàn bộ IP của các nước có nghi ngờ xuất phát các cuộc tấn công DDOS như sau:

Đầu tiên bạn cần có danh sách ip của các quốc gia này. Ví dụ danh sách các IP hay tấn công DDOS từ Trung Quốc các bạn có thể lấy ở link này: http://www.ipdeny.com/ipblocks/data/countries/cn.zone

Khi đã có link, các bạn lấy danh sách ip đó về một file gọi là iptables.block.list bằng lệnh sau

# wget -c --output-document=iptables.block.list http://www.ipdeny.com/ipblocks/data/countries/cn.zone

Sau khi có file danh sách này bạn viết một script như sau:

#vi iptables.sh
Nội dung file:
#!/bin/bash
WORKDIR="/root"
#######################################
cd $WORKDIR
if [ -f iptables.block.list ]; then
  iptables -F
  BLOCKDB="iptables.block.list"
  IPS=$(grep -Ev "^#" $BLOCKDB)
  for i in $IPS
  do
    iptables -A INPUT -s $i -j DROP
  done
fi

Tiếp theo là chạy file iptables.block.list và nhớ save danh sách bằng lệnh service iptables save như các bước trên.

File iptables-config

File /etc/sysconfig/iptables-config có chứa một số cấu hình cho dịch vụ iptables. Các bạn cũng nên tìm hiểu một số lệnh trong file này để ứng dụng.

IPTABLES_SAVE_ON_STOP = "no"  Giá trị này nên chuyển thành "yes" khi đó mỗi lần stop iptables (hay là khi tắt máy) thì các rules trong bộ nhớ sẽ được save vào file /etc/sysconfig/iptables để tải lại các lần sau

IPTABLES_SAVE_ON_RESTART ="no"  Giá trị này nếu sửa thành "yes" thì mỗi khi restart dịch vụ iptables, các rules cũng được ghi lại vào file

... ngoài ra còn một số tham số khác các bạn tự tìm hiểu thêm

Nguyên tắc cuối cùng: chống tự tử

Những ai đã từng làm filtering và firewalling đều có những bài học xương máu về việc tự sát. Đó là trong khi mải mê tạo ra các rules để ngăn chặn các cuộc tấn công, vô tình chúng ta cấm luôn cả ip của chính mình và kể từ đó không còn access được vào server nữa. Để tránh gặp phải thảm cảnh này, các bạn nên tuân thủ một số nguyên tắc sau:

1- The First match rule.

Trước khi tạo bất cứ một rules nào bạn cần phải tạo một rule cho phép chính mình và đặt ở đầu file iptables. Bởi vì mọi firewall đều làm việc theo nguyên tắc duyệt các rule từ trên xuống dưới, nếu thỏa mãn thì áp dụng ngay bất kể các rule bên dưới có match hay không. Vậy nên các trong khi thao tác với iptables, bạn cần biết IP của máy mình đang dùng là gì. Nếu có ip tĩnh thì quá tốt, nếu không thì cũng phải biết dải ip mà ADSL của mình thường xuyên được cấp. Sau đó tạo một rules đầu tiên trong file iptables như sau:

-A INPUT -s 111.111.111.111/32 -j ACCEPT

Trong đó 111.111.111.111 giả định là ip mà máy của bạn đang dùng. Nếu như bạn có một dài IP hay dùng thì thay bằng dòng

-A INPUT -s 111.111.111.0/24 -j ACCEPT

Như vậy bất kể sau đó bạn có khai báo một lệnh DROP hay REJECT nào thì ip của bạn vẫn access được đến server mà không sợ thiết lập rules "tự tử" cấm chính mình.

2- Alway got the second road.

Cho dù bạn cẩn thận đến đâu, kể cả khi bạn đã áp dụng nguyên tắc thứ nhất thì vẫn có thể bạn không access được vào server, chẳng hạn như bạn đã mở ip của bạn, nhưng mạng của nhà cung cấp dịch vụ lại cấm ip của bạn thì sao? hoặc giả bạn cho phép dải ip ở công ty của bạn access, nhưng bạn đang ở quán cafe wifi và muốn access vào VPS thì sao? Để tránh tình huống này bạn cần tạo ra một rule thứ 2 cho phép một máy dự phòng và máy này thì bạn có thể remote từ xa vào để thao tác. Hãy add thêm dòng lệnh sau vào ngay bên dưới dòng lệnh nêu trên trong file iptables

-A INPUT -s 222.222.222.222/32 -j ACCEPT

trong đó 222.222.222.222 là máy dự phòng để bạn có thể access vào máy chủ khi mà IP thứ nhất bị cấm.

3- Kiểm tra tất cả mọi thứ trước khi đặt lệnh chkconfig on

Các tác giả iptables đã lường trước rằng người dùng sẽ có thể vô tình tự tử khi thiết lập rule nên họ đặt ra một nguyên tắc là iptables làm việc với các rule thường trực trong RAM và chỉ save xuống iptables để lưu. Đồng thời họ để chế độ ngầm định là iptables sẽ không khởi động mỗi khi reboot máy. Đây là một cơ may cuối cùng khi bạn bị cấm ip. Lúc đó chỉ cần khởi động lại máy là các rules trong RAM sẽ bị xóa sạch và thậm chí là iptables sẽ không khởi động theo máy nên bạn sẽ có thể access lại máy chủ sau khi reboot. Tôn trọng nguyên tắc này bạn cần lưu ý mấy điểm sau:

• Gõ các rules từ dòng lệnh của linux để rules ghi vào ram chứ không ghi vào file iptables, để kiểm tra xem rule có tác động như thế nào, nếu sau khi ứng dụng rule mà bị ngắt thì khởi động lại server.
• Save các rule từ RAM sang một file tạm trước khi save vào iptable bằng lệnh iptables-save > filename. Việc này vừa để backup iptables và vừa đảm bảo là các rules được test kỹ trước khi save lại vào file cấu hình.
• Hãy kiểm tra cẩn thận trước khi gõ lệnh chkconfig iptables on vì sau khi gõ lệnh này, mỗi lần khởi động lại server sẽ tự load file iptables lên và áp dụng các rules ngay, do vậy nếu như đã trót save các lệnh "tự tử" vào file iptables mà lại đặt lệnh chkconfig on cho dịch vụ này thì coi như hết thuốc chữa.

Read more »

2/3 dịch vụ giao dịch trực tuyến tại Việt Nam dính lỗ hổng SSL 3.0

Hôm nay (21/10/2014), Công ty An ninh mạng Bkav Security, thành viên của Tập đoàn công nghệ Bkav, phát đi thông báo cho biết 2/3 dịch vụ giao dịch trực tuyến ở Việt Nam có lỗ hổng SSL 3.0.

Lỗ hổng SSL 3.0 được Google công bố ngày 14/10, có thể cho phép tin tặc chiếm tài khoản ebanking, tài khoản chứng khoán và thương mại điện tử của nạn nhân. (Ảnh minh họa. Nguồn: Internet)

SSL 3.0 là lỗ hổng được Google công bố ngày 14/10, có thể cho phép tin tặc chiếm tài khoản ebanking, tài khoản chứng khoán và thương mại điện tử của nạn nhân.
Lỗ hổng nằm trong giao thức SSL 3.0, được sử dụng phổ biến để mã hóa và bảo vệ dữ liệu trao đổi giữa các website ebanking, chứng khoán và thương mại điện tử với người dùng. Tuy đa phần các website đã chuyển sang giao thức mới TLS 1.2, nhưng vẫn đứng trước nguy cơ bị tấn công do các web server đều tương thích ngược với SSL 3.0.
Nếu website và trình duyệt của người dùng cùng sử dụng SSL 3.0 để trao đổi dữ liệu, tin tặc có thể đánh cắp tài khoản giao dịch trực tuyến của người dùng và chuyển tiền tới tài khoản khác hoặc thực hiện giao dịch chứng khoán, mua hàng hóa bằng tài khoản của nạn nhân. Ngay sau khi lỗ hổng được công bố, Bkav đã tiến hành kiểm tra các website giao dịch trực tuyến quan trọng và phát hiện hơn 2/3 (68%) các dịch vụ này vẫn sử dụng SSL 3.0.
Ông Ngô Tuấn Anh, Phó Chủ tịch phụ trách An ninh mạng Bkav cho biết: “Do tính chất quan trọng của các giao dịch ngân hàng, Bkav đã phối hợp với Ngân hàng Nhà nước thông báo tới các đơn vị cung cấp dịch vụ ebanking có sử dụng SSL 3.0. Chỉ cần các website vô hiệu hóa giao thức này là đủ để ngăn chặn tin tặc tấn công”.
Hiện tại, hầu hết các ngân hàng đã khắc phục xong lỗ hổng, người dùng có thể giao dịch một cách an toàn, tuy nhiên vẫn còn rất nhiều website giao dịch trực tuyến khác chưa tiến hành khắc phục.
Bkav khuyến cáo quản trị viên các website kiểm tra hệ thống của mình và vô hiệu hóa SSL 3.0 bằng công cụ được Bkav cung cấp tại địa chỉ Tools.whitehat.vn. Người dùng cũng có thể tự đảm bảo an toàn cho mình bằng cách cập nhật trình duyệt lên phiên bản mới nhất

Read more »