Hi all, I use iptables as a firewall on my local machine to filter any incoming connections one some ports I want to protect. I have tested this with one single port and then run a portscan o that machine. nmap was not able to connect to that protected port but it marked the port as "filtered". How can I prevent this? nmap should not be able to see if and which ports are filtered. I have tried with DENY and REJECT but got the same report. Thanx Michael
* Michael Neumann;
Hi all,
I use iptables as a firewall on my local machine to filter any incoming ^^^^^^^^^^^ filtered. I have tried with DENY and REJECT but got the same report.
DENY is now DROP the below is from the SENTRY Firewall CD $IPTABLES -N CHECK_FLAGS $IPTABLES -F CHECK_FLAGS ##------------------------------------------------------------------------## ## NMAP FIN/URG/PSH $IPTABLES -A CHECK_FLAGS -p tcp --tcp-flags ALL FIN,URG,PSH -m limit \ --limit 5/minute -j LOG --log-level $LOG_LEVEL --log-prefix "NMAP-XMAS:" $IPTABLES -A CHECK_FLAGS -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP ##------------------------------------------------------------------------## ##------------------------------------------------------------------------## ## SYN/RST $IPTABLES -A CHECK_FLAGS -p tcp --tcp-flags SYN,RST SYN,RST -m limit \ --limit 5/minute -j LOG --log-level $LOG_LEVEL --log-prefix "SYN/RST:" $IPTABLES -A CHECK_FLAGS -p tcp --tcp-flags SYN,RST SYN,RST -j DROP ##------------------------------------------------------------------------## ##------------------------------------------------------------------------## ## SYN/FIN -- Scan(probably) $IPTABLES -A CHECK_FLAGS -p tcp --tcp-flags SYN,FIN SYN,FIN -m limit \ --limit 5/minute -j LOG --log-level $LOG_LEVEL --log-prefix "SYN/FIN:" $IPTABLES -A CHECK_FLAGS -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP ##------------------------------------------------------------------------## ##------------------------------------------------------------------------## ## Make some types of port scans annoyingly slow, also provides some ## protection against certain DoS attacks. The rule in chain KEEP_STATE ## referring to the INVALID state should catch most TCP packets with the ## RST or FIN bits set that aren't associate with an established connection. ## Still, these will limit the amount of stuff that is accepted through our ## open ports(if any). I suggest you test these for your configuration before ## you uncomment them, as they could cause problems. # $IPTABLES -A CHECK_FLAGS -m limit --limit 5/second -p tcp --tcp-flags ALL RST -j ACCEPT # $IPTABLES -A CHECK_FLAGS -m limit --limit 5/second -p tcp --tcp-flags ALL FIN -j ACCEPT # $IPTABLES -A CHECK_FLAGS -m limit --limit 5/second -p tcp --tcp-flags ALL SYN -j ACCEPT ##------------------------------------------------------------------------## -- Togan Muftuoglu
Hi all,
I use iptables as a firewall on my local machine to filter any incoming connections one some ports I want to protect. I have tested this with one single port and then run a portscan o that machine. nmap was not able to connect to that protected port but it marked the port as "filtered". How can I prevent this? nmap should not be able to see if and which ports are filtered. I have tried with DENY and REJECT but got the same report.
Make sure you don't send out icmp unreachables. hint: man iptables. double hint: DROP. Damn those man pages and their documentation! ;)
Thanx Michael
Kurt Seifried, kurt@seifried.org A15B BEE5 B391 B9AD B0EF AEB0 AD63 0B4E AD56 E574 http://www.seifried.org/security/
I use iptables as a firewall on my local machine to filter any incoming connections one some ports I want to protect. I have tested this with one single port and then run a portscan o that machine. nmap was not able to connect to that protected port but it marked the port as "filtered". How can I prevent this? nmap should not be able to see if and which ports are filtered. I have tried with DENY and REJECT but got the same report. You can't with ipchains, but with iptables (kernel 2.4.x). Use return-rst.
hth Markus -- _____________________________ /"\ Markus Gaugusch ICQ 11374583 \ / ASCII Ribbon Campaign markus@gaugusch.dhs.org X Against HTML Mail / \
You can't with ipchains, but with iptables (kernel 2.4.x). Use return-rst.
**DANGEROUS** If you rely on return-rst to "secure" open ports all I do is firewall them or ignore them and I can get access to the port in question. Not such a great idea.
hth Markus
Kurt Seifried, kurt@seifried.org A15B BEE5 B391 B9AD B0EF AEB0 AD63 0B4E AD56 E574 http://www.seifried.org/security/
You can't with ipchains, but with iptables (kernel 2.4.x). Use return-rst.
**DANGEROUS**
If you rely on return-rst to "secure" open ports all I do is firewall them or ignore them and I can get access to the port in question. Not such a great idea. I don't understand? Why does is there a (firewalling) difference between return-rst (which makes the port look "closed") and "drop" or "reject" (which makes the port look "filtered")
Or is return-rst something completely different? Markus -- _____________________________ /"\ Markus Gaugusch ICQ 11374583 \ / ASCII Ribbon Campaign markus@gaugusch.dhs.org X Against HTML Mail / \
Yup, On 26-Sep-01 Markus Gaugusch wrote:
You can't with ipchains, but with iptables (kernel 2.4.x). Use return-rst.
**DANGEROUS**
If you rely on return-rst to "secure" open ports all I do is firewall them or ignore them and I can get access to the port in question. Not such a great idea. I don't understand? Why does is there a (firewalling) difference between return-rst (which makes the port look "closed") and "drop" or "reject" (which makes the port look "filtered")
Or is return-rst something completely different?
here we go again... First of all, a quote from the return-rst-1.1 README: --- "This is a firewalling tool, and as such it requires reasonable knowledge of IP and TCP protocols to understand it and use it effectively. Return-RST was written to overcome the lack of an ipchains policy that can return a RESET packet when denying a TCP connection. The DENY policy just drops the packet, and the REJECT policy sends back an ICMP message. Either policy will tip an attacker off to the fact they're being filtered. On the other hand, an RST in response to a TCP SYN packet is what happens when there is no server listening on a port - this program allows you to return this error, so attackers will think that there is no server available." --- Return-rst works in conjunction with ipchains, and no, it's *no* standalone firewalling tool, it does *not* automagically protect anything if not properly implemented. In order to use return-rst you'd have to construct specially designed ipchains rules, like so: ipchains -A input -p tcp -y -o 128 -j DENY -s <attacker> -d <yourhost> 22 The above line protects the ssh port of a server. The option "-o 128" copies the first 128 bytes to the netlink device (the support of which has to be compiled into the kernel). From the netlink device, return-rst (which is a background process/demon) processes the packets and sends an RST (reset) back to the attacker, whose favourite scanner would show a closed port/no listening service. The security relevance of all this depends on the environment in which return-rst is used. Of course, return-rst is no wonder cure against malicious hackers, it helps to reduce lingering portscan connections and keeps away most script kiddies. A proper use would include setting return-rst on ports where only "trusted" IPs have access to, say an administrative ssh service, etc. Hope that sheds more light on the issue.
Markus -- _____________________________ /"\ Markus Gaugusch ICQ 11374583 \ / ASCII Ribbon Campaign markus@gaugusch.dhs.org X Against HTML Mail
Boris Lorenz
Return-rst works in conjunction with ipchains, and no, it's *no* standalone firewalling tool, it does *not* automagically protect anything if not properly implemented. This was a misunderstanding. I did not use the tool return-rst, but the option of iptables. I didn't find it first, but here it is: --reject-with type The type given can be icmp-net-unreachable, icmp- host-unreachable, icmp-port-unreachable, icmp- proto-unreachable, icmp-net-prohibitedor icmp-host- prohibited, which return the appropriate ICMP error message (port-unreachable is the default). The option echo-reply is also allowed; it can only be used for rules which specify an ICMP ping packet, and generates a ping reply. Finally, the option ----> tcp-reset can be used on rules which only match the TCP protocol: this causes a TCP RST packet to be sent back. This is mainly useful for blocking ident probes which frequently occur when sending mail to broken mail hosts (which won't accept your mail otherwise). This is part of the REJECT target of iptables. I'm sorry, that I've confused you :(
Markus -- _____________________________ /"\ Markus Gaugusch ICQ 11374583 \ / ASCII Ribbon Campaign markus@gaugusch.dhs.org X Against HTML Mail / \
participants (5)
-
Boris Lorenz -
Kurt Seifried -
Markus Gaugusch -
Michael Neumann -
Togan Muftuoglu