AToL: Defending Network Services

14.6.2012 10:01 | Přečteno: 898× | Linux

Autor: Jan Vojtěch
Nasledovný príspevok je študentskou prácou, ktorá vznikla v rámci predmetu Advanced Topics of Linux Administration. Predmet je vypisovaný na Fakulte informatiky MU v spolupráci so spoločnosťou Red Hat Czech. Vyučovacím jazykom je angličtina a preto je v nej aj nasledovný príspevok, študent nemá právo výberu iného jazyka. Komentáre k obsahu príspevku sú vítané v ľubovoľnom zrozumiteľnom jazyku.

Every system administrator knows it – you have got a Linux server connected to the internet and this box runs several services. There are some users who access these services, but usually there is also a group of attackers who try to break your services or gain access to the box. These attacks spoil log files by large amount of "access denied" messages and increase load of the services. This article discusses some possibilities how to defend your Linux machine against these attackers.

Ways of defence

Generally there are two types of defence – preventive arrangements and active defence:

Preventive steps

• Turn off unnecessary services.
• Run services on other (not well-known) ports.
• Disable password authentication for SSH.
• Allow to use the services from certain IP addresses only.
• Make the services available only via local network and use VPN.

Active defence

• Check the logs regularly and keep updating your iptables.
• Use a specialised blacklisting tool.
• Use port knocking.

The most of the preventive steps decreases risk of attack about 90 %, but on the other hand these arrangements usually cannot be used for public services (such as WWW or FTP) because they either hide the service (using not well-known port) or limit group of users with access to the service. That's why the most of preventive steps above we can only use for private services with limited number of users.

For public services (accessible all around the world) we need something stronger – we need to differentiate between good and bad users and cut off the bad ones as soon as possible. Each user is identified by his IP address, but it may change during the time and also we have to take NAT (Network Address Translation) into account. That means we cannot only add new IP addresses on the blacklist. We also have to delete the old ones because they might have belonged to some good user.

Available blacklisting tools

There is several blacklisting tools which differ in some minor features, but the main principal of work is always the same – they parse log files of guarded services and if someone is doing something nasty, he is banned. Banning of the user is usually done using hosts.deny file or using iptables.

Probably the oldest tool is called DenyHOSTS. It supports only SSH protection and nowadays it is unmaintained and quite obsolete.

Also there is IPQ BDB Filter. It is quite interesting project which focuses on large networks. It uses netfilter for blacklisting and Berkeley DB for blacklist storage. It offers high performance (written in C) and flexibility due of modular architecture. Unluckily it is still in development, documentation is not too good and especially for inexperienced user it would be quite difficult to set it up. IPQ BDB Filter is surely not an out-of-the-box solution, but advanced users may appreciate it.

The most common used tools are fail2ban and SSHGuard. SSHGuard is fast, written in C and can be connected directly to syslog. It is ported to many UNIX based operating systems. On the other hand there is lack of configuration options and advanced administrators may say that it is a black box. This article focuses on fail2ban, but I think, SSHGuard is also a good option.

Fail2ban

Fail2ban is quite simple and easy-to-use blacklisting tool. There are some highlights:

• Supports various services, it is easy to add a new one.
• Multiple firewall backends (iptables, hosts.deny).
• Automatically unbans expired hosts.
• Written in Python.

How it works

• Filter – regular expression to be searched in the log file (filter.d directory).
• Action – commands to be triggered when filter finds something (action.d directory).
• Jail – set of one filter and one or more actions (jail.conf). Jail has got the following options:
  • enabled – allows you to activate or deactivate the jail.
  • filter – name of jail filter, each match increments the jail counter.
  • logpath – path to the log file provided to the filter.
  • maxretry – minimal value of jail counter to trigger the action.
  • findtime – when filter finds nothing, the counter is reset to zero after findtime seconds.
  • bantime – number of seconds to ban the host for.

If you want to protect a service, you must create a jail for it. Jail specifies what log file to search in, what to search and what to do when there is a rule violation. Fail2ban's default filters and actions are sufficient for the most of users, so usually the only thing you have to do after the installation is the jail creation.

Installation and configuration

• Install the package fail2ban if it available in your distribution. If not, you can download it from www.fail2ban.org.
• Configuration is stored in /etc/fail2ban
.
• Edit the /etc/fail2ban/jail.conf file and enable jails you are interested in.
• Start the fail2ban service using /etc/init.d/fail2ban start command and let it start automatically using chkconfig or similar command.
• Try to make several invalid logins to your service and wait for your ban, it should come almost immediately.

Troubleshooting

If you did not get ban, you can try the following things:

• Run the fail2ban-client -d command. It will dump the current configuration and you can check whether the fail2ban server actually uses the jails you defined.
• Run fail2ban-regex logfile regex command. Both logfile and regex you can find in dumped configuration. The command will parse the log file and print number of matches. If something goes wrong, you will probably find it there.

Dealing with localized timestamps

Fail2ban is nothing more than a log parser. Besides the regular expressions it also has to parse the timestamps. Although it supports several formats of timestamp, fail2ban cannot deal with localized month names correctly. Here you have two options:

• Set locales for your service to English – export LC_TIME="en_US.UTF-8" – in its init script.
• Fix the fail2ban to support your localized month names:
  • Edit the /usr/share/fail2ban/server/datetemplate.py file.
  • Near the line 90 there is a definition of month names – add localized strings used in your system – eg. TABLE["Jun"] = [u"čen"] etc. Save the file.
  • Recompile the file again – python -m compileall /usr/share/fail2ban/server/datetemplate.py.
  • Restart fail2ban service and you are done.

