Pix – Phocean.net

Postfix : TLS not working outside my network

phocean — Tue, 10 Jun 2008 23:37:28 +0000

As I just finished setting TLS and SASL to secure the access to my Postfix server, I realized that it was working only from inside my network.

What I got from my lan :

$ telnet mars 25
Trying 192.168.222.10...
Connected to phocean.net.
Connected to phocean.net.
Escape character is '^]'.
220 phocean.net ESMTP Postfix (Debian/GNU)
220 phocean.net ESMTP Postfix (Debian/GNU)
ehlo phocean.net
ehlo phocean.net
250-phocean.net
250-phocean.net
250-PIPELINING
250-SIZE 200000000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH NTLM DIGEST-MD5 CRAM-MD5
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

I shows well that the TLS handshake is initiated.

But from this outside, I just got this weired thing :

$ telnet phocean.net 25

$ telnet phocean.net 25
Trying 81.64.194.119...
Connected to phocean.net.
Connected to phocean.net.
Escape character is '^]'.
220 **********************************************
ehlo phocean.net
ehlo phocean.net
502 5.5.2 Error: command not recognized

Of course, the firewall, a Cisco Pix one, was properly set to redirect port 25 UDP/TCP to my server.

However, I soon focused my effort on this equipment. I considered a while that the cause could be some filtering from my provider, but most probably, the problem came from the Pix.

That was not difficult to figure out : it had some protocol inspector activated for SMTP :

$ sh ru
[...]
fixup protocol smtp 25
[...]

Just after :

> no fixup protocol smtp 25

… it started to work perfectly well !!!

The engine for the SMTP protocol could not recognize the TLS handshake, considered that the SMTP session as not valid and therefore blocked it !

I can deactivate it without any fear as my Postfix server is already pretty well secured, or at least configured to reject any weired SMTP dialog.

How to connect to a Cisco device using the serial port on Linux

phocean — Tue, 13 Nov 2007 11:41:35 +0000

Using the serial port is still necessary to manage some devices, when it is reseted to factory defaults. It could be also a security choice…

Nowadays many computers – and especially laptops don’t have anymore a built-in serial port. Not a problem, there are many cheap serial-usb converters like this.

As an alternative to the Hyperterminal of Microsoft, there is Minicom on Linux.

It is very easy to install and configure :

$ apt-get install minicom lrzsz

Before going further, you need to know what is the corresponding Linux device for the port where you plugged the router. As I used an usb adapter, my device was /dev/ttyUSB0. Otherwise, it will probably be one of the /dev/ttyS* devices.
Checking the dmesg output while you plug the device will give you the right device to use.

Now start minicom this way to edit the configuration :

$ minicom -s

In the menu, select Serial Port Configuration and :

press A and update the serial port path with the one you found in dmesg
press E and then C to change the speed to 9600
press F to switch off the hardware flow control
select Save the configuration as… and name it as, let’s say, “cisco”

You should be able to connect right now. Next time, just start Minicom like this :

$ minicom cisco

That’s it !

FTP configuration issues

phocean — Fri, 02 Nov 2007 16:10:28 +0000

I found that it was a real mess to set up a FTP server in a DMZ, behind a firewall Cisco Asa (501 model with IOS version 7.0).

The FTP server is on the DMZ area, and therefore I natted a public IP to the private IP in the DMZ subnet of this server.

static (dmz,outside)   netmask 255.255.255.255

Doing so, I expect that my FTP server (like Vsftpd on Linux) to be reachable within its public IP, from the Asa external interface.

Choosing a FTP transfer mode

Before going further, let’s recall the two modes in which the FTP protocol can work :

active mode : this is the historical mode, but should be considered obsolete now because of the numerous issues it contains. In this mode, after the client initiate the communication on the port 21 (command chanel), the server initiate the data transfert chanel from its port 20 toward a port specified by the client. It causes two big problems :
- the client must configure its firewaling to allow incomming traffic on this port. In the real life, this is most likely to be like allowing the 1024-65535 range port for incoming traffic. Not really secure, isn’t it ?
- if the client is behind a NAT, it won’t work ! As the server initiate the connection, the router does not have any entry for the flow in its NAT table. It will just drop the connexion.
passive mode : the difference here is that the server chooses on what port the data transfert will be operated. The port is given to the client when this one initiate the communication. Actually, the server never initiate any connexion, so the name “passive”. The only thing to do on the server side is to set the right firewall rule to allow the server ports. The client then initiate the transfert on the given port. It solves the client side firewalling problem, because the firewall will see it as outbound traffic. With correct rules, especially if the firewall is statefull, this is an easy thing.

Configuring the passive mode on the server

So, is the passive mode the end of all problems ?

Not yet…

By default, the FTP server will be listening on its netword interface and answer to the FTP requests with its private IP, if, like probably in many case, the FTP server is located on a DMZ network.

In such a case, the client gets a private IP to connect with… and can never reach the server properly.

To workaround this problem, most of FTP servers can be configured to answer with there public IP.

With VSFTP, this is a line like :

pasv_address = $public_IP

There another two issues for that :

the server won’t be reachable anymore within its private IP, for instance from the local subnet
the Cisco Asa firewall drops the traffic

