I want to run predfined 10 eth miners on private network so no one can enter the network except the 10 miners that I want.
I initialized a network using geth and I enabled --nodiscover option.
Is that enough to secure my network ?
Note: the network is on internet not local network
Related
I have a EC2 machine in public Subnet, In Security group I have only opened 22 port for my public static IP. How safe is it?
As per your comment
if i keep open security group for certain IPs, I am quite unsure
whether it is safe or not because there are multiple Hops b/w that IPs
and AWS IPs(packet data travels through it). am i correct ? and that
application can be accessible from that Hops?
It is absolutely safe to use the ssh port unless there is a vulnerability found in the future in the ssh protocol itself.
Firstly, you are restricting the access only from a static IP so no one else should be able to initiate the ssh session from any other machine.
Secondly, if you have protected your ssh private key and it is not shared then anyone else from the same static IP wouldn't be able to start an ssh connection.
Thirdly, ssh connection creates a secure encrypted data pipe between the client and servers, so even if someone tries to sniff the packets as it passes through different hops, it is hard to make any sense as all the data is encrypted.
Considering all of the above, in my opinion it is quite safe.
We have 3 ESXi servers that each have their public IP for manageability, however for the backups we need the servers to have an internal on a different NIC.
However, when we've added a new VMKernel network, the original (public IP) network won't connect anymore, resulting in the server being only reachable via the newly added LAN network.
Is there a solution we can use so the servers are reachable on both NICs/IPs ?
The 3 servers have these configuration for network:
Interface 1: Dell iDRAC
Interface 2: VMWare public management network (public)
Interface 3: VMWare private management network (10.0.0.1/24)
Interface 4-5: Double redundant uplink
Interface 6-7: LAN network trunked
You may use the same switch (with 2 uplinks and explicit LBFO settings for different port groups) or two different switches each using its own uplink - one for external and another for internal management network.
I think you can keep external management network setup as it is now (same vSwitch, same management port group, the same vmk0 adapter in default TCP/IP stack). This vmk0 adapter may have IP configuration like this:
IP: 192.168.5.5/24
GW: 192.168.5.1 - it may be defined for default TCP/IP stack or on vmk0 itself
For internal management network, just create another vSwitch, new management port group and new vmk1 adapter. Imagine you want to use internal management network like this:
IP: 10.5.5.5/24
GW: 10.5.5.1
Because we cannot have 2 gateways in default TCP/IP stack, you can define gateway directly on vmk1 (this is supported in ESXi 6.5):
esxcli network ip interface ipv4 set -g 10.5.5.1 -i vmk1 -t static -I 10.5.5.5 -N 255.255.255.0
Once you do this, I think both internal and external management networks should work for you. There may be some edge cases with routing where this scheme may not work, but I think for your use-case it should be fine.
In general there is not a problem with having two or more management interfaces. You should to give us some more information about network configuration. Did you change default gateway in host configuration? Remember that you may have only one default gateway and if you have changed it to correct for LAN then packets get by public interface not know how to return.
If this is the problem you should set default gateway properly for public interface. But you also need to connect from LAN. If machines in LAN are in the same network segment - it should just work. If machines are in other LAN - add entry to routing table, like described here: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2001426
I downloaded ethereum wallet for MacOS and I chose private network, but it is taking too long when downloading blocks, it is almost not moving. Is that normal?
Why it is downloading blocks when choosing private network? From where the blocks are downloaded? Is it from centralized servers or from peers like torrent?
To choose your local private network.
You have to start geth client in private network ( --networkId 3423 ).
After that when you start ethereum wallet. it will sync with your local network.
After launching Ethereum Wallet you can chose between Test Network and Main Network:
That has nothing to do with private or public, yet. The main network is the public Homestead network and the test network is the public Ropsten network.
The blocks are downloaded from peers: There are no servers hosting the blockchain but a full decentralized peer-to-peer network serving the block and state data.
If you want to launch a private network only for yourself, you need to configure your client with a custom network ID and genesis file.
I am trying to set up a private ethereum network to run within a set of 5 machines connected over LAN. As mentioned in the ethereum documentation I used a custom --networkid 15693 to set up the network, however when I run geth on different machines and form some initial connections using admin.addPeer() it just stays that way; the peer discovery doesn't seem to be working. For example, I have nodes 1, 2, and 3 such that connections are 1--2 and 2--3, so why is 3 not able to discover 1 ?
EDIT
If I setup the network locally(within a machine) then nodes are able to discover and connect to each other, however over the LAN it fails.
I have created a VPC with public and private subnets on AWS. All app servers are in private subnets and all outbound requests have to be through an internet-facing NAT instance.
At the moment, our project requires the app servers to access a ftp server provided by a service provider.
I have tried several ways to manage that, but all no luck. What I have done was to open a port range, let's say (40000 - 60000) on both NAT and APP security groups, also standard ftp ports 20 - 21 as well.
The user authentication can be passed, but I could not list contents from app servers.
I am able to access the ftp server from NAT, not problem at all.
So what should I do to make it work?
#JohnRotenstein is absolutely correct that you should use Passive FTP if you can. If, like me, you're stuck with a client who insists that you use Active FTP because their FTP site that they want you to connect to has been running since 1990 and changing it now is completely unreasonable, then read on.
AWS's NAT servers don't support a machine in a private subnet connecting using Active FTP. Full stop. If you ask me, it's a bug, but if you ask AWS support they say it's an unsupported feature.
The solution we finally came up with (and it works) is to:
Add an Elastic Network Interface (ENI) in a public subnet on to your EC2 instance in the private subnet
So now your EC2 instance has 2 network adapters, 2 internal IPs, etc.
Let's call this new ENI your "public ENI"
Attach a dedicated elastic IP to your new public ENI
Let's assume you get 54.54.54.54 and the new public ENI's internal IP address is 10.1.1.10
Add a route in your operating system's networking configuration to only use the new public ENI
In windows, the command will look like this, assuming the evil active ftp server you're trying to connect to is at 8.1.1.1:
route add 8.1.1.1 mask 255.255.255.254 10.1.1.1 metric 2
This adds a route for all traffic to the FTP server at 8.1.1.1 using subnet mask 255.255.255.254 (ie. this IP and only this IP) should go to the internet gateway 10.1.1.1 using ethernet adapter 2 (your second NIC)
Fed up yet? Yeah, me too, but now comes the hard part. The OS doesn't know it's public IP address for the public EIN. So you need to teach your FTP client to send the PORT command with the public IP. For example if using CURL, use the --ftp-port command like so:
curl -v --ftp-port 54.54.54.54 ftp://8.1.1.1 --user myusername:mypass
And voila! You can now connect to a nightmare active FTP site from an EC2 machine that is (almost entirely) in a private subnet.
Try using Passive (PASV) mode on FTP.
From Slacksite: Active FTP vs. Passive FTP, a Definitive Explanation:
In active mode FTP the client connects from a random unprivileged port (N > 1023) to the FTP server's command port, port 21. Then, the client starts listening to port N+1 and sends the FTP command PORT N+1 to the FTP server. The server will then connect back to the client's specified data port from its local data port, which is port 20.
Thus, the traffic is trying to communicate on an additional port that is not passed through the NAT. Passive mode, instead, creates an outbound connection, which will then be permitted through the NAT