Tips Server : Portsentry

Portsentry adalah aplikasi yang digunakan untuk mendeteksi dan merespon semua kegiatan yang berhubungan dengan 'port scanning' pada sebuah sistem.

install portsentry

centos
yum install portsentry
ato
rpm -ivh portsentry-1.1-11.fr.i386.rpm

mandriva
urpmi portsentry

dengan konfigurasi default portsentry langsung bisa digunakan. untuk file-file konfigurasi terletak di direktori :

/etc/portsentry/

dengan isi file sbb :

portsentry.blocked.atcp
portsentry.blocked.audp
portsentry.conf
portsentry.history
portsentry.ignore
portsentry.modes

untuk konfigurasi utama, silahkan di edit file /etc/portsentry/portsentry.conf , disini yang diperlu di perhatikan adalah di bagian 'kerjaan' portsentry setelah terjadi ato mendeteksi adanya 'port scanning'. di linux mandriva defaultnya adalah menge-blok usaha 'port scanning' tersebut menggunakan 'iptables', seperti terlihat di file portsentry.conf.

###################
# Dropping Routes:#
###################
# This command is used to drop the route or add the host into
# a local filter table.
#
# The gateway (333.444.555.666) should ideally be a dead host on
# the *local* subnet. On some hosts you can also point this at
# localhost (127.0.0.1) and get the same effect. NOTE THAT
# 333.444.555.66 WILL *NOT* WORK. YOU NEED TO CHANGE IT!!
#
# ALL KILL ROUTE OPTIONS ARE COMMENTED OUT INITIALLY. Make sure you
# uncomment the correct line for your OS. If you OS is not listed
# here and you have a route drop command that works then please
# mail it to me so I can include it. ONLY ONE KILL_ROUTE OPTION
# CAN BE USED AT A TIME SO DON'T UNCOMMENT MULTIPLE LINES.
#
# NOTE: The route commands are the least optimal way of blocking
# and do not provide complete protection against UDP attacks and
# will still generate alarms for both UDP and stealth scans. I
# always recommend you use a packet filter because they are made
# for this purpose.
#

...
# iptables support for Linux
KILL_ROUTE="/sbin/iptables -I INPUT -s $TARGET$ -j DROP"
...

dimana opsi diatas adalah default, dan bisa di ubah untuk menyesuaikan situasi dan kondisi serta kebutuhan.
semisal akan memerintahkan portsentry agar memasukkan usaha ip_orang 'port scanning' ke dalam file /etc/hosts.deny, cukup dengan mengkombinasikan dengan opsi yang ada di bagian tcp wrappers (service). liat contoh :

###############
# TCP Wrappers#
###############
# This text will be dropped into the hosts.deny file for wrappers
# to use. There are two formats for TCP wrappers:
#
# Format One: Old Style - The default when extended host processing
# options are not enabled.
#

KILL_HOSTS_DENY="ALL: $TARGET$"
#hilangkan tanda #

# Format Two: New Style - The format used when extended option
# processing is enabled. You can drop in extended processing
# options, but be sure you escape all '%' symbols with a backslash
# to prevent problems writing out (i.e. \%c \%h )
#
#KILL_HOSTS_DENY="ALL: $TARGET$ : DENY"

dan jika ingin memberikan alert tentang kejadian 'port scanning' tsb, misalnya menggunakan email, bisa langsung menggunakan konfigurasi 'External Command' :

###################
# External Command#
###################
# This is a command that is run when a host connects, it can be whatever
# you want it to be (pager, etc.). This command is executed before the
# route is dropped or after depending on the KILL_RUN_CMD_FIRST option below
#
#
# I NEVER RECOMMEND YOU PUT IN RETALIATORY ACTIONS AGAINST THE HOST SCANNING
# YOU!
...
KILL_RUN_CMD="/bin/mail -s 'Portscan from $TARGET$ on port $PORT$' admin@server.org < /dev/null"

...

mudah bukan mengkonfigurasi portsentry ? :D
dan yang perlu di perhatikan lagi adalah file /etc/portsentry/portsentry.ignore

# Put hosts in here you never want blocked. This includes the IP addresses
# of all local interfaces on the protected host (i.e virtual host, mult-home)
# Keep 127.0.0.1 and 0.0.0.0 to keep people from playing games.
#
# PortSentry can support full netmasks for networks as well. Format is:
#
# /
#
# Example:
#
# 192.168.2.0/24
# 192.168.0.0/16
# 192.168.2.1/32
# Etc.
#
# If you don't supply a netmask it is assumed to be 32 bits.
#
#

beberapa fitur dari portsentry (diambil dari tulisannya pak onno w purbo)

•Mendeteksi adanya Stealth port scan untuk semua platform Unix. Stealth port scan adalah teknik port scan yang tersamar / tersembunyi, biasanya sukar di deteksi oleh sistem operasi.
•PortSentry akan mendeteksi berbagai teknik scan seperti SYN/half-open, FIN, NULL dan X-MAS. Untuk mengetahui lebih jelas tentang berbagai teknik ini ada baiknya untuk membaca-baca manual dari software nmap yang merupakan salah satu software portscan terbaik yang ada.
•PortSentry akan bereaksi terhadap usaha port scan dari lawan dengan cara membolkir penyerang secara real-time dari usaha auto-scanner, probe penyelidik maupun serangan terhadap sistem.
•PortSentry akan melaporkan semua kejanggalan & pelanggaran kepada software daemon syslog lokal maupun remote yang berisi nama sistem, waktu serangan, IP penyerang maupun nomor port TCP atau UDP di mana serangan di lakukan. Jika PortSentry didampingkan dengan LogSentry, dia akan memberikan berita kepada administrator melalui e-mail.
•Fitur cantik dari PortSentry adalah pada saat terdeteksi sebuah scan, sistem anda tiba-tiba menghilang dari hadapan si penyerang. Fitur ini betul-betul membuat penyerang tidak berkutik.
•PortSentry selalu mengingat alamat IP penyerang, jika ada serangan Port Scan yang sifatnya random PortSentry akan bereaksi.

iptables : DNAT target

The DNAT target is used to do Destination Network Address Translation, which means that it is used to rewrite the Destination IP address of a packet. If a packet is matched, and this is the target of the rule, the packet, and all subsequent packets in the same stream will be translated, and then routed on to the correct device, host or network. This target can be extremely useful, for example,when you have a host running your web server inside a LAN, but no real IP to give it that will work on the Internet. You could then tell the firewall to forward all packets going to its own HTTP port, on to the real web server within the LAN. We may also specify a whole range of destination IP addresses, and the DNAT mechanism will choose the destination IP address at random for each stream. Hence, we will be able to deal with a kind of load balancing by doing this.

Note that the DNAT target is only available within the PREROUTING and OUTPUT chains in the nat table, and any of the chains called upon from any of those listed chains. Note that chains containing DNAT targets may not be used from any other chains, such as the POSTROUTING chain.

Table 11-5. DNAT target options

Option	--to-destination
Example	iptables -t nat -A PREROUTING -p tcp -d 15.45.23.67 --dport 80 -j DNAT --to-destination 192.168.1.1-192.168.1.10
Explanation	The --to-destination option tells the DNAT mechanism which Destination IP to set in the IP header, and where to send packets that are matched. The above example would send on all packets destined for IP address 15.45.23.67 to a range of LAN IP's, namely 192.168.1.1 through 10. Note, as described previously, that a single stream will always use the same host, and that each stream will randomly be given an IP address that it will always be Destined for, within that stream. We could also have specified only one IP address, in which case we would always be connected to the same host. Also note that we may add a port or port range to which the traffic would be redirected to. This is done by adding, for example, an :80 statement to the IP addresses to which we want to DNAT the packets. A rule could then look like --to-destination 192.168.1.1:80 for example, or like --to-destination 192.168.1.1:80-100 if we wanted to specify a port range. As you can see, the syntax is pretty much the same for the DNAT target, as for the SNAT target even though they do two totally different things. Do note that port specifications are only valid for rules that specify the TCP or UDP protocols with the --protocol option.

Since DNAT requires quite a lot of work to work properly, I have decided to add a larger explanation on how to work with it. Let's take a brief example on how things would be done normally. We want to publish our website via our Internet connection. We only have one IP address, and the HTTP server is located on our internal network. Our firewall has the external IP address $INET_IP, and our HTTP server has the internal IP address $HTTP_IP and finally the firewall has the internal IP address $LAN_IP. The first thing to do is to add the following simple rule to the PREROUTING chain in the nat table:

iptables -t nat -A PREROUTING --dst $INET_IP -p tcp --dport 80 -j DNAT \
--to-destination $HTTP_IP
   

Now, all packets from the Internet going to port 80 on our firewall are redirected (or DNAT'ed) to our internal HTTP server. If you test this from the Internet, everything should work just perfect. So, what happens if you try connecting from a host on the same local network as the HTTP server? It will simply not work. This is a problem with routing really. We start out by dissecting what happens in a normal case. The external box has IP address $EXT_BOX, to maintain readability.

1. Packet leaves the connecting host going to $INET_IP and source $EXT_BOX.

2. Packet reaches the firewall.

3. Firewall DNAT's the packet and runs the packet through all different chains etcetera.

4. Packet leaves the firewall and travels to the $HTTP_IP.

5. Packet reaches the HTTP server, and the HTTP box replies back through the firewall, if that is the box that the routing database has entered as the gateway for $EXT_BOX. Normally, this would be the default gateway of the HTTP server.

6. Firewall Un-DNAT's the packet again, so the packet looks as if it was replied to from the firewall itself.

7. Reply packet travels as usual back to the client $EXT_BOX.

Now, we will consider what happens if the packet was instead generated by a client on the same network as the HTTP server itself. The client has the IP address $LAN_BOX, while the rest of the machines maintain the same settings.

1. Packet leaves $LAN_BOX to $INET_IP.

2. The packet reaches the firewall.

3. The packet gets DNAT'ed, and all other required actions are taken, however, the packet is not SNAT'ed, so the same source IP address is used on the packet.

4. The packet leaves the firewall and reaches the HTTP server.

5. The HTTP server tries to respond to the packet, and sees in the routing databases that the packet came from a local box on the same network, and hence tries to send the packet directly to the original source IP address (which now becomes the destination IP address).

6. The packet reaches the client, and the client gets confused since the return packet does not come from the host that it sent the original request to. Hence, the client drops the reply packet, and waits for the "real" reply.

The simple solution to this problem is to SNAT all packets entering the firewall and leaving for a host or IP that we know we do DNAT to. For example, consider the above rule. We SNAT the packets entering our firewall that are destined for $HTTP_IP port 80 so that they look as if they came from $LAN_IP. This will force the HTTP server to send the packets back to our firewall, which Un-DNAT's the packets and sends them on to the client. The rule would look something like this:

iptables -t nat -A POSTROUTING -p tcp --dst $HTTP_IP --dport 80 -j SNAT \
--to-source $LAN_IP
   

Remember that the POSTROUTING chain is processed last of the chains, and hence the packet will already be DNAT'ed once it reaches that specific chain. This is the reason that we match the packets based on the internal address.

This last rule will seriously harm your logging, so it is really advisable not to use this method, but the whole example is still a valid one. What will happen is this, packet comes from the Internet, gets SNAT'ed and DNAT'ed, and finally hits the HTTP server (for example). The HTTP server now only sees the request as if it was coming from the firewall, and hence logs all requests from the internet as if they came from the firewall. This can also have even more severe implications. Take an SMTP server on the LAN, that allows requests from the internal network, and you have your firewall set up to forward SMTP traffic to it. You have now effectively created an open relay SMTP server, with horrenduously bad logging! One solution to this problem is to simply make the SNAT rule even more specific in the match part, and to only work on packets that come in from our LAN interface. In other words, add a --src $LAN_IP_RANGE to the whole command as well. This will make the rule only work on streams that come in from the LAN, and hence will not affect the Source IP, so the logs will look correct, except for streams coming from our LAN. You will, in other words, be better off solving these problems by either setting up a separate DNS server for your LAN, or to actually set up a separate DMZ, the latter being preferred if you have the money.

You think this should be enough by now, and it really is, unless considering one final aspect to this whole scenario. What if the firewall itself tries to access the HTTP server, where will it go? As it looks now, it will unfortunately try to get to its own HTTP server, and not the server residing on $HTTP_IP. To get around this, we need to add a DNAT rule in the OUTPUT chain as well. Following the above example, this should look something like the following:

iptables -t nat -A OUTPUT --dst $INET_IP -p tcp --dport 80 -j DNAT \
--to-destination $HTTP_IP
   

Adding this final rule should get everything up and running. All separate networks that do not sit on the same net as the HTTP server will run smoothly, all hosts on the same network as the HTTP server will be able to connect and finally, the firewall will be able to do proper connections as well. Now everything works and no problems should arise.

Everyone should realize that these rules only affect how the packet is DNAT'ed and SNAT'ed properly. In addition to these rules, you may also need extra rules in the filter table (FORWARD chain) to allow the packets to traverse through those chains as well. Don't forget that all packets have already gone through the PREROUTING chain, and should hence have their destination addresses rewritten already by DNAT.

Works under Linux kernel 2.3, 2.4, 2.5 and 2.6.