Hi, can someone give me any reason why a nameserver would make a request to 2049 which is nfs Packet log: input DENY ppp0 PROTO=17 212.156.4.20:53 212.156.196.114:2049 L=137 S=0x00 I=5423 F=0x0000 T=27 (#39) Packet log: input DENY ppp0 PROTO=17 212.156.4.20:53 212.156.196.114:2049 L=137 S=0x00 I=5574 F=0x0000 T=27 (#39) Packet log: input DENY ppp0 PROTO=17 212.156.4.20:53 212.156.196.114:2049 L=137 S=0x00 I=5738 F=0x0000 T=27 (#39) -- Togan Muftuoglu
Because most firewalls are improperly configured when it comes to DNS (port 53) and will let packets through that they shouldn't. ----- Original Message ----- From: "Togan Muftuoglu" <toganm@users.sourceforge.net> To: "Suse-Security" <suse-security@suse.com> Sent: Thursday, May 24, 2001 1:14 AM Subject: [suse-security] weird request from port 53 to 2049
Hi,
can someone give me any reason why a nameserver would make a request to 2049 which is nfs
Packet log: input DENY ppp0 PROTO=17 212.156.4.20:53 212.156.196.114:2049
L=137 S=0x00 I=5423 F=0x0000 T=27 (#39)
Packet log: input DENY ppp0 PROTO=17 212.156.4.20:53 212.156.196.114:2049 L=137 S=0x00 I=5574 F=0x0000 T=27 (#39) Packet log: input DENY ppp0 PROTO=17 212.156.4.20:53 212.156.196.114:2049 L=137 S=0x00 I=5738 F=0x0000 T=27 (#39)
-- Togan Muftuoglu
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
On 2001.05.24 09:14:19 +0200 Togan Muftuoglu wrote:
Hi,
can someone give me any reason why a nameserver would make a request to 2049 which is nfs
Packet log: input DENY ppp0 PROTO=17 212.156.4.20:53 212.156.196.114:2049 L=137 S=0x00 I=5423 F=0x0000 T=27 (#39) Packet log: input DENY ppp0 PROTO=17 212.156.4.20:53 212.156.196.114:2049 L=137 S=0x00 I=5574 F=0x0000 T=27 (#39) Packet log: input DENY ppp0 PROTO=17 212.156.4.20:53 212.156.196.114:2049 L=137 S=0x00 I=5738 F=0x0000 T=27 (#39)
Is there a nfs-server running on 212.156.196.114 ? If a name-lookup is startet the source-port is a free one above 1024. If there is no nfs-server running on this computer averityhing seems to bee all right. Gruß Jörg -- www.lug-untermain.de - Dipl.-Ing. Jörg Schütter joerg.schuetter@gmx.de
* J�rg Sch�tter <joerg.schuetter@gmx.de> [010524 10:42]:
Is there a nfs-server running on 212.156.196.114 ? If a name-lookup is startet the source-port is a free one above 1024. If there is no nfs-server running on this computer averityhing seems to bee all right.
No there is no nfs server running on that pc on the other hand I have checked my logs and found that 212.156.4.20 (nameserver of my ISP) had made requests to port 137 which were also denied by IPCHAINS. So if there is an err; is it on my side (ie firewall configuration )or at the ISP side ? -- Togan Muftuoglu
This all points to the name server at you ISP being "owned" by a hacker. Many, many hacker tools (including port scanners like nmap) have the option to attack with a source port of 53. I would ask your ISP to stop attacking you network and see what they say :-) Cheers Nix At 05:51 PM 24/05/2001, you wrote:
* Jörg Schütter <joerg.schuetter@gmx.de> [010524 10:42]:
Is there a nfs-server running on 212.156.196.114 ? If a name-lookup is startet the source-port is a free one above 1024. If there is no nfs-server running on this computer averityhing seems to bee all right.
No there is no nfs server running on that pc on the other hand I have checked my logs and found that 212.156.4.20 (nameserver of my ISP) had made requests to port 137 which were also denied by IPCHAINS.
So if there is an err; is it on my side (ie firewall configuration )or at the ISP side ?
-- Togan Muftuoglu
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
Viel Spaß Nix - nix@susesecurity.com http://www.susesecurity.com
* Jörg Schütter <joerg.schuetter@gmx.de> [010524 10:42]:
Is there a nfs-server running on 212.156.196.114 ? If a
name-lookup is
startet the source-port is a free one above 1024. If there is no nfs-server running on this computer averityhing seems to bee all right.
No there is no nfs server running on that pc on the other hand I have checked my logs and found that 212.156.4.20 (nameserver of my ISP) had made requests to port 137 which were also denied by IPCHAINS.
Because your isp's nameserver is a braindead windoze box that is not firewalled. otherwise their firewall would block 137. See nmap results: Oh, it's not a windoze box: They run Digital Unix OSF1 V 4.0-4.0F and they are a worthy challange. Open tcp ports: 21, 23, 53, 79, 80, 111, 515, 902, 1024, 1519, 6000, 6112 and some open udp ports.
So if there is an err; is it on my side (ie firewall configuration )or at the ISP side ?
Think, your isp should think about security.
-- Togan Muftuoglu
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
* Philipp Snizek <mailinglists@belfin.ch> [010524 13:08]:
Think, your isp should think about security.
If I can reach them by phone I will say that. By the way they are Turkish Telecom and they are the only one providing ADSL in my area so if I want to use ADSL I have no other ISP choice and tighten up my own security as much as possible. -- Togan Muftuoglu
Hi,
can someone give me any reason why a nameserver would make a request to 2049 which is nfs
Packet log: input DENY ppp0 PROTO=17 212.156.4.20:53 212.156.196.114:2049 L=137 S=0x00 I=5423 F=0x0000 T=27 (#39) Packet log: input DENY ppp0 PROTO=17 212.156.4.20:53 212.156.196.114:2049 L=137 S=0x00 I=5574 F=0x0000 T=27 (#39) Packet log: input DENY ppp0 PROTO=17 212.156.4.20:53 212.156.196.114:2049 L=137 S=0x00 I=5738 F=0x0000 T=27 (#39)
not a request. an answer. You ---> isp's dns (ist-dnssrv.ttnet.tr) 1024: ---> 53 / udp 1024: <--- 53 / udp only block 53/tcp. open 1024:5000 for client requests and receiving answers. These are usually the most used ports for communication from client to servers to client if you use masquerading on your linux box. Since you've got a dial up "router" you do use masquerading. But if you like I can give you some real reasons for being afraid :-)) HTH Philipp
* Philipp Snizek <mailinglists@belfin.ch> [010524 12:55]:
only block 53/tcp.
This is what I have now ( I am using DNS caching server only maybe I am doing this wrong) ipchains -A input -p tcp -s $REMOTENET -d $OUTERNET 53 -j ACCEPT ipchains -A input -p udp -s $REMOTENET -d $OUTERNET 53 -j ACCEPT and you are suggesting ipchains -A input -p tcp -s $REMOTENET -d $OUTERNET 53 -j REJECT
open 1024:5000 for client requests and receiving answers. These are usually the most used ports for communication from client to servers to client if you use masquerading on your linux box. Since you've got a dial up "router" you do use masquerading.
This part I did not get the picture I have an ADSL connection (so its pppoe) Is this what you mean ipchains -A input -p tcp -s $REMOTENET -d $OUTERNET 1024:5000 -j ACCEPT ipchains -A input -p udp -s $REMOTENET -d $OUTERNET 1024:5000 -j ACCEPT
But if you like I can give you some real reasons for being afraid :-))
I would appreciate being asigned for reading homework guidance -- Togan Muftuoglu
On 2001.05.24 12:25:32 +0200 'Togan Muftuoglu' wrote:
* Philipp Snizek <mailinglists@belfin.ch> [010524 12:55]:
only block 53/tcp.
This is what I have now ( I am using DNS caching server only maybe I am doing this wrong)
ipchains -A input -p tcp -s $REMOTENET -d $OUTERNET 53 -j ACCEPT ipchains -A input -p udp -s $REMOTENET -d $OUTERNET 53 -j ACCEPT
Since your are not an ISP, you don't need the tcp protocoll for dns
and you are suggesting
ipchains -A input -p tcp -s $REMOTENET -d $OUTERNET 53 -j REJECT
open 1024:5000 for client requests and receiving answers. These are usually the most used ports for communication from client to servers to client if you use masquerading on your linux box. Since you've got a dial up "router" you do use masquerading.
This part I did not get the picture I have an ADSL connection (so its pppoe) Is this what you mean
ipchains -A input -p tcp -s $REMOTENET -d $OUTERNET 1024:5000 -j ACCEPT ipchains -A input -p udp -s $REMOTENET -d $OUTERNET 1024:5000 -j ACCEPT
Also no tcp needed. You should make shure that all pakets have no syn-bit set. ipchains -A input -p udp -s $REMOTENET -d $OUTERNET 1024:5000 ! -y -j ACCEPT Gruß Jörg -- www.lug-untermain.de - Dipl.-Ing. Jörg Schütter joerg.schuetter@gmx.de
* J�rg Sch�tter <joerg.schuetter@gmx.de> [010524 13:52]:
Also no tcp needed. You should make shure that all pakets have no syn-bit set. ipchains -A input -p udp -s $REMOTENET -d $OUTERNET 1024:5000 ! -y -j ACCEPT
One question here what will be the effect of this 1024:5000 to: 1) real audio as it is using 7070. AFAIU I have to open 7070:7071 for realaudio then. 2) When I do ftp lets say suse.com do I have to specify a port again -- Togan Muftuoglu
* Jörg Schütter <joerg.schuetter@gmx.de> [010524 13:52]:
Also no tcp needed. You should make shure that all pakets have no syn-bit set. ipchains -A input -p udp -s $REMOTENET -d $OUTERNET
1024:5000 ! -y -j ACCEPT
One question here what will be the effect of this 1024:5000 to: 1) real audio as it is using 7070. AFAIU I have to open 7070:7071 for realaudio then.
Yes, of course. Open what you need.
2) When I do ftp lets say suse.com do I have to specify a port again
We have to differ between two types of ftp. Passive and active ftp. If you use active ftp the requested ftp server will decide what ftp data port to use. Then you must allow tcp-syn packets to you. If you decide use passive ftp (most of the ftp servers support that) then the requested ftp server leaves it up to your nat device or ftp proxy how to communicate with the ftp server. No tcp-syn to your box is needed then. In your case (you don't run any servers, don't you?) tcp-syn goes only in one direction. From you to the internet. Never from the inet to you. Best would be by using tcp dump or iptraf to analyze the traffic of passive and active ftp to see the difference.
* Philipp Snizek <mailinglists@belfin.ch> [010524 12:55]:
only block 53/tcp.
This is what I have now ( I am using DNS caching server only maybe I am doing this wrong)
ipchains -A input -p tcp -s $REMOTENET -d $OUTERNET 53 -j ACCEPT ipchains -A input -p udp -s $REMOTENET -d $OUTERNET 53 -j ACCEPT
and you are suggesting
ipchains -A input -p tcp -s $REMOTENET -d $OUTERNET 53 -j REJECT
No. u don't need tcp. U will only query on udp/53 since almost all of your dns queries will not be larger than 512bytes. If you do requests >512bytes your bind will use automatically tcp. But this won't happen. If you have two dns servers (one pri and one secondary dns) they will be in need to do zone x-fers. This also needs tcp. Because you only run a caching dns server all you need is udp/53 : Your dns -----> other party dns request 1024: -----> 53 udp 1024: <----- 53 udp answer
open 1024:5000 for client requests and receiving answers. These are usually the most used ports for communication from client to servers to client if you use masquerading on your linux box. Since you've got a dial up "router" you do use masquerading.
This part I did not get the picture I have an ADSL connection (so its pppoe) Is this what you mean
Ah, ok you have adsl. I saw there a ppp0 device in your ipchains. I thought this would be some kind of an analog modem or some isdn TA. If it's a leased line (I guess so; I never played before with pppoe) then you don't need masquerading if you don't wish to use it. See above and below explanation.
ipchains -A input -p tcp -s $REMOTENET -d $OUTERNET 1024:5000 -j ACCEPT
you don't need that at all because it's tcp
ipchains -A input -p udp -s $REMOTENET -d $OUTERNET 1024:5000 -j ACCEPT
This you need. I don't understand OUTERNET (is this your dmz network??) Ipchains for DNS only: #requesting rule ipchains -A output -p udp -s $my.dns.server 1024:5000 -d $internet 53 -i $interneteth -j accept #answering rule ipchains -A input -p udp -s $internet 53 -d $my.dns.server 1024:5000 -i $interneteth -j accept Be sure that bind is only bound to your $internallaneth. If so, bind will not act on your $interneteth and won't show an open 53/tcp port.
But if you like I can give you some real reasons for being
afraid :-))
I would appreciate being asigned for reading homework guidance
Read Oreilly's Building internet firewalls. This is a standard security bed lecutre.
-- Togan Muftuoglu
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
* Philipp Snizek <mailinglists@belfin.ch> [010524 16:31]:
Ah, ok you have adsl. I saw there a ppp0 device in your ipchains. I thought this would be some kind of an analog modem or some isdn TA. If it's a leased line (I guess so; I never played before with pppoe) then you don't need masquerading if you don't wish to use it.
Well we are assigned a dynamic IP (if I reconnect I get a new ip). ADSL connection is at my firewall/router box which is running 7.1 and I have my workstation (also 7.1) and my wife's laptop (running MS). So I have to use masquerading to let her surf or I die :-O
This you need. I don't understand OUTERNET (is this your dmz network??)
I use OUTERNET as my EXTERNALIP (ISP assigned) OK quick questions to make sure I got it correct
Ipchains for DNS only: #requesting rule ipchains -A output -p udp -s $my.dns.server 1024:5000 -d $internet 53 -i
$my.dns.server = points what ISP or my internal ? $internet = meaning 0/0 or my IP assigned by the ISP or ? $interneteth = this is the internet connecting interface not INTERNAL
Read Oreilly's Building internet firewalls. This is a standard security bed lecutre.
I will see if the bookstore has it if not will order via amazon. Thanks for the recommendation -- Togan Muftuoglu
On Thu, 24 May 2001, Togan Muftuoglu wrote:
Hi,
can someone give me any reason why a nameserver would make a request to 2049 which is nfs
Packet log: input DENY ppp0 PROTO=17 212.156.4.20:53 212.156.196.114:2049 L=137 S=0x00 I=5423 F=0x0000 T=27 (#39) Packet log: input DENY ppp0 PROTO=17 212.156.4.20:53 212.156.196.114:2049 L=137 S=0x00 I=5574 F=0x0000 T=27 (#39) Packet log: input DENY ppp0 PROTO=17 212.156.4.20:53 212.156.196.114:2049 L=137 S=0x00 I=5738 F=0x0000 T=27 (#39)
Yes, someone tries to fool your firewall by making it think its DNS, but indeed its a try to mount world exportable directories via NFS. Sebastian -- ~ ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer@suse.de - SuSE Security Team ~
participants (7)
-
'Togan Muftuoglu' -
Jörg Schütter -
Kurt Seifried -
Nix -
Philipp Snizek -
Sebastian Krahmer -
Togan Muftuoglu