Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - kek

Pages: [1]
Networking / What You Need to Know about VPN
« on: March 21, 2018, 02:28:49 PM »
What You Need to Know about VPN

In this post I will try to share what you should know about VPN, I will try to explain the theory behind what a VPN is, how it works, why one should use a VPN connection and some of the common mistakes I have encountered in the field.

This will be all explanations and theory, it will not be any specific How-To instructions in this post.

What is a VPN?
VPN is short for Virtual Private Network, as the name suggests it is used to create and or extends a private network across a public network, by doing this it enables users and services to send and receive data across shared or public networks as if their computer or network-devices were directly connected to the private network.
Why would I need a VPN?
There are several reasons for why you would need or want to use a VPN, a VPN on its own are just a way to bolster your internet security and access to resources on a different network you are not physically connected to. What you choose to do with a VPN is a different matter.

The first and foremost reason for using a VPN is security, as it is the only secure way of connecting remote devices or networks together, being your laptop connecting to your Home, School or Office network while you are out or you want to bypass silly country filters on services like Netflix, Hulu and Spotify for getting access to content that is not yet available in your aria without anyone able to see the traffic.

Second biggest reason for why you would need or want to use VPN is for privacy, some countries have silly rules that allows ISPs or other company to harvest your personal data and internet usage and then selling it to the highest bidder, whit a VPN the ISPs would be unable to see your personal data and internet usage as it is encrypted they will only see that you are connected to the VPN Server but not what type of date and usage is passed between the VPN Server and VPN Client.
There are a bunch more reasons for why you need or want to get a VPN, but these are the top two reasons that sticks out and covers everything you commonly would use a VPN.

Are there different types of VPN?
Yes there are several and very different types of VPNs, but unless you work in the field of Telecom, Networking or general IT and have a very specific need you are only going to see the two most common types of VPN is Remote Access based and Site to Site based connections and terminations.
What are the difference between Site to Site and Remote Access VPN?
Many users do not know the difference between Site to Site VPN and Remote Access VPN. While both are classified as VPN and uses basically the same computing infrastructure, there is a line that separates the two from each other and have different use cases.

Site to Site VPN:
A Site to Site VPN makes it possible for users in different fixed locations to establish a secure connection with each other over the internet, allowing a user in one location to access resources from another location. This means that if user A connects to a network where users B and C are connected, user A will be able to access resources that are in users B and C locations, and vice versa.

There are two types of Site to Site VPNs. The first one is intranet-based, where users create an intranet VPN with the intent of connecting multiple local-access networks (LANs) to a single wide-access network (WAN). The other one is extranet-based, where two separate intranets can connect to a secure shared network environment while still preventing access to each other’s intranets.

Remote Access VPN:
Remote Access VPN is different from Site to Site VPN in that it provides functionalities for multiple users, while the former tend to be more on the personal side. In a Remote Access VPN, individual users connect to a network in a remote location, through a secure and encrypted tunnel that allows them to access all resources in that network as if they are directly connected to the servers in that network.

In a Remote Access VPN, users connect to a Remote Access Server via the internet, using a dedicated VPN software. The VPN software establishes and maintains a secure tunnel to that Remote Access Server, allowing users to use a VPN through their devices over a safe connection.

Site to Site VPN is more for networks consisting of multiple users e.g. employees and departments within a company. Site to Site VPN allows each user to connect to a network where multiple users are also connected, allowing for resource sharing between the users within that VPN network. 

Remote Access VPN, on the other hand, is more focused on the personal user experience, providing users a number of benefits including a private and encrypted transfer of data and information, as well as access to the remote networks resources as if they are directly connected to that network. 

If you frequently use the internet for browsing and content consumption, then you will get more out of a Remote Access VPN than you would from a Site to Site VPN.

Are there different VPN Protocols?
Yes, there is as many different VPN Protocols, as there is types of VPNs. It seems as each type of VPN, has developed their own standards and protocols. However today there are only two protocols being used and recommended as the others are considered old, outdated and insecure on the modern internet, those two are IPSec and OpenVPN and both of these support Remote Access and Site to Site configuration and deployments.

List of common VPN Protocols you might see mentioned on the internet and in different guides are:
PPTP – Point to Point Tunnelling Protocol
L2TP – Layer 2 Tunnelling Protocol
OpenVPN – OpenVPN
IPSec IKEv1 – Internet Key Exchange (version 1)
IPSec IKEv2 – Internet Key Exchange (version 2)

