Tag Info

Hot answers tagged

6

For problems of this kind you can define new chains and jumping between them. You might for example add a chain LOGGING and at the beginning of this chain match those packets you don't want to log with an action of RETURN: $ iptables -N LOGGING $ iptables -A LOGGING -d 127.0.0.0/8 -j RETURN $ iptables -A LOGGING -d 239.192.0.0/16 -j RETURN $ iptables -A ...


5

The docs are out of date/misleading. The ! should go before --destination, not after it. Try: -A OUTPUT ! --destination 127.0.0.1 -m state --state NEW -j LOG --log-prefix "new_connection " --log-level 7 The clue is the summary line in the man page: [!] -d, --destination address[/mask][,...]


3

You should first set this rule: iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT It will authorize already open connection to continue then accept ssh connection (here by ethernet port) iptables -A INPUT -p tcp -i eth0 --dport ssh -j ACCEPT Finally you can drop every connections iptables -P INPUT DROP edit You should also allow ...


3

The protocol is plain TCP/IP. From posgresql documentation about "frontends" and "backends" protocol: PostgreSQL uses a message-based protocol for communication between frontends and backends (clients and servers). The protocol is supported over TCP/IP and also over Unix-domain sockets. Port number 5432 has been registered with IANA as the customary TCP ...


3

If you take a look at this tutorial it states you'll see a timeout which is consistent with what you're seeing, titled: Fail2ban - Rackspace Knowledge Center. excerpts Let's test fail2ban to make sure it behaves the way we want it to. We'll do that by failing a few ssh logins. We'll use two machines: The server we want to protect and another ...


2

Your limits are quite a bit aggressive. I don't see the point of having rules that only accept one packet per hour. You might have set high burstiness, but the bucket is only recharged by one every hour, and only if you actually received less than one packet per hour. The worst part is that these limits are applied for ALL packet, since you do not accept ...


2

Yes, but it doesn't work the way you want. From the man page: Multiple addresses can be specified, but this will expand to multiple rules (when adding with -A), or will cause multiple rules to be deleted (with -D). The way to do this is to add rules earlier in the chain to divert the traffic you don't want to log or modify, e.g. -A OUTPUT -o lo -j ...


2

The REJECT target rejects the packet. If you do not specify which ICMP message to reject with, the server by default will send back ICMP port unreachable (type 3, code 3). --reject-with modifies this behaviour to send a specific ICMP message back to the source host. You can find information about --reject-with and the available rejection messages in man ...


1

The most obvious one is IPv6, if there is some vulnerable server listening on that protocol. Any other network protocol could be a culprit. You don't need to drop all IPv4 traffic to secure a machine from remote attacks. It's sufficient to not run any vulnerable service. A default installation of any decent OS is fine in this respect. If you're paranoid ...


1

You probably want this rule: iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT which will allow all packages in already existing connections. Also, instead of your last rule to block everything else, I would recommend setting a policy: iptables -P INPUT DROP


1

As discussed in the comments, it seems like the problem was the VPN gateway wrongly sending ICMP redirects to the app server because setting the sysctl settings net.ipv4.conf.all.send_redirects and/or net.ipv4.conf.eth0.send_redirects to 0 appears to have solved the problem. I don't know why the VPN gateway would tell the app server to go via the outer ...


1

You don't get it completely right. The first two lines tell you that there is no »gateway« for reaching networks 10.0.0.0/24 and 10.1.1.0/24, but they are reachable through the respective interfaces eth1 and eth0, respectively. So if you want to send a packet to 10.0.0.1, the packet is send out over eth1, a packet to 10.1.1.47 over eth0. To reach »the ...


1

"Is there anything else I have to configure?" Your router, perhaps. You really have not provided enough information to provide a definitive answer, all you've done is point out is not because of iptables...perhaps. Iptables rules are processed in order. If that was the last rule appended (-A) and is last in the list when you look at iptables -L, then ...


1

Iptables needs some kernel modules loaded in order for "RELATED, ESTABLISHED" to work. If your HTTP clients are okay, you obviously have some of them. > lsmod | grep conntrack nf_conntrack_ipv4 20258 6 nf_defrag_ipv4 12702 1 nf_conntrack_ipv4 xt_conntrack 12760 6 nf_conntrack 99996 2 ...



Only top voted, non community-wiki answers of a minimum length are eligible