Tag: port-forwarding

Host Entry on Proxy

Symantec Community Leave a comment
I need a solution

Dear Team,

Whether it is possible to create host entry on proxy for particular Public IP instaed of forwarding ?

0

1529330742

Related:

7021930: Best Practices for Configuring Reflection Secure Shell (SSH)

Novell Leave a comment

Note the following:

  • Creating a secure network environment is a complex task involving many custom elements designed to fit your individual network environment and security needs. Neither the security matrix nor the additional security configuration suggestions made in this note should be considered to include all necessary security options for your environment. This information is designed to provide Reflection customers with a framework on which to start building individual security environments.
  • The Secure Shell configuration described in this note applies to all Reflection terminal sessions, Reflection FTP Client sessions, and Reflection X 14.x sessions. Reflection X Advantage Secure Shell settings are saved to the Reflection X Advantage database, not to the config file described in this note; and the user interface for making changes is different. Refer to the Reflection X Advantage product help for details.

For security update information, select your product from http://support.attachmate.com/security/.

Overview of Reflection Secure Shell

Reflection Secure Shell provides the following functionality:

  • The ability to establish secure connections to both SSH1 and SSH2 protocol servers using EXTRA! X-treme, INFOConnect, Reflection 2014, Reflection 2011, Reflection X, Reflection for UNIX and OpenVMS, Reflection for ReGIS Graphics, Reflection for HP, and Reflection FTP Client applications (see the Applies To section of this technical note).
  • Support for standard SSH features such as port forwarding (including X11), data stream compression and encryption, authentication using a password, public key or Kerberos ticket, and logging.
  • The ability to create RSA1 (SSH1 only), RSA, and DSA user keys with lengths between 512 and 8192 bits. (This feature is available both as an MS-DOS utility and through the client user interface.)
  • Support for secure file transfer, both within the Reflection FTP Client using SFTP and with standalone SCP and SFTP Windows command line utilities.

Determining How to Configure Reflection SSH for Secure Connections

The security matrix presented below lists Reflection Secure Shell parameters and recommends how each parameter should be configured to provide minimum, medium, or high security for your PC-to-host connection.

Note the following:

  • The minimum, medium, and high classifications used in this matrix do not represent clearly defined industry terms; rather, they are subjective classifications. The intent of creating such categories is to provide a starting place for administrators who are researching PC-to-host security options.
  • The matrix contains a subset of available Secure Shell security parameters, which apply to common network configurations. Additional options are available, and may be necessary in your specific network environment.
  • The recommendation for some settings is “do not use.” These are settings that have no impact or a negative impact on the security of your host to PC connection. These settings often apply only to SSH1, which has been deprecated.

Security Matrix

Secure Shell Parameter

Minimum Security

Medium Security

High Security

Dialog Box [*a]

ChallengeResponseAuthentication
no

(this parameter applies only to SSH1)
no

(this parameter applies only to SSH1)
no

(this parameter applies only to SSH1)

Cipher
do not use

(this parameter applies only to SSH1)
do not use

(this parameter applies only to SSH1)
do not use

(this parameter applies only to SSH1)
X
Ciphers [*b]
aes128-ctr, aes128-cbc, 3des-cbc, blowfish-cbc, aes192-cbc, aes256-cbc
aes128-ctr, aes128-cbc, aes192-ctr, aes192-cbc, aes256-ctr, aes256-cbc, 3des-cbc, blowfish-cbc
aes256-ctr, aes192-ctr, aes128-ctr
X
ClearAllForwardings
yes
yes
yes

CompressionLevel
no (default)
no (default)
no (default)
X
ConnectionReuse
yes (default for GUI applications)
no
no
X
DynamicForward
do not use
do not use
do not use

FIPSMode
no (default)
yes
yes
X
GatewayPorts
no (default)
no
no

GssapiAuthentication [*d]
no (default)
yes
yes
X
GssapiDelegateCredentials [*c]
no (default)
yes
no
X
GssapiUseSSPI [*e]
no (default)
yes
yes
X
HostKeyAlgorithms [*c]
x509v3-rsa2048-sha256, x509v3-sign-rsa, x509v3-sign-dss, ssh-rsa-sha2-256@attachmate.com, ssh-rsa,ssh-dss

(default)
x509v3-rsa2048-sha256, x509v3-sign-rsa, x509v3-sign-dss, ssh-rsa-sha2-256@attachmate.com
x509v3-rsa2048-sha256, x509v3-sign-rsa, x509v3-sign-dss, ssh-rsa-sha2-256@attachmate.com

KbdInteractiveAuthentication
yes (default)
no
no
X
KerberosAuthentication
do not use

(this parameter applies only to SSH1)
do not use

(this parameter applies only to SSH1)
do not use

(this parameter applies only to SSH1)
X
KerberosTgtPassing
do not use

(this parameter applies only to SSH1)
do not use

(this parameter applies only to SSH1)
do not use

(this parameter applies only to SSH1)
X
KexAlgorithms [*c]
diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha1, diffie-hellman-group14-sha1, diffie-hellman-group14-sha256 (default)
diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha1, diffie-hellman-group14-sha1, diffie-hellman-group14-sha256, gss-group1-sha1-*
diffie-hellman-group14-sha256, diffie-hellman-group14-sha1, gss-group1-sha1-*

Macs [*c]
hmac-sha256, hmac-sha2-256, hmac-sha1, hmac-md5, hmac-ripemd160, hmac-sha1-96, hmac-md5-96, hmac-sha512, hmac-sha2-512 (default)
hmac-sha256, hmac-sha2-256, hmac-sha1, hmac-sha512, hmac-sha2-512


 hmac-sha256, hmac-sha2-256, hmac-sha512, hmac-sha2-512
PasswordAuthentication
yes (default)
no
no
X
PreferredAuthentications
include all methods except: none
include all methods except:

password, none
include only: publickey, gssapi-with-mic
X
Protocol
2
2
2
X
PubkeyAuthentication
yes (default)
yes (default)
yes (default)
X
RSAAuthentication
no

(this parameter applies only to SSH1)
no

(this parameter applies only to SSH1)
No

(this parameter applies only to SSH1)
X
StrictHostKeyCheck

ing
ask (default)
ask (default)
yes
X

[*a] In the Dialog Box column, an “X” denotes that the parameter can be configured from either the Reflection interface or by editing the “My DocumentsAttachmateReflection.sshconfig” file. Parameters that are not marked with an “X” can be configured only from the config file. For more details, see the following sections.

[*b] The AES _ctr mode encryption algorithms are available in Reflection version 14.1, Reflection 2011, Reflection 2014, and EXTRA! 9.2 or higher.

[*c] The hmac_sha2 Macs, sha256 host key digital signature and sha256 key exchange algorithms are available in Reflection 14.1 SP3, EXTRA 9.3, Reflection 2011 R3 or higher, and Reflection 2014.

[*d] GSSAPI authentication requires that a Kerberos Key Distribution Center be set up and configured.

[*e] GssapiUseSSPI authentication requires that a Microsoft Windows Domain be set up and all systems be joined to the domain.

Configuring Reflection Secure Shell Parameters

Reflection Secure Shell security parameters can be configured by manually editing the “My Documents/Attachmate/Reflection/.ssh/config” file, or through the Reflection interface. When selecting which configuration method best suits your needs, consider the following:

  • Both methods save Reflection Secure Shell settings to the same file, “My DocumentsAttachmateReflection.sshconfig.”
  • Not all Reflection Secure Shell parameters are available through the Reflection interface.
  • Parameters configured through the Reflection interface apply only to a single host connection, not to all host connections, unless you use an SSH config scheme. (See the Reflection Secure Shell help topic, Config Schemes.)
  • Manually editing the config file allows you to configure parameters that apply to single host connections or multiple host connections (using wildcards).
  • Alternately, if you already have a config file on your host that is properly configured for security in your environment, you can use that file by copying it to each PC.

Using the Config File

To set the config file for basic minimum, medium, or high security, copy and paste the appropriate section below into your “My DocumentsAttachmateReflection.sshconfig” file.

Note the following:

  • The config file has host-specific sections, each containing parameters that apply to the specified host or group of hosts. For example:
Host Bluebell

Protocol 1

PasswordAuthentication yes

Host Redrose

Protocol 2

CompressionLevel 6

  • You can specify security parameters for connections to individual hosts or use the wildcard characters, “*” or “?”, to specify a group of hosts.

For example, in the sample below the Protocol and PasswordAuthentication parameters would apply to host Bluebell.flowers.com, and the CompressionLevel and LogLevel parameters would apply to all hosts in the domain, *.mycompany.

Host Bluebell.flowers.com

Protocol 1

PasswordAuthentication yes

Host Greenglass.mycompany.com

Protocol 2

LogLevel QUIET

Host *.mycompany

CompressionLevel 6

LogLevel INFO

  • A Reflection connection will use the first occurrence of any matching Host string (including wildcard characters). Any subsequent matches will be ignored.

If multiple “Host” sections apply to the host a user is connecting to (as with Host Greenglass in the example above), the first parameter in the first applicable Host section in the file is used. Therefore, if using wildcards to specify a group of hosts, it is helpful to place more specific host entries at the beginning of the file, and wildcard entries at the end of the file – unless you want the setting to override that specific keyword for all matching hosts.

Minimum

Note that only keywords containing non-default settings are included:

Ciphers aes128-ctr,aes128-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256

ClearAllForwardings yes

Protocol 2

RSAAuthentication no

Medium

Note that only keywords containing non-default settings are included:

ChallengeResponseAuthentication no

Ciphers aes128-ctr,aes128-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc,3des-cbc,blowfish-cbc

ClearAllForwardings yes

KbdInteractiveAuthentication no

Macs hmac-sha256,hmac-sha2-256,hmac-sha1,hmac-sha512,hmac-sha2-512

Protocol 2

PasswordAuthentication no

PreferredAuthentications external-keyx,gssapi,publickey

RSAAuthentication no

GssapiAuthentication yes


High

Note that only keywords containing non-default settings are included:

ChallengeResponseAuthentication no

ClearAllForwardings yes

Ciphers aes128-ctr,aes192-ctr,aes256-ctr

Macs hmac-sha256,hmac-sha2-256,hmac-sha512,hmac-sha2-512

KbdInteractiveAuthentication no

PasswordAuthentication no

PreferredAuthentications gssapi

PubkeyAuthentication no

RSAAuthentication no

StrictHostKeyChecking yes

GssapiAuthentication yes

Using the Reflection Interface

Some Secure Shell settings can be configured through the Reflection interface. Settings configured from the Reflection interface are saved per connection and apply only to single host connections.

Note: To configure global Secure Shell settings for connections, use the config file (see Using the Config File), or create an SSH config scheme from within the user interface.

To configure Secure Shell settings using the Reflection interface, follow the steps below:

  1. Start the Reflection product.
  2. Using the procedures below for your Reflection product, open the Reflection Secure Shell Settings dialog box.
View Full Size

Figure 1 - Reflection Secure Shell Settings Dialog Box, Encryption Tab
Figure 1 - Reflection Secure Shell Settings Dialog Box, Encryption Tab

For Reflection 2011 and Reflection 2014:

    1. Create a VT terminal session.
    2. In the VT Document Settings dialog box:

- Select Secure Shell

- Enter a host name

- Select Configure additional settings

- Click OK

    1. In the Settings for VT dialog box, click Set Up Connection Security.
    2. Proceed with step 3.

For Reflection for UNIX and OpenVMS and Reflection for HP with NS/VT:

    1. Click Connection > Connection Setup.
    2. Under Connect using, select Network and Secure Shell.
    3. Enter a host name and click Security. Proceed with step 3.

For Reflection X:

    1. In the Reflection X Manager, expand the Client Templates and Client Startup trees, and then select your host type.
    2. Change the connection Method to Secure Shell and enter your Host name and User name.
    3. Click Advanced and proceed with step 3.

For Reflection FTP Client:

    1. In the Connect to FTP Site dialog box, select a host to connect to and click Properties.
    2. Click Security, and then click the Secure Shell tab.
    3. Select the Use Reflection Secure Shell check box, and then click Configure. Proceed with step 3.
  1. The table below shows each of the Secure Shell parameters that can be configured through the Reflection interface, and matches each parameter to the equivalent configuration in the Reflection interface. Use this table, combined with the Security Matrix, to configure Reflection to meet your security needs.
    Secure Shell Parameter

    		Configured Using…

    Cipher
    		Encryption tab. View SSH protocol 1.

    Note: Cipher settings apply only to SSH1, which has been deprecated. Using SSH2 is highly recommended.
    Ciphers
    		Encryption tab. Under SSH protocol 2, remove any SSH protocol 2 ciphers you do not wish to use and order the remaining protocols by preference.
    CompressionLevel
    		General tab. Select or clear Enable compression.

    Note: The compression level slider control applies only to SSH protocol 1.
    GssapiAuthentication
    		General tab. Under User Authentication, select or clear GSSAPI/Kerberos.
    PasswordAuthentication
    		General tab. Under User Authentication, select or clear Password.
    Protocol
    		General tab. On the Protocol drop-down list, select a protocol.
    PubkeyAuthentication
    		User Keys tab. Click the Generate Key button. Select your options (for example, RSA or DSA for Key Type) and click Create.

    General tab. Under User Authentication, select or clear     Public Key.

    Note the following:

    If PubkeyAuthentication is enabled, you must also copy the public key from "My DocumentsAttachmateReflection.sshid_rsa.pub" or "My DocumentsAttachmateReflection.sshid_dsa.pub" to the host. For details, see the Reflection online help.
    RSAAuthentication
    		User Keys tab. Click the Generate Key button. From the drop-down Key Type list, select RSA1. Select other options and click Create.

    Note the following:

    If RSAAuthentication is enabled, you must also copy the public key from "My DocumentsAttachmateReflection.sshidentity.pub" to the host. For details, see the Reflection online help.

    RSAAuthentication applies only to SSH1, which has been deprecated. Using SSH2 is highly recommended.

Deploying Custom Secure Shell Settings

System administrators can simplify user setup by deploying system-wide (global) Secure Shell settings to client computers.

  1. Launch the product you are using for your secure connections and configure your Secure Shell settings as described in Configuring Reflection Secure Shell Parameters.

When you close the Reflection Secure Shell Settings dialog box, non-default configuration information is saved automatically to <My Documents>AttachmateReflection.sshconfig.

When you make connections, known host information is saved to <My Documents>AttachmateReflection.sshknown_hosts.

  1. Create the following copies of your Secure Shell files. These are the file names used for configuring system-wide/global settings.
    • Create a copy of config called ssh_config.
    • Create a copy of known_hosts called ssh_known_hosts.
  1. Deploy ssh_config and ssh_known_hosts to Reflection application data folder.

The procedure depends on which product you are using.

In Reflection 14.x

Go to Help > Help Topics and see “Deploying custom Secure Shell settings in Reflection 14.0.x.”

For general deployment information, see the System Administrator Guide at http://docs.attachmate.com/reflection/14.1/r14_1sag.pdf.

In Reflection for Secure IT 7.x

Go to Help > Help Topics and see the topic “Deploying Secure Shell Settings in Reflection for Secure IT 7.0.x”.

For general deployment information, see the User Guide at http://support.attachmate.com/manuals/rsit_win_client.html.

In Reflection 2014

Click Help > Contents > Secure Connections > Secure Shell Configurations Files, and see “Deploy Secure Shell Settings with a Companion Installer.”

For general deployment information, see “Installation and Deployment Guide” at http://docs.attachmate.com/reflection/2014/r1/deploy/deploymentguide.pdf.

In Reflection 2011

Click Help > Contents > Secure Connections > Secure Shell Configurations Files, and see “Deploy Secure Shell Settings with a Companion Installer.”

For general deployment information, see “Installation and Deployment Guide” at http://docs.attachmate.com/reflection/2011/r3/deploy/deploymentguide.pdf.

The Deployment Guide for Reflection X 2011 and Reflection Suite for X 2011 is available at http://support.attachmate.com/manuals/rx_rsx_2011.html.

In EXTRA! X-treme

See “Customizing the EXTRA! X-treme Installation" in Help: http://docs.attachmate.com/extra/x-treme/9.2/help/en/index.htm.

In INFOConnect Enterprise Edition

See “Appendix C: Attachmate Customization Tool Reference” in the Product Guide at http://docs.attachmate.com/infoconnect/ented/9.1sp1/pdf/product_guide_infoconnect.pdf.

Additional Configuration Points to Consider

