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 8 years ago.
Improve this question
I have a problem with connecting through FTP when iptables is enabled. I've tried all suggestions from this topic and a few others, but I'm still getting:
Error: Connection timed out
Error: Could not connect to server
There's no problem with connection when I turn off iptables, so I'm sure this is what's causing the issue.
This is how my iptables file looks like:
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 2020 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
# Allow FTP connections # port 21
-A INPUT -p tcp --sport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp --dport 21 -m state --state ESTABLISHED -j ACCEPT
COMMIT
First of all, the order of the rules is important. Since you have specified the REJECT rule before the FTP ACCEPT rules, FTP packets are rejected by that rule before reaching the relevant rules and having any chance of getting accepted.
Secondly, the link you've mentioned in your question discusses the rules required by the server, and not by the client. The appropriate rules for the client are opposite.
Since the default policy of the OUTPUT chain is ACCEPT, and you have allowed packets of ESTABLISHED or RELATED connections into your machine, passive-mode FTP should already be supported by your rule set.
In order to support active-mode FTP as well, you need to allow incoming TCP connections originating from the server at port 20, as follows:
iptables -A INPUT -p tcp --sport 20 -j ACCEPT
This link supplies a concise summary of the rationale for the above rules.
Since in active-mode FTP the data connection's hosts and ports can be reliably and easily determined from the control connection's hosts and ports, I think that loading the nf_conntrack_ftp module would prove the ad-hoc rule for allowing incoming TCP connections originating from the server at port 20 redundant. I haven't checked this, but loading the module with modprobe nf_conntrack_ftp might suffice because incoming RELATED and ESTABLISHED traffic is allowed. This approach would be preferable since it's a bit more secure.
The rule should be as given below:
$IPT -A INPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -p tcp --sport 21 -m state --state ESTABLISHED -j ACCEPT
The INPUT chain should have destination port 21 opened for incoming connections. Let me know your feedback after trying this out.
Related
I need an linux firewall rule that will accomplish the following: iptables –A INPUT rule that will accept any packet that comes in over ports 43,53 or 67.
I am new to this. Do you have to have -p "protocol" before --dport 43,53,67 or can you take out the -p "protocol" and just have the --dport 43,53,67. How would you have accept any packet that could come over multiple protocols?
You have to use it for all protocols you want to allow
iptables -A INPUT -p tcp -m multiport --dports 43,53,67 -j ACCEPT
iptables -A INPUT -p udp -m multiport --dports 43,53,67 -j ACCEPT
--dport is not a flag for general iptables rules. It's a flag for one of it's extended packet matching modules. These are loaded when you use -p protocol or -m. Unless you specify -m <protocol> or -p <protocol> with a specific protocol you can't use --dport
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 6 years ago.
Improve this question
Alright, this has not happened before in my past experience in coding and using Linux but right now, when I start up IPTables, I cannot access my website in every way possible. SSH still works.
My operating system:
CentOS Linux release 7.2.1511 (Core)
And the things inside my IPTables:
# sample configuration for iptables service
# you can edit this manually or use system-config-firewall
# please do not ask us to add additional ports/services to this default configuration
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
If anyone could help me fix this problem, it'd be great.
iptables -I INPUT 3 -p tcp -m state --state NEW -m tcp -m multiport --dports 80,443 -j ACCEPT
If you could read the manual of iptables, it also would be great.
I am having some trouble understanding iptables. I know it acts as a filter but something isn't clicking because it isn't working the way I think it should. Let me start by saying that I'm creating a white list, so all policies (INPUT, FORWARD, OUTPUT) default to DROP.
I have the following rules related to SMTP:
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p tcp --dport 25 -j ACCEPT
-A OUTPUT -p tcp --dport 25 -j ACCEPT //needed for receiving?
-A OUTPUT -p tcp --sport 25 -j ACCEPT //needed for sending?
*these 3 lines also exist verbatim for ports 587 & 465
If I remove the first OUTPUT line then my server won't receive emails & if I remove the last line it won't send emails. What I don't understand is why. Shouldn't:
-A INPUT -p tcp --dport 25 -j ACCEPT
-A OUTPUT -p tcp --sport 25 -j ACCEPT
be enough to let everything through? AFAIK all SMTP communication should go over 25, 587 or 465. My current understanding says an SMTP packet should always match one of these two rules. All input packets should come to port 25, and all output packets be sent from 25? What am I missing?
For SMTP you don't need any --sport rule. The source and destination don't depend on direction - they're match on the packet's source and destination ports. Every connection will have a random source port, so there's nothing to match on.
If I remove the first OUTPUT line then my server won't receive emails & if I remove the last line it won't send emails.
This is wrong. Only the INPUT line matters for receiving emails. Also, only the OUTPUT --dport 25 line matters for sending emails. So these rules should be enough:
-A INPUT -p tcp --dport 25 -j ACCEPT
-A OUTPUT -p tcp --dport 25 -j ACCEPT
The problem may be that you set OUTPUT to default to DROP, but allowed established connection on INPUT only. Usually people leave OUTPUT defaulting to ACCEPT. If you want to continue using a whitelist for OUTPUT, you'll have to add:
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Also, please read up on SMTP ports. Some of those you listed are only needed for email submissions and deprecated encryption, not for server-to-server communication. This may change how you plan your rules.
Previous answer state: Also, only the OUTPUT --dport 25 line matters for sending emails.
This is not always true. For instance some systems are configured as smarthost where the MTA become a client. In such case, the MTA will connect to a remote server on submission port (587) USING SASL authentication to send mails.
To resume, a client is sending mail through a remote server and the remote server itself connect to another remote server on port 587 with SASL authentication.
In such case, the following iptable rules applies (for the smarthost)
iptables -I OUTPUT -p -tcp -dport 597 -j ACCEPT
iptables -I INPUT -p -tcp -sport 587 -j ACCEPT
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 8 years ago.
Improve this question
I am new to tor and Kali linux, I have installed Kali linux and installed tor and download tor bundle, but I realised only when I brows through the tor bundle browser is when my traffic is being channel through tor, excluding any other browser and application.
How can I channel all my network traffic on linux to pass through the tor network?
Add the following to torrc:
AutomapHostsOnResolve 1
DNSPort 53530
TransPort 9040
create a file to contain your iptables rules. For IPv4: /etc/iptables.firewall.rules and for IPv6: /etc/ip6tables.firewall.rules.
Now edit the IPv4 file and add something like the following (make sure to grep for TODO items and follow the instructions):
# Ues the nat table to redirect some traffic to Tor
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
# Don't allow Tor traffic to get stuck in a redirect loop...
# TODO: Is `tor' your actual Tor user? It might be `debian-tor' or `toranon' or something else.
-A OUTPUT -m owner --uid-owner tor -j RETURN
# Redirect DNS lookups to Tor.
# TODO: Set this to your Tor DNSPort if it's not 53530.
-A OUTPUT ! -o lo -p udp -m udp --dport 53 -j REDIRECT --to-ports 53530
# Do not redirect private networks or loopback.
-A OUTPUT -d 10.0.0.0/8 -j RETURN
-A OUTPUT -d 172.16.0.0/12 -j RETURN
-A OUTPUT -d 192.168.0.0/16 -j RETURN
# Redirect HS connections to the TransPort.
-A OUTPUT -d 127.192.0.0/10 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j REDIRECT --to-ports 9040
# Redirect all TCP traffic to Tor's TransPort.
-A OUTPUT ! -o lo -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j REDIRECT --to-ports 9040
COMMIT
# Only accept anonymized network traffic in the filter table.
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:LAN - [0:0]
# Allow loopback
-A INPUT -i lo -j ACCEPT
# Allow connections that are already established.
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# Reject incoming connections.
-A INPUT -p udp -m conntrack --ctstate NEW -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -m conntrack --ctstate NEW -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-port-unreachable
# Accept network traffic for the Tor service itself.
# TODO: Tor user?
-A OUTPUT -m owner --uid-owner tor -j ACCEPT
# Accept DNS requests to the Tor DNSPort.
-A OUTPUT -d 127.0.0.1/32 -p udp -m udp --dport 53530 -j ACCEPT
# Accept outgoing traffic to the local Tor TransPort.
-A OUTPUT -d 127.0.0.1/32 -p tcp -m tcp --dport 9040 --tcp-flags FIN,SYN,RST,ACK SYN -j ACCEPT
# Accept outgoing traffic to the local Tor SOCKSPorts.
-A OUTPUT -d 127.0.0.1/32 -p tcp -m tcp --dport 9050 --tcp-flags FIN,SYN,RST,ACK SYN -j ACCEPT
-A OUTPUT -d 127.0.0.1/32 -p tcp -m tcp --dport 9150 --tcp-flags FIN,SYN,RST,ACK SYN -j ACCEPT
# Accept connections on private networks.
-A OUTPUT -d 10.0.0.0/8 -j LAN
-A OUTPUT -d 172.16.0.0/12 -j LAN
-A OUTPUT -d 192.168.0.0/16 -j LAN
-A LAN -p tcp -m tcp --dport 53 -j REJECT --reject-with icmp-port-unreachable
-A LAN -p udp -m udp --dport 53 -j REJECT --reject-with icmp-port-unreachable
-A LAN -j ACCEPT
# Reject all other outgoing traffic.
-A OUTPUT -j REJECT --reject-with icmp-port-unreachable
COMMIT
For the IPv6 file, you can do something similar with ip6tables, or just drop all IPv6 traffic.
Now set these rules to be loaded on startup by creating the file /etc/network/if-pre-up.d/firewall with the following contents:
#!/bin/sh
/sbin/iptables-restore < /etc/iptables.firewall.rules
/sbin/ip6tables-restore < /etc/ip6tables.firewall.rules
Restart Tor if needed, and load your new firewall rules manually by executing the previous commands.
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 7 years ago.
Improve this question
I am trying to apply these firewall rules over SSH. When I run the script with ./script.sh, the terminal will hang and I am forced to quit using ~ . Enter. The rules are applied, but my SSH connection is dropped and my terminal hangs. However, when I do bash -x ./script.sh, it runs the script while outputting debug information and doesn't interrupt my session.
My firewall rules are simple. Allow incoming/outgoing SSH and allow outgoing DNS and HTTP/S for updates.
This behavior was witnessed on Red Hat, Debian, and Ubuntu machines.
I consider you are running the scripts on a ssh session established on default port 22
then please replace the ssh rules
iptables -A INPUT -p tcp -m tcp --dport 22 -m limit --limit 5/minute --limit-burst 15 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT
for a less restrictive set i.e.
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT
once you get it working you can add to these now simpler rules the more restrictive parameters one at the time.
please consider if your input rule includes
--state NEW
only new ssh connections will be accepted; already established will not.
Move this rule to the top and test again:
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT