Cross site request forgery
iptables is a command-line firewall utility that uses policy chains to allow or block traffic. When a connection tries to establish itself on your system, iptables looks for a rule in its list to match it to. If it doesn’t find one, it resorts to the default action.
iptables almost always comes pre-installed on any Linux distribution. To update/install it, just retrieve the iptables package:
sudo apt-get install iptables
There are GUI alternatives to iptables like Firestarter, but iptables isn’t really that hard once you have a few commands down. You want to be extremely careful when configuring iptables rules, particularly if you’re SSH’d into a server, because one wrong command can permanently lock you out until it’s manually fixed at the physical machine.
Types of Chains
iptables uses three different chains: input, forward, and output.
Input – This chain is used to control the behavior for incoming connections. For example, if a user attempts to SSH into your PC/server, iptables will attempt to match the IP address and port to a rule in the input chain.
Forward – This chain is used for incoming connections that aren’t actually being delivered locally. Think of a router – data is always being sent to it but rarely actually destined for the router itself; the data is just forwarded to its target. Unless you’re doing some kind of routing, NATing, or something else on your system that requires forwarding, you won’t even use this chain.
There’s one sure-fire way to check whether or not your system uses/needs the forward chain.
iptables -L -v
The screenshot above is of a server that’s been running for a few weeks and has no restrictions on incoming or outgoing connections. As you can see, the input chain has processed 11GB of packets and the output chain has processed 17GB. The forward chain, on the other hand, has not needed to process a single packet. This is because the server isn’t doing any kind of forwarding or being used as a pass-through device.
Output – This chain is used for outgoing connections. For example, if you try to ping howtogeek.com, iptables will check its output chain to see what the rules are regarding ping and howtogeek.com before making a decision to allow or deny the connection attempt.
Even though pinging an external host seems like something that would only need to traverse the output chain, keep in mind that to return the data, the input chain will be used as well. When using iptables to lock down your system, remember that a lot of protocols will require two-way communication, so both the input and output chains will need to be configured properly. SSH is a common protocol that people forget to allow on both chains.
Policy Chain Default Behavior
Before going in and configuring specific rules, you’ll want to decide what you want the default behavior of the three chains to be. In other words, what do you want iptables to do if the connection doesn’t match any existing rules?
To see what your policy chains are currently configured to do with unmatched traffic, run the
iptables -L command.
As you can see, we also used the grep command to give us cleaner output. In that screenshot, our chains are currently figured to accept traffic.
More times than not, you’ll want your system to accept connections by default. Unless you’ve changed the policy chain rules previously, this setting should already be configured. Either way, here’s the command to accept connections by default:
iptables --policy INPUT ACCEPT
iptables --policy OUTPUT ACCEPT
iptables --policy FORWARD ACCEPT
By defaulting to the accept rule, you can then use iptables to deny specific IP addresses or port numbers, while continuing to accept all other connections. We’ll get to those commands in a minute.
If you would rather deny all connections and manually specify which ones you want to allow to connect, you should change the default policy of your chains to drop. Doing this would probably only be useful for servers that contain sensitive information and only ever have the same IP addresses connect to them.
iptables --policy INPUT DROP
iptables --policy OUTPUT DROP
iptables --policy FORWARD DROP
With your default chain policies configured, you can start adding rules to iptables so it knows what to do when it encounters a connection from or to a particular IP address or port. In this guide, we’re going to go over the three most basic and commonly used “responses”.
Accept – Allow the connection.
Drop – Drop the connection, act like it never happened. This is best if you don’t want the source to realize your system exists.
Reject – Don’t allow the connection, but send back an error. This is best if you don’t want a particular source to connect to your system, but you want them to know that your firewall blocked them.
The best way to show the difference between these three rules is to show what it looks like when a PC tries to ping a Linux machine with iptables configured for each one of these settings.
Allowing the connection:
Dropping the connection:
Rejecting the connection:
Allowing or Blocking Specific Connections
With your policy chains configured, you can now configure iptables to allow or block specific addresses, address ranges, and ports. In these examples, we’ll set the connections to
DROP, but you can switch them to
REJECT, depending on your needs and how you configured your policy chains.
Note: In these examples, we’re going to use
iptables -A to append rules to the existing chain. iptables starts at the top of its list and goes through each rule until it finds one that it matches. If you need to insert a rule above another, you can use
iptables -I [chain] [number] to specify the number it should be in the list.
Connections from a single IP address
This example shows how to block all connections from the IP address 10.10.10.10.
iptables -A INPUT -s 10.10.10.10 -j DROP
Connections from a range of IP addresses
This example shows how to block all of the IP addresses in the 10.10.10.0/24 network range. You can use a netmask or standard slash notation to specify the range of IP addresses.
iptables -A INPUT -s 10.10.10.0/24 -j DROP
iptables -A INPUT -s 10.10.10.0/255.255.255.0 -j DROP
Connections to a specific port
This example shows how to block SSH connections from 10.10.10.10.
iptables -A INPUT -p tcp --dport ssh -s 10.10.10.10 -j DROP
You can replace “ssh” with any protocol or port number. The
-p tcp part of the code tells iptables what kind of connection the protocol uses. If you were blocking a protocol that uses UDP rather than TCP, then
-p udp would be necessary instead.
This example shows how to block SSH connections from any IP address.
iptables -A INPUT -p tcp --dport ssh -j DROP
As we mentioned earlier, a lot of protocols are going to require two-way communication. For example, if you want to allow SSH connections to your system, the input and output chains are going to need a rule added to them. But, what if you only want SSH coming into your system to be allowed? Won’t adding a rule to the output chain also allow outgoing SSH attempts?
That’s where connection states come in, which give you the capability you’d need to allow two way communication but only allow one way connections to be established. Take a look at this example, where SSH connections FROM 10.10.10.10 are permitted, but SSH connections TO 10.10.10.10 are not. However, the system is permitted to send back information over SSH as long as the session has already been established, which makes SSH communication possible between these two hosts.
iptables -A INPUT -p tcp --dport ssh -s 10.10.10.10 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -d 10.10.10.10 -m state --state ESTABLISHED -j ACCEPT
The changes that you make to your iptables rules will be scrapped the next time that the iptables service gets restarted unless you execute a command to save the changes. This command can differ depending on your distribution:
Red Hat / CentOS:
/sbin/service iptables save
List the currently configured iptables rules:
-v option will give you packet and byte information, and adding
-n will list everything numerically. In other words – hostnames, protocols, and networks are listed as numbers.
To clear all the currently configured rules, you can issue the flush command.
ASTERISK SECURITY: USE IPTABLES TO BLOCK THE BAD GUYS
Having your asterisk server on the public internet, people will try to use your phone system for free.
One technique is for scripts simply to look for any accounts with easy to guess usernames and passwords. It’s easy to spot these attempts in the log files. Just look for any “Fail” messages:
grep “Fail” /var/log/asterisk/messages
[Jun 18 07:42:15] NOTICE chan_sip.c: Failed to authenticate user "MeucciSolutions" ;tag=as6f2c0dfb[Jun 18 07:49:45] NOTICE chan_sip.c: Failed to authenticate user "MeucciSolutions" ;tag=as51af5dba [Jun 18 09:02:47] NOTICE chan_sip.c: Failed to authenticate user "MeucciSolutions" ;tag=as3c4e5e5b [Jun 18 09:57:09] NOTICE chan_sip.c: Failed to authenticate user "MeucciSolutions" ;tag=as22d69494 ...
As you can see, some joker at 22.214.171.124 tried several times to authenticate on my server. Now, I have passwords that are not easy to guess, but still I’d prefer to block them from even getting to my asterisk server. Linux has a built-in firewall and it is possible to simply reject any packets from this IP address.
iptables -I INPUT -s 126.96.36.199 -j DROP
That translates to: If any packets come from this particular IP address (source), ignore (drop) them.
To view (list) all the blocked IP addresses:
iptables -n -L
Chain INPUT (policy ACCEPT) target prot opt source destination DROP all -- 188.8.131.52 0.0.0.0/0
What is Fail2Ban and How to configure it?
original source : http://kb.smartvox.co.uk/asterisk/secure-asterisk-pbx-part-3/
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:
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:
- Avoid having your PBX’s Internet IP address as one of the domains, and
- 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:
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.
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.
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 locatedhere.
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.