Bekijk de volledige versie : Firewall config for WL-500gP in access point operation mode with no Wifi
richard_roe
18-10-2007, 13:43
Hi all!
If you have the time to help me out a little bit I would be really greatful! :D
I'm running my Asus WL-500gP in access point operation mode with the Wifi disabled (Oleg's firmware), just as a NAT client wired to the LAN.
I believe that i would like to have some protection against SSH brute force attacks. Port 23 on my external router is forwarded to my WL-500gP which runs dropbear.
Would someone like to suggest a config for me?
Thanks in advance!
Richard
I've got this setup, got it on some forum discussion about portscan and SSH bruteforce attack. Frankly, I don't know where it comes from, who made it, or if it even works. Furthermore, I don't know what would have to be changed for your purpose. Not much help, but anyway.
# This we know...
WANIF=$1
LANIP=$4
# insert necessary modules
insmod ipt_recent
insmod ipt_psd
# Drop previous offenders - you dont want them in your net at all!
iptables -N BANDITDROP
iptables -A INPUT -m recent --rcheck --name BANDIT -j BANDITDROP
iptables -A FORWARD -m recent --rcheck --name BANDIT -j BANDITDROP
iptables -A BANDITDROP -m recent --update --seconds 3600 --rttl --name BANDIT \
-j LOG --log-prefix "Bandit DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
iptables -A BANDITDROP -j REJECT --reject-with icmp-net-unreachable
# Detect port scan
iptables -N PORTSCANDROP
iptables -A INPUT -i ${WANIF} -m psd -j PORTSCANDROP
iptables -A PORTSCANDROP -m recent --set --name BANDIT
iptables -A PORTSCANDROP -m recent --update --seconds 3600 --rttl --name BANDIT \
-j LOG --log-prefix "Port_Scan DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
iptables -A PORTSCANDROP -j REJECT --reject-with icmp-net-unreachable
# SSH server with brute force prevention
iptables -N SSHFORCEDROP
iptables -N SSHACCEPT
iptables -A INPUT -m tcp -p tcp --dport 22 -m state --state NEW -m limit --limit 3/min --limit-burst 2 -j SSHACCEPT
iptables -A INPUT -m tcp -p tcp --dport 22 -j SSHFORCEDROP
iptables -A SSHFORCEDROP -m recent --set --name BANDIT
iptables -A SSHFORCEDROP -m recent --update --seconds 3600 --rttl --name BANDIT \
-j LOG --log-prefix "SSH_Brute_Force DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
iptables -A SSHFORCEDROP -j REJECT --reject-with icmp-proto-unreachable
iptables -A SSHACCEPT -j LOG --log-prefix "SSH ACCEPT " --log-tcp-sequence \
--log-tcp-options --log-ip-options
iptables -A SSHACCEPT -j ACCEPT
iptables -t nat -A PREROUTING -i ${WANIF} -p tcp --dport 22 -j DNAT --to-destination ${LANIP}:22
Don't use port 22 (ssh) if you don't have too.
You can also do port translation, that already helps prevent 99.9999999% of ssh attacks..
e.g. translate port 54321 to port 22.
Almost nobody scans for ssh on any port than 22...
richard_roe
20-10-2007, 16:06
Thank You LinusW.
I think I've found the source of your script (http://www.macsat.com/macsat/component/option,com_smf/Itemid,50/topic,206.msg1716/#msg1716) ;)
I've assembled a post-firewall script that I'll try out very soon.
Since I'm a beginner I've likely made some mistakes .... Please feel free to point them out to me. Any suggestions for improvements?
Here's my script:
#!/bin/sh
# Firewall config for WL-500gP in access point operation mode with disabled Wifi, acting as
# a NAT client acessing Internet through a gateway.
#
# V 1.0 October 20, 2007
#
# Mainly inspired by the oceanpark.com firewall rules found at
# http://oceanpark.com/notes/firewall_example.html and from
# Pjotrek far out in the wild forests of Sweden who's work can be found at
# http://www.macsat.com/macsat/component/option,com_smf/Itemid,50/topic,206.msg1716/#msg1716
# ---------------------------------------------------
#
# First set a few values
#
LOCALNET="192.168.0.0/24"
SSHPORT=48751
#
# Configure default policies (-P), meaning default rule to apply if no
# more specific rule below is applicable. These rules apply if a more specific rule below
# is not applicable. Defaults are to DROP anything sent to firewall or internal
# network, permit anything going out.
#
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
#
# Flush (-F) all specific rules
# We don't know where we've been, do we?
#
iptables -F INPUT
iptables -F FORWARD
iptables -F OUTPUT
iptables -F -t nat
#
# Permit packets in to our host itself that are part of existing and related connections.
#
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#
# Allow all inputs from the local interface
#
iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT
#
# Accept all tcp SYN packets for protocol HTTP from the internal network:
#
iptables -A INPUT -p tcp -s $LOCALNET -d 0/0 --destination-port 80 --syn -j ACCEPT
#
# DNS queries, the reply will be a UDP connection back to the high
# numbered client port:
#
iptables -A INPUT -p udp -s $LOCALNET --source-port 53 -d 0/0 -j ACCEPT
#
# For some other obscure custom server running here listening on some port:
#
iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 12345 --syn -j ACCEPT
#
# insert necessary modules
#
insmod ipt_recent
#
# Drop previous offenders - you dont want them in your net at all!
#
iptables -N BANDITDROP
iptables -A INPUT -m recent --rcheck --name BANDIT -j BANDITDROP
iptables -A BANDITDROP -m recent --update --seconds 3600 --rttl --name BANDIT \
-j LOG --log-prefix "Bandit DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
iptables -A BANDITDROP -j REJECT --reject-with icmp-net-unreachable
#
# SSH server with brute force prevention
#
iptables -N SSHFORCEDROP
iptables -N SSHACCEPT
iptables -A INPUT -m tcp -p tcp --dport $SSHPORT -m state --state NEW -m limit --limit 3/min --limit-burst 2 -j SSHACCEPT
iptables -A INPUT -m tcp -p tcp --dport $SSHPORT -j SSHFORCEDROP
iptables -A SSHFORCEDROP -m recent --set --name BANDIT
iptables -A SSHFORCEDROP -m recent --update --seconds 3600 --rttl --name BANDIT \
-j LOG --log-prefix "SSH_Brute_Force DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
iptables -A SSHFORCEDROP -j REJECT --reject-with icmp-proto-unreachable
iptables -A SSHACCEPT -j LOG --log-prefix "SSH ACCEPT " --log-tcp-sequence \
--log-tcp-options --log-ip-options
iptables -A SSHACCEPT -j ACCEPT
#
# Finally, DENY all connection requests to any UDP port not yet provided
# for and all SYN connection requests to any TCP port not yet provided
# for. Using DENY instead of REJECT means that no 'ICMP port
# unreachable' response is sent back to the client attempting to
# connect. I.e., DENY just ignores connection attempts. Hence, use of
# DENY causes UDP connection requests to time out and TCP connection
# requests to hang. Hence, using DENY instead of REJECT may have
# the effect of frustrating attackers due to increasing the amount of
# time taken to probe ports.
#
# Note that there is a fundamental difference between UDP and TCP
# protocols. With UDP, there is no 'successful connection' response.
# With TCP, there is. So an attacking client will be left in the dark
# about whether or not the denied UDP packets arrived and will hang
# waiting for a response from denied TCP ports. An attacker will not
# be able to immediately tell if UDP connection requests are simply
# taking a long time, if there is a problem with connectivity between
# the attacking client and the server, or if the packets are being
# ignored. This increases the amount of time it takes for an attacker
# to scan all UDP ports. Similarly, TCP connection requests to denied
# ports will hang for a long time. By using REJECT instead of DENY, you
# would prevent access to a port in a more 'polite' manner, but give out
# more information to wannabe attackers, since the attacker can positively
# detect that a port is not accessible in a small amount of time from
# the 'ICMP port unreachable' response.
iptables -A INPUT -s 0/0 -d 0/0 -p udp -j DROP
iptables -A INPUT -s 0/0 -d 0/0 -p tcp --syn -j DROP
richard_roe
23-10-2007, 18:05
Since I use a SSH tunnel to access the web interface and the fact that the WL-500gP should not act as a DNS server I've removed the HTTP and DNS parts.
Here is my current config which I've now started to use. It seems to run well.
:D
#!/bin/sh
# Firewall config for WL-500gP in access point operation mode with disabled Wifi, acting as
# a NAT client acessing Internet through a gateway.
#
# V 1.1 October 23, 2007
#
# Mainly inspired by the oceanpark.com firewall rules found at
# http://oceanpark.com/notes/firewall_example.html and from
# Pjotrek far out in the wild forests of Sweden who's work can be found at
# http://www.macsat.com/macsat/component/option,com_smf/Itemid,50/topic,206.msg1716/#msg1716
# ---------------------------------------------------
#
# First set a few values
#
LOCALNET="192.168.0.0/24"
SSHPORT=48751
#
# Configure default policies (-P), meaning default rule to apply if no
# more specific rule below is applicable. These rules apply if a more specific rule below
# is not applicable. Defaults are to DROP anything sent to firewall or internal
# network, permit anything going out.
#
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
#
# Flush (-F) all specific rules
# We don't know where we've been, do we?
#
iptables -F INPUT
iptables -F FORWARD
iptables -F OUTPUT
iptables -F -t nat
#
# Permit packets in to our host itself that are part of existing and related connections.
#
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#
# Allow all inputs from the local interface
#
iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT
#
# For some other obscure custom server running here listening on some port:
#
iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 12345 --syn -j ACCEPT
#
# insert necessary modules
#
insmod ipt_recent
#
# Drop previous offenders - you dont want them in your net at all!
#
iptables -N BANDITDROP
iptables -A INPUT -m recent --rcheck --name BANDIT -j BANDITDROP
iptables -A BANDITDROP -m recent --update --seconds 3600 --rttl --name BANDIT
-j LOG --log-prefix "Bandit DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
iptables -A BANDITDROP -j REJECT --reject-with icmp-net-unreachable
#
# SSH server with brute force prevention
#
iptables -N SSHFORCEDROP
iptables -N SSHACCEPT
iptables -A INPUT -m tcp -p tcp --dport $SSHPORT -m state --state NEW -m limit --limit 3/min --limit-burst 2 -j SSHACCEPT
iptables -A INPUT -m tcp -p tcp --dport $SSHPORT -j SSHFORCEDROP
iptables -A SSHFORCEDROP -m recent --set --name BANDIT
iptables -A SSHFORCEDROP -m recent --update --seconds 3600 --rttl --name BANDIT
-j LOG --log-prefix "SSH_Brute_Force DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
iptables -A SSHFORCEDROP -j REJECT --reject-with icmp-proto-unreachable
iptables -A SSHACCEPT -j LOG --log-prefix "SSH ACCEPT " --log-tcp-sequence
--log-tcp-options --log-ip-options
iptables -A SSHACCEPT -j ACCEPT
#
# Finally, DENY all connection requests to any UDP port not yet provided
# for and all SYN connection requests to any TCP port not yet provided
# for. Using DENY instead of REJECT means that no 'ICMP port
# unreachable' response is sent back to the client attempting to
# connect. I.e., DENY just ignores connection attempts. Hence, use of
# DENY causes UDP connection requests to time out and TCP connection
# requests to hang. Hence, using DENY instead of REJECT may have
# the effect of frustrating attackers due to increasing the amount of
# time taken to probe ports.
#
# Note that there is a fundamental difference between UDP and TCP
# protocols. With UDP, there is no 'successful connection' response.
# With TCP, there is. So an attacking client will be left in the dark
# about whether or not the denied UDP packets arrived and will hang
# waiting for a response from denied TCP ports. An attacker will not
# be able to immediately tell if UDP connection requests are simply
# taking a long time, if there is a problem with connectivity between
# the attacking client and the server, or if the packets are being
# ignored. This increases the amount of time it takes for an attacker
# to scan all UDP ports. Similarly, TCP connection requests to denied
# ports will hang for a long time. By using REJECT instead of DENY, you
# would prevent access to a port in a more 'polite' manner, but give out
# more information to wannabe attackers, since the attacker can positively
# detect that a port is not accessible in a small amount of time from
# the 'ICMP port unreachable' response.
iptables -A INPUT -s 0/0 -d 0/0 -p udp -j DROP
iptables -A INPUT -s 0/0 -d 0/0 -p tcp --syn -j DROP