Monday, 29 June 2020

Ethics and Port Scanning



Port scanning, for those who are not totally clear on the practice, is the ability for a computer to send specially tailored packets to another machine and receive a response packet in return.  The response will tell the sender if ports are open or closed.  Depending on the tool and method of scanning you use, you will also garner additional information such as: services available, present operating system, and tons more.

In this blog I will not be teaching you what port scanning is.  Honestly a quick google of "what is port scanning?" will tell you what you need to know.  Our discussion will revolve around the ethics of port scanning.

(I also understand that I am not a philosopher, however with my passion for security ethics is a topic that is always close at hand).

Why be concerned about ethics and port scanning? With this particular skill, ethics should never be far from your mind.  These two concepts(ethics, port scanning) must be married together so that you, the avid system admin, understand how to conduct yourself "ethically" in the professional landscape.

Ethics deal with the "principles that govern the individual or group."  I understand this definition of ethics is fairly general.  However I thought I would share how I understand ethics and how it was taught to me by my IT Security Instructor over a decade ago. (Thanks Tim).

Ethics are a guiding principal for the individual.  My personal ethics create a framework for what I think is right and wrong. 

Ethics differ from morals generally in that there are some things that we as people think are wrong.  Morals are over arching and ethics are more personal.

Now let's talk about port scanning:

Before we start I want you to picture a hammer.  You know, the kind you use to slam a nail into a wood board.

What can you do with it?

In the hands of a skilled person one could build what ever they want.  They could even, if the job required it, disassemble something that was built.

Now with that same hammer ask yourself this, could a person smash a car window and grab a purse that is sitting on the front seat?

Yes, it's possible.

Is the hammer bad?  Did the hammer make the person build or destroy?

I say no.

In both of these cases there was clear intent.  I want to build something, I use my hammer.  I want to steal the purse, I use my hammer.
The hammer is a tool, just like port scanning is a tool.  You can use port scanning for good and bad.

There are so many reasons to use port scanning.

Manage Assets: "What do we have on our network?"

-You could use port scanning to help with budgeting, like determining what percentage of present devices are still using old operating systems.
-Monitor for devices that should not be on network
-Analyze devices (printers for example) to assess open ports so you can connect to it.
-Analyze devices to audit your own network for security compliance.
-Firewall testing

The Problem

The issue that people have is that quite often port scanning precedes a security event.  For example: I scan your computer for open ports, I determine you have an old version of ssh.  I bring up metasploit and I craft a exploit/payload tailored to your machine.  Launch exploit.  I now have full access to your machine.  If I had determined the version of your ssh my attack would not have worked.  I started with a port scan.

Now we begin to see how port scanning falls into a bit of a gray area.  Port scanning's primary function is to check for open/closed ports.  Should you be checking ports where you are not invited?  There is a popular analogy about a person walking through a neighbourhood walking up to houses and checking door knobs to see if the door is unlocked.  Is it bad to check doors? The person is not necessarily doing something "wrong." The problem here is that the act of checking the door is still invasive.

Pair this gray area with the fact that our legal system(Canada) really doesn't understand what port scanning is.  It is unclear generally what can be done about folks who actively port scan.  The only law that somewhat pertains to this activity is one in reference too tampering with radio frequencies.  You could potentially get away with claiming you were just "knocking on the door."

***Personal Opinion Alert***
Port scanning is not new.  It has been around a long time, the capabilities of the practice have grown immensely since it's conception.

The old guard ("powers that be", legal systems, etc.) who do not understand what the internet is, are "dyng out."  They are being replaced with people who have never lived in a time where the internet was not a thing.  Port scanning like other security norms, is known and present.  Rules and laws will be built to protect organizations and individuals from supposed "attacks" brought on by port scans.  I predict that the future of port scanning will be less gray and more black and white.  Gone will be the days where we can scan without fear of reprisal.

So with all that being said.  Hopefully you are clear on your own ethics.  Read up on laws in your area so that you can understand the risks.  Generally though, there are a couple things you should do.

Protect yourself.
1. Ask permission to scan
2. Build port scanning into your security policies


Thanks,
Andrew Campbell


Reference:





Monday, 22 June 2020

Dear Client: Security


The following is a fictitious letter to the "Every Client."  That client who trusts their MSP (Managed Service Provider) implicitly.  The client that knows that IT Infrastructure is important, but doesn't truly understand how IT supports their business. 

Dear Client:

Let's talk about security.  I know you know it's important.  We hear about it in the news all the time.  You dread the thought of an incident actually happening to your business.  I dread that too.

There are some things that we can do together too help protect your business.

1. Be Aware:
Client, you should be aware of what is happening, security related, with your business.  Do you need to be so granular that you have a detailed list of every Firewall rule?

No. 

It's my job to understand how your system could be targeted by, for example a Denial of Service attack.......However....... You should be aware that things like that (DOS) are happening.  You should know that that Firewall, Intrusion Detection, System, logs exist.  You should know that these logs contain the story of what has been going on with your business(security specifically).

2. Ask Questions:
I will do my best with the resources you have made available.  This is your business we are talking about and I am here to support it.  You should be aware of what the greatest security threat to your organization is. *cough employees.

It is not good enough to just believe your MSP.  If I tell you that "...this vendor is really good (Hadware Firewalls)." Ask me why?  Understand why some decision is better then the other.  Why did I pick this product to protect you?  Why did I select a more expensive option?  You have hired me because I am an expert, you trust that I know the difference between an apple and an orange when it comes to security.  Ask me, and I will tell you.  I like it when you are curious.  I like it when you want to understand the process of security.  I'm here to keep your business safe, you might as well understand how I am doing that.

3.  Ignorance is Not an Option:
We no longer live in a time where we can claim ignorance of security.  Your clients expect you to keep their data safe.  They expect you to support and/or provide a service too them. 

The internet is like the wild west, and security events are happening all the time. 

Your business could be targeted randomly/intentionally for an attack an any point.  Your employee could be lured into clicking on a phishing scam and then all of a sudden someone could be stealing or destroying your data.

If all else fails read tip 1 again ;)

Your IT Security Provider







Monday, 15 June 2020

Analysis of Firewalld created IPTables

Let's talk about IPtables and Firewalld.

IPtables is Unix' defacto firewall solution.  Super powerful, get's the job done, you can roll this solution out immediately.  You can incorporate scripting elements into implementation of IPTables to automate/simplify the job.  IPtables have been around a while, since 1998.

Many sysadmins utilize IPtables, honestly I don't see it going away anytime soon.  With a single line including arguments you can direct traffic between networks(forwarding) and control all traffic in and out of a system. 

Getting started with IPtables is not for the faint of heart however.  When you first get started you quickly realize that you have to think about everything when designing rules, "how does the traffic flow?" "What exactly is happening when the user does _____?""How do I appropriately administer 'Deny first-then allow'?"

Studying IPtables is an important part of fully understanding how FW work.  All this being said, a lot of smart people have worked on solutions to simplify tools.  Here we see Firewalld.

Firewalld is a application that is based on IPtables.  It provides the user with a terminal interface that allows the user to completely manipulate the FW.  Firewalld also brings in useful elements such as zones which are helpful for FW solution building.  For those who would rather use a gui, they can install "firewall-config" and get a very nice gui that makes the job that much easier.

Goal:  If both solutions utilize IPtables how if at all do the IPtables look different from one another.

Scenario: Target set to DROP, and only allowing user access to the internet.

Because IPtables ship with the default policy of ACCEPT(allowing everything) we need to turn everything to DROP (disallow everything)
 
iptables –-policy INPUT DROP
iptables –-policy OUTPUT DROP
iptables –-policy FORWARD DROP 

