January 2001 - openSUSE Security - openSUSE Mailing Lists

05 Jan '01

this is from my syslog: Jan 5 09:30:57 datatwirl nfsd[3841]: Unauthorized access by NFS client 192.168.1.50. i KNOW there is no 192.168.1.50 on my network, and should not be anywhere on the internet. that ip address does not ping, is not in my /etc/hosts file, and no machine on my local network was ever put on that ip address. so why would nfs tell me something like this? TIA max

3 3

ICMP ECHO was Skitter.ORG
by Raffy 05 Jan '01

05 Jan '01

> > [extract from rfc 1122]: > Interesting... I never read this RFC... I'm on it right now. Don't have too much time, should probably also do that *g* > >> quoted from RFC section > > Echo server and Echo client |3.2.2.6 |x| | | | | > > What is echo server and echo client? > >> 3.2.2.6 Echo Request/Reply: RFC-792 > >> Every host MUST implement an ICMP Echo server function that > >> receives Echo Requests and sends corresponding Echo Replies. > >> A host SHOULD also implement an application-layer interface > >> for sending an Echo Request and receiving an Echo Reply, for > >> diagnostic purposes. Seems nice. But if I block that at the firewall. I mean the host implemented it, but I block it :-) Honestly, I guess I will have to allow PING through the firewall, although, I DON'T LIKE THAT! What are other people's thoughts? > > Pass Echo Reply to higher layer |3.2.2.6 |x| | | | | > > Pass Echo Reply to higher layer? Meaning in the IP stack, right? > >> 3.2.2.6 Echo Request/Reply: RFC-792 > >> (...) > >> Echo Reply messages MUST be passed to the ICMP user > >> interface, unless the corresponding Echo Request originated > >> in the IP layer. > I phrased my question wrong... Anyway. Let me help you with the OSI model: > OSI layer diagram: (quoted from my Memory - e.g. may be wrong / different) > -Top- Application is the TOP > Application: HTTP/FTP > ???: ICMP/TCP SESSION > transportation: IP > ??? : Ether DataLink! Lowest layer ist Physical Layer! > >> 3.2.2.6 Echo Request/Reply: RFC-792 > >> (...) > >> An ICMP Echo Request destined to an IP broadcast or IP > >> multicast address MAY be silently discarded. > >> DISCUSSION: > >> This neutral provision results from a passionate debate > >> between those who feel that ICMP Echo to a broadcast > >> address provides a valuable diagnostic capability and > >> those who feel that misuse of this feature can too > >> easily create packet storms. > > Conclusion: > So I should implement my gateway/firewall to discard such incoming ICMP requests, right? You should block ICMP to the broadcast address in every case. This is the source for a lot of DOS attacks. Because it would generate quite some network traffic (all the machines in the subnet would PONG) > No other host could now how I subnetted my network. > I can not decide if an outgoing ICMP-request is legal (i.e. if 10.0.1.0 is a > host or network. But their router can be configured from their > administrator) What do you mean? Raffy

2 1

Skitter.ORG
by Raffy 05 Jan '01

05 Jan '01

Since I have set up my firewall to block PING, I have an aweful lot of entrys from Skitter.(e.g. host k-root.skitter.caida.org) Does anybody else have that problem? I don't want that guy to ping me all the time. What can I do? IpFilter logentries: Jan 5 10:38:19 pathfinder.cryptojail.net ASCEND: wan4 8/0/icmp 212.71.102.163 <- 193.0.14.253 66 !pass (ping-1) Jan 5 10:38:22 pathfinder.cryptojail.net ASCEND: wan4 8/0/icmp 212.71.102.163 <- 193.0.14.253 66 !pass (toping-1) Jan 5 10:38:24 pathfinder.cryptojail.net ASCEND: wan4 8/0/icmp 212.71.102.163 <- 193.0.14.253 66 !pass (toping-1) Jan 5 10:38:27 pathfinder.cryptojail.net ASCEND: wan4 8/0/icmp 212.71.102.163 <- 193.0.14.253 66 !pass (ping-1) Jan 5 10:38:30 pathfinder.cryptojail.net ASCEND: wan4 8/0/icmp 212.71.102.163 <- 193.0.14.253 66 !pass (toping-1) Jan 5 10:38:32 pathfinder.cryptojail.net ASCEND: wan4 8/0/icmp 212.71.102.163 <- 193.0.14.253 66 !pass (toping-1) Jan 5 10:38:35 pathfinder.cryptojail.net ASCEND: wan4 8/0/icmp 212.71.102.163 <- 193.0.14.253 66 !pass (ping-1) Jan 5 10:38:38 pathfinder.cryptojail.net ASCEND: wan4 8/0/icmp 212.71.102.163 <- 193.0.14.253 66 !pass (toping-1) Thanx Raffy

2 1

RE: [suse-security] Skitter.ORG
by Raffy 05 Jan '01

05 Jan '01

> Right. Its http://old.caida.org/Tools/Skitter/ for more information. Now I found it. You can send email to: skitter-configs(a)caida.org telling them to discontinue pinging you... Thanks Michael! Raffy

1 0

RE: [suse-security] Skitter.ORG
by Raffy 05 Jan '01

05 Jan '01

