Showing posts with label x-server. Show all posts
Showing posts with label x-server. Show all posts

Friday, December 23, 2016

Tunnel your X server traffic to remote X clients using an SSH

Tunnel your X server traffic to remote X clients using an SSH



To configure a remote X client without encryption, you can use the
following procedure:





1. On the remote X client, enter



   xhost +X_server_hostname



   This tells the client to accept connections from the X server.





2. On the X server, enter



   DISPLAY=X_client_hostname:0.0



   and then enter



   export DISPLAY



   This tells the X server to display its output on the remote X client.






3. From the X client, use the ssh client to access the shell prompt on
   the X server and then run the graphical application you want displayed
   on the X client. For example, you could enter gedit at the shell
   prompt to remotely display the gedit text editor. You could also enter
   office at the shell prompt to remotely display the OpenOffice.org
   suite.







Encrypted

This procedure works, but all the X traffic is transmitted
unencrypted. This isn’t good. Instead, you should use SSH to tunnel
the X server traffic between the X server and the X client. You can do
this using one of the following options:




On the X client system:



• Use the –X option with the ssh client program.




• Set the



  ForwardX11 



  option to a value of




  yes




  in the




   /etc/ssh/ssh_config 





    file








On the X server system:





Once this is done, you then need to set the




X11Forwarding 




option to





yes 





in the





/etc/ssh/sshd_config 





file






Encryption IV

Thursday, December 22, 2016

Encryption IV

Tunneling Traffic Through SSH

One of the key security issues you must deal with as a system
administrator is the fact that many commonly used network protocols
transfer information as clear text. Good examples of this are the POP3
and IMAP daemons we discussed in the preceding chapter. We noted that
for your Linux MTA to download e-mail messages to client systems, you
must first enable either your POP3 or IMAP daemon via xinetd. Once
done, end users can use an e-mail client to connect to the MTA and
download their mail using the appropriate protocol. The problem,
however, is the fact that both of these daemons transfer data as clear
text by default. That means the usernames and passwords users send to
authenticate to the MTA are sent as clear text along with all the con-
tents of their e-mail messages. This allows anyone with a sniffer to
capture packets and view the contents of the transmissions.



The good news is SSH can be used to encrypt clear-text traffic by
tunneling it through an SSH connection. When client software for the
tunneled protocol (such as an e-mail client using POP3) establishes a
connection with the local SSH client, the traffic is encrypted using
SSH and tunneled through to the SSH server. On the SSH server end, the
traffic is decrypted and then forwarded to the appropriate target
service (in this case, the POP3 daemon). This is great, because the
information is encrypted before being transmitted, even though the
original protocol (in this case, POP3) doesn’t support encryption.




Let’s walk through an example of how you can use SSH to tunnel POP3 traffic:



1. Make sure the ssh client is installed on the local system where the
   e-mail client will run.


2. Make sure the sshd daemon is installed and running on the POP3 server.


3. Ensure IP port 22 is open on the server where sshd is running.


4. On the system where sshd is running, switch to root and edit the
 


  /etc/ssh/sshd_config 



   file.


5. Locate the AllowTcpForwarding parameter, uncomment it if necessary,
   and then set it to a value of yes. An example is shown here:



    AllowTcpForwarding  yes



6. Save your changes to the file and exit the editor.


7. Restart the sshd daemon by entering systemctl restart sshd at the
   shell prompt (as root).



8. Switch to the client system.



9. Create a local ssh tunnel from a local high IP port (in this
   example, port 2345) to port 110 on the POP3 server using the following
   command (enter the remote user’s password when prompted):



    ssh -f -N -L 2345:pop3_host_address:110 user_name@pop3_host_address




   The options specified in this command do the following:



   • –N and –f 

     Tell ssh not to execute a command remotely on the server
      and to run in the background after prompting for the remote user’s
      password


   • –L 

      Specifies three things:

      • The local port to be used for the client end of the tunnel (in
        this case, 2345)

      • The hostname or IP address of the remote POP3 server

      • The port on the remote server that will be used for the server
        end of the tunnel (in this case, 110)



   You don’t have to use port 2345. You can use the same port on both
   ends if desired. However, be aware that you will need to switch to the
   root user if you want to use a port number less than 1024 on the
   client side of the tunnel. These are called privileged ports.



10. With the tunnel established, configure the local e-mail client
    program to retrieve mail from the local system on the port you
    configured for the client end of the SSH tunnel. In this example, you
    would configure it to get mail from the local system’s IP address on
    port 2345. An example of how to do this with the Evolution e-mail
    client is shown in Figure 18-6.


    Note that I used the hostname of the local host, not the POP3 server, in the Server field.
    I also added the port number of the workstation end of the tunnel to the end of the
    hostname.




At this point, when the client uses the POP3 protocol to download new
messages, the SSH client on the local system will encrypt the request
and forward it to the SSH server through the SSH tunnel you
established. The SSH server will receive the request, decrypt it, and
then pass the data on to the local port 110, where the POP3 daemon is
listening. The cool thing about this process is that it is completely
transparent to the e-mail client software. As far as it’s concerned,
it’s retrieving e-mail from a local POP3 server.



You can test the tunnel you created using the telnet command from the
client end of the tunnel. The syntax is


telnet localhost client_tunnel_port


Here’s an example:



telnet localhost 2345



When you do this, you should see a connection established with the remote system where the POP3 daemon is running. An example is shown in Figure 18-7.




You can also tunnel your X server traffic to remote X clients using an SSH connection. This is important because unencrypted X traffic provides an attacker with a gold mine of information that he or she can use to compromise your systems.






To configure a remote X client without encryption, you can use the
following procedure:


1. On the remote X client, enter



   xhost +X_server_hostname



   This tells the client to accept connections from the X server.



2. On the X server, enter



   DISPLAY=X_client_hostname:0.0



   and then enter



   export DISPLAY



   This tells the X server to display its output on the remote X client.




3. From the X client, use the ssh client to access the shell prompt on
   the X server and then run the graphical application you want displayed
   on the X client. For example, you could enter gedit at the shell
   prompt to remotely display the gedit text editor. You could also enter
   office at the shell prompt to remotely display the OpenOffice.org
   suite.








This procedure works, but all the X traffic is transmitted
unencrypted. This isn’t good. Instead, you should use SSH to tunnel
the X server traffic between the X server and the X client. You can do
this using one of the following options:



• Use the –X option with the ssh client program.


• Set the 


ForwardX11 


option to a value of 


yes


in the


 /etc/ssh/ssh_config 


  file on the X client system.




Once this is done, you then need to set the


X11Forwarding 


option to



yes 



in the



/etc/ssh/sshd_config 



file on the X server system.












LX0-104 Exam Objectives (X)

Thursday, December 8, 2016

Commonly used sections in a typical xorg.conf file VII

Commonly used sections in a typical xorg.conf file VII


The next section you need to be familiar with is the Monitor section,
which defines parameters for the monitor connected to your display adapter.

A sample Monitor section is shown next:



Section "Monitor"

    Identifier      "vmware"

    VendorName      "VMware, Inc"

    HorizSync       1-10000

    VertRefresh     1-10000

EndSection




You can use the following directives within the Monitor section:


• Identifier "name"

  Defines a unique name for the monitor



• VendorName "vendor"

  Specifies the monitor manufacturer


• ModelName "model"

  Specifies the monitor model


• HorizSync sync_range

  Defines the horizontal sync frequency range supported by
  the monitor, specified in KHz


• VertRefresh refresh_rate

  Defines the vertical sync frequency range supported by the
  monitor, specified in KHz





LX0-104 Exam Objectives (H)

Editing the X Configuration File

Editing the X Configuration File


If you’re using X.org on a Linux distribution that uses the init
daemon, your configuration settings are saved in

/etc/X11/xorg.conf. 


If you’re using XFree86, your configuration settings are saved in

/etc/X11/XF86Config. 


Here is a portion of a sample xorg.conf file



Section "InputDevice"

  Driver       "vmmouse"

  Identifier   "VMware Mouse"

  Option       "Buttons" "5"

  Option       "Device" "/dev/input/mice"

  Option       "Name" "ImPS/2 Generic Wheel Mouse"

  Option       "Protocol" "IMPS/2"

  Option       "Vendor" "Sysp"

  Option       "ZAxisMapping" "4 5"

  Option          "Emulate3Buttons"       "true"

EndSection




Section "Modes"

  Identifier   "Modes[0]"

  Modeline      "1024x768" 65.0 1024 1048 1184 1344 768 771 777 806
-hsync –vsync

  Modeline      "1024x768" 61.89 1024 1080 1184 1344 768 769 772 794

EndSection




Linux distributions that are based on systemd do not use the xorg.conf
configuration file. Instead, the X11 configuration is stored in a series 
of configuration files located in 

/etc/X11/xorg.conf.d.

However, the configuration principles are pretty much the same.
Instead of a single file divided into multiple sections, these systems
break up the one single file into separate files, such as


10-evdev.conf, 50-device.conf,
50-monitor.conf, and 50-screen.conf.


The syntax within these files is the same as that used in the xorg.conf file.


LX0-104 Exam Objectives (H)

X-Server: video card and monitor

Verify that the video card and monitor are supported by an X server .


Because the X server works directly with your video board and monitor,
configuring it is the most critical of all your GUI management tasks.
It’s imperative that you use the correct settings in your
configuration. If you proceed incorrectly, you could potentially
damage your monitor.

I know this because I had it happen to me once. I configured my system
to use a sync rate that was too fast for an older CRT monitor I was
using. It worked OK for a couple of weeks. However, one evening my monitor started
hissing, sparking, and smoking. I pushed it too fast for too long and
burned it up. Always check your video board and monitor documentation
to obtain the correct specs!


Before you begin, you should pull out your video board and monitor
documentation and identify the following information:


• Who’s the manufacturer of the video board?

• What model number is the video board?

• How much memory is installed on the video board?

• What’s the board’s maximum resolution?

• What’s the board’s maximum color depth?

• What chipset is installed on the board?

• What’s the maximum horizontal and vertical sync rate supported by
  your monitor?


With this information in hand, you need to check the HCL for your
distribution and make sure your video board and monitor are supported. Trust me, having this
information in hand before you begin will save you a lot of trouble.

Be warned, however, that you will many times find that newer video
boards are not listed in the HCL. Does this mean the board is not
supported and won’t work? Maybe, maybe not. Here’s what you can do:


• See if an older driver will support your newer video board until a
  newer driver is released.

  Most X server implementations will include a set of generic drivers
  that will support most
  video boards at some level. It won’t look great, but you can at least
  get your system up
  and running.

• Check the video board manufacturer’s website and see if they have
  released a driver for their board that isn’t included with your X
  server implementation.

  Once you have this information gathered, you’re ready to start
  configuring your X server. This can be done in two ways:

• Editing the X configuration file

• Using an X configuration utility


If you’re using X.org on a Linux distribution that uses the init
daemon, your configuration settings are saved in /etc/X11/xorg.conf.

If you’re using XFree86, your configuration settings are
saved in /etc/X11/XF86Config.


Linux distributions that are based on systemd do not use the
xorg.conf configuration file. Instead, the X11 configuration is stored
in a series of configuration files located in /etc/X11/xorg.conf.d.

However, the configuration principles are pretty much the same.
Instead of a single file divided into multiple sections, these systems
break up the one single file into separate files, such as

10-evdev.conf, 50-device.conf,
50-monitor.conf, and 50-screen.conf.


The syntax within these files is the same as that used in the xorg.conf file.




LX0-104 Exam Objectives (H)