From my raw server logs, I found these:
52.42.136.103 02/Aug/2016:17:58:12 GET /administrator/
54.234.186.225 03/Aug/2016:16:48:55 GET /administrator/
54.149.57.2 04/Aug/2016:18:40:55 GET /administrator/
52.40.119.32 06/Aug/2016:09:34:37 GET /administrator/
52.40.119.32 08/Aug/2016:06:02:45 GET /administrator/
The ip's all belong to Amazon Technologies (and I don't have an /admin directory).
I'm used to seeing that kind of random probe thing (/wp-admin, /wp-blog/, /dir, ... ) from Russia and Vietnam and so on, and I've always assumed there was some nefarious motive behind it. Is there? Why would Amazon be doing that? Is Jeff Bezos out of control?
Amazon itself is not crawling your site but more likely to be some of their EC2 users (i.e. rented servers on the cloud). See below for email address to contact Amazon if you think their users are doing something illegal or abusive
whois 52.40.119.32
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#
#
# The following results may also be obtained via:
# https://whois.arin.net/rest/nets;q=52.40.119.32?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2
#
NetRange: 52.32.0.0 - 52.63.255.255
CIDR: 52.32.0.0/11
NetName: AT-88-Z
NetHandle: NET-52-32-0-0-1
Parent: NET52 (NET-52-0-0-0-0)
NetType: Direct Allocation
OriginAS:
Organization: Amazon Technologies Inc. (AT-88-Z)
RegDate: 2015-09-02
Updated: 2015-09-02
Ref: https://whois.arin.net/rest/net/NET-52-32-0-0-1
OrgName: Amazon Technologies Inc.
OrgId: AT-88-Z
Address: 410 Terry Ave N.
City: Seattle
StateProv: WA
PostalCode: 98109
Country: US
RegDate: 2011-12-08
Updated: 2014-10-20
Comment: All abuse reports MUST include:
Comment: * src IP
Comment: * dest IP (your IP)
Comment: * dest port
Comment: * Accurate date/timestamp and timezone of activity
Comment: * Intensity/frequency (short log extracts)
Comment: * Your contact details (phone and email) Without these we will be unable to identify the correct owner of the IP address at that point in time.
Ref: https://whois.arin.net/rest/org/AT-88-Z
OrgTechHandle: ANO24-ARIN
OrgTechName: Amazon EC2 Network Operations
OrgTechPhone: +1-206-266-4064
OrgTechEmail: amzn-noc-contact#amazon.com
OrgTechRef: https://whois.arin.net/rest/poc/ANO24-ARIN
OrgAbuseHandle: AEA8-ARIN
OrgAbuseName: Amazon EC2 Abuse
OrgAbusePhone: +1-206-266-4064
OrgAbuseEmail: abuse#amazonaws.com
OrgAbuseRef: https://whois.arin.net/rest/poc/AEA8-ARIN
OrgNOCHandle: AANO1-ARIN
OrgNOCName: Amazon AWS Network Operations
OrgNOCPhone: +1-206-266-4064
OrgNOCEmail: amzn-noc-contact#amazon.com
OrgNOCRef: https://whois.arin.net/rest/poc/AANO1-ARIN
Related
I received a notification of suspicious activity from Microsoft at 2:09pm
I am in Australia - GMT+10 - I thought I also saw a previous notification but I can't see that in the records
However I have now logged in and it is logged as from IP 13.101.169.237
Which is registered to Microsoft - Is this just a false report - I have changed my password - but as that is microsoft I'm not sure if I should do something more
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2022, American Registry for Internet Numbers, Ltd.
#
NetRange: 13.64.0.0 - 13.107.255.255
CIDR: 13.96.0.0/13, 13.64.0.0/11, 13.104.0.0/14
NetName: MSFT
NetHandle: NET-13-64-0-0-1
Parent: NET13 (NET-13-0-0-0-0)
NetType: Direct Allocation
OriginAS:
Organization: Microsoft Corporation (MSFT)
RegDate: 2015-03-26
Updated: 2021-12-14
Ref: https://rdap.arin.net/registry/ip/13.64.0.0
OrgName: Microsoft Corporation
OrgId: MSFT
Address: One Microsoft Way
City: Redmond
StateProv: WA
PostalCode: 98052
Country: US
RegDate: 1998-07-10
Updated: 2022-03-28
I just setup our domain a couple weeks ago to use SPF and DMARC, but no DKIM atm. But every now an then I receive an DMARC Failure report from linkedin:
This is an email abuse report for an email message received from IP 213.160.4.146 on Tue, 16 Jul 2019 12:34:26 +0000.
The message below did not meet the sending domain's dmarc policy.
The message below could have been accepted or rejected depending on policy.
For more information about this format please see http://tools.ietf.org/html/rfc6591 .
Feedback-Type: auth-failure
User-Agent: Lua/1.0
Version: 1.0
Original-Mail-From:
Original-Rcpt-To: messages-noreply#linkedin.com
Arrival-Date: Tue, 16 Jul 2019 12:34:26 +0000
Message-ID: <5cd…8b2f#SR-EXC.biv.local>
Authentication-Results: dmarc=fail (p=none; dis=none) header.from=biv-ot.org
Source-IP: 213.160.4.146
Delivery-Result: delivered
Auth-Failure: dmarc
Reported-Domain: biv-ot.org
But I can't detect any error - the IP address and domain match our MX record which is included in the SPF entry. Also the referenced RFC 6591 doesn't include the auth faile "dmarc". I get this mail round about once a week and no other server send me ever an DKIM failure report. Any idea whats wrong?
DNS Entries:
biv-ot.org:
MX: mail.biv-ot.org
A: 148.251.171.224
SPF: v=spf1 a mx include:ot-live.zms.hosting a:mout.kundenserver.de ~all
DMARC: v=DMARC1; p=none; ruf=mailto:…; fo=s
mail.biv-ot.org:
A: 213.160.4.146
This behavior is often witnessed with automated responses, such as NDRs and Out of Office replies, from mail servers as described in the Simple Mail Transfer Protocol (SMTP) RFC, section 4.5.5
In these cases the smtp.mailfrom field is empty and in most SPF implementations the check falls back to checking the HELO identity (recommended), as described in the SPF RFC, section 2.4.
Even if you create an SPF record for the HELO identity, you may still fail DMARC (on SPF) because of misalignment, if the HELO identity does not share the organizational domain of Header.From address.
In your specific case, the HELO identity would be assumed as postmaster#firewall.biv-ot.org and the reported domain (Header.From) is set to: biv-ot.org. This means that publishing an SPF record for firewall.biv-ot.org would solve your issue.
Also note: You only publish a ruf= address in your DMARC policy. Almost no mailbox providers send forensic/failure reports, so it is not wise to rely on only these reports to judge whether or not your email authentication practices are in a good state.
These blogs by Dmarcian and Valimail outline why these forensic / failure reports are so scarce.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 years ago.
Improve this question
before I begin kindly note that I am a newbie and still learning.
Yesterday 10 hours from now, I had to move all my hosted websites to a new server(to be more specific - from one droplet to a new droplet). So, since the websites were moved to a new server, meant that their ip addresses would change too. So, I updated the dns configuration for all the websites to point to the new ip address now. But I was unaware that the previous dns configuration had set the ttl to 86400(1 day). I learned about this concept after searching on google why my websites would still resolve to the old server.
So, that basically meant that the old dns config is cached for 1 day and I have to wait that long to see the change in the domain name resolution to reflect the websites from the new server.
So, i tried to perform nslookup and dig commands on the domains to just check the remaining ttl. But, this is where I am upset right now.
The nslookup command with -debug parameter gave the following result:
Please Note:- I have replaced my website's domain name with (mywebsite.com) and my new server's ip address with (new.server.ip.address) from the actual nslookup result
nslookup -debug mywebsite.com new.server.ip.address
------------
Got answer:
HEADER:
opcode = QUERY, id = 1, rcode = REFUSED
header flags: response, want recursion
questions = 1, answers = 0, authority records = 0, additional = 0
QUESTIONS:
address.ip.server.new.in-addr.arpa, type = PTR, class = IN
------------
Server: UnKnown
Address: new.server.ip.address
------------
Got answer:
HEADER:
opcode = QUERY, id = 2, rcode = NOERROR
header flags: response, auth. answer, want recursion
questions = 1, answers = 1, authority records = 2, additional = 2
QUESTIONS:
mywebsite.com, type = A, class = IN
ANSWERS:
-> mywebsite.com
internet address = new.server.ip.address
ttl = 14400 (4 hours)
AUTHORITY RECORDS:
-> mywebsite.com
nameserver = ns2.centos-webpanel.com
ttl = 86400 (1 day)
-> mywebsite.com
nameserver = ns1.centos-webpanel.com
ttl = 86400 (1 day)
ADDITIONAL RECORDS:
-> ns1.centos-webpanel.com
internet address = 127.0.0.1
ttl = 14400 (4 hours)
-> ns2.centos-webpanel.com
internet address = 127.0.0.1
ttl = 14400 (4 hours)
------------
------------
Got answer:
HEADER:
opcode = QUERY, id = 3, rcode = NOERROR
header flags: response, auth. answer, want recursion
questions = 1, answers = 0, authority records = 1, additional = 0
QUESTIONS:
mywebsite.com, type = AAAA, class = IN
AUTHORITY RECORDS:
-> mywebsite.com
ttl = 86400 (1 day)
primary name server = ns1.centos-webpanel.com
responsible mail addr = myemail#gmail.com
serial = 2013071601
refresh = 86400 (1 day)
retry = 7200 (2 hours)
expire = 3600000 (41 days 16 hours)
default TTL = 86400 (1 day)
------------
Name: mywebsite.com
Address: new.server.ip.address
Now, here's what upset me. As in the above result, the ttl (even after 10 hours since changing the dns configuration) shows 86400. I was expecting it to show the remaining ttl but the ttl is constant at 86400. Does that mean that the dns will never update for my websites?? The ttl just does not decrease.
So, to verify even further I tried using linux's dig command and here's the result I got.
Please Note:- I have replaced my website's domain name with (mywebsite.com) and my old server's ip address with (old.server.ip.address) from the actual dig result
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.5 <<>> mywebsite.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15423
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;mywebsite.com. IN A
;; ANSWER SECTION:
mywebsite.com. 83221 IN A old.server.ip.address
;; Query time: 0 msec
;; SERVER: 67.207.67.2#53(67.207.67.2)
;; WHEN: Mon Feb 5 01:55:05 2018
;; MSG SIZE rcvd: 44
Now here, the dig command resolves the domain to my old server's ip address and it shows the ttl as 83221 !!! Like I said, its more than 10 hours that I updated the dns configuration to point to my new server's ip address. But, even after 10 hours passing, the ttl says 83221 !!!!
Running the dig command again does reflect a reduction in the ttl here though, unlike the nslookup command.
So, what do you guys think is the problem that has been going on here?? Or I am misunderstanding something?? If so, please correct me. Any kind of help will seriously assist a lot. It would really help me if someone can explain what is going on here and also what's wrong or if something is wrong with my new server.
And just if it helps, I have kept the websites' files on both - the old server as well as the new server.
Thanks.
Edit:- (Solved)
So here's what fixed all the issues I was facing. I use centos web panel on my server which comes bundled with freedns manager. So, a bug in freedns kept my nameservers and domains' dns from updating. So, I went for cloudflare dns and that fixed all the issues.
Your domain is not correctly configured, please use online diagnostics tools such as dnsviz.net, see the report: http://dnsviz.net/d/mkinfra.in/dnssec/
You are in a lame delegation situation.
If we query .IN authoritative nameservers for your domain, they reply:
mkinfra.in. 86400 IN NS ns1.centos-webpanel.com.
mkinfra.in. 86400 IN NS ns2.centos-webpanel.com.
mkinfra.in. 86400 IN NS ns3.centos-webpanel.com.
mkinfra.in. 86400 IN NS ns4.centos-webpanel.com.
mkinfra.in. 86400 IN NS ns5.centos-webpanel.com.
If we query any of these 5 nameservers for your domain, they reply:
mkinfra.in. 86400 IN NS ns1.centos-webpanel.com.
mkinfra.in. 86400 IN NS ns2.centos-webpanel.com.
Which is not the same set of records. You will first need to resolve this discrepancy.
For your website they all reply the same:
www.mkinfra.in. 86400 IN CNAME mkinfra.in.
mkinfra.in. 86400 IN A 139.59.63.210
So they all reply will your old IP and not the new one. Your problem has nothing to do with TTLs: the authoritative nameservers for your domain are still not delivering the new IP address you wish, so you have to configure them properly. If you do it yourself, please remember to update the serial of the zone for any change.
The serial is in fact 2018012401 which follows the pattern YYYYMMDDXX so we can infer that the zone was changed on January 24th but not since then (or was changed but serial not updated so the new content is not taken into account at all).
And to reply to your other question: if you query an authoritative nameserver you will always get the same TTL, which is per design. It is only if you query a resolving and caching nameserver that you will see the TTL decreasing from one query to another, because the case is slowly forgetting about the data it resolved in the past.
Never use nslookup but always dig but always specify the command you use when you ask for people to check what you are doing (it is very important to specify the nameserver you query with the # parameter of dig since the results will be vastly different from an authoritative or a recursive nameserver).
Summary:
This is a 2 part question. A simple Samba share on one ISP with router doesn't work while another ISP with a different router setup the same and a similar server with same Samba configuration works.
It seems to be either the router not forwarding the ports, although it successfully forwards SSH and others, or the ISP somehow blocking the standard Samba ports. It still bugs me that I can't figure out why it doesnt work and I'll still try to narrow down the cause.
The second question is I'm looking for a business use, simple, easy to use (for end users), secure share for a small number of people and files, hosted internally and accessible externally on the internet, between Windows 7, XP, Mac, and linux servers with simple clients for end users.
A new friend outside of stackoverflow helped with sshfs as a solution. On CentOS ssh already supports sshfs. The Windows client win-sshfs is working well and I'll be trying OSXFUSE with MACFusion described at UO.
Additionally, setup linux users for each person. To allow write by everyone in the linux group, change the umask in /etc/ssh/sshd_config described in this question at serverfault. People get to their home directory first, where I placed links to a shared folder with sticky bit set so they can't delete the folder. They can delete the links but that's easy enough to put back. The only issues I can see are lack of file locking and lack of auto-refresh.
Original Question:
I can't seem to get Samba working on a Centos 6.3 server over the internet. I have a similar test server on another internet connection working fine with the exact same setup. I've gone through http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/diagnosis.html twice, made sure the ports are forwarded through to the internet (although not sure how to test they are really open), double checked samba configuration, its only sharing /tmp simply now. The user account is setup, it can ssh in and get to /tmp and the samba password is set the same. I can't ping the server but that is because the router or IP is set not pingable by the owner/work. SSH and HTTPS apache work well on the server with ports forwarded the same way. I haven't been able to test the share within the local network yet since I am not there, but I assume that it should work internally. When trying to connect from Windows 7 it just times out, no prompt and it has never connected, whereas my test server on my own internet connection is always working internally and externally.
Any help would be greatly appreciated.
The requirement is a easy to use internally hosted shared folder alternative to using "dropbox" for use between Windows 7, XP, mac, and linux servers that works over external internet connection. It won't see heavy usage but should be quick, easy to access/setup on the client side, and secure for business. If there are any alternatives to install on CentOS that would be great as well.
Thank you!
Andrew
Edit, details:
Ports are forwarded:
(I had an image but as new user I cant post) 137, 138, 139, 445 are forwarded all with both TCP and UDP for testing now.
smb.conf is setup simply and exactly the same as the working test server:
# cat /etc/samba/smb.conf
[global]
workgroup=WORKGROUP
log level = 3
log file = /var/log/samba/log.%m
max log size = 50
security = user
passdb backend = tdbsam
[tmp]
comment = temporary files
path = /tmp
read only = yes
Samba restarted for good measure:
# service smb restart
Shutting down SMB services: [ OK ]
Starting SMB services: [ OK ]
Windows 7 times out when trying to access the share as \ which works fine with the test server:
(I had a screenshot but new users cant post)
A search for the error 0x80004005 results in http://answers.microsoft.com/en-us/windows/forum/windows_vista-networking/cannot-access-network-share-get-unspecified-error/9f840844-9d5b-e011-8dfc-68b599b31bf5
I've checked the workgroup, share settings, and restarted windows. Since the test share works I would think the Windows machine is working. I'll continue with the details.
Edit again:
Following the troubleshooting guide again:
Simplify the smb.conf to just:
# cat /etc/samba/smb.conf
[tmp]
comment = temporary files
path = /tmp
read only = yes
/etc/resolv.conf is using the ISPs servers and they work. They are different than the working server's DNS but that one is on a different ISP:
# nslookup google.com
Server: 71.242.0.12
Address: 71.242.0.12#53
Non-authoritative answer:
Name: google.com
Address: 74.125.228.2
I'm doing everything with IP addresses so I don't know that DNS would come into play.
I added dns proxy = no to smb.conf for fun but that didn't help.
/var/log/samba/log.smbd doesn't report anything different from the working server:
[2012/09/20 16:59:41, 0] smbd/server.c:1141(main)
smbd version 3.5.10-125.el6 started.
Copyright Andrew Tridgell and the Samba Team 1992-2010
[2012/09/20 16:59:41.484699, 0] param/loadparm.c:7648(lp_do_parameter)
Global parameter dns proxy found in service section!
[2012/09/20 16:59:41.486645, 0] printing/print_cups.c:109(cups_connect)
Unable to connect to CUPS server localhost:631 - Connection refused
[2012/09/20 16:59:41.486809, 0] printing/print_cups.c:468(cups_async_callback)
failed to retrieve printer list: NT_STATUS_UNSUCCESSFUL
[2012/09/20 16:59:41.507198, 0] smbd/server.c:501(smbd_open_one_socket)
smbd_open_once_socket: open_socket_in: Address already in use
[2012/09/20 16:59:41.507407, 0] smbd/server.c:501(smbd_open_one_socket)
smbd_open_once_socket: open_socket_in: Address already in use
[2012/09/20 17:00:39, 0] smbd/server.c:1141(main)
smbd version 3.5.10-125.el6 started.
Copyright Andrew Tridgell and the Samba Team 1992-2010
[2012/09/20 17:00:39.513793, 0] printing/print_cups.c:109(cups_connect)
Unable to connect to CUPS server localhost:631 - Connection refused
[2012/09/20 17:00:39.513955, 0] printing/print_cups.c:468(cups_async_callback)
failed to retrieve printer list: NT_STATUS_UNSUCCESSFUL
[2012/09/20 17:00:39.535458, 0] smbd/server.c:501(smbd_open_one_socket)
smbd_open_once_socket: open_socket_in: Address already in use
[2012/09/20 17:00:39.535689, 0] smbd/server.c:501(smbd_open_one_socket)
smbd_open_once_socket: open_socket_in: Address already in use
However the working server creates a log file in the directory named log. which the non working server does not.
testparm:
# testparm
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[tmp]"
Loaded services file OK.
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions
[global]
[tmp]
comment = temporary files
path = /tmp
continuing...
Continued:
nmb is running as well:
# service nmb restart
Shutting down NMB services: [ OK ]
Starting NMB services: [ OK ]
"Respond to Ping on Internet Port" is normally turned off on the routers. I turned it on, on both the Windows client and the server. Each can ping the other, sharing still doesn't work.
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\xxxx>ping xxxx
Pinging xxxx with 32 bytes of data:
Reply from xxxx: bytes=32 time=25ms TTL=51
Reply from xxxx: bytes=32 time=23ms TTL=51
Reply from xxxx: bytes=32 time=26ms TTL=51
Reply from xxxx: bytes=32 time=24ms TTL=51
Ping statistics for xxxx:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 23ms, Maximum = 26ms, Average = 24ms
# ping xxxx -c 5
PING xxxx (xxxx) 56(84) bytes of data.
64 bytes from xxxx: icmp_seq=1 ttl=251 time=20.7 ms
64 bytes from xxxx: icmp_seq=2 ttl=251 time=24.6 ms
64 bytes from xxxx: icmp_seq=3 ttl=251 time=21.4 ms
64 bytes from xxxx: icmp_seq=4 ttl=251 time=25.3 ms
64 bytes from xxxx: icmp_seq=5 ttl=251 time=22.9 ms
--- xxxx ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4029ms
rtt min/avg/max/mdev = 20.776/23.022/25.319/1.764 ms
continuing...
Continued:
iptables are off:
# iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
SELinux is off:
# sestatus
SELinux status: disabled
smbclient using a user setup in samba works from the samba server to its local IP and to its external IP. The Windows client gets:
Connection to <ip addr> failed (Error NT_STATUS_UNSUCCESSFUL)
Samba is running as a daemon/service and netbios-ssn is in listen mode:
# netstat -a|grep netbios-ssn
tcp 0 0 *:netbios-ssn *:* LISTEN
Continuing...
Continued:
We're not restricting connections or using inetd.
log.nmbd does not report any problems.
nmblookup -B BIGSERVER SAMBA works using the server's name
nmblookup -B ACLIENT * fails on all log files using the windows client name OR the external IP address
nmblookup -d 2 `*'. fails
"If your PC and server aren't on the same subnet, then you will need to use the -B option to set the broadcast address to that of the PC's subnet.
This test will probably fail if your subnet mask and broadcast address are not correct. (Refer to test 3 notes above)."
Im not sure here, since we're going over the internet do we need these to match and work?
smbclient //BIGSERVER/TMP works
On the client:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\xxxx>net view \\xxxx (ip addr)
System error 53 has occurred.
The network path was not found.
C:\Users\xxxx>
net use has the same problem, even with providing user and passwd.
nmblookup -M WORKGROUP returns a local windows machine on the network there, whereas on my test server it returns the client which is local to the test machine. Perhaps there is an issue here with workgroup being on another machine, but how would others connect from other networks if this was the issue?
I tried preferred master = yes as well.
Page 2 of samba howto next.
Update: A new friend said to try nmap to see check the ports:
# nmap -sS -P0 -sV -O xxxx
Starting Nmap 5.51 ( ) at 2012-09-21 11:09 EDT
Nmap scan report for xxxx (xxxx)
Host is up (0.024s latency).
Not shown: 995 filtered ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 5.3 (protocol 2.0)
25/tcp open smtp Postfix smtpd
110/tcp open pop3 Dovecot pop3d
443/tcp open ssl/http Apache httpd 2.2.15 ((CentOS))
9100/tcp open jetdirect?
Warning: OSScan results may be unreliable because we could not find at
least 1 open and 1 closed port
OS fingerprint not ideal because: Missing a closed TCP port so results
incomplete
No OS matches for host
Service Info: Host: xxxx
Since the Samba ports do not show up, I'm thinking the router or ISP is not forwarding/blocking the ports at this point.
As for a solution to sharing, I'm trying sshfs with a windows and mac client.
Answering your original question, the good way to test if your ISP is not blocking listed ports is this:
# yum -y install tcpdump
# tcpdump -i eth0 "port 137 or port 138 or port 139 or port 445"
(substitute eth0 with the name of the interface connected to the Internet).
Then you should try accessing the share (net view / net use / Windows Shell). If ports are forwarded correctly you should see something like that:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
01:25:48.631173 IP 192.168.0.10.54032 > 192.168.0.1.microsoft-ds: Flags [S], seq 4008761512, win 5840, options [mss 1460,sackOK,TS val 136010468 ecr 0,nop,wscale 7], length 0
01:25:48.631198 IP 192.168.0.1.microsoft-ds > 192.168.0.10.54032: Flags [S.], seq 2220435566, ack 4008761513, win 14480, options [mss 1460,sackOK,TS val 15507714 ecr 136010468,nop,wscale 7], length 0
01:25:48.631397 IP 192.168.0.10.54032 > 192.168.0.1.microsoft-ds: Flags [.], ack 1, win 46, options [nop,nop,TS val 136010468 ecr 15507714], length 0
01:25:48.642171 IP 192.168.0.10.54032 > 192.168.0.1.microsoft-ds: Flags [P.], seq 1:184, ack 1, win 46, options [nop,nop,TS val 136010479 ecr 15507714], length 183SMB PACKET: SMBnegprot (REQUEST)
...
If you see nothing at all it means that your ISP (or intermediate router) is blocking packets to those ports and it's most likely the case — SMB protocol proved to be quite insecure for open Internet deployments.
In the file /etc/samba/smb.conf, under the section [global], below the workgroup line add this two lines :
client min protocol = NT1
client max protocol = SMB3
I have several WHOIS servers for which I want to have a single proxy. The proxy should forward requests to appropriate servers based on the data in the query. How to approach this problem?
Step 1 read the RFC for WHOIS
Step 2 implement a mock server with Net::Server
Step 3 implement the proxy using your mock server and Net::Whois::Proxy or some other WHOIS module
A quick scan of the RFC seems to say that it is just a simple text based protocol that expects one CRLF terminated line and then sends a blob of CRLF terminate lines and closes the socket.
Yep, it really looks that simple, given this code
#!/usr/bin/perl
{
package Whois;
use strict;
use warnings;
use parent 'Net::Server';
sub process_request {
my $request = <>;
print "you sent me $request";
}
}
Whois->run;
you can say
whois -h localhost -p 20203 foo.com
and get back
you sent me foo.com
Given the "high-load" tag, you will probably want to switch over to Net::Server::PreForkSimple personality when you are done with testing.
And just because I was bored:
#!/usr/bin/perl
package Whois {
use strict;
use warnings;
use parent 'Net::Server::PreFork';
use Net::Whois::Raw;
my %handler = (
org => "whois.publicinterestregistry.net",
);
sub process_request {
(my $request = <>) =~ s/[.]([^.]+)\x{0d}\x{0a}/.$1/;
print exists $handler{$1} ?
whois $request, $handler{$1} :
"I don't know where to look for $request\r\n";
}
}
Whois->run(
user => "nobody",
group => "nobody",
port => 43,
min_servers => 1, #min number of children
max_servers => 10, #max number of children
min_spare_servers => 1, #fork if we don't have this many waiting
max_spare_servers => 5, #kill if we have this many waiting
max_requests => 10_000, #num of requests before killing a child
);
which when I run
sudo perl whois.pl
and then
whois -h localhost foo.org
gives us
NOTICE: Access to .ORG WHOIS information is provided to assist persons in
determining the contents of a domain name registration record in the Public Interest Registry
registry database. The data in this record is provided by Public Interest Registry
for informational purposes only, and Public Interest Registry does not guarantee its
accuracy. This service is intended only for query-based access. You agree
that you will use this data only for lawful purposes and that, under no
circumstances will you use this data to: (a) allow, enable, or otherwise
support the transmission by e-mail, telephone, or facsimile of mass
unsolicited, commercial advertising or solicitations to entities other than
the data recipient's own existing customers; or (b) enable high volume,
automated, electronic processes that send queries or data to the systems of
Registry Operator or any ICANN-Accredited Registrar, except as reasonably
necessary to register domain names or modify existing registrations. All
rights reserved. Public Interest Registry reserves the right to modify these terms at any
time. By submitting this query, you agree to abide by this policy.
Domain ID:D1608104-LROR
Domain Name:FOO.ORG
Created On:10-Jan-1995 05:00:00 UTC
Last Updated On:07-Mar-2011 00:26:43 UTC
Expiration Date:09-Jan-2012 05:00:00 UTC
Sponsoring Registrar:Fabulous.com Pty Ltd. (R133-LROR)
Status:CLIENT DELETE PROHIBITED
Status:CLIENT TRANSFER PROHIBITED
Registrant ID:fabwpp-000700385
Registrant Name:Domain Hostmaster, CustomerID : 85519846801225
Registrant Organization:Whois Privacy Services Pty Ltd
Registrant Street1:PO Box 923
Registrant Street2:
Registrant Street3:
Registrant City:Fortitude Valley
Registrant State/Province:QLD
Registrant Postal Code:4006
Registrant Country:AU
Registrant Phone:+61.730070090
Registrant Phone Ext.:
Registrant FAX:+61.730070091
Registrant FAX Ext.:
Registrant Email:85519846801225-959797#whoisprivacyservices.com.au
Admin ID:fabwpp-000700385
Admin Name:Domain Hostmaster, CustomerID : 85519846801225
Admin Organization:Whois Privacy Services Pty Ltd
Admin Street1:PO Box 923
Admin Street2:
Admin Street3:
Admin City:Fortitude Valley
Admin State/Province:QLD
Admin Postal Code:4006
Admin Country:AU
Admin Phone:+61.730070090
Admin Phone Ext.:
Admin FAX:+61.730070091
Admin FAX Ext.:
Admin Email:85519846801225-959797#whoisprivacyservices.com.au
Tech ID:fabwpp-000700385
Tech Name:Domain Hostmaster, CustomerID : 85519846801225
Tech Organization:Whois Privacy Services Pty Ltd
Tech Street1:PO Box 923
Tech Street2:
Tech Street3:
Tech City:Fortitude Valley
Tech State/Province:QLD
Tech Postal Code:4006
Tech Country:AU
Tech Phone:+61.730070090
Tech Phone Ext.:
Tech FAX:+61.730070091
Tech FAX Ext.:
Tech Email:85519846801225-959797#whoisprivacyservices.com.au
Name Server:NS1.HITFARM.COM
Name Server:NS2.HITFARM.COM
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
DNSSEC:Unsigned
whois.publicinterestregistry.net
I'm no expert on whois, but Net::Whois::Proxy would seem to be what you want.