> > Since I have set up my firewall to block PING, I have an aweful lot of > > entrys from Skitter.(e.g. host k-root.skitter.caida.org) > > Does anybody else have that problem? I don't want that guy to ping me all > > the time. > Perhaps Go!Zilla trying to load your images? It uses icmp to find the fastest > server for a resource (this silly thing does this also if you entered just > one location...) > > >What can I do? > Nothing. > Perhaps change your way of logging. (Something like last message repeated xxx > times...) Nono... It's certainly not gozilla. I checked that skitter guy. It's somehow an organisation trying to map the internet. I don't have the webpage handy right now. The machine is also not the webserver. It's a client in my net... So certainly no Go!Zilla.... Any other suggestions? Raffy

2 1

Re: [suse-security] And oh, btw..
by Nix 05 Jan '01

05 Jan '01

At 10:20 PM 4/01/2001 -0600, you wrote: >This has been out for a while, though only kept to those who found in at >the ftp site. It has much better USB support and there are several new >features in the kernel. I don't know, I would check it out. > >michael no.. those were -prerelease and -test releases. This is the final 2.4.0 release... -Nix -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking

2 1

Re: [suse-security] suggestion for ssh packaging
by Erwin Zierler - Stubainet 05 Jan '01

05 Jan '01

Hi Bob... 1) I do not think ssh is such an insecure service to be worried about the fact that it's installed by default. 2) anyone who is a little bit interested in his/her system will/should at least once check the settings in /etc/rc.config. The various START_* variables are really quite easy to understand (even for a novice) so all you have to do is set the value to "no" for all services that you dont know/need. A little reading in your handbook will give you enough info to make the right decision. The real problem nowadays is that most people dont want to be bothered reading anything anymore :-) At 12:36 04.01.01 +0000, you wrote: >Hello, > >I have 2 suggestions that I believe will increase both security and >usability: > >(1) split the ssh packages into client and server parts Uh I think I wouldn't like that. If SuSE starts doing that with all client/server stuff I will switch distro :-) >(2) have an ssh client installed as default > >It is absurd that someone who installs an ssh client should find >themselves running an ssh server. I would like to see most desktops in the >world running an ssh client, but only a tiny minority should be running >ssh servers. > >The current situation could lead to people who have installed ssh so that >they can access remote servers securely finding their home computers have >been compromised because they unknowingly run an ssh service. Ssh is not _that_ easy to compromise (if I compare it to telnet for instance) so if we are talking security I'd rather have a few services disabled in /etc/inetd.conf >The second suggestion is just to make my life easier...part of my job is >to explain to people how to install ssh clients on their home machine, and >the less they have to do the better. rpm -ql ssh will tell you what files are installed, /etc/ssh* will be sufficient to configure the package for your needs and /etc/rc.config needs START_SSHD=no. Thats pretty much it as far as manual intervention goes and with that everyone can use ssh clients and no server is running. >Happy new year, >Bob Happy new year to you as well! Erwin Erwin Zierler | Web-/Hostmaster - Stubainet | Email: Erwin.Zierler(a)stubainet.at / webmaster(a)stubainet.at | Tel.: 05225 - 64325 Fax 99 Mobil: 0664 - 130 67 91

5 4

RE: [suse-security] WG: [suse-security] ftp/firewall security
by Raffy 05 Jan '01

05 Jan '01

> Yes, sendmail is queries to port 113 on my firewall box. On > this box no auth is running. Not accepting these queries > results in much slower down-/upload of mails. Since on the > firewall box is no auth server installed I don't see a real > threat. So I let it be. I classified it problem no 3742978237 > on my to do list. > > > Disable it, if that is your problem. Or am I misreading anything? > > No, you're not. If, then I have to disable it on sendmail > first and afterwards on the firewall box. So disable it in sendmail.cf: # timeouts (many of these) .... O Timeout.ident=0s Although, I'm not really sure if that did all the trick. Because I think I remember that I still had 113-queries from sendmail. Maybe someone else knows... Hope that helps Raffy

1 0

WG: [suse-security] ftp/firewall security
by Philipp Snizek 05 Jan '01

05 Jan '01

Hi Raffy, Saw your homepage. Like your banner in the middle where Hoax, and so on links are found. How did you do that (it's pure html as much as I saw)? I work on the same. I have problems with the borders although they're set to 0. But let me get to the problem. > > ipchains -A input -p tcp -s 212.232.168.180/32 1024: -d > 212.232.168.183/32 > > 113 -i eth0 -j ACCEPT # Don't worry guys, there is no auth > server running > on > > 212.232.168.183, it's there because of sendmail. I still > didn't find a > > suitable solution to make it faster although I'm sure there is one. > > > Aehm, let me ask you what exactly you mean by this? Is it the > problem that > sendmail queries authd when sending emails? Yes, sendmail is queries to port 113 on my firewall box. On this box no auth is running. Not accepting these queries results in much slower down-/upload of mails. Since on the firewall box is no auth server installed I don't see a real threat. So I let it be. I classified it problem no 3742978237 on my to do list. > Disable it, if > that is your > problem. Or am I misreading anything? No, you're not. If, then I have to disable it on sendmail first and afterwards on the firewall box. CUL Philipp

1 0

RE: [suse-security] ftp/firewall security
by Raffy 05 Jan '01

05 Jan '01

> ipchains -A input -p tcp -s 212.232.168.180/32 1024: -d 212.232.168.183/32 > 113 -i eth0 -j ACCEPT # Don't worry guys, there is no auth server running on > 212.232.168.183, it's there because of sendmail. I still didn't find a > suitable solution to make it faster although I'm sure there is one. Aehm, let me ask you what exactly you mean by this? Is it the problem that sendmail queries authd when sending emails? Disable it, if that is your problem. Or am I misreading anything? Thanks Raffy

1 0