after specifying Tor exit node country , I get Netherlands instead of Italy.
That doesn't sound like normal behavior, anyone knows what could be the problem.
Configuration is Ubuntu 14.04 and Tor (apt-get) version 0.2.4.20 (git-0d50b03673670de6).
Configuration file:
Log notice file /var/log/tor/notices.log
VirtualAddrNetwork 10.192.0.0/10
StrictExitNodes 1
ExitNodes {it}
StrictNodes 1
AutomapHostsSuffixes .onion,.exit
AutomapHostsOnResolve 1
TransPort 9040
TransListenAddress 192.168.100.1 #(assuming this is the static IP address of the server)
DNSPort 9053
DNSListenAddress 192.168.100.1
Your configuration isn't correct but Tor wasn't able to build a circuit using an exit node in Italy most likely because there isn't the capacity to.
As you can see from the data here, there aren't many exits in Italy at all and they all have very low bandwidth capacity so your Tor client wasn't able to use any of them.
Some may not even be suitable for you depending on whether their exit policies allow what you are trying to access.
Related
I have a VPS running ubuntu 20.04 that I'm trying to setup as a SSH server.
On my first try I got overrun by Chinese bots. I deleted everything and started from scratch.
I installed and setup fail2ban, currently on about 2000 banned ip.
I removed root login, setup a new random username, with a 12 char password.
But sometimes when i run netstat -tpna i still get results like this
These are again Chinese ip addresses. These 2 disappeared after a couple of seconds.
Is it something I'm missing here? Are these 2 really connected to my server ? How ?
Or is it just that I don't really understand how netstat works ?
I am indeed planning on removing password login, using just ssh keys, but after I finish setting up the VPS.
Thank you for your help.
On my first try I got overrun by Chinese bots
Regardless of IDS (fail2ban etc) it is always advisable to change port sshd listening on something else (if you don't necessarily bound on 22 for some reason).
i still get results like this ... ESTABLISHED ...
This can basically have 2 major reasons:
this IPs are not (yet) banned due to some missing rule or not fully covered "attack" vector.Did you check the IPs were really banned? See also first answer in wiki :: FAQ.
If there just no finding for this IPs at all in fail2ban.log ([sshd] Found 192.0.2.1), you may also try to set mode = aggressive for the jail. And check whether your fail2ban version or your sshd filter is not too old, e. g. here is actual filter for latest v.0.10. There is no guarantee that this filter would work with your fail2ban version, if you have also v.0.10, but other version (for example latest 0.10.6 vs. 0.10.2 on your side), so be careful updating the filter only.
If they are really banned by fail2ban, it may depend on its banning action (and config of the net-filter and network subsystem). Sometimes it is possible that only the new packets will be rejected or dropped, already established connections are not affected. This don't imply that the intruder is able to continue the attack.
However if the IP is banned (so [sshd] Ban 192.0.2.1 is there), but you always see Already banned for this address in fail2ban.log later (and you see new attempts or even connections from this IP), then your banning action may not work properly (some errors in log after every ban, wrong port are protected, net-filter white-listing rules available, etc).
Are these 2 really connected to my server ? How ?
The connection may remain established (also if the IP got banned) for some time, if it is not dropped (killed) or one of both side does not close it.
As already said it depends.
You can surely add some custom second action killing all the connections from IP (e. g. using tcpkill, killcx, ss or whatever), but it is not needed if you don't see any communication from its side (all packets are rejected, so no new attempts in log and no new connections later from this IP, etc).
Anyway if they disappeared as you said after couple of seconds (I guess firstly going in TIME_WAIT state), then it is a good sign. But better check it with something like:
tail -f /var/log/fail2ban.log /var/log/auth.log | grep sshd
# or for journal:
journalctl -f | grep sshd
so you would see what happens before and after ban of some address (for example whether it remains silent hereafter).
Question regarding the traffic coming out from the TOR exit node:
I have been reading on a forum of people arguing the capabilities and risks of using TOR network. I have never used TOR before, nor would I have the need to use it, but I still want to know more about it.
I understand TOR uses randomly selected relays for traffic to travel through, but the traffic eventually comes out of an exit node somewhere. I have read that such traffic can be used to trace the user.
What i don't understand is if this traffic can be analysed, wouldn't it just show the requests are coming from the last relay instead of the original IP? Or does it show the entire trail including all the relay nodes that the traffic has passed through?
Say, this traffic can indeed be traced, does using encryption makes any difference? IF i was running an exit node (I'm not, I know the risks) and analyse the exiting traffic that is encrypted, can I still trace the original IP?
What if the user:
*is on open Wifi > connects to it with a laptop with dual NICs > is using live USB OS with say...a squid box as proxy > connects to it with another laptop > > connects to VPN > uses TOR with encryption
Is there a way for a normal user or a researcher, without ample resources like the government/law enforcement has, to still analyse the exiting traffic and trace the original IP?
Thanks in advance.
Since an exit relay is responsible for relaying source traffic out to the internet, if that traffic uses an unencrypted protocol (e.g. http), it can see the contents of that traffic.
For that reason, you shouldn't send sensitive data over Tor unencrypted when possible. The guard (entry), and middle (relay) nodes can't see the actual traffic, only the exit can. Only the guard node can see your true IP address.
The exit (while it can see the actual traffic and the destination) has no way of knowing your IP. If it could, you'd be much less anonymous when using Tor.
The threats here are if an adversary controls many relays. One of the worst case scenarios for being tracked through Tor would be if you selected a circuit where the guard node and exit node were controlled by the same adversary.
In this scenario, they could see your actual source IP address and your exit traffic (if unencrypted) or at the very least the destination for your exit traffic.
The other tricky part is correlating your entry traffic with the exit traffic. Whether or not entry traffic to a relay they control is also related to exit traffic from another relay they control is strictly up to timing and traffic analysis.
To understand more, you first need to understand how Tor works on a basic level, for that see the documentation page and the overview. Then, search for things like "Tor traffic analysis", "Tor traffic fingerprinting", "Tor timing attacks", and "Tor traffic correlation" to understand more and the research being done to defend against it.
More recent versions of Tor have started padding all cells to make smaller and larger traffic indistinguishable from eachother, and much past research has been done into relay selection
to prevent the chances of randomly selecting malicious exits or guards.
Hope that helps.
Some sites require that the same IP address be used for certain requests in order to provide more security. When using Tor 6.5, the IP address is changed for each request. Is it possible to tell Tor, "Prepare to reuse the IP address from which the server will see the next request come so that I can use it when I need to"?
My research indicates that Tor used to change exit nodes every ten minutes, but I guess they figured that they could change it for every request, so now the sites that required the same IP for two operations won't let me do those operations :-(.
I am specifically talking about btc-e.com. Thanks for any advice!
I have setup a CentOS 6.4 server (minimal install) which is connected to network through an ethernet cable. The problem is that when the network link goes down, the status changes are not automatically detected but if i type "ifconfig" the interface still keeps its IP address (which is assigned by a DHCP server). After some time that the link is down the interface loses the address but when the link comes up again the network connection is not automatically restored like it would happen in a desktop computer. Even the command "dhclient eth0" does not always work to restore things, and I have to restart the whole network service with "/ect/init.d/network restart".
Is there any way to automatically detect network status changes like it happens in desktop installations? I'm thinking about a cron script that every 5 minutes pings a server outside my network and if it doesn't get any response it restarts network service, but this does not sound very efficient... is there another way?
EDIT: I realized I have not explained the situation correctly. My network topology is: server --> switch --> router --> external network (the router is another centos server with DHCPD).
For some reasons (that i'm not getting), when it happens that the router goes down and reboots, the other server becomes unreachable, and I have to manually restart network service on it. So the link does not effectively go down (the switch keeps it up), but the status change is at IP level.
You can check if you have NetworkManager enabled, I usually don't use it in the servers but it can help you in this case because it will monitor automatically the connections (it is quite common in desktop installations).
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/ch-NetworkManager.html
To look for messages indicating an issue with the NIC just check the kernel ring buffer using the dmesg command.
For example when the cable is disconnected from a given interface this is what I get:
igb: eth1 NIC Link is Down
The first word will depend on the name of your network driver.
You could also configure the system to log these messages also to /var/log/messages (by default I am not sure if they appear there). Then it would be just a matter of monitoring the log, look for similar messages and restart the network service.
In any case the NetworkManager, if it is not already enabled, it should be an easier solution.
There is a module called miimon for monitoring the network interface's status. ethtool will give you the link status.
$ethtool eth0
...
Link detected: yes
I'm performing some latency measurements over the Tor network. TO avoid congesting the relays, each run of my test lasts about 15 to 20 minutes, consuming an average bandwidth of 2 kbps.
Because of the way the relay works, my measurements get disrupted because the identity automatically changes every few minutes. I wonder if someone knows how to do these:
Specify the time interval between identity changes. Alternatively, disabling the automatic identity change and allowing me to use vidalia's control panel to change identities manually
Specify an IP address as an exit relay. I edited torrc, setting ExitNodes to an ipaddress, and StrictNode to 1, but after an initial connection to that specific exit relay and 1 http connection to the outside world, no subsequent traffic is routed out of tor.
I unfortunately can't seem to find an answer to my dilemma looking at previous questions. :-/ My setup consists of ubuntu 12.04 lts, installing vidalia and tor using apt-get and firefox connecting to tor using socks via localhost:9050
1) Specify the time interval between identity changes.
Hi Nina, thanks for being careful about the load you put on the network! By default Tor cycles your circuits every ten minutes. You can customize this with the MaxCircuitDirtiness option in your torrc.
2) Specify an IP address as an exit relay.
Tor does not make this particularly easy. Probably the best option would be to extend one of your existing circuits to the desired endpoint. You can do this via stem using the extend_circuit() method.