I am using ryu controller and mininet:
I am creating an traffic network classifier using Machine Learning to predict "normal traffic" or "anormal traffic". But now, I have a issue in "how to block the port of the victim host when the traffic is anormal?"
This is my partial code:
*if normal_traffic:
self.logger.info("Normal Traffic...")
elif anormal_traffic:
self.logger.info("Anormal Traffic Detected...")
#How to add mitigation rules?*
Related
I am writing an application using Webview and a local server :
The server part is written in Google Go (Golang).
The client part is written in JavaScript and runs inside Webview.
It's like using Electron, except the communication between the frontend and the backend happens via HTTP on localhost.
My question is:
Since the app is in two parts which communicate via loopback (127.0.0.1), can the network listen to the packets of data transiting between the two parts of my app or is it 100% safe from network sniffing?
Is an app designed this way safe when the computer is plugged on the internet?
To answer the first part, packets to the loopback address do not traverse the network.
127.0.0.0/8 - This block is assigned for use as the Internet host
loopback address. A datagram sent by a higher level protocol to an
address anywhere within this block should loop back inside the host.
This is ordinarily implemented using only 127.0.0.1/32 for loopback,
but no addresses within this block should ever appear on any network
anywhere [RFC1700, page 5]
localhost traffic can't be sniffed locally.
To answer the second part, it's protected from sniffing on the Internet, but localhost traffic can be sniffed on the host. Therefore if you have a breach via the Internet it would be possible for someone to obtain localhost traffic.
References
RFC3330
I have a fedora workstation with 5 physical network interfaces on it.
Four of the network interface have ip 10.10.10.11 10.10.10.12 10.10.10.13 10.10.10.14.
There runs a filerun serice(port 8081),a gitlab serivce(port 8082), and a transmission(port 8083) service via docker. On my mac, I could access 10.10.10.11:8081 or 10.10.10.12:8081 or 10.10.10.13:8081 or 10.10.10.14:8081.
What I want is to access filerun via 10.10.10.11:80, gitlab 10.10.10.12:80, transmission via 10.10.10.13:80. How to configure the network?
Thanks a lot.
You have to bind on the right IP address/interface each service using the same port.
Ports (UDP or TCP) have their own pool per IP address.
You can listen on the same port if you change IP address or protocol (UDP or TCP).
See: http://www.bleepingcomputer.com/tutorials/tcp-and-udp-ports-explained/
Alternatively you could use a webserver like NGINX as a reverse proxy and bind the services to a specific ip address and port. Here you would also benefit in caching content and web acceleration for improved performance.
Find out how to set it up: https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/
I have built a d3.js dashboard that ties into a tornado websocket. Everything works perfectly locally. I now would like to have the ability to share the websocket with a few friends, nothing production. Is there a way to do this without a big deployment on Heroku or other similar service? I've googled and can't seem to find an answer. Thanks
Not specific to Tornado. This is more of a networking question.
What you want to do is:
Run your server on your computer.
Connect to the internet.
Note down your public IP address.
Give your IP address to your friends.
Certain things you need to take care of:
Run your server on a higher, non-standard port (e.g. 8000 would be good) because ISPs block traffic to port 80 and other standard ports.
The IP address assigned to you by your ISP will most probably be dynamic. That mean, every time you diconnect and reconnect to the internet, your IP address will change.
Turn off your computer's firewall to let in the traffic at whichever port your server is running.
Finally, you'll need to configure port forwarding on your router. What that means is all the incoming HTTP requests will arrive at your router at your public IP address. But your computer where you'll be running your server will have an internal IP address assigned by your router. So, you'll need to forward incoming requests to your computer's internal IP.
I'm developing a proof-of-concept of some kind of transparent proxy on Linux.
Transparent proxy intercepts TCP traffic and forwards it to backend.
I use https://www.kernel.org/doc/Documentation/networking/tproxy.txt and spoofing sockets for outgoing TCP connection.
On my dev PC I was able to emulate network using Docker and all works fine.
But I need to deploy test environment on AWS.
Proposed design:
Three VMs within the same subnet:
client, 192.168.0.2
proxy, 192.168.0.3
backend, 192.168.0.4
On client I add route to 192.168.0.4 thru 192.168.0.3
On proxy I confugure TPROXY to intercept TCP packets and forward it to backend with 192.168.0.2 IP source address. Here our transparent proxy works.
On backend I run simple web server. Also I add route to 192.168.0.2 thru 192.168.0.3 otherwise packets will go back directly to 192.168.0.2
The question:
Will proposed network design work as expected?
AWS uses some kind of software defined network and I don't know will it work in the same way as I would connect 3 Linux boxes to one Ethernet switch.
Will proposed network design work as expected?
Highly unlikely.
The IP network in VPC that instances can access is, from all appearances, an IP network (Layer 3), not an Ethernet network (Layer 2), even though it's presented to the instances as though it were Ethernet.
The from/to address that is "interesting" to an Ethernet switch is the MAC address. The from/to address of interest to the EC2 network is the IP address. If you tweak your instance's IP stacks by spoofing the addresses and manipulating the route tables, the only two possible outcomes should be one of these: the packets will actually arrive at the correct instance according to the infrastructure's knowledge of where that IP address should exist... or the packets will be dropped by the network. Most likely, the latter.
There is an IP Source/Destination Check Flag on each EC2 instance that disables some of the network's built-in blocking of packets the network would otherwise have considered spoofed, but this should only apply to traffic with IP addresses outside the VPC supernet CIDR block -- the IP address of each instance is known to the infrastructure and not subject to the kind of tweaking you're contemplating.
You could conceivably build tunnels among the instances using the Generic Route Encapsulation (GRE) protocol, or OpenVPN, or some other tunneling solution, and then the instances would have additional network interfaces in different IP subnets where they could directly exchange traffic using a different subnet and rules they make up, since the network wouldn't see the addresses on the packets encapsulated in the tunnels, and wouldn't impose any restrictions on the inner payload.
Possibly related: In a certain cloud provider other than AWS, a provider with a network design that is far less sensible than VPC, I use inter-instance tunnels (built with OpenVPN) to build my own virtual private subnets that make more sense than what that other cloud provider offers, so I would say this is potentially a perfectly viable alternative -- the increased latency of my solution is sub-millisecond.
But this all assumes that you have a valid reason for choosing a solution involving packet mangling. There should be a better, more inside-the-box way of solving the exact problem you are trying to solve.
I have a RHEL client machine which has to get data from the RHEL server machine at the time of booting up.
The IP address of the server is known.
The gateway which has to be used by the client machine is known.
The client machine has multiple network interfaces. All may not be up at the same time or all may be connected to different networks.
I need to determine which network interface has to be used.
I know that this can be easily done using the "ping" or "traceroute".
The issue is ICMP protocol is disabled both at the client end as well as the server end.
ICMP has been disabled due to security concerns.
ICMP may be disabled at machine level or it may be disabled for the whole network.
In otherword, I need to find a way that can give me if two ip's are communicating if ICMP is disabled.
Also, I have to use this result in my script, which I am writing in bash, to set the network of the client machine.
What is the best possible way to achieve this?
You can ping the ip with ARP try using arping command