Review these points to help determine how strictly you want to control user configuration functionality.

  • The ssh_config and ssh_known_hosts files in the Shared Application Data folder should have restricted write access to prevent unauthorized changes to the configuration settings or keys. (These files are typically located in Documents and SettingsAll UsersApplication DataAttachmateReflectionssh)
  • The configuration and key information from these files will be read first, and if a valid host match is found, the Reflection Secure Shell client will not check the user's config or known_hosts files; however, this does not preclude a user from manually creating these files in their My DocumentsAttachmateReflection.ssh folder. You may want to restrict access to the .ssh folder as well.
  • If you want to ensure that users do not connect to any unauthorized hosts, set the StrictHostKeyChecking parameter in the ssh_config file to "yes" at the top of the file.

Additional Suggestions

Beyond configuring Reflection Secure Shell, there are many other things administrators can do to help secure a PC-to-host connection. The following is a list of additional steps to consider when designing your security environment.

Note: This list is non-inclusive. Many other security steps may be necessary in your network environment; however, the suggestions on this list should be considered when establishing your security policies.

SSH Resources

For general information about SSH1 and SSH2, as well as information about SSH servers and clients, see the OpenSSH web page, http://www.openssh.com.

Related:

7021485: Telnet Port Forwarding and the Reflection Secure Shell Client

Novell Leave a comment

A Brief Introduction to SSH

SSH is a set of computer applications based on the IETF Internet-Draft for the Secure Shell protocol. SSH provides strong, encrypted authentication and a secure encrypted tunnel through which users can execute commands and move data. The current version of Secure Shell is ssh-2. (The ssh-1 protocol is deprecated; therefore, it is highly recommended that you use ssh-2.)

For more information about Secure Shell, see “Fortified SSH: A Cost-Effective Way to Safeguard Your Network” on the Attachmate web site at http://www.attachmate.com/WhitePapers/Literature_0954.htm.

Using Reflection Secure Shell Client for Secure Connections

The Reflection Secure Shell Client is included in Reflection version 12.0 or higher.

To tunnel a Telnet session through an SSH connection, you must establish the SSH connection, then configure Reflection to redirect Telnet through the SSH tunnel. To do this, you must create two Reflection settings files, one to configure and start SSH, and one to configure and start the Telnet session.

Figure 1 - Telnet Port Forwarding
Figure 1 – Telnet Port Forwarding

Note: Both connections must remain open for port forwarding to be available. The SSH connection window may be minimized. If the user tries to log off or close the SSH connection while the Telnet session is being tunneled, they will be unable to do so. The SSH session will remain open until the Telnet session is terminated.

Step I—Create the SSH Connection Settings File

Follow the steps below (for the appropriate Reflection product) to create a settings file that opens a Secure Shell connection to your secure host.

For Reflection 2014 or Reflection 2011

  1. Verify with your host administrator that an SSH daemon (sshd or sshd2) is running on the host computer.
  2. Start the Reflection Workspace, select an IBM or VT terminal template, and then click Create.
  3. Select the Secure Shell radio button.
  4. Enter the Host name and your User name.
  5. Select the Configure additional settings check box, and then click OK.
  6. Click Set Up Connection Security.
  7. On the Tunneling tab, under Local Forwarding, click Add.
  8. In the “Forward local port” field, enter the local Telnet port. The example below uses port 1025. Port numbers higher than 1025 are user-defined ports. Using ports 1 – 1024 requires administrative privileges.
  9. Under Destination Host, in the Name field, enter localhost, and in the Port field, enter 23.

Important: Localhost is used for the remote machine if the Telnet server you are connecting to is running on the same server where the SSH daemon resides, which is often the case.

If the SSH daemon resides on a different host than the host you are connecting to with Telnet, enter the name of the host you are connecting to with Telnet in the ‘to remote’ field. In this instance, the telnet connection between the Reflection Secure Shell client and the SSH daemon is secure, but the Telnet connection between the SSH daemon and the target host is not secure.

  1. Click OK > OK > OK.
  2. To verify that you can successfully establish the Secure Shell connection, log in to the host. Once successfully connected, click Disconnect.
  3. Click the Save icon. Enter a descriptive file name for this Secure Shell connection and click Save.

For Reflection 14.x

  1. Verify with your host administrator that an SSH daemon (sshd or sshd2) is running on the host computer.
  2. Start Reflection.
  3. Click Connection > Connection Setup.
  4. Under Connect using, select Network and Secure Shell.
  5. Under Connection options, enter the Host name, your User name, and then click Security.
  6. Click the Tunneling tab. Under Local Forwarding, click Add.
  7. In the ‘Forward local’ field, enter the local Telnet port. The example below uses port 1025. Port number 1025 or higher are user-defined ports. Using ports 1 – 1024 requires administrative privileges.
  8. In the ‘to remote’ field, enter localhost, and in the ‘port’ field, enter 23.

Important: Localhost is used for the remote machine if the Telnet server you are connecting to is running on the same server where the SSH daemon resides, which is often the case.

If the SSH daemon resides on a different host than the host you are connecting to with telnet, enter the name of the host you are connecting to with telnet in the ‘to remote’ field. In this instance, the telnet connection between the Reflection Secure Shell client and the SSH daemon is secure, but the telnet connection between the SSH daemon and the target host is not secure.

Figure 2 - Add Local Port Forwarding

Figure 2 – Add Local Port Forwarding

  1. Click OK to close dialog boxes and return to the Connection Setup dialog box.
  2. Click Connect and verify that you can successfully establish the Secure Shell connection. Once connected, click Connection > Disconnect.
  3. Click File > Save. Enter a descriptive file name for this Secure Shell connection and click Save.

Step II—Create the Telnet Connection Settings File

