Hi, I have shorewall version 1.4.10g on Redhat 9 Local clients are on eth1 in subnet 192.168.3.0/24. eth0 is for the outside (over xdsl with includes a ppp0 interface). Nessus (nessusd) is installed *on the firewall* and managed trough nessus (the client or frontend) running on one of the internal machines. When I was running a scan against 194.152.181.36 I observed several entries like following in the log of the firewall (its IP is 81.223.219.255): Nov 8 11:24:45 fw kernel: Shorewall:newnotsyn:DROP:IN= OUT=ppp0 SRC=81.223.219.255 DST=194.152.181.36 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=14693 DF PROTO=TCP SPT=1747 DPT=80 WINDOW=6432 RES=0x00 ACK FIN URGP=0 ------------------------------------------------------------------- Nov 8 11:24:45 fw kernel: Shorewall:newnotsyn:DROP:IN= OUT=ppp0 SRC=81.223.219.255 DST=194.152.181.36 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=20959 DF PROTO=TCP SPT=1749 DPT=80 WINDOW=6432 RES=0x00 ACK FIN URGP=0 I *guess* this is due to some tricks like FIN-, connect()- or SYN-scans (see below) or whatever, which are done by either nessusd or nmap, in order to look for open ports on the target. I am quiet shure, that reading trough the manuals for nessus or nmap I will find a solution on how to avoid these entries in the log. But I would prefer, to open the access for nessusd to the outside completely, so that even wired packets can get trough. I also did read FAQ 26 - may be I did not understand anything, but it seems not not be related to the above. Anhow, my config is NEWNOTSYN=No. Did anyone here already figure out how to achive this? TIA, Ingo. From the nmap man-page: TCP SYN scan: This technique is often referred to as "half-open" scanning, because you don’t open a full TCP connection. You send a SYN packet, as if you are going to open a real connection and you wait for a response. A SYN|ACK indicates the port is listen- ing. A RST is indicative of a non-listener. If a SYN|ACK is received, a RST is immediately sent to tear down the connection (actually our OS kernel does this for us). The primary advantage to this scanning technique is that fewer sites will log it. Unfortunately you need root privileges to build these custom SYN packets. This is the default scan type for privileged users. TCP connect() scan: This is the most basic form of TCP scanning. The connect() system call provided by your operating system is used to open a connection to every interesting port on the machine. If the port is listening, connect() will succeed, oth- erwise the port isn’t reachable. -- Ingo Lantschner T (+43-1) 59 55 766 M (+43-664) 143 84 18
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ingo Lantschner (Lists) wrote: | | Hi, | I have shorewall version 1.4.10g on Redhat 9 Local clients are on eth1 | in subnet 192.168.3.0/24. eth0 is for the outside (over xdsl with | includes a ppp0 interface). | | Nessus (nessusd) is installed *on the firewall* and managed trough | nessus (the client or frontend) running on one of the internal machines. | | When I was running a scan against 194.152.181.36 I observed several | entries like following in the log of the firewall (its IP is | 81.223.219.255): | | Nov 8 11:24:45 fw kernel: Shorewall:newnotsyn:DROP:IN= OUT=ppp0 | SRC=81.223.219.255 DST=194.152.181.36 LEN=52 TOS=0x00 PREC=0x00 TTL=64 | ID=14693 DF PROTO=TCP SPT=1747 DPT=80 WINDOW=6432 RES=0x00 ACK FIN URGP=0 | ------------------------------------------------------------------- | Nov 8 11:24:45 fw kernel: Shorewall:newnotsyn:DROP:IN= OUT=ppp0 | SRC=81.223.219.255 DST=194.152.181.36 LEN=52 TOS=0x00 PREC=0x00 TTL=64 | ID=20959 DF PROTO=TCP SPT=1749 DPT=80 WINDOW=6432 RES=0x00 ACK FIN URGP=0 | | I *guess* this is due to some tricks like FIN-, connect()- or SYN-scans | (see below) or whatever, which are done by either nessusd or nmap, in | order to look for open ports on the target. I am quiet shure, that | reading trough the manuals for nessus or nmap I will find a solution on | how to avoid these entries in the log. But I would prefer, to open the | access for nessusd to the outside completely, so that even wired packets | can get trough. | | I also did read FAQ 26 - may be I did not understand anything, but it | seems not not be related to the above. Anhow, my config is NEWNOTSYN=No. | | If you are going to be in the scanning business, turn NEWNOTSYN=Yes! - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBj7OcO/MAbZfjDLIRAi5pAKDKzO19QdgrqnUR9pmjUrwgV6zqbgCcCCIM exkxmnopEIp005sfXLzkI6Y=rxNq -----END PGP SIGNATURE-----
Tom Eastep wrote:> If you are going to be in the scanning business, turn NEWNOTSYN=Yes!Thanks Tom, that''s interesting and first of all: It worked! These log-entries are gone now. But I am bit confused now or better said, its not clear to me, what this newnotsyn-flag is about and what are the implications of setting it to Yes. In shorewall.conf I can read: --- NEWNOTSYN If this variable is set to "No" or "no", then when a TCP packet that does not have the SYN flag set and the ACK and RST flags clear then unless the packet is part of an established connection, it will be dropped by the firewall --- In my understanding of the above, this would block *any* connection-attempt from the fw. (The first part of a the tree-way-handshake is a SYN-request, so IMHO only the SYN-flag is set.) Fortunatly but confusing a rule like this ACCEPT fw net:194.152.181.36 all - allows most connections to the target-host regardless of the NEWNOTSYN-flag in shorewall.conf. Also interesting - in nmap-manpage I can read: --- TCP SYN scan: This technique is often referred to as "half-open" scanning, because you don’t open a full TCP connection. You send a SYN packet, as if you are going to open a real connection and you wait for a response. A SYN|ACK indicates the port is listen- ing. A RST is indicative of a non-listener. If a SYN|ACK is received, a RST is immediately sent to tear down the connection (actually our OS kernel does this for us). [...] TCP connect() scan: This is the most basic form of TCP scanning. The connect() system call provided by your operating system is used to open a connection to every interesting port on the machine. If the port is listening, connect() will succeed, oth- erwise the port isn’t reachable. --- In my understanding of the above, both scantechniques use normal, standard TCP-behavior - the so called three-way-handshake. They should succeed, if connections from the fw to the target are allowed. In fact they do not, if newnotsyn is set to no. So propably there is small but important lack in my knowledge of TCP, may be someone can help to clarify it. Other topic but also related to nessusd: If I see this in the log (194.152.181.36 is the target I scan) ... --- Nov 8 13:02:46 fw kernel: Shorewall:all2all:REJECT:IN= OUT=ppp0 SRC=81.223.219.255 DST=194.152.181.36 LEN=528 TOS=0x00 PREC=0x00 TTL=64 ID=43286 PROTO=ICMP TYPE=9 CODE=0 --- ... propably this is the solution (cited from FAQ): run_iptables -D OUTPUT -p ! icmp -m state --state INVALID -j DROP May be someone can pls. confirm and propably explain shortly why. Many TsIA, Ingo. -- Ingo Lantschner T (+43-1) 59 55 766 M (+43-664) 143 84 18
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ingo Lantschner (Lists) wrote: | Tom Eastep wrote: | |> If you are going to be in the scanning business, turn NEWNOTSYN=Yes! | | Thanks Tom, | that''s interesting and first of all: It worked! These log-entries are | gone now. But I am bit confused now or better said, its not clear to me, | what this newnotsyn-flag is about and what are the implications of | setting it to Yes. | | In shorewall.conf I can read: | --- | NEWNOTSYN | If this variable is set to "No" or "no", then when a TCP packet that | does not have the SYN flag set and the ACK and RST flags clear then | unless the packet is part of an established connection, it will be | dropped by the firewall Ingo -- See if this helps. It is from more recent versions of the software: # TCP connections are established using the familiar three-way "handshake": # # CLIENT SERVER # # SYN--------------------> # <------------------SYN,ACK # ACK--------------------> # # The first packet in that exchange (packet with the SYN flag on and the ACK # and RST flags off) is referred to in Netfilter terminology as a "syn" packet. # A packet is said to be NEW if it is not part of or related to an already # established connection. # # The NETNOTSYN option determines the handling of non-SYN packets (those with # SYN off or with ACK or RST on) that are not associated with an already # established connection. # # If NEWNOTSYN is set to "No" or "no", then non-SYN packets that are not # part of an already established connection will be dropped by the # firewall. The setting of LOGNEWNOTSYN above determines if these packets are # logged before they are dropped. # # If NEWNOTSYN is set to "Yes" or "yes" then such packets will not be # dropped but will pass through the normal rule/policy processing. # # Users with a High-availability setup with two firewall''s and one acting # as a backup should set NEWNOTSYN=Yes. Users with asymmetric routing may # also need to select NEWNOTSYN=Yes. # # The behavior of NEWNOTSYN=Yes may also be enabled on a per-interface basis # using the ''newnotsyn'' option in /etc/shorewall/interfaces and on a # network or host basis using the same option in /etc/shorewall/hosts. # # I find that NEWNOTSYN=No tends to result in lots of "stuck" # connections because any network timeout during TCP session tear down # results in retries being dropped (Netfilter has removed the # connection from the conntrack table but the end-points haven''t # completed shutting down the connection). I therefore have chosen # NEWNOTSYN=Yes as the default value. - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBj+IUO/MAbZfjDLIRAvsuAJ0ZSZKcJopX5AJ4/vKLJ1Ss7KLJdACcCPDI zpXpGlh/G+8tLt8hr1rhUY0=LOLK -----END PGP SIGNATURE-----