Now our user is only allowed to connect to the internet.  We know that http is over port 80 and https is over port 443.  Also keep in mind that our user will need to resolve with DNS, port 53.

-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -P TCP -m tcp --dport 443 -j ACCEPT

-A OUTPUT -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT

-A OUTPUT -p tcp --dport 80 --syn -m state --state NEW -j ACCEPT

-A OUTPUT -p tcp --dport 443 --syn -m state --state NEW -j ACCEPT

-A OUTPUT -p tcp --dport 53 --syn -m state --state NEW -j ACCEPT


Let's look at a few of these lines and see what is happening.

-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -P TCP -m tcp --dport 443 -j ACCEPT

Here we have rules for packets coming in. Hence INPUT, we are setting the protocol to tcp, choosing a destination port (80 and 443) and accepting packets through these ports.

Keep in mind that everything IN/OUT is set to DROP.  So packets will only come in on port 80 and 443.

Next lets look at OUTPUT.  With IPtables if you have a rule for INPUT you have to have a similar/equal rule for OUTPUT (unless OUTUT is set to ACCEPT)

For the most part things are operating in a similar fashion, so lets highlight a few key differences. 

We can see that we are working with the same ports 80 and 443,
with the addition of:
--syn -m state --state NEW We are setting "--syn" which can also be interpreted as
--tcp-flags FIN,SYN,RST,ACK SYN

Next is "-m state --state NEW"  we are matching the state NEW.

Finally we are including the port 53.  We need to be able to resolve addresses.

Seems simple enough right?  Let's see how Firewalld handles the exact same scenario. (#iptables -S ) output below.

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N INPUT_direct
-N INPUT_ZONES
-N FORWARD_direct
-N FORWARD_IN_ZONES
-N FORWARD_OUT_ZONES
-N OUTPUT_direct
-N IN_security
-N IN_security_pre
-N IN_security_log
-N IN_security_deny
-N IN_security_allow
-N IN_security_post
-N FWDI_security
-N FWDI_security_pre
-N FWDI_security_log
-N FWDI_security_deny
-N FWDI_security_allow
-N FWDI_security_post
-N FWDO_security
-N FWDO_security_pre
-N FWDO_security_log
-N FWDO_security_deny
-N FWDO_security_allow
-N FWDO_security_post
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED,DNAT -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -j INPUT_direct
-A INPUT -j INPUT_ZONES
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED,DNAT -j ACCEPT
-A FORWARD -i lo -j ACCEPT
-A FORWARD -j FORWARD_direct
-A FORWARD -j FORWARD_IN_ZONES
-A FORWARD -j FORWARD_OUT_ZONES
-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -j OUTPUT_direct
-A INPUT_ZONES -i wlan0 -g IN_security
-A INPUT_ZONES -g IN_security
-A FORWARD_IN_ZONES -i wlan0 -g FWDI_security
-A FORWARD_IN_ZONES -g FWDI_security
-A FORWARD_OUT_ZONES -o wlan0 -g FWDO_security
-A FORWARD_OUT_ZONES -g FWDO_security
-A IN_security -j IN_security_pre
-A IN_security -j IN_security_log
-A IN_security -j IN_security_deny
-A IN_security -j IN_security_allow
-A IN_security -j IN_security_post
-A IN_security -j DROP
-A IN_security_allow -p tcp -m tcp --dport 53 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A IN_security_allow -p udp -m udp --dport 53 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A IN_security_allow -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A IN_security_allow -p tcp -m tcp --dport 443 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A FWDI_security -j FWDI_security_pre
-A FWDI_security -j FWDI_security_log
-A FWDI_security -j FWDI_security_deny
-A FWDI_security -j FWDI_security_allow
-A FWDI_security -j FWDI_security_post
-A FWDI_security -j DROP
-A FWDO_security -j FWDO_security_pre
-A FWDO_security -j FWDO_security_log
-A FWDO_security -j FWDO_security_deny
-A FWDO_security -j FWDO_security_allow
-A FWDO_security -j FWDO_security_post
-A FWDO_security -j DROP