Follow the steps below to create a settings file that starts a Telnet session over the port that you have redirected to connect through SSH.

For Reflection 2014 or Reflection 2011

  1. In the Reflection Workspace, click the New Document icon.
Figure 3 - Reflection Workspace New Document Icon
Figure 3 – Reflection Workspace New Document Icon
  1. Select a template and then click Create.
  2. Select the Telnet radio button.
  3. In the “Host name / IP address” field, enter localhost.
  4. In the Port field, enter port 1025 (or whatever port number you configured in step I-8 above), and then click OK.
  5. Click OK in the “Host: localhost” error dialog box. (The error occurs because the SSH connection settings file is not currently loaded.)
  6. Click the Save icon. Enter a descriptive file name for this Telnet connection and click Save.

For Reflection 14.x

  1. Open Reflection and then click Connection > Connection Setup.
  2. Under Connect using, select Network and Telnet. In the ‘Host name’ field, enter localhost, and then click More Settings.
  3. On the General tab, select TCP port 1025 (or whatever port number you configured in step I-8 above), and then click OK.
  4. Click File > Save. Enter a descriptive file name for this Telnet connection and click Save.

Step III—Tunnel the Telnet Connection through the SSH Connection

Once you have created the Secure Shell and Telnet settings files, follow these steps to tunnel Telnet through the secure pipe.

  1. Double-click the Secure Shell settings file you saved in Step I-12 (Reflection 2014 or 2011) or Step I-11 (Reflection 14.x).
  2. Enter your password. An SSH connection is established.
  3. With the SSH connection established (you may minimize the Reflection window, but do not close it), double-click the Telnet settings file you saved in Step II-4. A Telnet session will be started through the SSH tunnel.
  4. Enter your user name and password.

Verify the Secure Connection

Follow the steps below to verify that your Telnet session is running through the SSH tunnel.

  1. Click Start > Run.
  2. In the Open field, type cmd, and then click OK.
  3. In the Windows Command window, type netstat.

Note: If the netstat command is not recognized, navigate to the C:WindowsSystem32 directory and enter the command again.

If the port forwarding is successful, you should see a response similar to the following:

Active Connections

Proto Local Address Foreign Address State

TCP MY_PC:2460 my.server.com:22 ESTABLISHED

TCP MY_PC:1025 localhost:2461 ESTABLISHED

TCP MY_PC:2461 localhost:1025 ESTABLISHED

In the example above, the first TCP row shows the SSH connection from port 2460 (a random port) on the workstation to port 22 (the default SSH port) on the SSH server.

The second and third TCP rows show the Telnet connection between port 1025 on the workstation, the port that has been configured to redirect Telnet connections (port 23) through the SSH tunnel (port 22), and a random port (2461) on the SSH server.

Note: If the second or third row shows the actual host name, such as my.server.com, instead of localhost, the tunnel has failed and the Telnet connection is not encrypted.

Related:

Hacked

Symantec Community Leave a comment
I need a solution

.

I have a BT hub 6A it’s my 4th one.

So my walls are thin enough for me to know my neighbours have hacked me. I can often hear them bragging about it. I’ve called BT so many times like more than 15 and they say it’s fine their end but yet every device I have has been modified. Anyway.

I have used an app called Fing to do some port scans and to get some info. I have screenshots but I can’t put them up in here by the looks of it.

Anyway my router shows up as BTHUB.
It says it’s netbios name is BTHUB (have no idea what that is) and it’s saying it’s a file server.

So a scan reveals that the following ports are open

53
Domain name server
80
Http

But then I get this
139
Netbios-ssn

443
Secure World Wide Web ssl

445
Microsoft-ds
Smb directly over IP

8888
Sun-answerbook
Sun answer http server or gnump3d streaming music server

10080
Amanda
Amanda backup util

Sometimes I’m getting a upnp port opening as well on 1900
5000

When I use another device I constantly have this port open

62078
Iphone-sync

I read online that apparently this is a way that some hackers are able to remotely access devices.
Is there anyone who can tell me what’s going on.

I keep upnp off now because of it but yet they are still able to log on and switch it on and come set port forward rules from port 0 to 0 it says on the technical log.

I’m not sure if this is supposed to happen but I have a loop back on my router 127.0.0.1 and I’m pretty sure they have forced my IP to remain static.

Not only this when you go to the IPv6 settings there is no dns it says not available.

When I went on my pc it said there was no IPv6 connection at all.

Also when I do a portscan localhost using my iPhone I get the following ports open

1080
Socks

1083
Ansoft-lm-1
Anasoft license manager

8021
FTP-proxy
Common ftp proxy port.

Also I have seen something on my computer screen called teredo isatap where it says media disconnected.

I’ve had my email password blocked about 40 times this is not an exaggeration.

I think they are using Cisco equipment to link up our hubs.

When I leave the house and connect to a friends Wifi if I do a localhost scan on fing I get

1990
Stun p1 Cisco

It is saying my address assignment is static.
That IPv6 is not configured on the technical logs it has shown some unusual MAC addresses but then they disappear off the devices.

I am getting new static route added with an External IP address that hasn’t changed.

Also with this fing app you can see upnp service info.
For my router I get this

Hostname bthub
Upnp name BT Homehub 6.0A

Upnp services

WanCommonInterfaceConfig(1)
WanPPPConnection(1)

Net bios name BTHUB
File server : Yes

I am also getting NFLC Media Server show up when there is nothing except my phone connected.

I did a cmd net local group I think and it came up with IPC$ and ADMIN$ which means someone is remotely logging in as admin and is sharing files.

