winbindd fails to resolve local network names when firestarter firewall is up on ubuntu - linux

I'm using Samba and windbindd on my linux boxes. Without a firewall up on the linux box I have no trouble resolving LAN machine names:
user#laptop-linux:~$ ping desktop
PING desktop (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 ttl=128 time=0.878 ms
when I start the firewall I get:
user#laptop-linux:~$ ping desktop
ping: unknown host desktop
I have opened up the Samba ports (137-139 445) as well as the mDNS port 5353 with no effect. WINS has been enabled in nsswitch.conf and I've also tried removing the mdns4 entries for host lookup. I can see the DNS query going out regular DNS with my ISP domain suffix attached which is not what I want. I want to use wins / NetBIOS to do the work. Do I have allow some form of broadcast port? Can this be done while maintaining security? I want to have a firewall running on my laptop because I access open hotspots on a regular basis. Thanks

Sorry for necroing this post, but i had considerable trouble figuring this out, and hence am putting it up for anyone else who might run into it.
Basically you have to enable incoming packets (NB response packets) coming from port 137/udp of the responding system. In ubuntu 11.04, using ufw, this can be easily done as:
ufw allow proto udp from 192.168.1.0/24 port 137 to any
This assumes that your LAN is using the 192.168.1.0/24 ip range.

Related

I got a port scan (blocked by kaspersky antivirus on my windows 10 machine)

I got a notification from my kaspersky antivirus on my windows 10 (which is always on)
Apparently, there was a port scan and it was blocked.
User: NT AUTHORITY\SYSTEM
User type: System user
Component: Network Attack Blocker
Result description: Blocked
Name: Scan.Generic.PortScan.TCP
Object: TCP from 104.152.52.xxx at 192.168.0.10:1701
Additional: 192.168.0.10
Databases release date: Yesterday, 1/19/2022 12:34:00 PM
192.168.0.10 is a virtual machine running debian; I have UFW on this debian and port 1701 is not in any UFW rules. (so it's not allowed)
I have done a grep on the ports of the debian VM using: sudo netstat -tulpn | grep 1701 Found nothing
I assume the port scan has been done on all the machines in my network?
How can I find out where the scan comes from?
What are the consequences? What should I do next?
So from what i understand of what you published, 104.152.52.xxx made a scan. What's odd is how could he effectively reach your machine at 192.168.0.10, so i believe you have port forwarding enabled on your router. *-{see edit}
I also assume that the IP address of your VM is bind directly to your home network 192.168.0.0\24 (and not in a sub network on Windows 10). So your router should be accessible at 192.168.0.1 (or 192.168.0.254 sometimes)
Consequences of a scan ?
most likely, none, except if you have some port opens, kaspersky blocked the 1701, but probably other ports have been scanned. So verify the configuration of your router
Is it normal ?
Yes. Every device accessible from internet is constantly scanned. Always.
What to do next ?
Make sure no port-forwarding is enabled on your router
If port forwarding is enable, and needed. Make sure the software behind it is secured and up to date. if you have a password access, the password should be strong. If you have an SSH server, deactivate the authentication by password and activate the authentication by public key.
== EDIT ==
Other possibility than port forwarding and seems to be the answer:
If the VM is in a DMZ, then all unassigned ports on the router may be (depends on the router) redirected to the VM, therefore, a scan on the public ip address, would result on a scan on the VM.

How service can bind on 127.0.0.xxx without interface to be present

Recently I found that I was able to bind Apache on 127.0.0.73 without 127.0.0.73 to be present.
Only 127.0.0.1 is present as normal.
I also spoke with a friend and he said that is "normal" on Linux and probably on Windows and not works on MacOS, but he has no idea why.
I can do following:
[nmmm#zenbook nmmm]$ curl 127.10.0.123
curl: (7) Failed to connect to 127.10.0.123 port 80: Connection refused
and it shows that whole A class network is available.
How this works?
I do not see anything special in ifconfig and ip, except lo interface has no broadcast. Is that the key point?
According to https://en.wikipedia.org/wiki/Localhost
IPv4 network standards reserve the entire address block 127.0.0.0/8 (more than 16 million addresses) for loopback purposes.2 That means any packet sent to any of those addresses is looped back. The address 127.0.0.1 is the standard address for IPv4 loopback traffic; the rest are not supported by all operating systems. However they can be used to set up multiple server applications on the host, all listening on the same port number. The IPv6 standard assigns only a single address for loopback: ::1.
Or from https://www.rfc-editor.org/rfc/rfc3330
127.0.0.0/8 - This block is assigned for use as the Internet host
loopback address. A datagram sent by a higher level protocol to an
address anywhere within this block should loop back inside the host.
Even though you can't see anything from ifconfig or ip, you still can ping all the addresses in that 127.0.0.0/8 block.

Why does my vps reply to dns queries even if it has no dns server running?

I've got a cheap openvz Ubuntu vps and i'm trying to run my own dns server on it for learning purpose.
The dns server works fine in localhost (on the vps through ssh), i can query it using dig google.com #127.0.0.1 and i get the expected result (which is not the IP of google.com but a custom one).
When i try to query the dns server from outside the vps, using the same command, I do get a reply but the IP is not what I expect (it's an actual google.com IP).
After further investigation I found out my dns server is not receiving/sending packets when the query is done from outside the vps. So the answer is sent by something else, it seems like inbound packets with destination port 53 are deviated, they do not even reach my dns server.
I tried to query my dns server, still from outside, but this time while the VPS was SHUTDOWN. Magically i got a reply from god knows who.
Changing port from 53 to 54 everything works perfectly.
The problem is i need it to use port 53.
I don't have iptables rules nor any other firewall doing something related to port 53
I also tried to query some other random vps, from different hosting providers, seems like everyone has a dns server running! Why does everyone reply?
Of course i asked technical support, that's what they said:
Hello,
Sorry but we don't do "software" technical support on VPS.
We deliver the hosting and the operating systems, customers that order VPS are their own admins, and have to know how to manage a linux server.
We don't block any port on our side.
Best regards,
Support
Mybe your dns server is bound to the loopback interface only (so it's only listening on localhost). You can check the current service ports used (udp for DNS) using netstat and filter (grep) udp port used
netstat -an | grep ":53"
Also you can test the same dns query using the nslookup command, and checking the dns server ip that answer your dns query, in the result output:
nslookup google.com [dns_server_ip]
Also test it without dns_server_ip to check if there is a default nameserver when the specified nameserver is not responding.
Problem solved, it's my ISP intercepting and replying to dns queries.
I can do dig google.com #1.2.3.4 and i get a reply :D
Who wants to know more about this:
ISP Intercepting DNS Lookups

Tunnel dynamic UDP port range

Usually I prefer finding a solution on my own, but unfortunately that didn't work out too well this time so I'm asking here.
I'm trying to deal with a server (rather a computer with no screen and debian minimal on it) which is on the usual home network. Problem is the ISP is running out of ipv4 addresses and therefore
decided to use ipv6 instead and dual-stack lite to access the ipv4 side of the internet. This means the computer is not accessible over the ipv4 address from the outside
but is able to connect to a ipv4 computer.
I do have a vserver (debian as well) which still uses only ipv4, so my plan was to use it as some kind of relay or porxy. Problem there is, I am not able to use iptables to configure NAT
since the server provider has removed that module from the kernel.
My first attempt was to use an SSH tunnel like this:
ssh -f user#vserver -R 2222:localhost:22 -N
This allows me to access the CLI over SSH which now listens on port 2222.
Next step was to open a second SSH tunnel and tunnel UDP traffic through that using socat:
homeserver:~# socat tcp4-listen:${tcpport of second tunnel},reuseaddr,fork udp:localhost:${udpport to forward traffic from}
vserver:~# socat -T15 udp4-recvfrom:${udpport to forward traffic to},reuseaddr,fork tcp:localhost:${tcpport of second tunnel}
This does work, however once the client application is trying to connect to the UDP port, the server application is trying to continue the communication on a different new port from the dynamic
port range (Ephemeral Port Range I think). That one random port of course is not being forwarded since socat is not listening to.
The second attempt also involved an SSH tunnel, only a dynamic one this time (basically a socks proxy).
I was trying to setup a virtual network device to route all the traffic through the socks proxy:
(As described in man pages from badvpn-tun2socks)
homeserver:~# openvpn --mktun --dev tun0 --user <someuser> #create tun0 device
homeserver:~# ifconfig tun0 10.0.0.1 netmask 255.255.255.0 #configure it
homeserver:~# route add <IP_vserver> gw <IP_of_original_gateway> metric #Route all traffic through tun0
homeserver:~# route add default gw 10.0.0.2 metric 6 #exept the ones to the vserver
homeserver:~# badvpn-tun2socks --tundev tun0 --netif-ipaddr 10.0.0.2 --netif-netmask 255.255.255.0 --socks-server-addr 127.0.0.1:1080 \
--udpgw-remote-server-addr 127.0.0.1:7300
This needs to SSH socks-proxies since upd needs to be handled seperately.
On the vserver side of things these need to be handled as well:
vserver:~# badvpn-udpgw --listen-addr 127.0.0.1:7300
The connection between both is successful but this time the homeserver is not accessible at all. (seems to me like the vserver has no clue what to do with the packets)
I hope there is a simple fix to either of my attempts. But as it stands now,
I think my whole approach is fundamentally flawed and I'm starting to run out of ideas.
Any help would be appreciated, Thanks in advance!

Cannot send or receive packets from my VirtualBox debian linux VM using UDP

For the sake of simplicity, I will refer you to http://en.wikipedia.org/wiki/Berkeley_sockets and the UDP server and client source code there.
I am trying to send a packet using UDP protocol to a linux VirtualMachine server program. Both my host and VM ping well; all packets sent are received in both directions. However my server program is either not receiving any packets, or it is simply not printing. Either way, it isn't printing the confirmation or contents of any packets I send to it from the host.
I do not have another PC handy, but both programs communicate well enough if I stage them on the same computer and Wireshark reports that the packets are being sent.
Mine is a three part question: first, how can I fix this. Second, why would the host and VM receive each others ping messages, but not pass these on to the open sockets of both ends of my UDP system? Finally, do you have any suggestions about the form or intent of this question?
EDIT: I've tried running my VM with the NAT and bridged adapter network setups. However, I can't conceptualize the relationship between those setups and my problems right now.
With NAT networking, the VM gets a private IP address (usually 192.168.x.y) and the host does NAT translation of outgoing packets, and translates reply packets back to the VM. In this mode, all communication must be initiated by the VM -- outside machines can only send packets to the VM in reply to packets the VM sent to them. On the network, the packets will look like they're coming from/going to the host on some unrelated port.
With bridged networking, the VM gets a device that connects directly to the host's network device. In this mode, the VM appears as a separate machine on the same network LAN as the host, with its own IP address. You need to allocate an IP address for it, the same as the host get allocated an IP address (usually via DHCP).
In either case, to debug what is going on, use tcpdump/wireshark on the host to monitor the host's network device. Send packets from the VM, and you should see them in the trace -- they'll appear to come from the host and a different port in the NAT case, and will appear to come from the VM's IP address (and unchanged ports) in the bridged case.
Once you see that, you should be able to send packets back to the VM, though in the NAT case, they must come FROM the address/port the original packet(s) were sent to.
There are known issues with VirtualBox bridged networking not working properly on wifi devices; in general you can only use bridged networking with wired networks.
Oracles VB manual page clear all the terminology used in settings.
I've had similar problem, where my VB program didn't receive any packets, which I solved by setting "Bridged Networking" and setting up proper source/destination IP address in my program by analyzing WLAN interface with wireshark and using ifconfig (or ipconfig) in terminal.

Resources