arpspoofing and ARP table - arp

I dont understand the ARP table of 1 machine on my testing network consisting of 3 PCs on Ubuntu20
a client of IP 192.168.0.1
an attacker of IP 192.168.0.2
a server of IP 192.168.0.3
On machine n°2 (attacker), I've installed :
dnsiff and launched arpspoof ( sudo arpspoof -t 192.168.0.1 192.168.0.3)
mitmproxy in transparent mode, which makes a proxy and redirects all the traffic arriving on port 80 to port 8080 by setting properly the iptables rules.
sudo apt install dnsiff
sudo apt install mitmproxy
I activated the ip_forwarding by uncommenting net.ipv4.ip_forward=1 in file /etc/sysctl.conf and then reloaded the system :
sudo sysctl -p /etc/sysctl.conf
mitmproxy --mode-transparent -p 8080
sudo iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8080
All works but when I open the arp table of machine 1 (192.168.0.1) , I read :
192.168.0.3 #MAC of the attacker (which is what I expected)
192.168.0.2 #MAC of the attacker (which is surprinsing)
How is it that address 192.168.0.2 appears whereas there is no trace on any wireshark frame , when wireshark listens to machine 1 interface.
Another surprinsing thing occurs when I set manually the #IP et #MAC of the server :
sudo arp -s 192.168.0.3 #MAC of the attacker
This time the ARP table of machine 1 does not display 192.168.0.2 (attacker).
Thank you for any explanation.

Related

Postgres is hogging port 3000 and I can't kill it

I keep getting "Something is already running on port 3000", and I've tried sudo lsof -i :3000, and I get this:
postgres 92237 postgres 7u IPv6 0xcbfedaba1d3eb2b7 0t0 TCP *:hbci (LISTEN)
postgres 92237 postgres 8u IPv4 0xcbfedaba2d4680c7 0t0 TCP *:hbci (LISTEN)
So I ran sudo kill -9 92237 to stop it
But more instances of postgres will generate after I kill it, how can I stop this??

Failed to execute adb -a -P 5037 fork-server server

5037 is not occupied and the error message is reply fd for adb server to client communication not specified. The version of adb is 1.0.39. I want to share port for STF Provider. Appreciate for any help.
As Moon said in his comment: the solution is to run
adb -a -P 5037 daemon
and then
stf provider --adb-host ip -port 5037

Check if Postgresql is listening

Given an IP Address and port number, is it possible to check if the machine with that IP address has Postgresql listening on the specified port? If so, how?
I just want to obtain a boolean value of whether Postgresql is listening on the specified port of the specified machine.
You can use, for example, nmap tool:
=$ sudo nmap -v -p 5930 127.0.0.1
Starting Nmap 6.00 ( http://nmap.org ) at 2013-06-25 19:28 CEST
Initiating SYN Stealth Scan at 19:28
Scanning localhost (127.0.0.1) [1 port]
Discovered open port 5930/tcp on 127.0.0.1
Completed SYN Stealth Scan at 19:28, 0.03s elapsed (1 total ports)
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000045s latency).
PORT STATE SERVICE
5930/tcp open unknown
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds
Raw packets sent: 1 (44B) | Rcvd: 2 (88B)
Alternatively you can just "SELECT 1" with psql, and check output:
=$ psql -h 127.0.0.1 -p 5930 -c "select 1"
?column?
----------
1
(1 row)
=$ psql -h 127.0.0.1 -p 5940 -c "select 1"
psql: could not connect to server: Connection refused
Is the server running on host "127.0.0.1" and accepting
TCP/IP connections on port 5940?
I think you need to define what you're trying to achieve better. Do you just want to know if anything is listening on a certain point? If PostgreSQL is listening on a given port? If PostgreSQL is running and actually accepting connections? If you can connect to PostgreSQL, authenticate successfully and issue queries?
One option is to invoke psql to connect to it and check the result code. Do not attempt to parse the output text, since that's subject to translation into different languages.
Better, use the client library for the language of your choice - psycopg2 for Python, PgJDBC for Java, the Pg gem for Ruby, DBD::Pg for Perl, nPgSQL for C#, etc. This is the approach I'd recommend. The SQLSTATE or exception details from any connection error will tell you more about why the connection failed - you'll be able to tell the difference between the server not listening, authentication failure, etc this way. For example, in Python:
import psycopg2
try:
conn = psycopg2.connect("host=localhost dbname=postgres")
conn.close()
except psycopg2.OperationalError as ex:
print("Connection failed: {0}".format(ex))
There are exception details in ex.pgcode (the SQLSTATE) to tell you more about errors that're generated server-side, like authentication failures; it'll be empty for client-side errors.
If you just want to see if something is listening on a given IP and TCP port, you can use netcat (*nix only), or a simple script in the language of your choice that creates a socket and does a connect() then closes the socket if it gets a successful response. For example, the following trivial Python script:
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
try:
s.connect(('localhost',5432))
s.close()
except socket.error as ex:
print("Connection failed with errno {0}: {1}".format(ex.errno, ex.strerror))
The same approach applies in any programming language, just the details of the socket library and error handling vary.
For some purposes it can also be useful to use the netstat tool to passively list which processes are listening on which network sockets. The built-in netstat on Windows is pretty brain-dead so you have to do more parsing of the output than with netstat for other platforms, but it'll still do the job. The presence of a socket in netstat doesn't mean that connecting to it will succeed, though; if the process has failed in some way that leaves it broken but still running (stuck in an infinite loop, blocked by a debugger, SIGSTOPed, etc) then it won't respond to an actual connection attempt.
In brief
In details
Fastest way is to use netcat aka nc with timeout ability as shared here
Results as 0/1 means postgres working/not-working
echo 'QUIT' | nc -w SECONDS YOUR_HOST PORT; echo $?
# eg
echo 'QUIT' | nc -w 1 localhost 5432; echo $?
Another also-faster way that works for me is to use telnet as discussed here.
echo -e '\x1dclose\x0d' | telnet YOUR_HOST PORT
# eg
echo -e '\x1dclose\x0d' | telnet localhost 5432