I have done a scan over my mums she lives across the road and they’ve tried to stop me from using her Wifi in the past.

When I do a port scan on her router she’s with virgin we get

80
Http

1900
Upnp

5000
Complex main upnp

Her upnp services then show as

Layer3Forwarding(1)
WanCommonInterfaceConfig(1)
WanIPConnection(1)

And she had a few unknown devices on there as well.

I’ve spoke to BT and they are swearing blind that I can’t be hacked it’s not possible but it seems to be all these servers popping. I have a upnp scanner on my android and randomly after some code has been changed it’s showing that they are trying to make requests using that.

I just don’t know what or who else to ask please help

0

Related:

7021999: Local and Remote Port Forwarding and the Reflection for Secure IT Client 7.1 or Higher

Novell Leave a comment

A Brief Introduction to SSH

SSH is a computer program based on the Secure Shell protocol. SSH provides strong, encrypted authentication and a secure encrypted tunnel through which users can execute commands and move data. The current version of Secure Shell is ssh-2. (The ssh-1 protocol is deprecated; therefore, it is highly recommended that you use ssh-2.)

For more information about Secure Shell, see “Fortified SSH: A Cost-Effective Way to Safeguard Your Network” on Attachmate.com: http://www.attachmate.com/WhitePapers/Literature_0954.htm.

An Introduction to Port Forwarding (Tunneling)

Port forwarding, also known as tunneling, provides a way to redirect non-secure TCP/IP communications through a secure SSH connection. When port forwarding is configured, all data sent to a specified port is redirected through the secure channel. Most remote services that use TCP/IP can be secured, including client-server applications, database systems, and services such as HTTP, Telnet, FTP, POP3, and SMTP. The Reflection for Secure IT and Reflection clients also provide dynamic forwarding for the X11 Windows System commonly used on UNIX machines.

There are two types of port forwarding: local and remote.

Local Port Forwarding—In most cases, local port forwarding is used to forward data securely from another client application running on the same computer as the Secure Shell client. The Secure Shell client is configured to redirect data from a specified local port (on the same computer as the Secure Shell client), through the secure tunnel to a specified destination host and port. You can configure any other client running on the same computer to connect to the forwarded port (rather than directly to the destination host and port). After the Secure Shell connection is established, the Secure Shell client listens on the specified port and redirects all data sent to that port through the secure tunnel to the Secure Shell server. The server decrypts the data, and then directs it to the destination host and port.

Remote Port Forwarding—Remote port forwarding is used to forward data securely from any client application running on the same computer as the Secure Shell server. In this case, the client session requests that a specified remote port (on the same computer as the Secure Shell server) be used to redirect the data. You can configure any other client running on the same computer as the Secure Shell server to connect to the forwarded port (rather than directly to the destination host and port). After the Secure Shell connection is established, the Secure Shell server listens on the specified port and redirects all data sent to that port through the secure tunnel to the Secure Shell client. The client decrypts the data and then directs it to the destination host and port.

To tunnel TCP traffic with SSH, you must configure local or remote port forwarding (or both), establish the SSH connection, and then configure the application you want to secure to redirect its communication through the SSH tunnel.

Using the Reflection for Secure IT Client for Secure Connections

Port forwarding is configured only by the SSH client, not the Reflection for Secure IT server. However, you can configure the server to enable or disable requests made by the client.

Step I—Configuring the SSH Server to Allow TCP Tunneling

Before using port forwarding, ensure that the SSH server is configured to enable tunneling. How you configure the server depends on which server version and platform you are using.

Both local and remote port forwarding are enabled by default in version 7.0 or higher of the Reflection for Secure IT Server. For details about these settings, go to the product documentation page, http://support.attachmate.com/manuals/sshdocs.html. Select your product; open the Reflection for Secure IT Server Users Guide for your product version; and search for Port Forwarding.

For details on configuring other SSH server software, refer to your man pages or the product’s documentation.

Step II—Configuring Port Forwarding

The client can be configured to request local or remote port forwarding, or both.

For information about configuring the Reflection for Secure IT Client for port forwarding, go to the product documentation page, http://support.attachmate.com/manuals/sshdocs.html. Select your product; open the Reflection for Secure IT Client Users Guide for your product version; and search for Port Forwarding.

Using the Reflection for Secure IT Interface (Windows Client)

Follow the steps below to create, close, and edit an SSH tunnel using the Reflection for Secure IT Windows Client.

Configure Local Port Forwarding

To create a local tunnel:

  1. Click Start > Programs > Attachmate Reflection > SSH Client.
  2. Click Connection > Connection Setup; enter the host name, and then click Security.
  3. On the Tunneling tab, under Local Forwarding, click Add.
  4. In the Forward local port field, enter a local port number that the Reflection client should use to listen for TCP or FTP data requests. Data sent from this port will be forwarded through the Secure Shell tunnel.

Note the following:

    • Port numbers higher than 1025 are user-defined ports. Using ports 1 – 1024 requires administrative privileges.
    • Make sure to select a non-used port for your Source Port. If the port number entered matches a port that is already configured to listen for another service, the Reflection SSH client will be unable to forward the data.
    • If you create several tunnels for one connection, you must specify a different local port for each tunnel.
  1. In the Name field in the Destination Host section, enter localhost.

Important: Localhost is used for the name of the remote machine if the tcp application server you are connecting to through the tunnel is running on the same server where the SSH daemon resides, which is often the case.

