RE: [Leaf-user] Hits on port 53.
Has anybody out their seen the following, hits on port 53?
Yep, this is a well known problem (see archives, when they work...). Change
ipfilter_firewall_cfg in ipfilter.conf with these extra lines (#New Port 53
filter start/end):
ipfilter_firewall_cfg () {
local ADDR
local DEST
local NET
local SERVICE
#
# set default policies
#
# ONLY DENY FORWARDING ETC IF YOU KNOW WHAT YOU ARE DOING! If
# you turn off the filters, the box will become opaque to any traffic!
#
ipfilter_policy DENY
# Clear any garbage rules out of the filters
ipfilter_flush
# New Port 53 filter start
IP_LIST=`cat /etc/dns_floods`
for IP in $IP_LIST; do
$IPCH -I input -j DENY -p tcp -s $IP/32 -d $EXTERN_IP/32 53 -i
$EXTERN_IF
done; unset IP
#New Port 53 filter end
# Set up Fair Queueing classifier lists
ipfilter_fairq
#
# Set up port forwards for internal services
#
snip etc.
Now create a dns_floods file in your /etc directory with all of the hosts
you receive port 53 spewage from. Here's my current list:
128.121.10.90
128.242.105.34
129.250.244.10
194.205.125.26
194.213.64.150
202.139.133.129
203.194.166.182
203.208.128.70
207.55.138.206
207.68.131.17
212.78.160.237
216.220.39.42
216.33.35.214
216.34.68.2
216.35.167.58
62.23.80.2
62.26.119.34
64.14.200.154
64.37.200.46
64.56.174.186
64.78.235.14
Now do:
svi network ipfilter flush
svi network ipfilter reload
Make sure you backup your changes (/etc).
Paul Rimmer,
Calgary, Alberta, Canada
___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
Is this typical of what fills everybody's logs? -was- Re: [Leaf-user] Hits on port 53.
--- Kevin Kropf [EMAIL PROTECTED] wrote: Has anybody out their seen the following, hits on port 53? Sample: Dec 1 14:48:57 kc_firewall kernel: Packet log: input DENY eth0 PROTO=6 216.34.68.2:15209 24.80.151.202:53 L=44 S=0x00 I=0 F=0x T=248 (#44) No, but In a very cursory look through my recent logs I have noticed one instance of about 100 packets from one address denied in a 30 sec period. I'm guessing it's a scan through my /27 block for some service on port 27374, sample: Nov 28 18:19:43 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.1.84.76:2017 216.136.89.98:27374 L=48 S=0x00 I=41493 F=0x4000 T=111 SYN (#25) Nov 28 18:19:43 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.1.84.76:2018 216.136.89.99:27374 L=48 S=0x00 I=42517 F=0x4000 T=111 SYN (#25) Nov 28 18:19:44 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.1.84.76:2019 216.136.89.100:27374 L=48 S=0x00 I=43285 F=0x4000 T=111 SYN (#25) Nov 28 18:19:45 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.1.84.76:2022 216.136.89.103:27374 L=48 S=0x00 I=45077 F=0x4000 T=111 SYN (#25) Nov 28 18:19:46 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.1.84.76:2023 216.136.89.104:27374 L=48 S=0x00 I=45589 F=0x4000 T=109 SYN (#25) Nov 28 18:19:46 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.1.84.76:2024 216.136.89.105:27374 L=48 S=0x00 I=46869 F=0x4000 T=111 SYN (#25) Most of the time however, my logs show a stream of denials occurring at a round-the-clock average rate of roughly 3 per minute (occasionally a period of a few minutes with nothing) of packets from various ip addresses denied mostly by the 'forward' rule to primarily ports 80 and 21, and occasionally ports 111 113 137 and others I'm sure, directed to various ip's of my /27 block defined in my DMZ, but on which most have no services running. Would someone care to tell me what some of these are? And is this fairly typical of what goes on out there? I know I should be concerned enough to learn how to identify whether any of this is any form of attack, or whether it is port scanning that may be hampering our network useage. In the mean time, does anyone care to look through the following and let me know if you see anything of concern? My network is 216.136.89.96/27, isp router, my networks gateway: .97, Dachstein eth0: .101, eth2 DMZ: .102 Thanks. Samples from today: Dec 2 10:09:00 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.136.86.206:1412 216.136.89.107:80 L=48 S=0x00 I=24134 F=0x4000 T=116 SYN (#25) Dec 2 10:09:03 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.136.86.206:1412 216.136.89.107:80 L=48 S=0x00 I=25139 F=0x4000 T=116 SYN (#25) Dec 2 10:10:42 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.136.86.206:1550 216.136.89.125:80 L=48 S=0x00 I=64214 F=0x4000 T=115 SYN (#25) Dec 2 10:10:44 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.136.86.206:1550 216.136.89.125:80 L=48 S=0x00 I=65482 F=0x4000 T=116 SYN (#25) Dec 2 10:11:11 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.136.86.206:1512 216.136.89.114:80 L=48 S=0x00 I=12453 F=0x4000 T=116 SYN (#25) Dec 2 10:11:14 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.136.86.206:1512 216.136.89.114:80 L=48 S=0x00 I=13254 F=0x4000 T=116 SYN (#25) Dec 2 10:11:36 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.136.81.30:4181 216.136.89.118:80 L=44 S=0x00 I=10711 F=0x4000 T=120 SYN (#25) Dec 2 10:11:39 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.136.81.30:4181 216.136.89.118:80 L=44 S=0x00 I=35036 F=0x4000 T=121 SYN (#25) Dec 2 10:11:45 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.136.81.30:4595 216.136.89.124:80 L=44 S=0x00 I=9191 F=0x4000 T=121 SYN (#25) Dec 2 10:11:48 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.136.81.30:4595 216.136.89.124:80 L=44 S=0x00 I=31725 F=0x4000 T=121 SYN (#25) Dec 2 10:13:27 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.136.86.206:1832 216.136.89.122:80 L=48 S=0x00 I=1362 F=0x4000 T=115 SYN (#25) Dec 2 10:13:30 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.136.86.206:1832 216.136.89.122:80 L=48 S=0x00 I=2563 F=0x4000 T=116 SYN (#25) Dec 2 10:16:15 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.55.133.33:4520 216.136.89.112:80 L=48 S=0x00 I=21015 F=0x4000 T=108 SYN (#25) Dec 2 10:16:32 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.136.81.30:4645 216.136.89.100:80 L=44 S=0x00 I=3569 F=0x4000 T=120 SYN (#25) Dec 2 10:16:35 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.136.81.30:4645 216.136.89.100:80 L=44 S=0x00 I=59894 F=0x4000 T=121 SYN (#25) Dec 2 12:56:42 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.136.86.206:1188 216.136.89.118:80 L=48 S=0x00 I=17741 F=0x4000 T=115 SYN (#25) Dec 2 12:56:45
Re: Is this typical of what fills everybody's logs? -was- Re: [Leaf-user] Hits on port 53.
Leaf Leaf wrote: No, but In a very cursory look through my recent logs I have noticed one instance of about 100 packets from one address denied in a 30 sec period. I'm guessing it's a scan through my /27 block for some service on port 27374, sample: Nov 28 18:19:43 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.1.84.76:2017 216.136.89.98:27374 L=48 S=0x00 I=41493 F=0x4000 T=111 SYN (#25) Nov 28 18:19:43 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.1.84.76:2018 216.136.89.99:27374 L=48 S=0x00 I=42517 F=0x4000 T=111 SYN (#25) Nov 28 18:19:44 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.1.84.76:2019 216.136.89.100:27374 L=48 S=0x00 I=43285 F=0x4000 T=111 SYN (#25) Nov 28 18:19:45 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.1.84.76:2022 216.136.89.103:27374 L=48 S=0x00 I=45077 F=0x4000 T=111 SYN (#25) Nov 28 18:19:46 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.1.84.76:2023 216.136.89.104:27374 L=48 S=0x00 I=45589 F=0x4000 T=109 SYN (#25) Nov 28 18:19:46 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.1.84.76:2024 216.136.89.105:27374 L=48 S=0x00 I=46869 F=0x4000 T=111 SYN (#25) Most of the time however, my logs show a stream of denials occurring at a round-the-clock average rate of roughly 3 per minute (occasionally a period of a few minutes with nothing) of packets from various ip addresses denied mostly by the 'forward' rule to primarily ports 80 and 21, and occasionally ports 111 113 137 and others I'm sure, directed to various ip's of my /27 block defined in my DMZ, but on which most have no services running. Would someone care to tell me what some of these are? And is this fairly typical of what goes on out there? Take a look at: http://www.dshield.org/topports.html and it all makes some sense. Look at the sequence of the ports originating from the one who is probing, 2017, 2018, 2019, etc. No use in trying to locate who, what is doing this, they're usually cracked boxes, anyway I know I should be concerned enough to learn how to identify whether any of this is any form of attack, or whether it is port scanning that may be hampering our network useage. In the mean time, does anyone care to look through the following and let me know if you see anything of concern? My network is 216.136.89.96/27, isp router, my networks gateway: .97, Dachstein eth0: .101, eth2 DMZ: .102 Thanks. Samples from today: Dec 2 10:09:00 firewall kernel: Packet log: forward DENY eth2 PROTO=6 216.136.86.206:1412 216.136.89.107:80 L=48 S=0x00 I=24134 F=0x4000 T=116 SYN (#25) Nimda is a real pain... -- Patrick Benson Stockholm, Sweden ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Delays in updating wanpipe.lrp
We are very sorry for any delays we may incur; but, we are among the unlucky @Home victims. Notwithstanding ATT's six weeks of assurances that we would experience no interruptions, apparently the dear judge judged the case at least one week quicker than ATT anticipated and transition us to the new network. Thank goodness for modems and netZero ; I can receive Email; but, not in realtime, for the near future. And, large uploads to anywhere are intolerable ; -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . Sign Up for NetZero Platinum Today Only $9.95 per month! http://my.netzero.net/s/signup?r=platinumrefcd=PT97 ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] More info on E2B DMZ_SWITCH=PRIVATE problems
Further to an email of yesterday, having set the DMZ network to be 192.168.2.0/24 as part of the greater internal 192.168.0.0/16 network, I can now talk out of the DMZ to the external world. However, none of the DMZ features appear to work: no connection from internal or external networks to services adevertised in the DMZ seems possible. Adding and removing DMZ_SERVERn entries seems to have no effect on the output of the ipchains listing. :-( I have looked through the mail archives and seen some recent discussions about dachstein rc2 with DMZ_SWITCH=PRIVATE but little else. Maybe discussions of private DMZ on E2B are in the older LRP archives? Anyway, here are selections from network.conf and 'svi network ipfilter list'. Any help very much appreciated. some snipping follows: eth0_IPADDR=150.101.234.2 eth0_MASKLEN=30 eth0_BROADCAST=150.101.234.3 eth0_DEFAULT_GW=150.101.234.1 eth1_IPADDR=192.168.42.254 eth1_MASKLEN=24 eth1_BROADCAST=192.168.42.255 eth2_IPADDR=192.168.1.254 eth2_MASKLEN=24 eth2_BROADCAST=192.168.1.255 # the DMZ network # eth3_IPADDR=192.168.2.254 eth3_MASKLEN=24 eth3_BROADCAST=192.168.2.255 eth3_IP_SPOOF=YES eth3_IP_KRNL_LOGMARTIANS=YES eth3_IP_SHARED_MEDIA=NO eth3_BRIDGE=NO eth3_PROXY_ARP=NO eth3_FAIRQ=NO # Internal interface (Intern_IF and Intern_Ip are bogus) # INTERN_IF=eth1 # Internal Interface INTERN_NET=192.168.0.0/16 # Internal network (to be masqueraded) INTERN_IP=192.168.42.254 # IP number of Internal Interface # (to allow forwarding to external IP) MASQ_SWITCH=YES # Masquerade internal network to outside # world - YES/NO # ports (domain and ssh are just on the firewall) # EXTERN_UDP_PORTS=0/0_domain 0/0_www EXTERN_TCP_PORTS=0/0_ssh 0/0_www # The DMZ # DMZ_SWITCH=PRIVATE DMZ_IF=eth3 DMZ_NET=192.168.2.0/24 DMZ_OUTBOUND_ALL=YES # I've tried these with and without double quotes and with and without # the extern_ip as a variable vs. hardcoded. # DMZ_SERVER0=tcp_150.101.234.2_www_192.168.2.10_www DMZ_SERVER1=udp_150.101.234.2_www_192.168.2.10_www Chain input (policy DENY: 0 packets, 0 bytes): pkts bytes target prot opttosa tosx ifname mark outsize sourcedestination ports 0 0 DENY icmp l- 0xFF 0x00 * 0.0.0.0/00.0.0.0/0 13 - * 0 0 DENY icmp l- 0xFF 0x00 * 0.0.0.0/00.0.0.0/0 14 - * 0 0 DENY all l- 0xFF 0x00 eth0 0.0.0.0 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 255.255.255.255 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 127.0.0.0/8 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 224.0.0.0/4 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 10.0.0.0/8 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 172.16.0.0/120.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 192.168.0.0/16 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 0.0.0.0/80.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 128.0.0.0/16 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 191.255.0.0/16 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 192.0.0.0/24 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 223.255.255.0/24 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 240.0.0.0/4 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 192.168.0.0/16 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 150.101.234.20.0.0.0/0 n/a 0 0 REJECT all l- 0xFF 0x00 eth0 0.0.0.0/0127.0.0.0/8 n/a 0 0 REJECT all l- 0xFF 0x00 eth0 0.0.0.0/0192.168.0.0/16n/a 0 0 REJECT tcp -- 0xFF 0x00 eth0 0.0.0.0/00.0.0.0/0 * - 137 0 0 REJECT tcp -- 0xFF 0x00 eth0 0.0.0.0/00.0.0.0/0 * - 135 0 0 REJECT udp -- 0xFF 0x00 eth0 0.0.0.0/00.0.0.0/0 * - 137 0 0 REJECT udp -- 0xFF 0x00 eth0 0.0.0.0/00.0.0.0/0 * - 135 0 0 REJECT tcp -- 0xFF 0x00 eth0 0.0.0.0/00.0.0.0/0 * - 138:139 0 0 REJECT udp -- 0xFF 0x00 eth0 0.0.0.0/00.0.0.0/0 * - 138
[Leaf-user] Updated LEAF 2.4.14+ Shorewall 1.1.18
I have updated the LEAF 2.4.14 + Shorewall distro described in my previous post: http://www.geocrawler.com/archives/3/7232/2001/11/50/7129319/ everything is in http://leaf.sourceforge.net/devel/jnilo/kernel-2.4.14 The updated 1680k diskimage is called leaf-2.4.14-1680-b1.bin Changelog: 1/ TMPFS is used instead of /dev/ram /dev/ram0 is only used to boot initrd.lrp then the main filesystem is pivot_rooted to tmpfs and /dev/ram0 released. Three parameters can be introduced in the command line (but defaults should be OK in most cases): syst_size= max size of LRP filesystem (default SYSTSIZE=6M) log_size= max size of /var/log (default LOGSIZE=2M) tmp_size= max size of /tmp (default remaining available memory) Therefore ramlog.lrp is not needed anymore Everything is in /var/lib/lrpkg/root.linuxrc initrd fs umount and freeramdisk /dev/ram0 are done in /etc/init.d/rcS 2/ Initrd.lrp can be backuped as any other file The scheme goes as follow: whatever package ($INITRD) is found after initrd= is treated as a compressed minix fs. Then in lrcfg.back.script if $PACKAGE=$INITRD a new script is called that will take care of backuping this special file. See lrcfg.back.initrd. The max size of the uncompressed initrd.lrp package can be setup through initrd package configuration menu. The procedure is fully transparent to the user. Standard rules for including/excluding files apply. Files in /boot/modules will saved in there. 3/ Busybox updated to 0.60.2 pivot_root mkfs.minix added 3/ Shorewall is now really 1.1.18 (was 1.1.17 by mistake in the previous release). Shorewall is setup with the two-interfaces configuration file provided by Tom and adapted to a standard LEAF distro by me. Move to the three-interface one for setting up a DMZ. 4/ There seems to be a bug in busybox umount -a which does not umount tmpfs filesystems. Until it's fixed the util-linux-2.11m version takes care of umount -a. 5/ keyboard.lrp provided in the distro. fr.map is default... (No, I am kidding...) Todo's: 1/ clean-up /etc/init.d/network, /etc/network.conf and /etc/ipfilter.conf to get rid of all the unecessary stuff. 2/ In the above mentioned files check the QoS and bridge stuff 3/ Adjust weblet script to take care of firewall messages Jacques ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Updated kernel available
There is a new 2.2.19-3 release of the kernel used for Dachstein available: http://lrp2.steinkuehler.net/files/kernels/ http://lrp1.steinkuehler.net/files/kernels/ http://lrp.steinkuehler.net/files/kernels/ The major change from the earlier kernels is the removal of the reiserfs patch which was preventing ext2, nfs, and other filesystems from loading properly as modules. I don't think this problem is entirely the fault of reiserfs, but rather an interaction between the reiserfs patch and the openwall patch. While I was re-compiling everything, I updated the openwall patch from ow3 to ow4. The only other thing is the addition of an extra-version ID to the kernel (uname -a), to try and prevent confusion about exactly which version you're running...everything else remains the same. NOTE: Unless you are currently trying to use one of the affected file-system modules (you'll know, because it's broken), you don't need to migrate to the new kernel. NOTE: The older kernel directories have been removed...the contents are still available as tar.gz files, if needed. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Re: [Leaf-devel] Updated LEAF 2.4.14+ Shorewall 1.1.18
4/ There seems to be a bug in busybox umount -a which does not umount tmpfs filesystems. Until it's fixed the util-linux-2.11m version takes care of umount -a. My bad. The problem was the -n switch. umount -a works perfectly well whereas umount -n -a does not. This makes sense to me since my bbox is compiled with #define BB_FEATURE_MTAB_SUPPORT commented out. So got rid of util-linux umount, restored the bbox one and changed /etc/init.d/umountfs to put umount -a instead of umount -n -a. Jacques ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-devel] [Leaf-user] Testing help needed
On 12/1/01 at 3:12 PM, Jack Coates [EMAIL PROTECTED] wrote: On Sat, 1 Dec 2001, Tony wrote: If so, wouldn't it be easier/safer/more secure to forward them to an internal syslog server? syslog-ng is supposed to fix a lot of these problems, but I've never gotten around to taking a look at it. syslog-ng is very nice; it's set up to act as our central UNIX log server for the corporation. It has a unique ability in that it can use TCP instead of UDP - allowing it to be tunneled via ssh to an external server where it can then receive log messages from a syslog-ng located on that side. This allows you to receive messages through a firewall that blocks UDP syslog traffic (as it ought to). -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
