At 10:29 AM 11/4/02 -0600, [EMAIL PROTECTED] wrote:
Well, there is not all that much for me to look at, since (once again) you have not supplied the information I suggest including in the SR FAQ. Most of what is here is a firewall script you (or someone) wrote, and while I can struggle through it, doing so is much harder (and less certain to yield understanding) than reading the actual set of iptables rules the script generates ... especially when the script gets the network addresses from an external source, so lacks any information on them.Ray, I finally got time to do this 'right'. If you want to take the time to look at it, cool, there is certainly no urgency on my part.
I can offer a couple of small observations, and do, below (though commenting on them is hard since I don't know what relationships the various source and destination addresses have to your internal and external networks, and I no longer have your prior postings handy to check).
I rearranged the firewall script a little, partly because of one of your suggestions and it seems to be performing very well. Now I have no idea where the New non SYNs are coming from.I marked them in the log with !!!!!!! to make them a little easier to find.
[...]
!!!!!!! Here is the section in questionI would note here that taken by itself, the FORWARD-table rules will LOG and DROP all new-connection packets, not just ones originating on the external interface. Of course, prior rules in the table may ACCEPT some new connections (ideally, ones originating on the LAN), but as I said, this script form is too hard for me to work through to sort out the sequence of the ruleset.
# LOG and DISALLOW BAD TCP packets, NEW non connections
$IPT -A INPUT -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "IP New
non SYN: "
$IPT -A FORWARD -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "IP New
non SYN: "
$IPT -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
$IPT -A FORWARD -p tcp ! --syn -m state --state NEW -j DROP
[...]
Well, I will guess here that this is an INPUT-table report (your intended rules do not readily distinguish INPUT- and FORWARD-table logging). The source IP address appears, from its associated FQN, to be a US Post Office Web server (postcalc1.usps.gov). I assume the destination port is your external IP address. You might look into who uses that server and for what, to figure out why it is trying to initiate an extra connection to your site. In any case, I'd guess from this log entry (and particularly from the fact that we do not see a FORWARD-table entry following it closely) that the -j DROP rule is working.!!!!!!Here is a New non SYN Nov 4 09:37:53 NLynxGW kernel: IP New non SYN: IN=eth0 OUT= MAC=00:04:e2:10:4a:68:00:e0:1e:5f:f4:69:08:00 SRC=56.0.78.82 DST=66.118.15.69 LEN=40 TOS=0x00 PREC=0x00 TTL=114 ID=64142 PROTO=TCP SPT=80 DPT=1230 WINDOW=0 RES=0x00 RST URGP=0
[...]
Same thing, different packet ID number, so probably another INPUT-table logging from the same source.!!!!!!Here is a New non SYN Nov 4 09:38:23 NLynxGW kernel: IP New non SYN: IN=eth0 OUT= MAC=00:04:e2:10:4a:68:00:e0:1e:5f:f4:69:08:00 SRC=56.0.78.82 DST=66.118.15.69 LEN=40 TOS=0x00 PREC=0x00 TTL=114 ID=5647 PROTO=TCP SPT=80 DPT=1229 WINDOW=0 RES=0x00 RST URGP=0
[...]
!!!!!!Here is a New non SYN Nov 4 09:38:50 NLynxGW kernel: IP New non SYN: IN=eth0 OUT= MAC=00:04:e2:10:4a:68:00:e0:1e:5f:f4:69:08:00 SRC=56.0.78.69 DST=66.118.15.69 LEN=40 TOS=0x00 PREC=0x00 TTL=114 ID=37197 PROTO=TCP SPT=80 DPT=1233 WINDOW=0 RES=0x00 RST URGP=0
Same as the first two, except a different USPS server (ircalc-a.usps.gov). [...]
!!!!!!Here is a New non SYN Nov 4 09:39:20 NLynxGW kernel: IP New non SYN: IN=eth0 OUT= MAC=00:04:e2:10:4a:68:00:e0:1e:5f:f4:69:08:00 SRC=56.0.78.69 DST=66.118.15.69 LEN=40 TOS=0x00 PREC=0x00 TTL=114 ID=42857 PROTO=TCP SPT=80 DPT=1232 WINDOW=0 RES=0x00 RST URGP=0
Same thing again. [...]
This one is stranger, since its destination is a non-routable address. And I cannot do a reverse lookup on 209.119.238.78. Without more info about your setup, I cannot say anything useful here.!!!!!!Here is a New non SYN Nov 4 09:41:24 NLynxGW kernel: IP New non SYN: IN=eth0 OUT=eth1 SRC=209.119.238.78 DST=192.168.1.7 LEN=40 TOS=0x00 PREC=0x00 TTL=244 ID=36350 PROTO=TCP SPT=3729 DPT=25 WINDOW=0 RES=0x00 RST URGP=0
[...]
!!!!!!Here is a New non SYNYes, but this time (and this is true for a bunch of the ones that follow this one in your report) the source interface is eth1, which I assume is an internal (LAN or DMZ) interface. LAN hosts are *supposed* to initiate connections through the firewall. In the example above, it appears that someone on your LAN is trying to connect to a Web site at Akamei Technologies (207.229.152.40 = a207-229-152-40.deploy.akamaitechnologies.com).
Nov 4 09:44:53 NLynxGW kernel: IP New non SYN: IN=eth1 OUT=eth0
SRC=192.168.1.133 DST=207.229.152.40 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=61696
DF PROTO=TCP SPT=1035 DPT=80 WINDOW=8383 RES=0x00 ACK FIN URGP=0
I'm skipping the rest that you marked, since they are of the same character as the one above (that is, packets coming from the LAN, and presumably logged by the FORWARD table).
--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski -- Han Solo
Palo Alto, California, USA [EMAIL PROTECTED]
-------------------------------------------------------------------------------
-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