If the SSH daemon resides on a different host than the host on which the tcp application is running, enter the name of the host you are connecting to in the Destination Host field. In this instance, the connection between the Reflection SSH client and the SSH daemon is secure, but the connection between the SSH daemon and the target host is not secure.

  1. In the Port field, enter the TCP/IP port on the SSH server where the application that uses the tunnel sends its data requests. For example, if you will be forwarding Telnet, the default port for Telnet is 23.
  2. Optional: The Local Port Forwarding dialog box enables you to configure several additional settings including Tunnel Remote Desktop, Forward type, and Application to Launch. For information about these settings, click the Help button on the Local Port Forwarding dialog box.
  3. Click OK twice to return to the Connection Setup dialog box.

This tunnel configuration is automatically saved to the user’s config file (under SSH config scheme) and will be used again when you connect to the same host (using the same host name).

  1. Enter a User name and click Connect. Once the SSH connection has been established, unencrypted TCP traffic from a third-party application can be securely sent through the SSH tunnel.
  2. To save all of the non-SSH related settings, such as host and user names, for use the next time you launch the Reflection for Secure IT client, click File > Save in the SSH client window. Enter a file name and click Save.

When the Reflection SSH client receives a local request on the specified source port, the application is connected to the destination port through the SSH tunnel.

Note the following:

  • Changes you make to these settings are saved to the currently specified SSH config scheme.
  • Secure Shell settings are saved to the Secure Shell configuration file. You can also configure Secure Shell settings by editing this file manually in any text editor. The keyword used to configure local port forwarding is LocalForward.

Close a Tunnel

To close a tunnel, terminate the host session.

Edit a Tunnel Configuration

To edit tunnel settings:

  1. While the tunnel is not connected (no host connection has been made), click Connection > Connection Setup. Make sure that the correct host name has been entered, and then click Security.
  2. On the Tunneling tab, select the local tunnel you want to edit and click Modify.
  3. Edit the settings and click OK twice.

Using the Command Line (Windows and UNIX Clients)

You can use commands to establish the SSH connection and create the SSH tunnel from the command line.

Use the following command to forward TCP traffic on the workstation through an SSH tunnel to the SSH server.

Syntax:

ssh –L <local workstation port>:localhost:<SSH server port> <user name>@<host name>

Example:

ssh –L 4000:localhost:4005 RKoa@mySSHserver

In the example above, TCP traffic will be forwarded through port 4000 on the workstation to port 4005 on the SSH server.

Step III—Configuring the Application to Use the SSH Tunnel

After creating the SSH tunnel by following the procedure in Step II, you must configure your application to use the SSH tunnel. The configuration will be different for each application. For details, refer to the application documentation.

An Example

The following example shows how to configure Reflection for HP or Reflection for UNIX and OpenVMS to redirect a Telnet session over the port you have redirected to connect through SSH.

  1. Start the Reflection for Secure IT SSH tunnel (see Step II for details).
  2. Open Reflection for HP or Reflection for UNIX and OpenVMS, and then click Connection > Connection Setup.
  3. Under Connect using, select Network and Telnet. In the ‘Host name’ field, enter localhost, and then click More Settings.
  4. On the General tab, select TCP port 1025 (or whatever port number you configured in Step II-4 above), and then click OK.
  5. Click Connect, and log in to the host.

Verifying the Secure Connection with the Windows Client

To verify that your Telnet session is running through the SSH tunnel, follow these steps.

  1. Click Start > Run.
  2. In the Open field, type cmd, and then click OK.
  3. In the Windows Command window, type netstat.

Note: If the netstat command is not recognized, navigate to the C:WindowsSystem32 directory and enter the command again.

If the port forwarding is successful, you should see a response similar to the following:

Active Connections

Proto Local Address Foreign Address State

TCP My_PC:1554 my.server.com:22 ESTABLISHED

TCP My_PC:1025 localhost:1564 ESTABLISHED

TCP My_PC:1564 localhost:1025 ESTABLISHED

In the example above, the first TCP row shows the SSH connection from port 1554 (a random port) on the workstation to port 22 (the default SSH port) on the SSH server.

The second and third TCP rows show the Telnet connection between port 1025 on the workstation, the port that has been configured to redirect Telnet connections (port 23) through the SSH tunnel (port 22), and a random port (1564) on the SSH server.

Note: If the second or third TCP row shows the actual host name, such as my.server.com:telnet(23), instead of localhost:<port number>, the tunnel has failed and the Telnet connection is not encrypted.

Sample Settings

The following sample settings show how to forward HTTP.

Forwarding HTTP

  1. Use the Reflection SSH client to connect to the host running the HTTP and SSH servers.
  2. Create a local tunnel with the following values.
    Field
    		Data
    Local forward
    		8080

    Note: This number can be any port number over 1024.
    To remote
    		localhost
    Port
    		80
  1. Open your web browser and go to http://localhost:8080.

Your HTTP connection is now going through the SSH tunnel.

Related:

Currently the Application Discovery Configuration Server web interface is invoked using the port 8080.. But this port is used in another software.

IBM Customer Leave a comment
Currently the Application Discovery Configuration Server web interface
is invoked using the port 8080.. But this port is used in another
software..
So the NEED is to use OTHER port than 8080..

Related:

Access local owncloud installation with a domain name

Antonio Kovačević Leave a comment

I have owncloud installed on a local server at the office located at a buisness incubator and a web site with a domain name on a remote server.

Current installation:

  • Domain: example.com that points to my remote server
  • owncloud installation with local static ip 192.168.17.98:80
  • incubator’s ip/port 123.123.456.789:1234 forwarded to owncloud’s local ip/port

I can access owncloud installation using incubarot’s ip/port 123.123.456.789:1234 and a local ip 192.168.17.98:80

My goal is to be able to access owncloud using a sub domain owncloud.example.com/

Is this configuration possible?

Related:

Can’t access ElasticSearch through local port forward