The first thing you should notice is that all three policies are set to ACCEPT.  From a security standpoint this goes completely against "deny first - then allow."  However if we take a step back and look at how Firewalld functions, we will see that it uses on zones.  Some zones come prepackaged with Firewalld and you can guess that some of the default zones are a lot less restrictive than what we are going for here.  Hence why everything is open(ACCEPT).  Firewalld accepts all input then filters it to the required zone specified set to default.  Since our zone is set to DROP everything, then we are ok.

Next we see a bunch of lines beginning with "-N."  Basically what is happening here is that our zone "security" exists and all the direct rules that pertain to this zone are in place.

Now the really interesting part, how firewalld is handling INPUT

-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED,DNAT -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -j INPUT_direct
-A INPUT -j INPUT_ZONES
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED,DNAT -j ACCEPT
-A FORWARD -i lo -j ACCEPT
-A FORWARD -j FORWARD_direct
-A FORWARD -j FORWARD_IN_ZONES
-A FORWARD -j FORWARD_OUT_ZONES
-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -j OUTPUT_direct
-A INPUT_ZONES -i wlan0 -g IN_security
-A INPUT_ZONES -g IN_security
-A FORWARD_IN_ZONES -i wlan0 -g FWDI_security
-A FORWARD_IN_ZONES -g FWDI_security
-A FORWARD_OUT_ZONES -o wlan0 -g FWDO_security
-A FORWARD_OUT_ZONES -g FWDO_security
-A IN_security -j IN_security_pre
-A IN_security -j IN_security_log
-A IN_security -j IN_security_deny
-A IN_security -j IN_security_allow
-A IN_security -j IN_security_post
-A IN_security -j DROP
-A IN_security_allow -p tcp -m tcp --dport 53 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A IN_security_allow -p udp -m udp --dport 53 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A IN_security_allow -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A IN_security_allow -p tcp -m tcp --dport 443 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A FWDI_security -j FWDI_security_pre
-A FWDI_security -j FWDI_security_log
-A FWDI_security -j FWDI_security_deny
-A FWDI_security -j FWDI_security_allow
-A FWDI_security -j FWDI_security_post
-A FWDI_security -j DROP
-A FWDO_security -j FWDO_security_pre
-A FWDO_security -j FWDO_security_log
-A FWDO_security -j FWDO_security_deny
-A FWDO_security -j FWDO_security_allow
-A FWDO_security -j FWDO_security_post
-A FWDO_security -j DROP


Very similar to our original IPtables where we are matching state.  Firewalld is utilizing conntrack-tools , a free software that interacts with the in-kernel Connection Tracking System. 

As you can see at the beginning we are matching for various states that will allow our user to have connections outside of their machine.

I want to draw your attention to a specific rule.

"-A INPUT -m conntrack --ctstate INVALID -j DROP"

This is a very useful rule, which should be included in every FW solution.  Essentially what is happening here is that if a packet that was not intended to be received occurs, DROP it.  For example your system receives a random SYN-ACK, first of all it is out of order in regards to the three-way-handshake.  It.is.just.not normal.  Another example, what if your machine receives an RST packet randomly.  Not a typical out-of-the-blue situation. 

Both of these examples could show that potentially your system is being scanned, or potentially a DOS is occurring.

Now we can see a few lines down some content that I selected myself. 

When I created the zone 'security' I had manually set my target to DROP

-A IN_security -j DROP

The line above is saying "in the zone 'security' drop everything"


-A IN_security_allow -p tcp -m tcp --dport 53 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A IN_security_allow -p udp -m udp --dport 53 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A IN_security_allow -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A IN_security_allow -p tcp -m tcp --dport 443 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT

These next 4 are ports that I specificed --> DNS/HTTP/HTTPS.  Notice that we are looking for NEW (referring to the first packet of a connection) and UNTRACKED ("UNTRACKED: Any packets exempted from connection tracking in the raw table with the NOTRACK target end up in this state." See references at end)

