FTP Bounce 227 = 22_ means SmartDefence not so Smart

A quick update to my post about using Python to test FTP. I am indebted to Kevin for his comment on that post saying that he found the issue was related to the FTP Bounce protection in Checkpoint SmartDefence product.

Kevin jogged my memory to say that our Network Security team did find that the change made to the firewall that broke my FTP service was the enabling of the FTP Bounce protection. Having looked up what FTP Bounce is, it does indeed seem like something that should be protected against but clearly there seems to be a problem with the SmartDefence inplementation of it. At present FTP Bounce protection is turned off and my FTP service has been fine since.

I haven’t quite got the bottom of how SmartDefence ends up corrupting ports with a 4th quad of 227 but it appears to related to the fact that 227 is the status message for an FTP server entering passive mode.

This is all way beyond my area of expertise so I will leave it at that, other than to say if you get strange FTP behaviour check out if you are protecting against FTP Bounce with SmartDefence.

Escape from Telnet

Not the title of a 50s sci-fi novel but something I find I need to do at work now and again. Telnet is something of a deprecated method of connectivity because of its inherent lack of security. ( Anything transmitted over a telnet session is transmitted in the clear ). The preferred method of remote connectivity is usually ssh that will encrypt the traffic. However many devices like jet direct print server boxes only support telnet and indeed many of the Unix servers at work don’t have ssh installed. (Sshhh don’t tell the crackers).

So now and again I find I am telnetted (new verb) on to a system and then telnet to a device only for it to hang and I need to escape from the telnet session. Now as standard Ctrl + ] (^]) will get you to the telnet “command prompt” and from here you can type quit to end the hung session. However there is a snag when you have telnetted to one server and then to another server or device. The Ctrl + ] is actually interpreted by the first telnet connection and you end up escaping that one and severing your initial connection not the secondary one.

The reason for this is fairly obvious telnet inspects your keystrokes and passes them through to the remote connection, if it sees the escape sequence then it responds. Now when you telnet from a telnet session that first telnet inspects all your keystrokes before passing them on to the remote connection which is itself running telnet. (See diagram below).

So how do I get the second telnet session to see the Ctrl+] ? Well the trick is to press Ctrl+] to get to the command prompt of the first session and change the escape sequence of that session using the command “set escape” you need to choose a control sequence you won’t type for any other reason say Ctrl+[ or Ctrl+B then hit "enter" to return back to your connection.

At this point you can type Ctrl+] and the first telnet session will see this as a normal character sequence and pass it on to the remote connection (our second telnet session). The second telnet session will then to the escape sequence and give you the command prompt where you can type quit.

So now you are back are the first connection and you can do whatever work you want to do. You just have to remember if you need to escape from this session for some reason use your newly set escape sequence Ctrl+B or whatever.