oschlueter Leave a comment

I’m stuck at connecting to my SearchGuard-proteced ElasticSearch instance inside the company network from my local machine at home. I’m using a local SSH forward same as I got working for a phpMyAdmin instance.

My ~/.ssh/config contains these:

Host workstation-forward-phpmyadmin
    LocalForward localhost:8080 $WORKSTATION:443
    HostKeyAlias $GATEWAY
    Hostname $GATEWAY
    ExitOnForwardFailure yes
    User oschluet

Host workstation-forward-elasticsearch
    LocalForward localhost:9200 $WORKSTATION:9200
    HostKeyAlias $GATEWAY
    Hostname $GATEWAY
    ExitOnForwardFailure yes
    User oschluet

I engage these in a screen-session like so:
ssh workstation-forward-elasticsearch or ssh workstation-forward-phpmyadmin
and detach the screen.

Now I can access the phpMyAdmin through my browser by accessing https://localhost:8080 or use telnet to talk to the web server directly.
Unfortunately there seems to be an issue with ElasticSearch in this regard. From a different machine inside the company network I can access the ElasticSearch like this:

oschluet@ravenwood:~$ curl -k https://$WORKSTATION:9200 --user $user:$pass
{
  "name" : "redacted",
  "cluster_name" : "redacted",
  "cluster_uuid" : "redacted",
  "version" : {
    "number" : "5.1.1",
    "build_hash" : "5395e21",
    "build_date" : "2016-12-06T12:36:15.409Z",
    "build_snapshot" : false,
    "lucene_version" : "6.3.0"
  },
  "tagline" : "You Know, for Search"
}

Using the same credentials locally yields nothing:

[oschlueter@B5400 ~]$ curl -k https://localhost:9200 --user $user:$pass
# nothing happens

Using no credentials:

oschluet@ravenwood:~$ curl -k https://$WORKSTATION:9200
Unauthorized

[oschlueter@B5400 ~]$ curl -k https://localhost:9200
# again nothing

However telnet opens a connection:

[oschlueter@B5400 ~]$ telnet localhost 9200
Trying ::1...
Connected to localhost.
Escape character is '^]'.

I tried having ElasticSearch listen on the ip address, the hostname and 0.0.0.0 which all allowed me to connect from the other machine inside the network however no connection from my local machine could be established. I’m admin of $WORKSTATION and of my local machine. Could anyone help me locate the issue please?

Related:

Iptables port forwarding with restrictions on some

Doug Leave a comment

I have a set of services where I’d like to set IP based ACLs (whitelist) for one, but not for the other. The issues seems to show up as the services run on the same port internally (port 80) but I use different ports on the gateway to access them.

Port 8088 on Gateway -> Port 80 on 10.0.0.A (with IP whitelist)
Port 80 on Gateway -> Port 80 on 10.0.0.B

And I can get this to work with everything open with the following rules:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8088 -j DNAT --to 10.0.0.A:80
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 10.0.0.B
iptables -A FORWARD -p tcp -i eth0 --dport 80 -j ACCEPT

The issue is that the FORWARD ACCEPT rule covers both of these nat rules, as they seem to be based on the destination port (–dport 80), instead of the incoming port on the gateway (80 vs 8088).

I can’t figure out how to rewrite the FORWARD rule into 2 separate rules so that I can have different behaviour for connections coming into the gateway on 80 vs 8088.

Additional info:

lsb_release -d
Description:    Debian GNU/Linux 7.5 (wheezy)
iptables --version
iptables v1.4.14

1st Solution Attempt
I have been able to spin off a chain and perform the routing there, but I am unable to add the ACL (reject) line due to the following error message:

x_tables: ip_tables: REJECT target: only valid in filter table, not nat

Here’s what I put in:

iptables -t nat -N Whitelist
iptables -t nat -A Whitelist -p tcp -j DNAT --to 10.0.0.A:80
iptables -t nat -A Whitelist -s <whatsmyip.org> -j RETURN
iptables -t nat -A Whitelist -j REJECT
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8088 -j Whitelist

Everything works fine until line 4, where the REJECT inside nat fails. If I comment the REJECT line out, I can confirm that the remainder of the logic works and the port becomes open to the wild because nothing is rejected.

Next Solution Attempt
Seem to be tripping up on the original issue while working with a properly setup separate chain. The PREROUTING rule changing the port right off the top still seems to cause an issue with the non-nat ACL attempt. The ACL rules have no effect and the port is open to the wild.

iptables -N Whitelist
iptables -A Whitelist -s <whatsmyip.org> -j RETURN
iptables -A Whitelist -j REJECT
iptables -A INPUT -i eth0 -p tcp --dport 8088 -j Whitelist
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8088 -j DNAT --to 10.0.0.A:80

Current Investigation
Try to move the port change to something after the ACL check, after the nat prerouting.

Related:

How to temporarily disable local forwards

jeb Leave a comment

I have in my ~/.ssh/config file entries with local forward definitions like

HOST myServer
   hostname 10.10.0.1
   user xyz
   LocalForward 8080 localhost:80
   LocalForward 4000 127.0.0.1:4000
   ...

This works like a charm, but I also have scripts to synchronize some data.
These scripts show many warnings when they try to connect to the server while there is already a connection.

bind: Address already in use
channel_setup_fwd_listener_tcpip: cannot listen to port: 8080
bind: Address already in use
channel_setup_fwd_listener_tcpip: cannot listen to port: 4000
....

Is there a neat way to use ssh or rsync with an option to disable all local forwards for a session?

Obviously I could copy&paste each config block and build one with and one without local forwards, but I hope there is a better solution.

Related: