I am issuing the following rule from the shell prompt:
iptables -A INPUT -s localhost -j ACCEPT
After that, when I check iptables -L, I see two entries for the same.
The summary of iptables-save -c before and after:
root#debian:~# iptables-save -c
# Generated by iptables-save v1.4.21 on Fri Nov 3 09:11:15 2017
*filter
:INPUT ACCEPT [8:528]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [5:492]
COMMIT
# Completed on Fri Nov 3 09:11:15 2017
root#debian:~# iptables -A INPUT -s localhost -j ACCEPT
root#debian:~# iptables-save -c
# Generated by iptables-save v1.4.21 on Fri Nov 3 09:11:24 2017
*filter
:INPUT ACCEPT [6:396]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [4:496]
[0:0] -A INPUT -s 127.0.0.1/32 -j ACCEPT
[0:0] -A INPUT -s 127.0.0.1/32 -j ACCEPT
COMMIT
# Completed on Fri Nov 3 09:11:24 2017
root#debian:~#
Any idea, why there are two entries for one rule?
Related
I'm trying to understand iptables and can't seem to redirect traffic at all. The target is to redirect traffic form port 4567 to 8443 and have a (local) program listen on the latter.
I've written a short script to make sure I flush and restart the iptables each time I change the rule:
#!/bin/bash
iptables -t nat -F
iptables -t nat -A PREROUTING -p tcp --dport 4567 -j REDIRECT --to-ports 8443
sudo /sbin/iptables-save
I've also setup the ip_forwarding (although I'm not entirely sure whether I need that):
sudo echo "1" > /proc/sys/net/ipv4/ip_forward
I'm running this simple python script to test the routing. The site is made as to allow http requests on any port.
import requests
r = requests.get("http://portquiz.net:4567")
print(r.status_code)
As well as checking if any packets / bytes pass through the prerouting by looking at the output of iptables -t nat --list -v
Chain PREROUTING (policy ACCEPT 4 packets, 560 bytes)
pkts bytes target prot opt in out source destination
0 0 REDIRECT tcp -- any any anywhere anywhere tcp dpt:4567 redir ports 8443
Both the iptables and the python script are on the same machine (my laptop).
The python request seems to be going through without problems, and does not seem to be intercepted by the prerouting policy.
I'm running on the latest ubuntu 20.02
This is the output of the iptables-save, in case it's useful:
# Generated by iptables-save v1.8.4 on Tue Nov 10 13:20:02 2020
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -p tcp -m tcp --dport 4567 -j REDIRECT --to-ports 8443
COMMIT
# Completed on Tue Nov 10 13:20:02 2020
# Generated by iptables-save v1.8.4 on Tue Nov 10 13:20:02 2020
*filter
:INPUT ACCEPT [16727:8538288]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [16979:3211690]
COMMIT
# Completed on Tue Nov 10 13:20:02 2020
One needs to pay close attention between local packets, and network packets, when using iptables.
Local packets are packets created on the local machine, whereas network packets are packets received. PREROUTING works on network packets, for instance what you would get on a router device. Since in this case it's all local, then one must use OUTPUT instead of PREROUTING to redirect the packets.
The necessary rule is therefore.
iptables -t nat -A OUTPUT -p tcp --dport 4567 -j REDIRECT --to 8443
I have found this picture to be very useful:
Which comes from this article:
https://danielmiessler.com/study/iptables/
==== Basic information ====
iRedMail version (check /etc/iredmail-release): iRedMail-0.9.5-1
Linux/BSD distribution name and version: Ubuntu 14.01 container inside Ubuntu 14.01 TurnkeyLinux Core
Store mail accounts in which backend (LDAP/MySQL/PGSQL): MySQL
Web server (Apache or Nginx): Apache
Postfix log excerpt:
Jan 6 10:24:38 iredmail postfix/submission/smtpd[2631]: connect from x.y.z[127.0.0.1]
Jan 6 10:24:38 iredmail postfix/submission/smtpd[2631]: Anonymous TLS connection established from x.y.z[127.0.0.1]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Jan 6 10:24:38 iredmail postfix/submission/smtpd[2631]: 6EEA060306: client=x.y.z[127.0.0.1], sasl_method=LOGIN, sasl_username=address#x.y.z
Jan 6 10:24:38 iredmail postfix/cleanup[2636]: 6EEA060306: message-id=
Jan 6 10:24:38 iredmail roundcube: User iaaberga [192.168.121.1]; Message for destination#gmail.com; 250: 2.0.0 Ok: queued as 6EEA060306
Jan 6 10:24:38 iredmail postfix/qmgr[2587]: 6EEA060306: from=, size=575, nrcpt=1 (queue active)
Jan 6 10:24:38 iredmail postfix/submission/smtpd[2631]: disconnect from x.y.z[127.0.0.1]
Jan 6 10:24:38 iredmail postfix/smtpd[2648]: connect from x.y.z[127.0.0.1]
Jan 6 10:24:38 iredmail postfix/smtpd[2648]: C97F262D1B: client=x.y.z[127.0.0.1]
Jan 6 10:24:38 iredmail postfix/cleanup[2636]: C97F262D1B: message-id=
Jan 6 10:24:38 iredmail postfix/qmgr[2587]: C97F262D1B: from=, size=1628, nrcpt=1 (queue active)
Jan 6 10:24:38 iredmail postfix/smtpd[2648]: disconnect from x.y.z[127.0.0.1]
Jan 6 10:24:38 iredmail amavis[1742]: (01742-01) Passed CLEAN {RelayedInternal}, ORIGINATING/MYNETS LOCAL [127.0.0.1]:35413 -> , Queue-ID: 6EEA060306, Message-ID: , mail_id: 4QjhhYZODSHf, Hits: -2.986, size: 575, queued_as: C97F262D1B, dkim_new=dkim:y.z, 328 ms, Tests: [ALL_TRUSTED=-1,RP_MATCHES_RCVD=-3.199,TVD_RCVD_SINGLE=1.213]
Jan 6 10:24:38 iredmail postfix/smtp[2642]: 6EEA060306: to=, relay=127.0.0.1[127.0.0.1]:10026, delay=0.4, delays=0.05/0.01/0.01/0.33, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as C97F262D1B)
Jan 6 10:24:38 iredmail postfix/qmgr[2587]: 6EEA060306: removed
Jan 6 10:24:47 iredmail postfix/smtp[2618]: connect to mx6.mail.icloud.com[17.172.34.71]:25: Connection timed out
Jan 6 10:24:47 iredmail postfix/smtp[2622]: connect to alt1.gmail-smtp-in.l.google.com[173.194.69.27]:25: Connection timed out
====
Hi!
I did install iRedmail as an lxc container on an Ubuntu 14.01 / Ubuntu 14.01 host/container system.
While I can receive emails, Postfix does not send messages (that appear to be sent out in the webmail client, but do never arrive at dest).
From the container level connectivity seems to work in general: I can ssh to some host I have access to; I can use apt-get tools to install new sw, etc.
Trying to telnet alt1.gmail-smtp-in.l.google.com on port 25 does not succeed (if done from inside the container).
root#iredmail ~# telnet alt1.gmail-smtp-in.l.google.com 25
Trying 173.194.69.26...
Eventually the connection will fail.
If I do exit from the container and try the same telnet connection, all is well
root#lxc ~# telnet alt1.gmail-smtp-in.l.google.com 25
Trying 173.194.69.27...
Connected to alt1.gmail-smtp-in.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP t19si1302495wrb.232 - gsmtp
QUIT
221 2.0.0 closing connection t19si1302495wrb.232 - gsmtp
Connection closed by foreign host.
This is the container's iptables config:
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
*filter
:FORWARD ACCEPT [0:0]
:INPUT DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type echo-request -j ACCEPT
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 12320 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 12321 -j ACCEPT
# Mail SMTP
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A FORWARD -p tcp -d 192.168.121.1 --dport 25 -j ACCEPT
# POP3
-A INPUT -p tcp -m tcp --dport 110 -j ACCEPT
# SMTPS
-A INPUT -p tcp -m tcp --dport 465 -j ACCEPT
# IMAPS
-A INPUT -p tcp -m tcp --dport 587 -j ACCEPT
# IMAPS - 2
-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT
COMMIT
I am not familiar with containers' networking, so I might very well missing anything obvious!
It does not look to be a problem with Postfix config..
Thanks for any help,
Aldo
As it often happens (once you know the solution) the problem was trivial...
In short: a wrong NAT setting in the host was intercepting and forwarding traffic from all sources, CONTAINERS INCLUDED!!
This is the relevant part of the HOST'S iptables rules as it was:
*nat
:PREROUTING ACCEPT [22532:1479233]
:INPUT ACCEPT [22432:1472721]
:OUTPUT ACCEPT [11623:812922]
:POSTROUTING ACCEPT [2959:155572]
-A PREROUTING -p tcp -m tcp --dport 25 -j DNAT --to-destination 192.168.121.174:25
-A PREROUTING -p tcp -m tcp --dport 110 -j DNAT --to-destination 192.168.121.174:110
-A PREROUTING -p tcp -m tcp --dport 143 -j DNAT --to-destination 192.168.121.174:143
-A PREROUTING -p tcp -m tcp --dport 465 -j DNAT --to-destination 192.168.121.174:465
-A PREROUTING -p tcp -m tcp --dport 587 -j DNAT --to-destination 192.168.121.174:587
-A PREROUTING -p tcp -m tcp --dport 993 -j DNAT --to-destination 192.168.121.174:993
-A PREROUTING -p tcp -m tcp --dport 995 -j DNAT --to-destination 192.168.121.174:995
-A POSTROUTING -o br0 -j MASQUERADE
-A POSTROUTING -s 192.168.121.0/24 ! -o natbr0 -j MASQUERADE
COMMIT
It tells iptables to pass all traffic say to port 25 to the virtual address of the mail server container.
This happens even for traffic from the container itself.
BINGO!!
Now this is the correct setting, where br0 is the AWS network interface that links to the outside world.
So, only packets arriving there first, should be routed to the NATted virtual address of the email server package.
*nat
:PREROUTING ACCEPT [22532:1479233]
:INPUT ACCEPT [22432:1472721]
:OUTPUT ACCEPT [11623:812922]
:POSTROUTING ACCEPT [2959:155572]
-A PREROUTING -p tcp -m tcp --in-interface br0 --dport 25 -j DNAT --to-destination 192.168.121.174:25
-A PREROUTING -p tcp -m tcp --in-interface br0 --dport 110 -j DNAT --to-destination 192.168.121.174:110
-A PREROUTING -p tcp -m tcp --in-interface br0 --dport 143 -j DNAT --to-destination 192.168.121.174:143
-A PREROUTING -p tcp -m tcp --in-interface br0 --dport 465 -j DNAT --to-destination 192.168.121.174:465
-A PREROUTING -p tcp -m tcp --in-interface br0 --dport 587 -j DNAT --to-destination 192.168.121.174:587
-A PREROUTING -p tcp -m tcp --in-interface br0 --dport 993 -j DNAT --to-destination 192.168.121.174:993
-A PREROUTING -p tcp -m tcp --in-interface br0 --dport 995 -j DNAT --to-destination 192.168.121.174:995
-A POSTROUTING -o br0 -j MASQUERADE
-A POSTROUTING -s 192.168.121.0/24 ! -o natbr0 -j MASQUERADE
COMMIT
Obviously without the interception loop the email server inside the container easily sends mail out!!
I have a config file with lines:
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:sdfilter - [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A sdfilter -j DROP
COMMIT
*nat
:OUTPUT ACCEPT [0:0]
:ds - [0:0]
-A POSTROUTING -o dev -j MASQUERADE
COMMIT
*mangle
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o dev -j MASQUERADE
COMMIT
and I am trying to insert a line -I FORWARD -m physdev --physdev-in eth2 -j DROP between *filter and first COMMIT and only before the COMMIT in that pattern .so that resulting output looks like :
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:sdfilter - [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A sdfilter -j DROP
-I FORWARD -m physdev --physdev-in eth2 -j DROP
COMMIT
*nat
:OUTPUT ACCEPT [0:0]
:ds - [0:0]
-A POSTROUTING -o dev -j MASQUERADE
COMMIT
*mangle
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o dev -j MASQUERADE
COMMIT
I have tried several ways and nearest solution I have reached is that I can append before every line in that pattern by using sed:
sed '/\*filter/,/COMMIT/i\FORWARD -m physdev --physdev-in eth2 -j DROP' file
please suggest a pattern that I can insert only before last ("COMMIT") line in that filtered pattern ?
Using awk I can write,
/^\*filter$/{found++}
found && /COMMIT/ {
print "-I FORWARD -m physdev --physdev-in eth2 -j DROP";
found=0
}
1
What is does?
/^\*filter$/{found++} If current line is *filter, increament found by one.
found && /COMMIT/ If the current line has COMMIT and filter is non zero,
Print the string that we need to print and set the found to zero.
1 This is always true, in that case awk performs the default task to print the current line.
Example
$ awk '/^\*filter$/{found++} found && /COMMIT/{print "-I FORWARD -m physdev --physdev-in eth2 -j DROP"; found=0} 1' file
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:sdfilter - [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A sdfilter -j DROP
-I FORWARD -m physdev --physdev-in eth2 -j DROP
COMMIT
*nat
:OUTPUT ACCEPT [0:0]
:ds - [0:0]
-A POSTROUTING -o dev -j MASQUERADE
COMMIT
*filter
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o dev -j MASQUERADE
-I FORWARD -m physdev --physdev-in eth2 -j DROP
COMMIT
This might work for you (GNU sed):
sed -e '/^\*filter/,/^COMMIT/{/^COMMIT/{i-I FORWARD -m physdev --physdev-in eth2 -j DROP' -e ':a;n;ba}}' file
Find the range of lines between *filter and COMMIT then insert the required string before the line containing COMMIT and finally print all following lines.
Here it comes sed answer:
sed -n -r '/COMMIT/{x; s/(\*filter.*)/\1\n-I FORWARD -m physdev --physdev-in eth2 -j DROP/; p; x;p; b end }; H; b; :end n; p; b end' config_file | sed -e '1d'
Replace --inserted text-- with text that will be appended before first 'COMMIT', plaese.
Explanation
H appends current line to buffer
b <label> - go to
: <label> - definition
b - with no simply ends current line processing
n - go to next line
x - swap pattern and hold buffer (there are only thoose two in sed)
p - print pattern buffer on screen
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 years ago.
Improve this question
on an empty iptables I did:
$iptables -P INPUT DROP
$iptables -P OUTPUT DROP
$iptables -P FORWARD DROP
and a few rules for SSH, HTTP and TEAMSPEAK
and when I did iptables-save I got that result that allows some IP
# Generated by iptables-save v1.4.8 on Thu Feb 20 23:55:32 2014
*raw
:PREROUTING ACCEPT [6299:1141558]
:OUTPUT ACCEPT [6172:2577934]
COMMIT
# Completed on Thu Feb 20 23:55:32 2014
# Generated by iptables-save v1.4.8 on Thu Feb 20 23:55:32 2014
*nat
:PREROUTING ACCEPT [328:23247]
:INPUT ACCEPT [170:9752]
:OUTPUT ACCEPT [1190:168880]
:POSTROUTING ACCEPT [717:89971]
COMMIT
# Completed on Thu Feb 20 23:55:32 2014
# Generated by iptables-save v1.4.8 on Thu Feb 20 23:55:32 2014
*mangle
:PREROUTING ACCEPT [6299:1141558]
:INPUT ACCEPT [6299:1141558]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [6172:2577934]
:POSTROUTING ACCEPT [5699:2499025]
COMMIT
# Completed on Thu Feb 20 23:55:32 2014
# Generated by iptables-save v1.4.8 on Thu Feb 20 23:55:32 2014
*filter
:INPUT DROP [17:1024]
:FORWARD DROP [0:0]
:OUTPUT DROP [76:11042]
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p udp -m udp --dport 9987 -j ACCEPT
-A OUTPUT -p tcp -m tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCE\
PT
-A OUTPUT -p tcp -m tcp --sport 80 -m conntrack --ctstate ESTABLISHED -j ACCEPT\
-A OUTPUT -p udp -m udp --sport 9987 -j ACCEPT
COMMIT
The question is, is it normal? Am I hacked?
If your question is referring to the numbers in square brackets i.e.
*nat
:PREROUTING ACCEPT [328:23247] <-- these numbers
Then no, you haven't been hacked.
Those are packet and byte counters.
A very good tutorial on iptables by Oskar Andreasson is found at: http://www.faqs.org/docs/iptables/index.html
with a page covering what you are asking about at: http://www.faqs.org/docs/iptables/iptables-save.html
Note that iptables-save is made to be used by iptables-resture, hence the complex formatting. Use iptables -S for a more simple form.
Furthermore, I would suggest using a more simple rules such as:
Allow outgoing traffic and continue any already established connections
iptables -F
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -P FORWARD DROP
Specific port you want to use for input
iptables -A INPUT -p TCP --dport 22 -m state --state ESTABLISHED,NEW -j ACCEPT
iptables -A INPUT -p TCP --dport 80 -m state --state ESTABLISHED,NEW -j ACCEPT
iptables -A INPUT -p TCP --dport 443 -m state --state ESTABLISHED,NEW -j ACCEPT
iptables -A INPUT -p TCP --dport 9987 -m state --state ESTABLISHED,NEW -j ACCEPT
Of course, run those in a script, otherwise the 'iptables -f' would disconnect your current SSH session.
I have a question about Squid configuration as trasparent proxy using SSL.
I would to use Squid 2.6 as trasparent proxy with http and https connection.
I followed this steps:
1) I configurated my iptables:
# Generated by iptables-save v1.4.7 on Wed Nov 9 13:37:50 2011
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [10363:2864591]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth+ -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -p icmp -j ACCEPT
-A FORWARD -i lo -j ACCEPT
-A FORWARD -i eth+ -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
# Completed on Wed Nov 9 13:37:50 2011
# Generated by iptables-save v1.4.7 on Wed Nov 9 13:37:50 2011
*nat
:PREROUTING ACCEPT [4:650]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
-A PREROUTING -i eth0 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 3129
COMMIT
2) I configurated my squid.conf about http_port and it work well.
3) About SSL I setted this:
https_port 3129 transparent key=/etc/squid/ssl/myhost.com-private.pem
cert=/etc/squid/ssl/myhost.com-certificate.pem
but about https not work.
If I use this command lsof -n -i -P | grep squid
about the squid I see also:
squid 6483 squid 6u IPv4 155998 0t0 UDP *:43053
squid 6483 squid 13u IPv4 156001 0t0 TCP *:3128 (LISTEN)
squid 6483 squid 14u IPv4 156003 0t0 UDP *:3130
and I not see 3129 port. Is correct this way?
Any suggestions?