Port Redirection not working (80->3306)

i have got a new Linux Server (Debian 6.0) with a Database (MySQL) which is accessed by Port 3306 like as usual.
Now I'd like to access the database due port problems of some users (because port 3306 is often blocked by network firewalls) by port 80 or 443. So the transfer must be redirected from Port 80 to 3306 to keep the Database working.
I have tried following command:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3306
but I got following error:
iptables: No chain/target/match by that name.
Does anyone can help me solve this problem? The NAT table is empty (PREROUTING,POSTROUTING,OUTPUT have no entries) (checked with iptables -t nat -n -L)
In iptables Kernel modules required for NAT functionality:
Run following command to load modules in kernel:
# modprobe iptable_nat
# modprobe ipt_REDIRECT
Make sure you have above modules compiled in kernel:
[root#instructor tmp]# grep REDIRECT /boot/config-$( uname -r )
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_BRIDGE_EBT_REDIRECT=m
In VPS Server:
Enable modules on host server using modprobe command
Execute following command from the host server to enable all the modules for the VPS
vzctl set VEID --iptables iptable_nat --iptables ipt_REDIRECT
Add rules in file /etc/vz/conf/veid.conf
IPTABLES="iptable_nat ipt_REDIRECT"

specifying IPv6 addresses to fuser

Using CentoS 5.5.
I have an Apache 2.x server running on port 9999 and I am trying to find it using fuser.
I can find it using netstat, i.e.:
netstat -an | grep 9999
outputs:
tcp 0 0 :::9999 :::* LISTEN
Question 1: Why is netstat displaying the port using IPv6 syntax?
Question 2: What fuser command can I use to find the pid of the server? None of the following work:
fuser -n tcp :::9999
fuser -n tcp 9999
fuser -4 -n tcp 9999
fuser -6 -n tcp 9999
fuser -6 -n tcp :::9999
Thanks!
Why is it listening on IPv6? Well, by default on Linux, binding to [::] will not only bind to IPv6, but will also bind to an IPv4–compatible address. The ::ffff:0.0.0.0/96 space in IPv6 is used for IPv4–compatible connections.
The advantage of the software doing this is that it only needs to bind to the one socket. It makes the coding slightly simpler.
Not all distros or operating systems do this. For example, Windows requires you to bind to both [::] or 0.0.0.0 explicitly in order to support IPv6 or IPv4. And on Linux, if the net.ipv6.bindv6only sysctl is set to 1 (like it is on Debian, but not most other distros, including CentOS or Ubuntu), then you will need to explicitly bind to [::] and 0.0.0.0 to support both.
As for how to look it up in fuser, do it like this:
# fuser 80/tcp
80/tcp: 3052 3143 3144 3146 3147 3148
Or to show what process is bound to the port:
# fuser -v 80/tcp
USER PID ACCESS COMMAND
80/tcp: root 3052 F.... apache2
www-data 3143 F.... apache2
www-data 3144 F.... apache2
www-data 3146 F.... apache2
www-data 3147 F.... apache2
www-data 3148 F.... apache2
One was fix was to disable ipv6:
Added to /etc/modprobe.conf:
alias net-pf-10 off
I don't think fuser likes ipv6.

Resources