I did run "tcpdump port 80" where I saw incoming packet. Then repeated
process but watching port 8080 this time but no packets have been
captured. I assumed it never went through.
I have never worked with tcpdump before so there may be some mistakes on
my side.
I do not know what is "reverse xlate rule" - can you show me how would
you write this rule, please?
I do not care how it is written as long as netfilter rule checks source
address (from set) that asks for connection to port 80, 443...and
redirects it to IP:8080 where web server error page awaits.
It is ip or cidr set/list of repeated attackers from netfilter log but I
run "commercial" web site and I wanna inform blocked people who may be
legit vistiors.
Sadly, IPv4 blocking is joke and most Internet users are unaware that
they became part of botnet and their shared IP is blocked.
On 13/01/2020 22:40, Florian Westphal wrote:
david NEW <david@xxxxxxxxx> wrote:
hi,
I am trying to route blocked ip set to IP:8080 where is info about "you have
been blocked"
table ip raw {
set bad_ip {'
type ipv4_addr
elements = { xxx.xxx.xxx.xxx }
}
chain prerouting {
type filter hook prerouting priority -500; policy accept;
nft add raw preroute ip saddr @bad_ip tcp dport { 80, 443 } ip daddr set
xxx.xxx.xxx.xxx tcp dport set 8080 notrack
}
netfilter doesn't complain about this rule but nothing happens...connection
timed out and nothing happened. I see no errors in Apache2 logs.
I can see connection attempt in tcpdump but it is not redirected.
How do you know from tcpdump? tcpdump occurs before port rewrite.
You should see syn to foo:80, then a syn-ack from xxx.xxx.xxx.xxx:8080.
As original client connected to foo:80, the syn-ack is dropped on client
side.
You need to add a reverse xlate rule if you really want this, or use
normal redirect via nat.