Knockd – porter who opens only for you

Imagine you have a small home router running Linux. This box is maintained via SSH from private network, but sometimes it would be very handy to access it from outside. If you permitted port 22 on WAN interface, you would become a target of script kiddies very quickly. In addition this service would be almost never used. It would be nice to let the port closed and open it only when we need to access the machine. And this is exactly what konckd does.

Knockd monitors incoming network connections and their target ports. If it detects a "magic sequence", like ports 7000/TCP, 8000/TCP, 9000/TCP accessed in sequence within 30 seconds, it triggers a specific action, for example it opens port 22 for 5 minutes.

Installation and configuration

• Install the package knockd. It it is not available in your distribution, get it here: http://www.zeroflux.org/projects/knock.
• On Debian-based distributions there is a configuration file /etc/default/knockd where you can enable the service and specify command line options for knockd. In RedHat based distributions this will be probably different.
• The main configuration file is /etc/knockd.conf. Its structure is very simple:
  [openSSH] sequence = 7000,8000,9000 seq_timeout = 30 command = /sbin/iptables -A Knocking -s %IP% -p tcp --dport 22 -j ACCEPT tcpflags = syn cmd_timeout = 15 stop_command= /sbin/iptables -D Knocking -s %IP% -p tcp --dport 22 -j ACCEPT The section above defines magic sequence of ports 7000, 8000, 9000 within 30 seconds. When detected, executes the command and after 15 seconds executes the stop_command.
• Create as many sections as you need, then save the file and start service using /etc/init.d/knockd start.

How to knock

Knockd comes with a small utility called knock. Its first argument is a hostname to knock, the rest of them are port numbers to knock (the magic sequence). When you want to knock the SSH service from the example above, you would use the following command: knock myverysecretrouter.com 7000 8000 9000.

Of course, it may happen very easily that you don't have the knocking utility with you. In this case you can use almost any application generating TCP requests (or UDP requests if your knockd waits for them). It can be a telnet application or your web browser (you enter address http://myverysecretrouter.com:7000, then http://myverysecretrouter.com:8000 etc.). There are only two limitations:

• The application must have configurable target port and you must be able to change it quickly enough. Otherwise you exceed the seq_timeout and the sequence won't be accepted.
• The application must generate only one request at a time. For example it is not possible to knock using Google Chrome because it does not receive any replay for knocking (it is right) and that's why it sends the request again to ensure the server is really dead. Of course this breaks the sequence. On the other hand Mozilla Firefox does not do that and therefore it is suitable for knocking.

Troubleshooting

If knockd does not open ports for you, stop the service and run it in the foreground in verbose mode: knockd -D -i eth0 -v. It should print out what sequence it really received and why it was not accepted.

If the magic sequence is recognized correctly and the port is not opened anyway, check your iptables command. If you use iptables -A command, remember that the rule is added at the end of your firewall chain definition. Is not your one to last rule "reject all other packets"? It is a good idea to create an empty chain for knockd, add this chain on the right place during firewall initialization and then let knockd modify only its own chain.

Logwatch – keeps your server in check

This simple application written in Perl monitors log files stored on the machine and creates a summary which is usually sent by e-mail to the administrator. Of course, this does not protect your services against some misuse, but it is a useful security supplement. Logwatch supports all common services and it is quite easy to add a new one. Parsed time range is restricted to one day or the whole log file, for example, it is not possible to generate one week log summary. Logwatch is not a daemon, it is only a small script run by CRON, so for the most of time it does not consume any CPU time.

• Install the logwatch package, it is available in all main distributions.
• Default configuration is stored in /usr/share/logwatch/default.conf (note it is a directory). If you want to change an option, you should copy the affected file to /etc/logwatch. This directory is initially almost empty and it is intended for custom configuration which will not be overwritten by package updates. Of course, settings in /etc are preferred to defaults.
• The overall configuration is located in logwatch.conf. The most important options include:
  • MailTo – local user account or a full email address where to send the log files.
  • MailFrom – sender of the emails.
  • Range – what time period should be processed, valid options are Today, Yesterday and All.
  • Detail – verbosity of the log summary, 0 – 10.
• Logwatch works immediately after the installation, default user who receives the emails is root.

Conclusion

I have mentioned some useful tips how to enhance security of network services. Please keep in the mind that the best protection is to turn off unnecessary services. If it is not possible, you can apply some of tips written above. Also please do not consider port knocking to be a security mechanism. It is only a security supplement, which does not replace standard methods of authentication.

Thank you for reading, I hope this article will help you to protect your network services better.

       

Komentáře

[Käyttäjä 11133]

Jakmile jsem došel k

Run services on other (not well-known) ports.

jsem se rozhodl že se zbytkem článku nemá ani smysl ztrácet čas. :)

[Bystroushaak]

Třeba u ssh je to docela dobrá praxe, kterou se člověk zbaví armády bruteforce botů a navíc mu (např. v případě 443) umožňuje projít skrz firewally různě v knihovnách a tak.

[AsciiWolf]

+1

(Každopádně i tak je to stále tak trochu "Security through obscurity". )

[Jendа]

(Každopádně i tak je to stále tak trochu "Security through obscurity". )

Jenže on to nezavedl kvůli security.