IPtables is blocking my https-alt port and the sieve one.
I restricting iptables rules a little.
This is the rules I'm putting inside iptables.
#!/bin/sh
#
# A shell script used to setup rules for iptables. Rules gleened from
# various websites.
#
# References:
# http://www.newartisans.com/blog_files/tricks.with.iptables.php
# Wipe the tables clean
iptables -F
# INPUT SIDE
# Accept all loopback input
iptables -A INPUT -i lo -p all -j ACCEPT
# Allow the three way handshake
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Reject spoofed packets
iptables -A INPUT -s 10.0.0.0/8 -j DROP
iptables -A INPUT -s 169.254.0.0/16 -j DROP
iptables -A INPUT -s 172.16.0.0/12 -j DROP
iptables -A INPUT -s 127.0.0.0/8 -j DROP
iptables -A INPUT -s 224.0.0.0/4 -j DROP
iptables -A INPUT -d 224.0.0.0/4 -j DROP
iptables -A INPUT -s 240.0.0.0/5 -j DROP
iptables -A INPUT -d 240.0.0.0/5 -j DROP
iptables -A INPUT -s 0.0.0.0/8 -j DROP
iptables -A INPUT -d 0.0.0.0/8 -j DROP
iptables -A INPUT -d 239.255.255.0/24 -j DROP
iptables -A INPUT -d 255.255.255.255 -j DROP
# Stop smurf attacks
iptables -A INPUT -p icmp -m icmp --icmp-type address-mask-request -j DROP
iptables -A INPUT -p icmp -m icmp --icmp-type timestamp-request -j DROP
iptables -A INPUT -p icmp -m icmp -m limit --limit 1/second -j ACCEPT
# Drop all invalid packets
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A FORWARD -m state --state INVALID -j DROP
iptables -A OUTPUT -m state --state INVALID -j DROP
# Drop excessive RST packets to avoid smurf attacks
iptables -A INPUT -p tcp -m tcp --tcp-flags RST RST -m limit --limit 2/second --limit-burst 2 -j ACCEPT
# Attempt to block portscans
# Anyone who tried to portscan us is locked out for an entire day.
iptables -A INPUT -m recent --name portscan --rcheck --seconds 86400 -j DROP
iptables -A FORWARD -m recent --name portscan --rcheck --seconds 86400 -j DROP
# Once the day has passed, remove them from the portscan list
iptables -A INPUT -m recent --name portscan --remove
iptables -A FORWARD -m recent --name portscan --remove
# These rules add scanners to the portscan list, and log the attempt.
iptables -A INPUT -p tcp -m tcp --dport 139 -m recent --name portscan --set -j LOG --log-prefix "Portscan:"
iptables -A INPUT -p tcp -m tcp --dport 139 -m recent --name portscan --set -j DROP
iptables -A FORWARD -p tcp -m tcp --dport 139 -m recent --name portscan --set -j LOG --log-prefix "Portscan:"
iptables -A FORWARD -p tcp -m tcp --dport 139 -m recent --name portscan --set -j DROP
# Allow the following ports through from outside
# https e ssh se usi sslh
[b]iptables -A INPUT -p tcp -m tcp --dport 8443 -j ACCEPT[/b]
# smtp
iptables -A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
# smtps
iptables -A INPUT -p tcp -m tcp --dport 465 -j ACCEPT
# smtps
iptables -A INPUT -p tcp -m tcp --dport 587 -j ACCEPT
# http
iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 1080 -j ACCEPT
# pop3
iptables -A INPUT -p tcp -m tcp --dport 110 -j ACCEPT
# ntpd
iptables -A INPUT -p udp -m udp --dport 123 -j ACCEPT
# imap
iptables -A INPUT -p tcp -m tcp --dport 143 -j ACCEPT
# https e ssh se usi sslh
iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
# imaps
iptables -A INPUT -p tcp -m tcp --dport 993 -j ACCEPT
# pop3s
iptables -A INPUT -p tcp -m tcp --dport 995 -j ACCEPT
# proxy squid
iptables -A INPUT -p tcp -m tcp --dport 3128 -j ACCEPT
# sieve
[b]iptables -A INPUT -p tcp -m tcp --dport 4190 -j ACCEPT[/b]
# ssh & sftp
iptables -A INPUT -p tcp -m tcp --dport 49494 -j ACCEPT
# Allow pings through
iptables -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
# Kill all other input
iptables -A INPUT -j REJECT
# Output side
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Sieve
[b]iptables -A OUTPUT -p tcp -m tcp --dport 4190 -j ACCEPT[/b]
# Allow the following ports through from outside
# smtp
iptables -A OUTPUT -p tcp -m tcp --dport 25 -j ACCEPT
# smtps
iptables -A OUTPUT -p tcp -m tcp --dport 465 -j ACCEPT
# smtps
iptables -A OUTPUT -p tcp -m tcp --dport 587 -j ACCEPT
# DNS requests
iptables -A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
# DHCP/Bootstrap Protocol Server
iptables -A OUTPUT -p udp -m udp --dport 67 -j ACCEPT
# http
iptables -A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 1080 -j ACCEPT
# pop3
iptables -A OUTPUT -p tcp -m tcp --dport 110 -j ACCEPT
# ntpd
iptables -A OUTPUT -p udp -m udp --dport 123 -j ACCEPT
# imap
iptables -A OUTPUT -p tcp -m tcp --dport 143 -j ACCEPT
# https e ssh se usi sslh
iptables -A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT
# https
[b]iptables -A OUTPUT -p tcp -m tcp --dport 8443 -j ACCEPT[/b]
# imaps
iptables -A OUTPUT -p tcp -m tcp --dport 993 -j ACCEPT
# pop3s
iptables -A OUTPUT -p tcp -m tcp --dport 995 -j ACCEPT
# Proxy quid
iptables -A OUTPUT -p tcp -m tcp --dport 3128 -j ACCEPT
# ssh & sftp
iptables -A OUTPUT -p tcp -m tcp --dport 49494 -j ACCEPT
# Allout pings out
iptables -A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
# Kill all other output
iptables -A OUTPUT -j REJECT
# FORWARD SIDE
iptables -A FORWARD -j REJECT
as you can see there is rules to accept connections on port 8443 (it is my https alternative port) and there is a rule to accept connection on 4190 where my sieve is.
With this rules I cannot access neither sieve neither https-alt.
Why?
Thanks!!!
1 Reply
@sblantipodi:
With this rules I cannot access neither sieve neither https-alt.
Try temporarily disabling your output rules (empty the chain and set the policy to accept) and see if it works. From a quick glance it looks like you've got your output rules filtering on destination port where they should be using source port (e.g., on output the traffic is coming from the well known server port, not to it). So the traffic is probably reaching the daemons, but the return traffic can't leave.
Personally I tend to leave the output chain pretty simple, generally trusting that once a process is operating locally, it ought to be able to generate outbound traffic. There's nothing wrong with a more locked down output chain, which I'm sure others prefer, you just have to be sure you account for the proper traffic patterns. Although, to cover your regular services you might be able to just use a single "established" rule, since I'd think for any inbound traffic to become established it would have had to make it through your input chain and reach a daemon. Then you just need individual output chain rules for whatever locally originated outbound connections you wish to support (such as, for example, outbound mail delivery).
– David