PPTP – Point to Point Tunnelling Protocol
Point-to-Point Tunnelling Protocol is the most common VPN protocol. It is widely supported for Windows users, as it was created by Microsoft. It is available as standard on just about every VPN platform, making it easy to set up. It also requires a low computational overhead to implement, which means (for you VPN novices) that it is also quick to set up.
However, the PPTP was developed using 128-bit encryption keys which has since become considered quite weak in our quickly advancing digital world. Since there have been some security vulnerabilities with this protocol, most of today’s VPNs use a 256-bit security encryption.

L2TP – Layer 2 Tunnelling Protocol
Layer 2 Tunnelling Protocol does not provide encryption and relies on PPP (Point-to-Point protocol) to encrypt. The difference between PPTP and L2TP is that L2TP provides data confidentiality and data integrity. L2TP was built by Microsoft with Cisco as a foundation of PPTP and L2F (Layer 2 Forwarding) combined.
This VPN protocol is built to function with all modern operating systems and VPN devices. It’s also effortless to set up. While there are problems that may arise, this technology uses UDP port 500, which can be blocked by NAT firewalls.
L2TP encapsulates data twice, and that can compromise speed, but as encryption/decryption happens in the kernel and L2TP/IPsec, it enables multi-threading (OpenVPN does not), and as a result, it is faster.

OpenVPN – OpenVPN
OpenVPN is a somewhat new VPN protocol technology, and one big advantage is that it’s highly configurable and can easily bypass firewalls. It runs best on a UDP port and can be set to operate on any port. It uses 128-bit block size rather than Blowfish’s 64-bit block size, so it is able to handle larger files better.
The performance speed does depend on the level of encryption employed. Furthermore, it has become the default VPN connection type, even though it requires third-party software support. It’s also little hard to set up which can be frustrating for the new VPN user.

IPSec IKEv1 – Internet Key Exchange (version 1)
Outdated, no good reason to use this, use the updated IKEv2 protocol

IPSec IKEv2 – Internet Key Exchange (version 2)
Internet Key Exchange (version 2) is an IPSec based tunnelling protocol that was developed by Microsoft and Cisco. IKEv2 is good at re-establishing a VPN connection when users temporarily lose their internet connections. Mobile users benefit from using IKEv2 VPN protocol because of it support for the Mobility and Multi-homing(MOBIKE) protocol, which is useful if you want to connect your phones to a Wi-Fi network while at home but switch to mobile data use when out and about. IKEv2 is faster than PPTP and L2TP, as it does not use the overhead associated with Point to Point protocols (PPP). Stable and secure, easy to set up, and fully supportive of iOS, macOS, and Windows mobile devices, IKEv2 is available for Android devices but requires a connection with a third-party app.

Improvements with IKEv2
Fewer RFCs: The specifications for IKE were covered in at least three RFCs, more if one takes into account NAT traversal and other extensions that are in common use. IKEv2 combines these in one RFC as well as making improvements to support for NAT traversal and firewall traversal in general.
Standard Mobility support: There is a standard extension for IKEv2 (named MOBIKE) used to support mobility and multihoming for it and ESP. By use of this extension IKEv2 and IPsec can be used by mobile and multihomed users.

NAT traversal: The encapsulation of IKE and ESP in UDP port 4500 enables these protocols to pass through a device or firewall performing NAT.[14]
SCTP support: IKEv2 allows for the SCTP protocol as used in Internet telephony protocol VoIP.
Simple message exchange: IKEv2 has one four-message initial exchange mechanism where IKE provided eight distinctly different initial exchange mechanisms, each one of which had slight advantages and disadvantages.

Fewer cryptographic mechanisms: IKEv2 uses cryptographic mechanisms to protect its packets that are very similar to what IPsec Encapsulating Security Payload (ESP) uses to protect the IPsec packets. This led to simpler implementations and certifications for Common Criteria and FIPS 140-2, which require each cryptographic implementation to be separately validated.
Reliability and State management: IKEv2 uses sequence numbers and acknowledgments to provide reliability and mandates some error processing logistics and shared state management. IKE could end up in a dead state due to the lack of such reliability measures, where both parties were expecting the other to initiate an action - which never eventuated. Workarounds (such as Dead-Peer-Detection) were developed but not standardized. This meant that different implementations of workarounds were not always compatible.

Denial of Service (DoS) attack resilience: IKEv2 does not perform much processing until it determines if the requester actually exists. This addressed some of the DoS problems suffered by IKE which would perform a lot of expensive cryptographic processing from spoofed locations.
Supposing HostA has an SPI of A and HostB has an SPI of B.

What about speed and bandwidth over VPN?
Now that we have covered types and protocols, you might wonder about what speeds that you can expect, and the cold hard fact here is that you will never get a faster connection then the slowest link in the connection given from the ISP to ether side.

However there have been cases where one have gotten more speed over the VPN as the ISP have had a poor implementation of bandwidth limiting on their part and have not been able to detect the VPN traffic and given it a full connection, but these cases are few and far between and are not the norm.
When using a VPN it is expected to have a loss of about 25 – 30% on speed due to the overhead of encrypting \ decriypting the traffic before it is sent or received.

Common mistakes:
The biggest or most common mistakes people do when they try to connect or configure a VPN is that they do not think about the IPs and Subnets involved in the configuration as those can not overlap when creating the Transport or Tunnel network as it will then think the destination is the same as the sender,

Site A has LAN of – 255. /24 –
Site B has LAN of – 255. /24 –
Tunnel Network

For the VPN this would look like this:
Sender – 255 ? ? – 255 Receiver

As you see here both site has exactly the same LAN network so when they try to connect to each other the network is going to be confused as they have the same information for sender and receiver.

Site A has LAN of – 255. /24 –
Site B has LAN of – 255. /24 –
Tunnel Network

For the VPN this would look like this:
Sender – 255 ? ? – 255 Receiver
This example would work as there is a clear understanding of the source and destination of the traffic

Transport or Tunnel Network is the Private Network shared between the devices on the VPN Connection.

If you want a deeper technical explanation of how VPN works I can recommend watcing Eli The Computer Guy’s video on VPS

Lets talk about FANs, especially Noctua fans, many may not be aware of that there are different fans for different configurations and deployments aside form case fans and cpu fans, at the base level any fan is better than no fan at all, unless you are custom building a fan less appliance.

Knowing what fan to use in the different cases makes all the differens in stability of the system as it get the correct amount of cooling, noise reduction as you use the right fan you need less of them and by that you also reduce noise production

The main difference between the fan models are that some are designed for Air Flow and others for Static Pressure

Air Flow fans are commonly used where there is little to no obstacles to push the air around it in a specific direction these fans usually have larger space between the blades and run at lower RPM

Static Pressure fans on the other hand is uses to push as much air through tight spaces such as radiators and cooling tower heatsinks and in some tower cases as intake fans as they have obstetrical like drive cages inches away from the intake vents

Now you should ask your self which Noctua fan is right for my setup?

Here is an overview of the different 120mm models form Noctua

NF-S12A: The NF-S12A has been optimized for “low impedance” applications that don’t require high static pressure and thus combines moderate pressure with outstanding airflow and superb quietness of operation. Choose the NF-S12A for case ventilation, applications with little or no obstruction to airflow as well as all other applications where minimum noise emission has first priority.

NF-P12: The NF-P12 has been designed with more pressure demanding “high impedance” applications in mind. It provides an even balance of high static pressure, high airflow and excellent quietness, which has made it a standard choice for low noise CPU cooling, cases with tight fan grills and other low noise cooling applications with mid- to high airflow resistance.

NF-F12: The NF-F12’s unique Focused Flow™ system produces extremely high static pressure and focuses the airflow in order to achieve even better results on air cooling heatsinks and water cooling radiators. With a top speed of 1500rpm, it also offers more performance headroom for less noise-sensitive applications. Choose the NF-F12 if you’re looking for the best possible performance on heatsinks and radiators.

This information is based on:

Linux and BSD / [How-To] - Enable Serial Com Port in CentOS 7
« on: November 29, 2017, 11:19:37 PM »
[How-To] - Enable Serial Com Port in CentOS 7

In this post I want to share how you enable the serial console to work at boot and have the server send the login screen both to the regular monitor and to the serial com connection in CentOS 7. If you need to know more about what it is or why you should use a serial connection for your servers see my other post: What is a Serial Console, and why would we use it?, but in short is goes something like this:

you connect to your headless server using SSH or WebGUI over IP \ DNS but you messed up some configurations and you are no longer able to access your server over the network, and now you have to find a keyboard and monitor to access it and restore it. and that in it self can be a hassle and if you had serial connection enabled on a rs-232 com port you would only need to connect a console cable to it and do the troubleshooting needed, not to say most of the networking gear like routers and switches you see in business and enterprise environment need to be configured over console connection before they are deployed and you can use SSH or WebGUI over IP \ DNS.

Before I begin the configurations I will make two assumptions:
1. You have a clean and fresh install of CentOS 7 using LVM partitioning.
2. That your server have a working RS-232 Console Port installed and are recognized by the kernel and the drivers are installed.

To make the serial console available at boot we need to adjust the boot loader of the system to send the output to both the console port and the monitor, and to do this you need to login to the system whit a user that has sudo or root access.[/size]

Hardware Information:
Now that you are logged in to your system you want to first check that your Serial Comport is installed, to do this type the command: sudo dmesg | grep tty

Output should look like this example:
Code: [Select]

   [kek@centos7 ~]# sudo dmesg | grep tty
    [    0.000000] console [tty1] enabled
    [    0.000000] console [ttyS0] enabled
    [    1.891572] 00:05: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

In this example I have one input \ output (I\O) console hardware port in the server and that is ttyS0 whit the full path of /dev/ttyS0, note this down as we need it later in the configuration

Now we need to check what LVM labels where given to the system if you used the easy installer option, in most cases it uses the hostname as labels, but since it can break the system if we do not get this part correct we better check as we do not want to do any unnessecary work or troubleshooting, to check LVM labels of your partitions run the command: sudo lvscan

Output should look similar to this:
Code: [Select]

   [kek@centos7 ~]# sudo lvscan
    ACTIVE      '/dev/cl_centos7/swap' [  2.00 GiB] inherit
    ACTIVE      '/dev/cl_centos7/root'  [<17.00 GiB] inherit

What we need to note from this command is the cl_centos7/root and cl_centos7/swap labeles as we need this later to get the device mapper string to point to the correct hard drive partitions for booting.

System Configuration:
Now that we have all the needed hardware information we are ready to configure the serial console and the boot loader, to do this you need to edit the following configuration file: /etc/sysconfig/grub to do this use your favourite text editor like vim or nano (not installed by default), command is: sudo vi /etc/sysconfig/grub

The file should look similar to this before editing:
Code: [Select]

GRUB_CMDLINE_LINUX=" crashkernel=auto rhgb quiet"

You would need to make some changes to this file, as you can see it contains no information about the serial connection or the terminal settings to use, in my setup I use the following configuration:

Code: [Select]

GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"
GRUB_CMDLINE_LINUX="crashkernel=auto rhgb quiet"
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0,115200"

The settings in here should be self explainatory and should be generic egnouh to cover 90% of all serial adapters, but the general descripton of them are:
GRUB_TERMINAL is set to both Console and Serial enabling it for both on screen monitor and serial output.
GRUB_SERIAL_COMMAND sets the value of what speed it should run and how it should communicate whit the remote device these settings needs to match at both sides to make a connection.
GRUB_CMDLINE_LINUX specifies where the swap and root partition is stored for the LVM so the system can boot, this is why we looked up the disk information.
GRUB_CMDLINE_LINUX_DEFAULT tells the boot loader to where it should send the information where tty1 is the monitor and ttyS0 is the Serial port.

At this point you are nearly done, just a few commands left to run as the majority of the configuration is the get the grub config correct, now we just need to enable our Serial connection using the command:
 stty -F /dev/ttyS0 ispeed 115200

You may get an error saying it could not run all of the settings, but do not worry about that for now, next up would be to generate a new bootloader file for grub whit the settings we just saved in
/etc/sysconfig/grub we do that by running the following command: grub2-mkconfig -o /boot/grub2/grub.cfg

Now you are ready to connect the serial console cable and connect from your workstation or laptop using something like screen or putty depending on OS you are using, the console will at this point connect to a black screen as it has not active console running at the moment, and if you are at a blank window whit no errors then you can run the command: sudo /sbin/reboot on your CentOS 7 server and you should see the grub and boot process both on the monitor and the serial terminal window.


Hardware / What is a Serial Console, and why would we use it?
« on: November 29, 2017, 05:22:29 PM »
What is a Serial Console, and why would we use it?

In this post I would like to take the time to tell you a little about Serial Consoles and COM ports, and why we still uses it

What is Serial Console?
The serial console is a connection over the RS-232 or serial port connection that allows a person access to a computer or network device console. Typically, a console is accessed over an SSH connection. However, with software, hardware, or other access problems, it may only be possible to access the machine or device (e.g. routers and switches) over a serial connection. Older computers and headless computer (computers or devices without monitors) also use the serial console as the main way to access the console.

The system console, computer console, root console, operator's console, or simply console is the text entry and display device for system administration messages, particularly those from the BIOS or boot loader, the kernel, from the init system and from the system logger. It is a physical device consisting of a keyboard and a screen, and traditionally is a text terminal, but may also be a graphical terminal. System consoles are generalized to computer terminals, which are abstracted respectively by virtual consoles and terminal emulators. Today communication with system consoles is generally done abstractly, via the standard streams (stdin, stdout, and stderr), but there may be system-specific interfaces, for example those used by the system kernel.

The console is the text output device for system administration messages. These messages come from the kernel, from the init system and from the system logger. On modern small computers the console is usually the computer's attached monitor and keyboard. On many older computers the console is an RS-232 link to a terminal such as a DEC VT100. This terminal is in a locked room and is continually observed by the minicomputer's operators. Large systems from Sun, Hewlett-Packard and IBM still use serial consoles. It is usually possible to login from the console. A login session from the console is treated by many parts of the operating system as being more trustworthy than a login session from other sources. Logging in as the root super-user from the console is the Command Line of Last Resort when faced with a misbehaving system.

Why should we use a serial console?
For the average user a serial console has no advantage over a console offered by a directly attached keyboard and screen. Serial consoles are much slower, taking up to a second to fill a 80 column by 24 line screen. Serial consoles generally only support non-proportional ASCII text, with limited support for languages other than English. A new terminal can be more expensive than an old PC.

There are some scenarios where serial consoles are useful. These are:

 - Systems administration of remote computers
 - High density racks of computers
 - Recording console messages
 - Embedded software development

Systems administration of remote computers
Linux is a good operating system for deployment at unstaffed sites. Linux is also good for hosting critical network infrastructure such as DNS and DHCP services. These services are generally installed at every site of an organisation including sites which may be too small or too remote to have information technology staff. System administration of these remote computers is usually done using SSH, but there are times when access to the console is the only way to diagnose and correct software failures. Major upgrades to the installed distribution may also require console access. In these cases the serial console is attached to a modem. Access to the console is gained from a remote computer by dialing into the modem. This allows the console to be reached from any telephone socket.

High density racks of computers
Clusters of personal computers can outperform mainframe computers and form competitive supercomputers for some applications. See the Cluster-HOWTO for more information on clustering. These clusters are typically assembled into 19 inch telecommunications equipment racks and the system unit of each computer is typically one rack unit (or 1.75 inches) tall. It is not desirable to put a keyboard and monitor on each computer, as a small cathode ray tube monitor would consume the space used by sixteen rack units. A first glance it seems that a monitor and keyboard switch is the best solution. However the VGA signal to the monitor is small, so even with the switch the monitor cannot be placed very far away from the rack of computers. It is desirable to allow the consoles to be monitored in the operators' room of the computer center, rather than in the very expensive space of the machine room. Although monitor switches with remote control and fiber optical extensions are available, this solution can be expensive. A standard RS-232 cable can be 15 meters in length. Longer distances are easily possible. The cabling is cheap. Terminal servers can be used to allow one terminal to access up to 90 serial consoles.

Recording console messages
This is useful in two very different cases.

Kernel programmers are often faced with a kernel error message that is displayed a split second before the computer reboots. A serial console can be used to record that message. Another Linux machine can be used as the serial terminal. Some secure installations require all security events to be unalterably logged. One way to meet this requirement is to print all console messages. Connecting the serial console to a serial printer can achieve this.

Embedded software development
Linux is increasingly being used as an operating system for embedded applications. These computers do not have keyboards or screens. A serial port is a cheap way to allow software developers to directly access the embedded computer. This is invaluable for debugging. Most chip sets designed for embedded computers have a serial port precisely for this purpose. The shipping product need not present the RS-232 port on an external connector. Alternatively the RS-232 port is often used for downloading software updates.

News from the Admin team / Deleted accounts during maintinace
« on: November 29, 2017, 04:21:34 PM »
Hello folks, there as been a few inactive accounts on this forum that was never registered online and as activated accounts, these was today (2017-11-29) deleted from the system if some of these where real and active accounts, please contact one of our admin or moderators staff and we will be looking at restoring your profile back


Pages: [1]