Finally the IPtables finishes with how traffic is to be forwarded inside our zone.  Since our scenario does not call for any forwarding, these rules are effectively empty.  They exists here only because they are part of the 'zone' template.

So there you have it, we have taken a closer look at how Firewalld uses IPtables.  Zones are a useful aspect to the FW solution.  The fact that Firewalld automatically includes some very useful IPTables rules, without the user even needing to specify is also very helpful. 

IPtables are powerful for filtering and directing traffic, Firewalld takes an already powerful solution and removes some of the complexity and makes FW management more available to the masses.


References:








Monday, 8 June 2020

The Good the Bad and the Proxy

Hello All,
*(There are two main parts to this post and I am fully aware that they contradict each other.  First Part: Discuss the dangers of free proxies.  Second Part:  How to automatically obtain a list of hundred of free proxies. )

The topic for today is Proxy Servers, specifically shady "free" ones.  For those who are not totally familiar with what a proxy is or what it can be used for.  A proxy acts like a middle man between you(your machine) and your destination(a website, or some hosted application). 
Without a proxy, which is how most of us surf the internet, you open your browser type the address in and you are taken to the site you asked for.  Behind the scenes there is a lot going on, specifically what we are narrowing in on is that the website knows where the visit came from.

If anonymity is important to you then you may want to send your internet traffic through a proxy. 

Here is how it works:

If I am living in a city in Alberta Canada and want to access a website, but I would like to hide the fact that the originating website request was made from Alberta I could send my request to a proxy in Mexico which would then forward the request to the desired website.  The desired website would receive the request however it would not see Alberta Canada as the originator it would see Mexico.  It would then send the appropriate HTTP packet back along its way to Mexico which then sends it to me in Alberta.

Here is where the benefit and problem occur.  Yes I hid my location, that was the desired result.  However it comes at a cost.  Since the traffic is passing through a middle man, what's to stop the middle man from modifying the data in some fashion?  For that matter how do I know for sure that the traffic that I am receiving back has not been altered in some way?

What is there to gain from offering free proxies?  Maybe the folks serving the free proxies have a contract with some advertiser and are able to modify the ads you see on the website that is fed back to you?  Nothing is free.

Like everything in security you have to measure your risks.  While researching for this post I was wrestling with the idea of how to collect free proxies.  So I found a way.  Utilizing Python one can scrape websites offering free proxies.

Below is a snippet of the free proxies you can get with my script (Run June 5, 2020 17:17). 
These are just a few of the 600 you can get.  You can find a copy of the script under my Projects page.

118.174.232.106 : 50491 --- Thailand --- 1 minute ago
190.166.249.44 : 37359 --- Dominican Republic --- 1 minute ago
107.178.4.215 : 35330 --- United States --- 1 minute ago
202.29.220.34 : 61153 --- Thailand --- 1 minute ago
103.50.154.4 : 57677 --- India --- 1 minute ago
195.209.176.2 : 8080 --- Russian Federation --- 1 minute ago
81.217.151.218 : 56193 --- Austria --- 1 minute ago
213.6.158.192 : 33746 --- Palestinian Territory --- 1 minute ago
103.251.225.18 : 35101 --- India --- 1 minute ago
178.215.76.193 : 53281 --- Russian Federation --- 1 minute ago
90.189.209.127 : 80 --- Russian Federation --- 1 minute ago
160.2.38.41 : 8080 --- United States --- 1 minute ago


Obviously you need to understand the risks of utilizing free proxies.  Be careful.

Andrew Campbell











Proxy Picture

Monday, 1 June 2020

HTTP and Request Smuggling

Hello All,
I recently stumbled upon an article that detailed an interesting exploit.  It is one that has been around for awhile and if accurately executed could have a disastrous impact on an organization.  Today we are talking about "Request Smuggling."