Cisco Asa issue

The Asa log file shows :

FTP port command different address: $IP_addr ($IP_addr2) to $IP_addr_3 on interface int_name

The explanation from the cisco website :
A client issued an FTP port command and supplied an address other than the address used in the connection. This error message is indicative

of an attempt to avert the site’s security policy. For example, one might attempt to hijack an FTP session by changing the packet on the way, and putting

different source information instead of the correct source information. The PIX Firewall drops the packet, terminates the connection, and logs the event.

In the error message displayed, the IP address in parentheses is the address from the PORT command.
Well, as there is nothing to do against this behaviour, I won’t use the pasv_address option.

Private IP issue

So, for now we stick with a server sending its private IP address in any case. That solves any issue in the local subnet, but is it possible to do anything for external clients which needs to get a public IP ?

Actually, and this is really not a satisfying answer, it depends on the client. Most of the FTP client must have the some options to workaround this issue, but not all.

Let’s check how it is with a few FTP clients.

Basic FTP command line client (Linux)

$ ftp X.X.X.X
ftp> dir
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
-rw-rw-r--    1 102      1001           21 Aug 16 10:53 test
226 Directory send OK.

Humm… it is working, but it shouldn’t as my server is configured for passive mode.

Let’s see what is going on with Wireshark… Two packets are interesting :

28    35    192.168.1.2    X.X.X.X   FTP    Request: PORT 192,168,1,2,173,87
29    36    X.X.X.X    192.168.1.2    FTP    Response: 200 PORT command successful. Consider using PASV.

From the client, we have a PORT request, which shows that our client is connecting in active mode.

Surprise, the server replies ! And says successful, even if the IP given is a private one. That should not work and, if any response, not go out of the external firewall…
Note : (192,168,1,2,173,87) is the FTP way to manage IPs and port. The IP is simply given by the four first numbers : 192,168,1,2 <=> 192.168.1.2.
The 2 last ones gives you the port number with this formula : 173,87 => 173 x 256 + 87 = port n°44375
Anyway, let’s try the passive mode :

ftp> passive on
Passive mode on.
ftp> dir
227 Entering Passive Mode (10,1,1,1,15,195)
receive aborted
waiting for remote to finish abort

We tried to switch to passive mode. The server gaves its IP, but its private one (192.168.10.1). The client trying to reach this address can’t and falls in timeout (I killed it, no more patience :) ) .

Now, let’s summarize.
Using the ftp basic client, we can’t go through in passive mode. We get a private IP and we have no workaround.
The active mode works, but it is thanks to the behaviour of VSFTP.

A look on the man page of VSFTP gives some answers : the

port_enable

directive, set to YES by default, allow the PORT command from the client even in passive mode. So, we could add in the vsftd.conf configuration file :

port_enable=NO

After that the server will answer

550 Permission denied

when a PORT command is issued. At the end, I won’t set this, because such a behaviour is actually nice.

I still wonder how VSFTP could get the public IP when the PORT command send the private IP. I guess, and it would be a smart behaviour, that the program checks the underlying protocol layers and takes the right IP from the IP header… I will have it confirmed and update this post.

Gftp

This Gnome FTP client behave like the ftp command line client in passive mode : it falls into timeout.

It doesn’t try by default to fail over active mode.

You can configure either active mode or ignoring the passive command IP in the options :

Filezilla

Filezilla has the most interesting behaviour. When the standard passive mode fails, it is able to fail over by using active mode or using the public IP seen from the server.

This can be configured in the connexion options :

When Filezilla uses the public IP address instead of the transmitted one :

 PASV
227 Entering Passive Mode (10,1,1,1,15,209)
LIST
150 Here comes the directory listing.
226 Directory send OK.

When it is configured to switch to active mode :

PASV
227 Entering Passive Mode (10,1,1,1,15,179)
PORT 192,168,1,2,130,1
200 PORT command successful. Consider using PASV.
LIST
150 Here comes the directory listing.
226 Directory send OK.

Conclusion

I could not reach the point where I can be 100% sure that it will work in all configurations. The best I could do is a series of small fixes to get the best compromise as possible.

I guess that using VSFTD as a server and recomanding a good client as Filezilla will work pretty well – and that won’t be a big deal to get to such a configuration.

If anyone has some better ideas, or see I fooled somewhere before my conclusion, please let me know.

But anyway, really, FTP sucks. It is anoying that the use of this protocol is still required by some companies.

SSH timout

phocean — Sat, 21 Apr 2007 18:18:00 +0000

After a fresh set up of your network, don’t be surprised that your ssh connections are slow.

Depending on the systems and equipment you use, you might encounter some timeout that make any login impossible.

I got such timeouts with an OpenBSD machine behind a Pix firewall. With Linux machines, it was very slow but worked.

This issue is related to the reverse DNS check that SSH makes by default during the login process. This is in order to improve the security. Howerver, this is not so secure as a DNS cache can also be spoofed.
Considering this, you can disable this check with not much worry with the right option in your /etc/sshd_config file :

UseDNS no

Of course, the best solution will be that you set up a full DNS infrastructure as soon as possible.