Tag: IPTables

MiTM using ettercap and burp suit and iptables

I’m trying to perform a MiTM attack on a local network connected device. I configured the iptables to route the incoming traffic to port 443 and port 80 so it can be captured by the Burp Suite. However when i’m performing ARP poisoning using ettercap (as arpspoof is not available in KALI 2020) wireshark can capture the packets but burp can’t be able to intercept the packets.

I followed this tutorial… https://www.pentestgeek.com/penetration-testing/credential-harvesting-via-mitm-burp-suite-tutorial

But it’s not helping me anymore as arpspoof is deprecated.

Is it recommended to drop all traffic by default in iptables and then accept only what is required?

I was told using iptables -P OUTPUT DROP and then rules such as iptables -A OUTPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT to accept what is required didn鈥檛 do much from a security standpoint. Is that true?

This is what I am been using for some time (planning on implementing some SSH brute force rules shortly):

apt update apt install -y iptables-persistent iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT iptables -A OUTPUT -p tcp --dport 53 -m state --state NEW -j ACCEPT iptables -A OUTPUT -p udp --dport 53 -m state --state NEW -j ACCEPT iptables -A OUTPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT iptables -A OUTPUT -p tcp --dport 443 -m state --state NEW -j ACCEPT iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -P FORWARD DROP iptables -P INPUT DROP iptables -P OUTPUT DROP iptables-save > /etc/iptables/rules.v4

What is the most restrictive way to allow IPv6 ICMP requests on iptables?

This is what I have so far but it is pretty open.

*filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] -A INPUT -p ipv6-icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A OUTPUT -p ipv6-icmp -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT COMMIT

If you have time, explaining the rules would be amazing.

Block SYN,ACK response with iptables

I have a virtual environment and I am making a SYN flood attack to a Ubuntu Server’s port 53 using Kali 2020.

I realized that a countermeasure for this attack is to limit or block the responses to the SYN packets, which are the SYN,ACK.

But how can I do this with iptables?

What else should be done to prevent that kind of attacks?

smb iptables configuration not working with vpn killswitch

my main goal is to setup iptables that work as a VPN killswitch for my openvpn connection. Thanks to a post from forest, this was pretty straight forward: OpenVPN kill switch on Linux . So. everything that is not going to TUN1 should be blocked.

Now there is an issue while configuring an exception as the smb mount to the local NAS should not be tunneled. I tried to add the different ports a suggested here: https://serverfault.com/questions/346196/tcp-ip-ports-necessary-for-cifs-smb-operation but the mount can not be executed. Without any iptable rules, the mount works fine.

Here is my set of iptables:

iptables -F iptables -A INPUT -p tcp -s 192.168.1.0/24 --dport 9365 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 9365 -m conntrack --ctstate ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --dport 8080 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 8080 -m conntrack --ctstate ESTABLISHED -j ACCEPT iptables -A OUTPUT -j ACCEPT -m owner --gid-owner openvpn iptables -A OUTPUT -j ACCEPT -o lo iptables -A OUTPUT -j ACCEPT -o tun1 iptables -A INPUT -s 192.168.1.0/24 -p udp -m udp --dport 137 -j ACCEPT iptables -A INPUT -s 192.168.1.0/24 -p udp -m udp --dport 138 -j ACCEPT iptables -A INPUT -s 192.168.1.0/24 -p tcp -m tcp --dport 139 -j ACCEPT iptables -A INPUT -s 192.168.1.0/24 -p tcp -m tcp --dport 445 -j ACCEPT iptables -A OUTPUT -p udp --sport 137 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p udp --sport 138 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 139 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 445 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -j ACCEPT -m state --state ESTABLISHED iptables -P OUTPUT DROP iptables -P INPUT DROP

If I allow the access to the complete local network with iptables -A OUTPUT -d 192.168.1.0/24 -j ACCEPT, the mount works fine. But I do not want to allow complete access to the local network on all ports … and also want to understand what’s missing. I investigated the connection without rules and the mount is connected to the port 445.

  1. What is missing in the iptables to allow the smb connection?
  2. Will port 445 be sufficient or do I need the other 3 ports as well?

Thanks in advance 馃槈

Best, Ren茅

Does this iptables entry indicate someone’s trying to break in?

Two days ago I built a Debian 10 server in the United States for use as a file server for my web application. When I created the server, I installed the fail2ban package and configured a basic, minimal firewall using the following rules:

*filter  # Allow all loopback (lo0) traffic and reject traffic # to localhost that does not originate from lo0. -A INPUT -i lo -j ACCEPT -A INPUT ! -i lo -s 127.0.0.0/8 -j REJECT  # Allow ping. -A INPUT -p icmp -m state --state NEW --icmp-type 8 -j ACCEPT  # Allow SSH connections. -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT  # Allow inbound traffic from established connections. # This includes ICMP error returns. -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT  # Log what was incoming but denied (optional but useful). -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables_INPUT_denied: " --log-level 7  # Reject all other inbound. -A INPUT -j REJECT  # Log any traffic which was sent to you # for forwarding (optional but useful). -A FORWARD -m limit --limit 5/min -j LOG --log-prefix "iptables_FORWARD_denied: " --log-level 7  # Reject all traffic forwarding. -A FORWARD -j REJECT  COMMIT

Today when I checked my firewall, I found the following:

Chain INPUT (policy ACCEPT) target     prot opt source               destination f2b-sshd   tcp  --  anywhere             anywhere             multiport dports ssh ACCEPT     all  --  anywhere             anywhere REJECT     all  --  127.0.0.0/8          anywhere             reject-with icmp-port-unreachable ACCEPT     icmp --  anywhere             anywhere             state NEW icmp echo-request ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh state NEW ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED LOG        all  --  anywhere             anywhere             limit: avg 5/min burst 5 LOG level debug prefix "iptables_INPUT_denied: " REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable  Chain FORWARD (policy ACCEPT) target     prot opt source               destination LOG        all  --  anywhere             anywhere             limit: avg 5/min burst 5 LOG level debug prefix "iptables_FORWARD_denied: " REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable  Chain OUTPUT (policy ACCEPT) target     prot opt source               destination  Chain f2b-sshd (1 references) target     prot opt source               destination REJECT     all  --  49.88.112.114        anywhere             reject-with icmp-port-unreachable RETURN     all  --  anywhere             anywhere

There are only two user accounts on the server, the root account and a personal account for myself. I’m not a firewall expert but the Chain f2b-sshd entry looks suspicious to me:

When I run whois on that IP address, I see that it originated somewhere in China.

I have other production servers that have been running for over a year that are built on Debian 9 and I’ve never seen entries like this ever.

  1. Does this entry indicate that someone at that IP address has tried to break into my server?
  2. If the answer is “yes”, is Debian 10 now recording all break-in attempts with entries like this?
  3. Are there additional steps I should take to secure my server?

MITM setup using airmon-ng, iptables, and isc-dhcp server

I want to set up a MITM-scenario as an exercise for myself. My setup looks like this:

Internet <——–> Laptop <———-> Client

At this stage I just want to route the traffic from my AP to the internet, without monitoring it.

I use an Alfa-Network-Card in monitor-mode to create an AP with no encryption:

sudo airbase-ng -e demo wlan0mon

My next step was to set the networkinterface at0 up and assign an IP-address:

sudo ip link set at0 up sudo ip addr add 192.133.1.1/24 dev at0

I allowed ip-forwarding like this

sudo sysctl -w net.ipv4.ip_forward=1

My dhcpd.config file is shown here:

subnet 192.133.1.0 netmask 255.255.255.0 { default-lease-time 600; max-lease-time 7200; option routers 192.133.1.1; option broadcast-address 192.133.1.255; option domain-name "demo"; range 192.133.1.10 192.133.1.50; }

To specify the interface my dhcp-server should listen on I added this line to /etc/default/isc-dhcp-server file:

INTERFACESv4="at0"

To start the dhcp-server ran this:

sudo dhcpd -cf /etc/dhcp/dhcpd.conf -pf /var/run/dhcpd.pid at0 sudo bash /etc/init.d/isc-dhcp-server start

If I connect now to the AP I get an IP-address and everything looks fine. To route the traffic to my internal laptop wlan interface (wlp5s0) i used iptables:

sudo iptables -A FORWARD --in-interface at0 -j ACCEPT sudo iptables -t nat -A POSTROUTING -out-interface wlp5s0 -j MASQUERADE sudo iptables -t nat -A PREROUTING -j DNAT --to-destination 192.133.1.1 sudo iptables -P FORWARD ACCEPT

After that my nat-table looks like this:

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)  pkts bytes target     prot opt in     out     source               destination              0     0 DNAT       udp  --  any    any     anywhere             anywhere             to:192.133.1.1  Chain INPUT (policy ACCEPT 0 packets, 0 bytes)  pkts bytes target     prot opt in     out     source               destination           Chain OUTPUT (policy ACCEPT 438 packets, 36016 bytes)  pkts bytes target     prot opt in     out     source               destination           Chain POSTROUTING (policy ACCEPT 188 packets, 15827 bytes)  pkts bytes target     prot opt in     out     source               destination           1874  147K MASQUERADE  all  --  any    wlp5s0  anywhere             anywhere

My problem is, that I cannot connect to the internet from a client. I think my iptabes-setup is wrong but I have no clue what to do about it. I guess I need a little help here…

Adding manual iptables rules to UFW

I have a use case that needs iptables’ ability to restrict a rule to a group id (–gid-owner). Ufw doesn’t have support for this in its rule syntax.

From my experiments and reading online (e.g. UFW rules disappear after manually adding them to user.rules ubuntu 16.04) it seems ufw will reject any manually-added iptables rules. That is to say, I can edit /etc/ufw/user.rules and add -A ufw-user-output ... --gid-owner ... but because it’s not prefixed with a magic ufw-correct comment (since no such syntax exists), it’s ignored and erased.

Do I have to pick one of ufw or iptables or is there a way I can get the best of both worlds?

驴Como hacer segura mi PC con iptables para tener un servidor web casero?

Quiero mostrar ejemplos de c贸digo y aplicaciones web a otras personas. Y se me ocurri贸 hacer un servidor web casero LAMP (Linux, Apache, MySQL y PHP) que se ejecute en mi PC. Pero quiero que sea lo m谩s seguro posible, porque hay c贸digo fuente que no quiero mostrar, no porque est茅 en contra del software libre ni nada por el estilo, sino porque no ser铆a conveniente hacerlo.

Adem谩s, en mi PC uso Deepin Linux y quiero que sea lo m谩s seguro posible y no mandarme macanas. Creo que iptables me ayuda en eso, pero no se si con eso es suficiente.

Seg煤n este sitio web me dice como borrar todas las reglas de iptables, pero 驴Como hago para crear las necesarias desde cero?

驴Que reglas de iptables me recomiendan aplicar? Quiero permitir s贸lo conexiones del puerto 80 y 443. Se como configurar correctamente el router para que acepte conexiones entrante y las mande a mi PC (con DMZ y redirecci贸n de puertos). Estoy confiando en que Apache es lo bastante maduro y seguro, y tiene pocas vulnerabilidades o ninguna.