As I do when I begin traveling down the rabbit hole of security, I begin planning all kinds of cool fun scripts that could compliment the concept that I have been studying.  For this script today, this is no different.  However I had to scale back, I had a ton of features added that would make an interesting product.  In the end I decided to remove these add-ons and include in a separate package later.  In this script we are focusing on http headers only and obtaining the required information from them.

I hope that you did read the article, is was well done.  As a high level description, the passage of information between your machine and a the back end server hosting the site you are visiting may have multiple layers of servers between them.  This process is becoming more and more common as hosted environments are moved to cloud solutions.  Incorrect settings between front facing servers and back end servers may allow a person with malicious intent to package malware etc. on to additional http packets coming through.  Specifically we are looking for a relationship between Tranfser-Encoding and Content-Length.

These in themselves are normal and happen all the time. however if packaged together incorrectly a connection could potentially leave a server in a state where it would disregard the content length.  Which leaves us with a vulnerability very similar to a buffer over flow. Also justifying the name "Request Smuggling."  The attacker is smuggling his/her own code in with another HTTP request.

Below I have added my script that retrieves headers for target site.  Ideally this script would be used by an auditor(yourself) to analyze the headers that are present on your site.  The information gathered here is transferred between the host machine and the server every time someone visits the website.  There are actually tons of ways to analyze http headers.  My way here is not unique, however I have added additional features that make it interesting.

Extra features:
  • I intentionally make three separate requests to the site.  The purpose for this is that the script is primed for you to utilize proxies.  When you are scraping or accessing a site frequently to gather information, it is a good idea to obscure your location.  Also proxies assist in privacy.  You will see that I have a section for you to add proxies.  When you add your proxy change this line in each function
    • r = requests.get(var) ----->r = requests.get(var,proxy=proxies1) [modify appropriately for the function]
    • The vision was that you would use three different proxies.
  • Multiprocessing:  As soon as I added three separate requests it became immediately evident that multiprocessing was needed. You could use a proxy from Belarus and in the next function use a proxy from Mexico.  Your request would effectively be connecting to and hopping along large distances.  While we actually do this all the time while we hop along the internet it is nice for things to go a little faster.  For those familiar with interpreted languages you understand that the process is very linear.  Multiprocessing allows us to better utilize our host machines.
You can run the script from the terminal as follows:

python3 http_view.py https://mytargetsite.com

***Always be careful using free proxies online.  Nothing is free.  Free proxies are known to manipulate the traffic traveling through them.  I only use free proxies when I don't care that my traffic is being manipulated.  Why would I not care?  Well that is a discussion for another blog entry ;)

Enjoy!

import requests
import sys
from multiprocessing import Process
from bs4 import BeautifulSoup
import socket

var = sys.argv[1]

proxies1 = {
    
    'http': 'http://50.233.42.98:51696',
    'https':'http://50.233.42.98:51696'
}
proxies2 = {
    
    'http': 'http://50.233.42.98:51696',
    'https':'http://50.233.42.98:51696'
}
proxies3 = {
    
    'http': 'http://50.233.42.98:51696',
    'https':'http://50.233.42.98:51696'
}

print("utility to collect HTTP Headers!\n")

def r():
    print("\n\n")
    r = requests.get(var)#proxy=proxies1
    for key, value in r.headers.items():    
        print(key,"###",value)
    r.close()

def p():
    print("\n\n")
    p = requests.head(var)#proxy=proxies2
    print("#"*20)
    for key, value in p.headers.items():
        print(key,"##",value)
    p.close()

def o():
    o = requests.options(var)#proxy=proxies3
    print("\n\n")
    print("#"*20)
    for key, value in o.headers.items():
        print(key,"##",value)
    o.close()

myProcess1 = Process(target=r)
myProcess2 = Process(target=p)
myProcess3 = Process(target=o)


myProcess1.start()
myProcess2.start()
myProcess3.start()