I have been working away with Freeradius 3+ & REST module with the default PEAP/EAP-TTLS sites. I am however unable to send error messages to the target client at any stage of AAA.
I have tried manually setting
update reply { Reply-Message := "test" }
at the post-auth section of the inner/outer tunnels, both to no avail.
I have read also that Reply-Message is not allowed to be accompanied by a EAP-Message so I am very confused on how I actually message the user error codes ect. Has anyone figured out how to send messages to the client on PEAP/EAP-TTLS
Other Details:
AP - Unifi, Clients - Iphone; Linux XUbuntu; Windows 10
Kind Regards
The simple answer is you can't.
A long long time ago, in a job far far away, we had HP ProCurve switches. When these switches received a Reply-Message, they'd transform the contents into an EAP-Notification packet, which'd be sent after the final EAP-Success.
With Linux supplicants this caused the authentication process to restart. With other operating systems, they simply ignored it (OSX would actually log the contents but not display it).
The wpa_supplicant author Jouni Malinen would not fix the issue as he quite rightly claimed the switches and our RADIUS servers were not compliant with RFC3579.
The only way you could possibly send the user a message would be in an EAP-Notification packet crafted by FreeRADIUS, which we don't currently support, and even if we did, it'd probably be ignored by most supplicants and may cause weird behaviour in others.
There are policies in the default virtual server that actually remove any Reply-Message attributes present to prevent users breaking RFC3579, but if you want to experiment, set the Reply-Message in the outer server and remove this line.
Related
We are having some challenges around using Azure Portal to manage IoT edge devices in development. I am posting in case someone can confirm these are known issues, or supply possible workarounds.
The first inconsistency is that when we have no clients connected, it will show up saying 1 under the connected client count field; even though at the same time giving a warning that the device is disconnected from the hub.
The second (and more annoying) inconsistency is that the modules that are running don’t match the modules that are showing up on the hub. When we run the docker ps command we get what we think is the correct situation, while at the same time, the hub shows that we have modules that are “running” that aren’t there at all, and one that is “pending deployment” that we can see is running.
We've also seen that the EdgeAgent container is pumping out a bunch of warnings saying: [WRN] - Building state for computing patch failed with error 'Could not find type in JObject. type Newtonsoft.Json.JsonSerializationException.' We wonder if this error has anything to do with it, maybe it’s trying to send status updates back to the hub but falling over somewhere along the line?
We would be grateful for any comments or updates on portal status. I have some images supporting my message, but can't upload them because I am a Stack Overflow newbie.
Thanks for any guidance as to whether these are known issues with the portal at this stage, or if there is something we are doing incorrectly.
Dave
I have a MQTT environment like this:
there is One (gray) sensor and one Observer that are related by the topic room/temp, so far so good, sensor can publish and the Observer can get the info as it should.
the Issue I have is now: I need to block IN THE BROKER that a 2nd undesired client comes(the orange one),and start to publish into the same topic, as far as I know, MQTT is loose coupled so that observer doesn't care who is pushing the temp values, but I find a security flawless when someone hack my environment and publish non sense triggering my alarms...
any suggestion?
am using eMQTTd by the way and according to this there is nothing in the etc/emqttd.config file I can do to avoid that...
Thanks!
I only have experience with Mosquitto but, from a quick read of the document linked, it looks like there are several ways you could achieve this.
I am unclear if you are talking about an incidental problem here--i.e. bad information is being accidentally sent--or if you are protecting against an active threat.
If you are concerned with incidental overwriting of a value, then the simple clientid solution on (pg. 38) would work.
But my impression is that it would still be transmitted in the clear and thus be of little use to you if you are facing an actual adversary (hacker etc.). If that is your concern simply setup SSL and remove all non-SSL listeners. (See pg. 24). That should limit all traffic to an encrypted channel. Then if you wish add password / user authentication (pg. 38) to complete the security.
Alternatively, depending on your configuration, you could block unapproved ip addresses at the firewall level (i.e. block access to the port that your broker is listening on to all addresses except for the temperature sensor) or using eMQTTd's built in ACL facility (pg. 25). That would be less secure than a full SSL setup but depending upon your needs it might be enough.
With Delphi XE2, what is the most reliable method to detect if the computer is able to do the following things?
reach a specific website with HTTP which does not have a fixed IP address
send and receive e-mail with any local or remote e-mail client
There are too many factors involved (type of Internet connection, firewall/router rules, proxies, etc). The most reliable approach is to simply not try to determine the current state and just attempt the desired operation (perform the actual HTTP request, or the SMTP/POP3/IMAP operation, etc), and just be prepared to react to any errors. You can detect connection-related errors and prompt the user to check their Internet connection before retrying.
Use TIdHTTP.Get and try to download http://google.com.
Of course it depends on the definition of being connected to the internet. Sometimes web traffic (port 80) is blocked while other ports are open. Fortunately, nowadays most people are actually allowed to browse the web, since it also provides help with their daily activities. Google is probably one of the least firewalled websites with one of the highest uptimes.
But still, it's a lucky guess. Depending on what you need it for, you might as well just try your thing and see if it works. If not, apparently the computer was not properly connected, even if it could reach Google. :)
[edit]
Because of the discussion. InternetCheckConnection is a good alternative too, but it also checks the connection by pinging an actual server.
MSDN says
Use the InternetCheckConnection function to check the connection to
the Internet. It attempts to ping the server designated by the URL
that is passed to the function. If the FLAG_ICC_FORCE_CONNECTION flag
is set and the URL is NULL, the function checks to see if there is an
entry in the server database for the nearest server. If one exists,
the function pings that server
But since this function uses ping, it may be a bit faster than actually retrieving content. On the other hand, many firewalls actively refuse pings.
For my portfolio software I have been using fetchmail to read from a Google email account over IMAP and life has been great. Thanks to the miracle of idle connection supported by imap3, my triggers fire in near-realtime due to server push, much sooner than periodic polling would allow otherwise.
In my basic .fetchmailrc setup, in which a brokerage customer's account emails trade notifications to a dedicated Gmail/Google Apps box, I've had
poll imap.gmail.com proto imap user "youraddress#yourdomain-OR-gmail.com" pass "yoMama" keep nofetchall ssl idle mimedecode limit 29000 no rewrite mda "myCustomSpecialMDAhandler.sh %F %T"
Trouble is, now I need to support reading from multiple email boxes, and hand off the emails to other specialized MDA scripts I wrote. No problem, just add more poll lines to .fetchmailrc, right? Well that doesn't work when the other accounts also use imap.gmail.com. What ends up happening is that while one account reads fine (and not necessary the first one listed, though usually yes), the other is getting "socket error" all day and the emails remain untouched, unread. I can't figure out why and not even sure if it's some mechanism at imap.gmail.com or not, eg. limiting to one IMAP connection from a host. That doesn't seem right since I have kept IMAP connections to many separate Gmail & Google Apps accounts from the same client for years (like Thunderbird) and never noticed this exclusivity problem.
I haven't tried launching multiple fetchmail daemons using separate -f config files (assuming they wouldn't conflict), or deploying one or more getmail and other similar email fetchers in addition. Still trying to avoid that kind of mess--unscaleable the more boxes I have to monitor.
Don't have the reference offhand but somewhere in fetchmail's docs I recall reading that idle is not so much an imap feature as a fetchmail optional trick, which has a (nasty for me) side effect of choking off all other defined accounts from polling until the connection is cut off by some external event or timeout. So at least that would vindicate Google.
Credit to Carl's Whine Rack blog for some tips.
For now I use killall fetchmail; fetchmail -f fetcher.$[$RANDOM % $numaccounts].rc periodically from crontab to cycle reading accounts each defined individually in fetcher.1.rc, fetcher.2.rc, etc. Acceptable while email events are relatively infrequent.
Our web application sends e-mails. We have lots of users, and we get lots of bounces. For example, user changes company and his company e-mail is no longer valid.
To find bounces, I parse SMTP log file with log parser. The logs come from Microsoft SMTP server.
Some bounces are great, like 550+#5.1.0+Address+rejected+user#domain.com. There is user#domain.com in bounce.
But some do not have e-mail in error message, like 550+No+such+recipient.
I have created simple Ruby script that parses logs (uses log parser) to find which mail caused something like 550+No+such+recipient.
I am just surprised that I could not find a tool that does it. I have found tools like Zabbix and Splunk for log analysis, but they look like overkill for such simple task.
Anybody knows a tool that would parse SMTP logs, find bounces and e-mails that cause them?
As far as I can see, log file analysis is really only useful to detect mails which are rejected at the SMTP session level. What about bounces which occur after the remote MTA has accepted a message for delivery but subsequently fails to deliver it?
We use the following set up to detect and classify all bounces after delivery to the remote MTA.
All outgoing mails are given a unique return-path header which, when decoded, identifies the recipient email address and the particular mailing.
An Apache James server which receives mail returned to the returned-path address.
A custom mailet, developed in Java and executing within Apache James which decodes the to address, sends the email text to boogietools bounce studio for bounce type classification and then persists the results to our database.
It works very, very well. We are able to detect permanent hard bounces and transient soft bounces which are further classified into very granular bounce types such as spam rejections, out of office replies etc.
This article is exactly what you are looking for. It is based on the great tool log parser.
Log parser is a powerful, versatile
tool that provides universal query
access to text-based data such as log
files, XML files and CSV files, as
well as key data sources on the
Windows® operating system such as the
Event Log, the Registry, the file
system, and Active Directory®. You
tell Log Parser what information you
need and how you want it processed.
The results of your query can be
custom-formatted in text based output,
or they can be persisted to more
specialty targets like SQL, SYSLOG, or
a chart. Most software is designed to
accomplish a limited number of
specific tasks. Log Parser is
different... the number of ways it can
be used is limited only by the needs
and imagination of the user. The
world is your database with Log
Parser.
You don't want to parse the logs to try and identify bounces. You will have both false negatives and false positives if you just look at logs.
Bounces might be generated downstream from the server you deliver to. They will look like successful deliveries in your outgoing server logs.
The naive pattern match for bounces in incoming logs (from the null sender, to one of your VERP-ed addresses) will be inaccurate. There are a few reasons why:
There will be delay warnings mixed in with actual failure bounces.
Most Out-of-Office and similar autoresponders use the null sender to prevent battlin-bots syndrome.
Similarly, challenge-response systems (like *spit* boxbe.com) tend to use the null sender.
Your VERP-ed sender addresses, if they are persistent per recipient, will get harvested by spammers and come back as either spam targets or backscatter.
So, sadly, the only reliable way to do it is to examine the bounce messages themselves. Most of them will have a "report/delivery-status" MIME part as per RFC1894, and depending on your language of choice there are probably libraries or modules to help with other bounce formats. The only one I have direct experience with is the Perl Mail::DeliveryStatus::BounceParser module, which works well enough.
I like logParser. When I need to parse for somthing very specific or custom or using regular expressions, I use biterScripting. They actually have some sample scripts that I used to get started. One is at http://www.biterscripting.com/Download/SS_WebLogParser.txt.
I based a bounce counter program on this post, only to find out later that this method doesn't actually work for high-volume senders because SMTP logs are not in sequential order. There's more about it in my blog post: Email Bounce Detection in SMTP Logs and Why It Is Impossible.