I have two machines (Machine1 & Machine2) on the same subnet. Machine1 has a tool installed that returns some data. for example if I run the following command, it returns some data.
printf "get:info\nend\n" | nc localhost 1234
However if do the same on Machine2, of course changing localhost to machine1, nothing happens. Any Idea what can be the problem?
printf "get:info\nend\n" | nc machine1 1234
After investigating alot I finally managed to find the reason why I was not able to communicate to the other machine on the specific port.
Iptables setting in my machine1 was not allowing machine1 to listen. I turned off of the iptables and everthing worked fine.
But its not a good idea to turn off the iptables. So for the next step I allowed port 1234 for machine1.
sudo iptables -A INPUT -p tcp --dport 1234 -j ACCEPT
You can find more information about iptables on the link below:
https://help.ubuntu.com/community/IptablesHowTo
Related
In Ubuntu 16.04LTS, I typed the folllowing lines:
iptables -F
iptables -X
iptables -A INPUT -m mac --mac-source 1C:**:2C:**:72:**:78 -j ACCEPT
here is the result of iptables -L -nvx.
I can't access my web server (port 80) with the machine that MAC address is
1C:**:2C:**:72:**:78.
However, with rule iptables -P INPUT ACCESS on the web server, it works well.
Could anyone give me any solution or advice for this?
Thanks.
I believe that it will not work with you except that your PC is on the same LAN with the WEB server.
Because if you where on different LAN then your packets will reach the server with the mac address with the latest network interface before the web server (which is the network switch interface mac address).
So you can filter the packets based on MAC address only if you where on the same LAN.
You need to supply the MAC address in the form xx:xx:xx:xx:xx:xx, not with :: in between. I.e.:
iptables -A INPUT -m mac --mac-source xx:xx:xx:xx:xx:xx -j ACCEPT
From man iptables:
--mac-source [!] address
Match source MAC address. It must be of the form XX:XX:XX:XX:XX:XX. Note that this only makes sense for packets coming from an Ethernet device and entering the PREROUTING, FORWARD or INPUT chains.
I have the following problem. I'm using Debian GNU/Linux Stretch and I am trying to use netcat as a simple server. I start it using following command:
$ netcat -l 127.0.0.1 33333
It starts just fine and accepts connections but on a different port than requested:
$ netstat -tulpn | grep netcat
tcp 0 0 0.0.0.0:38782 0.0.0.0:* LISTEN 2851/netcat
This behavior is independent of requested port, user or ufw status. Recently I installed LXC with following packages:
apparmor
bridge-utils
cgmanager
libapparmor-perl
lxc
All have been removed later, but somehow I feel like this behavior may be related to some changes in configuration.
It looks like you are using traditional netcat which requires providing -p argument for the listening port:
netcat -l 127.0.0.1 -p 33333
From nc -h:
-p port local port number
Syntax you use would work with OpenBSD netcat.
I'm analysing the traffic on my Virtual Lab, using arpspoof/sslstrip.
I'm using the following script
iptables -A INPUT -i eth1 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --dport 8080 -j ACCEPT
iptables -A PREROUTING -t nat -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 8080
echo '1' > /proc/sys/net/ipv4/ip_forward
-- 10.10.10.2 Target
-- 10.10.10.1 Router
arpspoof -i eth1 -t 10.10.10.2 10.10.10.1
arpspoof -i eth1 -t 10.10.10.1 10.10.10.2
sslstrip -l 8080
This work partially since I can get the info in the sslstrip.log file just fine.
The problem is that the PC target (Win7 64 Bit IE 11) is unable to successfully complete the login process.
What happens is:
On the target PC I write https://hotmail.com.ar
It's get redirected to http://hotmail.com.ar
I type usser & passdord
The info is correctly save in sslstrip.log
BUT after confirm, the browser reload the page without actually login in
What seems to be the problem ?
Thanks
I know the question is older than two years and you have probably found a solution. I tried the same scenario for a research on Hotmail and come to the same problem.
I think the answer for this problem is that Hotmail is using for the authentication the HTTP Strict Transport Security (HSTS), that allows the server only to connect with HTTPS-connections. Uncertain I do not know why Hotmail is not using the HSTS for the inputs of the username and password and only for the authentication.
I hope I could help you
I'm conecting to a VPN in Windows to access a remote computer (Linux) with a static IP. From this remote computer I have access to different machines (database, svn, etc.).
I am trying to set up my remote computer to have access from my Windows machine to the database, the svn server, etc, because working on a remote connection is very slow.
So I tried the next lines in /etc/rc.local, but it doesn't work:
/sbin/iptables -P FORWARD ACCEPT
/sbin/iptables --table nat -A POSTROUTING -o eth0 -j MASQUERADE
/sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp -d B1.B2.B3.B4 --dport 89 -j DNAT --to R1.R2.R3.R4:89
/sbin/iptables -A FORWARD -p tcp -d R1.R2.R3.R4 --dport 89 -j ACCEPT
Where B1.B2.B3.B4 is my remote database IP, 89 is the port we use to access the database, and R1.R2.R3.R4 is my remote machine IP.
What is wrong in this configuration?
Thanks.
Make sure ip_forward is enabled:
echo 1 > /proc/sys/net/ipv4/ip_forward
Also, you need to make sure the VPN pushes routes for B1.B2.B3.B4 to your Windows machine when connecting; if not, you'll have to add the routes yourself.
I think the MASQUERADE rule should be enough, but write it like this:
iptables -t nat -A POSTROUTING -s WINDOWS_BOX_VPN_IP -j MASQUERADE
But if you don't want to mess with iptables, you can use SSH to setup tunnels to your remote services, for example (you need some Windows SSH client that can create tunnels, I'm giving an example how to run this from a linux box):
ssh user#R1.R2.R3.R4 -L 8989:B1.B2.B3.B4:89
This will create a tunnel on localhost:8989 which will forward the connection to B1.B2.B3.B4:89 (look for "Local port forwarding", http://chamibuddhika.wordpress.com/2012/03/21/ssh-tunnelling-explained/ )
At the end I found Rinetd that allows TCP redirections with an easy configuration.
According to my question, the configuration I had to add in /etc/rinetd.conf is:
R1.R2.R3.R4 89 B1.B2.B3.B4 89
Then I run Rinetd:
/usr/sbin/rinetd
And that's all.
If you want to run it automatically everytime you restart your computer, you can add the command before in the file /etc/rc.local
I try to redirect port from my lxc-container to loopback.
My lxc-container configured with lxcbr1 bridge 11.0.3.1.
I try to connect with netcat from host to lxc, and from lxc to host. Success.
localhost:
# nc -l 1088
lxc:
# nc 11.0.3.1 1088
Hello!
And localhost See message: "Hello!". Success!
When I redirect port that way:
# iptables -t nat -A PREROUTING -i lxcbr1 -p tcp -d 11.0.3.1 --dport 1088 -j DNAT --to-destination 127.0.0.1:1088
# nc -l 127.0.0.1 1088
Thereafter, i try to connect from lxc-container:
# nc 11.0.3.1 1088
Hello !
But localhost doesn't see this message.
Where am i wrong?
I found this answer: https://serverfault.com/questions/211536/iptables-port-redirect-not-working-for-localhost
There sound words that loopback doesn't use PREROUTING. What should i do?
DNAT for loopback traffic is not possible.
I found alot of similar questions. 1, 2, 3, etc...
According to RFC 5735, network 127.0.0.0/8 should not be routed outside host itself:
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 loops back inside the host. This is
ordinarily implemented using only 127.0.0.1/32 for loopback. As
described in [RFC1122], Section 3.2.1.3, addresses within the entire
127.0.0.0/8 block do not legitimately appear on any network anywhere.
RFC 1700, page 5, «Should never appear outside a host».
There is one of exits: use inetd.
There are many inted servers, xinetd, etc.
My choice was rinetd.
I use this manual http://www.howtoforge.com/port-forwarding-with-rinetd-on-debian-etch
My config looks like this:
$ cat /etc/rinetd.conf
# bindadress bindport connectaddress connectport
11.0.3.1 1081 127.0.0.1 1081
11.0.3.1 1088 127.0.0.1 1088
I restart rinetd:
$ /etc/init.d/rinetd restart
Stopping internet redirection server: rinetd.
Starting internet redirection server: rinetd.
And redirection works like a charm.
I will not close this question by myself, cause I still in looking for more elegant solution for such task. It is unlikely to do this by any animal, netcat or inetd, it doesn't matter. This is my opinion.
Just for reference if someone stumbles upon here, on new kernel versions (probably >= 3.6), all you need to do extra is:
~# echo 1 | sudo tee /proc/sys/net/ipv4/conf/all/route_localnet
REFERENCE: ipv4: Add interface option to enable routing of 127.0.0.0/8